Why develop iteratively at all? Well, clearly because it gives us more frequent feedback loops.
Developing a small chunk of the solution allows us to get an early indication that it is evolving correctly, getting closer to the business’ need.
But for iterative development to be successful, we need to ensure that our timeboxes are of a suitable length, and that we pause at the end of each timebox to review progress.
So how long should a timebox be? The rule is “between 2 and 6 weeks with a preference for the shorter timeframe.” Why is this? The optimum timebox length is a compromise between rapid feedback and having sufficient time to develop a demonstrable part of the solution, which can depend on many factors like team size, technology, solution complexity and how it is integrated with the rest of the code base. I personally prefer two week timeboxes, but others prefer three.
In Atern, timeboxes are structured as follows:
* Each timebox starts with a kick-off workshop, during which the team select which requirements they need to deliver, and re-prioritise them for the timebox. Every included requirement needs to be fully understood by the whole team at this time, although not all of the work required will be completely clear. At this point the team (re-)estimate the relative size of each requirement and verify their velocity. The timebox is then broken into three distinct parts :
* Investigation – 10% – 20% of timebox length is spent going into the detail of each requirement to be included and planning the work required to satisfy it. There needs to be a brief review at the end of this to validate the estimate made when the timebox kicked off.
* Refinement – 60% – 80% of the time is spent evolving the solution in line with the priorities set at the timebox kick-off. At the end of this there is a brief review to determine what has been completed and what work is still in progress. This allows the business to prioritise work in progress so that the most useful features are completed at the end of…
* Consolidation – the final 10% – 20% of the timebox during which as many requirements as possible are completed and accepted by the business. Work that cannot be completed in time may need to be temporarily abandoned so that other work can be completed.
Each timebox concludes with a close-out which comprises two parts – a demonstration of the solution as it has been evolved so far (during which the business accept what has been delivered and identify any weaknesses or omissions), and a retrospective in which the team look back on their performance. More on demonstrations and retrospectives in later posts