Name & Affiliation:

Peter Clark
pclark.net Consulting, LLC
1736 Berkeley Ave
Saint Paul, MN 55105
USA
pclark@pclark.net

Iterate, Iterate, Iterate

Position

My experience has shown me that timeboxed, story-driven iteration is the most powerful technique for managing a project with ill-defined requirements but tightly-defined schedule. It's not the only one, nor is it sufficient in and of itself, but it's the one that provides the most bang for the buck. It can also be one of the more difficult to adopt, because it forces the external stakeholders to play along, wheras techniques like test-before-code and pair-programming can be done internal to the development team. If you have to pick only one agile technique to adopt, the planning game (played often), is the one to pick. And once you get your team and customers comfortable with that one, the others come naturally.

Background:

Back in the dot-com age, I worked on a save-the-company project with a team of around 20 engineers. The project had a reasonably-clear high-level vision, ill-defined and changing priorities and requirements, and nowhere near enough time to get everything done. (Sound familiar?) The cross-functional product planning team wasn't particularly interested in software development methodologies, and was actively hostile to management practices that took time away from building the maximum number of features, even if those practices lowered overall project risk. The team initially had difficulty getting traction due to trying to bite off more than we could chew, building too much at once, trying to design in too much abstractness to accomodate the changing requirements, and trying to reconcile several different viewpoints on what the priorities were. It was a very frustrating time.

After a bit of that, we took a stab at the planning game, solely internal to the development team. We agreed that iterations would be a good thing (no small decision in itself, as it turned out), and decided to set down a very concrete set of goals for our first iteration without much input from the rest of the product planning team. We made that decision mainly to avoid having the definition of the first iteration become a political challenge.

Once that was done, we published our goals for the iteration and our finish date to the planning team, and got buy-in to proceed, while the rest of the planning team refined the business case for the product, gathered customer input, and debated requirements. When we got close to completing our first iteration, we demoed what we'd built, discussed what we'd learned, had a bunch of concrete questions about how certain features were expected to operate in the hands of the end users, and proposed following that process for the rest of the development effort. We didn't win over the entire cross-functional product planning team, but we did convince them to try it for another couple iterations. We also added in several more agile techniques, in particular using JUnit and coding tests prior to writing code, where possible. We weren't able to do that across the board.

The team shipped on time, with a product that had more in it than we had expected to be able to fit.

Our story-driven approach broke down near the end, when we had to integrate some modules from other, geographically-diverse groups who were using other development styles, and for final system integration, testing, and packaging. We could have done a better job here.

Questions: