Slop and slack

Michael Feathers identified iteration slop as the time spent before an iteration, preparing for it, and the time spent after an iteration, finalizing the work.

On a current project, the team have been suffering with post-iteration slop. A retrospective identified some possible causes. First, under pressure to deliver the maximum business value in every iteration, very little slack was being included in the iterations. Second, iterations became overloaded because, as new information emerged about user stories through ongoing conversations with the customer, there was a tendency not to reassess the task estimates and the iteration plan, and adjust them accordingly. This resulted in user stories not being started and being descoped from iterations.

James Shore talks about the slack and scheduling problems and describes a more deeply rooted problem: "I've seen a number of XP teams that regarded the iteration plan as no more than a rough guide. They thought that, if they didn't finish all of the stories in the plan, that was okay ... 'we're agile!' ... postponing stories to the next iteration was an acceptable (and frequently used) option. The whole point of an iteration timebox is to provide a hard deadline. Timeboxes are a proven technique for helping a team focus on the really important stuff. If you're always letting stories fall over to the next iteration, you don't have a timebox at all. Slack enables you to deliver even in the face of unexpected delays."

The team is now including slack in each iteration having persuaded the customer of its importance, and the content of the slack is agreed with the customer during the planning meeting. The team is also trying to improve discipline around maintaining and adjusting the iteration plan to more accurately reflect the remaining effort. However, another cause of iteration slop, which is proving more difficult to eliminate, is a lack of ad-hoc functional testing performed in parallel with development. The end-of-iteration reviews with the customer reveal functional defects that should have been detected and fixed within the iteration.

Michael Feathers comments on this situation: "Some teams end up relying on their post-iteration slop. It may not be a conscious thing, just a little bit of decreased diligence. But, unfortunately, often that is enough to completely muddle any sense of done on the team. 'Yes, we are done', the team says at the end of the iteration, 'we passed all our tests', but the bug backlog silently increases, quality goes down and the project heads toward ruin." He suggests, "sometimes the best way of dealing iteration slop is to just slowly reduce it".

Without dedicated testers, it's up to the team to work more carefully to avoid creating defects. An added benefit is that the customer is willing to test user stories as they evolve during development. The aim in January, when the project resumes, will be to reduce the overall number of defects and, consequently, to decrease the amount of time spent fixing defects after the iteration review.


Tags: agile, extreme programming, slack, iterative development

posted by Simon Baker @ permalink
blinklist : del.icio.us : digg : furl : simpy : spurl : reddit