A less obvious benefit of Iterations

In Tiny projects keep it new, Jason Fried of 37 Signals talks about the cycle of waning interest as long projects lumber on (“No one likes being stuck on a project that never seems to end”), and the power of small projects to keep motivation up by presenting frequent fresh starts.

On the surface, this is one of the benefits of the Agile practice of breaking work into iterations/sprints/episodes. Every few weeks, the team gets a start fresh. Now this isn’t quite true, as many who have been on Agile projects for more than a year will tell you: Runs of iterations with similar themes can get monotonous. Still, the cadence of doing work in discrete iterations, and the frequent customer feedback this enables, can help team members stay engaged for much longer than they might on a long waterfall project. And iterations provide natural stopping points for rotating developers between teams, which keeps things fresh by spreading knowledge around.

Iterations have another, less obvious, benefit: They reduce the opportunity for people to get dangerously ahead of the rest of the team by latching on to interesting technical bits that appear somewhere out ahead on the project roadmap. I’ve seen this happen over and over in long waterfall projects. Someone sees a technical challenge that will have to be solved eventually, rationalizes that starting on it now will “reduce risk”, and then pours time, effort, love, and raw ego into the problem, making architectural decisions that the rest of the team comes to feel constrained by and resentful of later. And if the project makes a mid-course adjustment, the “risk reducing” cherry-picked work can end up being expensive waste.