Erik Huddleston recently wrote a provocative post on the Death of the Iteration.
He states that we mainly adopted iterations based on three (3) primary drivers:
- Cadence –Iterations represent a rhythm to the development process. Rhythm through repeated routine is a critical driver of productivity and consistency of output in any repetitive task.
- Forcing Function – The iteration, with its short duration of typically a week to a month, serves as a forcing function to drive features to conclusion. This forcing function also ensures that features are small and implementable in a reasonable amount of time.
- Synchronization – Most importantly, iterations form a natural synchronization point for stakeholders both upstream and downstream to the development process. Small iterations reduce the risk of defects and environmental instability and shrink remediation times for defects by shortening the time that between when a change is introduced and when it can be put into a production or simulated production environment.
So why do iterations need to be laid to rest?
- Iterations are an unnatural concept – As the name implies, iterations are an arbitrary time slice…a line in the sand. This leads to all sorts of technical and logistical gymnastics, that often have more drawbacks than benefits.
- Iterations encourage the introduction of Technical Debt – The “unnatural” and arbitrary sprint end deadline creates a few interesting behaviors in developers. While the forcing function nature is great, it puts enormous pressure on developers to cut corners to meet the team commitment.
- Iterations hurt your developers self esteem – The sustainability goals of Agile are well known and critical to long term productivity of an development organization. While the velocity metric provides a defense to burnout, the iteration introduces a couple of critical cancers to development health.
This leaves us with iteration-less development. Benefits?
Erik tells us the benefits include:
- Iterationless development gets rid of the tyranny of the iteration end. This opens the door for developers (and the organization) to execute at the optimal sustainable cycle time.
- Cycle time has the opportunity to be reduced by removing the cycle time tax incurred by the timeboxed “boxcar” of requirements.
- Requirements and prioritization changes can take place at any time, without causing consternation with development. WIP is much smaller, limiting the likelihood of a requirement change impacting an active development activity.
- It opens up opportunities for more diverse team organization functions like place shifted (remote) and time shifted (multiple time zones or work schedules) development.
So, what are your thoughts on this? Seeing as though there are literally TONS of books, articles, blogs, and research that support the value of iterative development, this certainly seems either anti-establishment, idealistic, foolish, or maybe revolutionary.
What do you think?