Although many people consider iteration to be a key characteristic of agile software development, some question whether or not they're important, and add value to an agile method, or if they're superfluous, or even wasteful. InfoQ has assembled a roundup of arguments on the subject, to help agile teams decide if iterations are important for them.
On the lean-agile-scrum mailing list, jdmcauliffe2002 asked:
We know that Lean tells us to do things differently, to use flow better. If we had a backlog of items that were sized, what if we didn't take the time to fully estimate them all for the iteration, and instead just pulled the top story and then do the work (plan, detail estimate, design, code, test, accepted). Once we were done (accepted) with this story, move onto the next item in the list. Wouldn't this be a more efficient and lean way to do it?
Liz Sedley responded:
A lot of people are getting rid of sprints, including Yahoo and David Anderson.
I think it definitely would eliminate waste. Here are some other things I think you need to make sure you don't eliminate:
- Celebrate success.
- Inspect and adapt.
- Planning at the level your manager requires.
- Sustainable Pace.
Max Guernsey III suggested that it might depend on discipline of the team:
Sprints are also a powerful political tool. They are an easy to understand unit of time against which the amount of work can be measured. You can see velocity go up and down. Now... you can also do that with regular weeks, months, years, or days. Sprints have one other important political aspect: they give you a clear way of telling whether a team has succeeded and failed.
Once the resistence has been broken down - once the organizational transformation has been completed - then it might make sense to shed some of the rigors of Scrum in place of a more fluid process. Until that point, you need things like sprints to bring order to the undisciplined, to quiet the fears of the unconvinced, and to shield those who really are trying from the subversive political maneuvers of those who never will.
Other people have raised these concerns. Aaron Sanders, in Naked Planning Explained - Kanban in the Small described:
The idea of the variable length Product Backlog with the need to reorganize priorities and estimate size was replaced with a fixed-length queue placed on a whiteboard for the Product Owner (Customer) to fill with Minimal Marketable Features (MMF), or what in Scrum would be User Stories. The length of the queue is seven, as this is believed by Arlo to be about the maximum amount of items any one person can hold in their head at a time. The slots are marked with permanent marker. Since the Product Owner trusts the team to do the work, the team believes these features to truly be: minimal, as anything less would not be marketable, which has immediate value for new or existing users.
The customer is allowed to rearrange these 7 MMFs as often as is seen fit. When the team is ready to pull a new feature, it is whatever is currently at the top of the stack. The 7 MMFs must fit to one of two goals on the board. When entering a hew feature, the customer determines if the completion of remaining MMFs in the queue would satisfy the goal. If so, a new goal can be added to the board and if not, another MMF to satisfy the goal is added. There is one expedite slot for the customer to override WIP, anything else has to wait for a slot to open.
Releases can occur any time any one MMF is finished, as there is an ability to hide Work In Progress on the production site. The customer also has an idea parking lot for the overflow from these 7 items, or for other goals. An approximate wait time of when a feature may be released is added to the bottom of the board. MMFs are dated when they are placed on the board, and when they are finished to derive the average time of a feature. Significant changes in the size of work which effects throughput trigger a recalculation of this lead time. Arlo calls it the “approximate Disneyland wait time”, and is a statement such as, “Your expected wait time today from this point is between x and y days.”
Amit Rathore proposes, on his blog:
Reduce iteration lengths to zero. Do away with the artificial construct altogether.
- Ensure business analysts work with product-owners and stake-holders to maintain a constantly prioritized list of user-stories.
- Ensure maximum effectiveness of the development team by allowing business analysis, and tasking, and development to occur in a just-in-time manner.
- Showcasing product, conducting retrospectives, and taking breaks should occur whenever needed!
Mary Poppendieck's article on Managing the Pipeline describes the importance of cadence, which could be difficult to achieve without iterations:
In a lean factory, every process is runs at a regular cadence called ‘tact time.’ If you want to produce 80 cars in 8 hours, you produce 10 cars per hour, so one car rolls of the line every 6 minutes. In software development the recommended practice is to establish an iteration cadence of perhaps two weeks or a month, and deliver small batches of deployment-ready software every iteration.
A regular cadence, or ‘heartbeat,’ establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.
A regular cadence also gives inter-dependent teams synchronization points that they can depend on. Synchronization points are good places to get customer feedback, they are useful for coordinating the work across multiple feature teams, and they can help decouple hardware development from software development.
Another way to think about an iteration-free process is that each feature might have its own feature-sized iteration, worked on in isolation, possibly using feature branches:
A feature branch is the sort of branch that's been the dominant example in this chapter, the one you've been working on while Sally continues to work on /trunk. It's a temporary branch created to work on a complex change without interfering with the stability of /trunk. Unlike release branches (which may need to be supported forever), feature branches are born, used for a while, merged back to the trunk, then ultimately deleted. They have a finite span of usefulness.
Some might argue that this approach doesn't truly shed iterations, it simply redefines them as feature-scoped and parallel, possibly not so different from the parallel iteration approach described for use in complex projects.
Many agilists and those who describe themselves as post-Agile would suggest that each team decide for itself which processes are important and useful, and which aren't. At the very least, the arguments suggest that you might consider whether or not iterations are useful for you, and your teams. That is: do they add value, or are they waste, to be discarded?