Prototypes can actually be functioning results or code in Agile, that’s really the strength. Put real working code in front of people, learn and iterate. It’s a balance between investing to much time in code when something can go faster on paper, but paper based decisions are just that, paper based and not interactive based. 

Sprints can vary in size, they definitely don’t need to be 30 days and sometimes teams benefit from 1-2 week sprints. It’s hard to go from a traditional approach to smaller sprints, but as teams get more comfortable I’ve seen sprints get shorter. Iterations are the opportunity to improve, but it’s harder to improve mid-sprint. 

Greetings from Holland.

I like the idea of dedicated team members focusing on projects at hand, and not jumping from one project to another, which is what often happens in a corporate environment, and slows down development.

Some aspects remind me of the days when I worked on interactive media projects with the Human Element/Allen Interactions. A studio (group of team members) focused on my projects, using rapid development, prototyping, and usability testing of parts of the project – parts that were representative of the whole project … to confirm design and interaction met the goals… before implementation through-out the project and completion.