A recent thread on the Yahoo! Agile Usability group (click here for thread) confirmed what I’d been seeing for a while – that the best teams will do Iterative and not just Incremental development.
For those of you not clear on the distinction the quote below is taken from Wikipedia:
“Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. It does not presuppose incremental development, but works very well with it. A typical difference is that the output from an increment is not necessarily subject to further refinement, and its’ testing or user feedback is not used as input for revising the plans or specifications of the successive increments. On the contrary, the output from an iteration is examined for modification, and especially for revising the targets of the successive iterations.” (click here for the wikipedia page)
Jeff Patton’s Blog also has some really great stuff on this…the Mona Lisa picture is a great visual representation of the difference between the two.
The problem is that lots of customers (product owners) and development teams start out thinking they have a very clear idea of what they’re going to deliver and then they chop this up into chunks of development time – time boxed Iterations. Now the problem is that teams say they’re doing Iterative development because they develop in Iterations but in fact they’re simply incrementally delivering a solution set down at the start of the project.
Not only does this require a lot of upfront work to get this “clear” definition (I know customers that spend £150k plus on detailed screen designs) but when the customer needs change what they want (and they will…you can lay money on it) the clear definition of the solution the team were incrementally delivering starts to become less clear and the team then struggle to deliver what the customer needs because they’re not used to really iterating a solution. They also have some subset of an overall solution they were building towards that is often not amenable to changing to do something different.
So RUP and more recently XP/Scrum and the Agile methods have got development teams doing Iterative development which is definitely a good thing. The problem is that, without the right management support, the pressure is put on teams to “get stories done” and to “increase velocity”. It seems to force teams into getting the work done with the least amount of work and reduces/removes the ability for the team to iterate through a solution and delivery that truly astounding product.
So firstly you need the right management support in place to really make iterative development work properly.
Secondly factor into a project an amount of rework to give yourself the time to iterate through the solution and refine the product you deliver. Also factor in some rework the User Stories, MMF (or whatever you call them) that have usability aspects to them…the bigger the story the more time to factor in.
Finally, consider a more Kanban style of development where there aren’t explicit development iterations but the cadence is set by the release cycle…I’ve got an upcoming post on this subject. I’ve found this helps teams that have struggled with trying to break stories down into smaller parts simply to fit within the iteration length which is artificial, takes time and removes the focus of the team on the real thing they’re trying to deliver to the customer down into a focus on the smaller parts…leading to incremental not iterative development. Without having to worry about development iterations the team has more freedom to iterate through development and only release the software when it’s what the customer really wants.