Alister Scott‘s post on Incrementation vs Iteration was doing the rounds at work with some comments, and I felt the need to comment.  I had a couple of attempts at responding to this.  It’s a big topic, but to some degree I think iterative vs incremental is a bit of a distraction as a general philosophical discussion (and I *love* philosophical discussion, so I am not meaning to be dismissive).

I think it’s more important to ask –

– What is our plan for validating the product definition?

– What is our plan for validating the architecture?

– How does the organisation want to ‘manage the work’.

– As a team, how will we know when our work is ‘good enough’?

– As a team, how do we plan to manage incomplete work (ie. future enhancements and defects).

The first two are probably the biggest factors of uncertainty that will drive the degree of iteration vs incrementation.

The third is a question relating to the organisations belief systems around predictability of software projects and how much power management wants in designing work methods to support their agendas.

The fourth question will shape how actively the team works against ‘doneness’ by finding bugs, soliciting feedback and exploring the solution space throughout the iteration.

The last question is about how the team wants to manage defects and backlog.  If you don’t want to carry bugs and want to minimise backlog management, my experience is that the sprint needs to plan for internal iteration (or you need to get rid of sprints/iterations and go with a pull/dock assembly approach).

The most important thing is understanding why we iterate.  Alister highlights a couple of examples when he talks about time to market vs user experience prioritisation, but it’s only sensible to talk about iteration in specific contexts of uncertainty and risk management.  Similarly, we discuss incrementation in the context of the cost/benefit of a particular release approach and/or schedule.