Image via Wikipedia
For release 4.0 of V-Commander, the team voted to change our iteration length from 3 weeks to 2 weeks. There were a number of reasons for running this experiment, including:
- addressing the slight lull that we experience in week 2
- reducing the length of planning sessions and having the ability to plan in shorter time frames
- introducing a change to shake out any issues that are hidden by 3-week iterations
As a team, we have mixed opinions as to the result of the experiment. I would say it was successful but not a home run, though there were some unexpected results that lead others on the team to draw a different conclusion.
Of interest, we observed the following:
- less work in progress: the shorter timeline and reduced number of stories made us more aware of when stories were dragging and we had greater visibility when our work in progress was too high. a large part of the decrease in WIP is because of the next point.
- increased collaboration: because there were less stories required in the iteration, team members became much more aware of when others needed help and there was a marked rise in the collaboration to complete stories quickly. we have always been good at helping each other and the shorter iteration provided additional structure for us to do so.
- slack: if we had too much WIP and someone was coming free who was unable to help on an open story, this time was often used as slack to address escaped stories bugs, team infrastructure needs, product management estimation requests, or customer engagement and support. I’m not sure if this was entirely related to iteration length or was also related to the time frame for this release.
- increased feeling of pressure to constantly deliver: while the shorter time frame introduced slack, the nearer iteration end dates also forced us to consider the impending deadlines. this pressure is something we largely put on ourselves, but it was reinforced with the 2-week heartbeat.
- greater sensitivity to vacations and sickness: if we had a large number of vacations (e.g. March Break) or a number of people got sick at the same time, we had less time in the iteration to recover. over time, I think this averages out, but the drop in completed work for that iteration had a demotivating effect.
- greater sensitivity to support issues: there were a couple of iterations where a major support issue reduced capacity in the team by 10+%. as with vacations and sickness, there was less time to recover in a 2-week iteration.
- more noticeable impact of iteration stop and start: iteration kickoffs and completions interrupt the flow of development as team members overcome the static friction of starting new stories at the beginning and wrap up everything in advance of the demo at the end. the reduced iteration length introduced more of these stop-start cycles.
- faster kickoffs, demos, retrospectives: since there was less content in the iteration, each of the ceremonies took less time to complete, which generally resulted in higher-quality and more-focused meetings.
- unnecessary retrospectives: there were some iterations where nothing out-of-the-ordinary occurred so some retrospectives where short and even unnecessary. the solution was to skip them for some iterations , though they were starting to get stale even with this modification.
We will re-evaluate our iteration at the end of this release.
- Selecting the Right Iteration Length for Your Software Development Process (Mountain Goat Software)
- Ideal Iteration Length (InfoQ)