A Post by Erik Huddleston RIP: The Iteration 19?? – 2010 came across our desks last week, and it sound’s like he’s pretty serious in thinking that Iterations are a thing of the past. Please give his post a read before you continue onward here. You might also want to look at CBQ’s posts on Iteration Based Contracts and What Makes a Successful Iteration, as well as mine on Communicate early, Communicate often, but don’t repeat yourself!.

Erik should definitely use whatever tools and methods work for him, but at Highgroove, we love doing iterative development, Pivotal Tracker makes it easy to get it right, and we wouldn’t have it any other way! First up, some rough thoughts from some other team members:

They sound like they adhere to a script even when it isn’t working.

Adopting a “pattern” for the sake of using patterns has never been a good idea. Being an “Agile” developer is more about being Agile with your processes than using “Agile” processes.

They’re just abusing developers in another way and finding another way to make them miserable.

If something is forced on a team that makes people unhappy, productivity will go down and quality will suffer.

They’re clearly in an environment where developers aren’t smart enough to accept responsibility.

Everyone on a team has to be willing to stand up for themselves and for doing things the Right Way. If a company culture or manager blocks out this kind of feedback, or developers aren’t willing to speak up, it’s probably a sign of an Office Space sequel in the works.

Some of those are a little coaxed and are a bit harsh, but I think the underlying feeling is pretty accurate. Here’s some specific counter-points to Erik’s arguments.

Iterations are an unnatural concept Iterations are a very natural concept, each week the team and the stakeholders agree on what they’re going to get done in the upcoming iteration, and the past iteration is reviewed. Businesses have held weekly “status” meetings for a very long time, and the tick of an iteration is only different in that it actually has an agenda, action items, and results in value being added.

Iterations encourage the introduction of Technical Debt Iterations let teams focus on things that matters the most to stakeholders and get those features fine tuned and delivered before spending time on less important things. Especially when other agile tools like code reviews are used, this leads to extremely high quality code at every stage of a project. Overcomplicated systems can’t be built because there are automated tests, multiple eyes on the code at all times, and any mistakes in code or architecture can be caught very quickly and fixed before 2 months of time is spent on them. “Release Ready code at any time” is a feature of iterative development, not a requirement.

Iterations hurt your developers self esteem Iterations are great for developer self esteem. We end our iterations on Tuesday night at Highgroove which makes any hint of a crunch time come on Tuesday instead of Friday or the weekend. If stories aren’t completed in an iteration, there is no attempt at catch up in the next iteration. In the iteration retrospective/planning meeting, we look at what went wrong and re-estimate/re-prioritize stories with the client so that the next iteration is successful.

Requirements are always constantly changing, but a developer only needs to focus on what the next few stories are, so a very tight feedback loop with clients is actually desired. A client saying “Hey this needs to get done next” results in them prioritizing what they want to happen next at the top of the list. This means that other things get pushed down, and when using a tool like Pivotal Tracker, its obvious to everyone where things are going at any moment.

As a developer, I’m extremely happy doing iterative development, and wouldn’t have it any other way (and can’t imagine working any other way).

Iterations increase cycle time and decrease predictability The only reason that iterations may appear to slow progress or add uncertainty is because they force complete exposure of functionality a client has in mind, capture time spent on that “just one more thing” that clients ask for, and capture the time spent on the “oh this will be super quick and easy” that developers mistakenly promise for complex features.

Here’s a great example of the progress over ~10 iterations on a project that went extremely well, where both the developers and the client were extremely happy at every stage of the project.

The initial number of ‘points’ was around 160, but as the project progressed and functionality needs clarified, the total number of points approached 375. New stories were constantly being added and re-prioritized.

We estimate projects in a rough range of iterations (5 to 8 for example) so clients know what to expect. When clients communicate well and have a lot of input in the prioritization process, we often hit the lower end of our estimates, and when clients realize how quickly we get work done, some choose to add in more functionality than was in the initial estimate to make full use of the maximum number of iterations we can offer them. Highgroove is in high demand so most team members are scheduled to start new projects the day after their last project ends.

Looking for someone to build a product or service for you? Highgroove would love to iterate on it and make you wonder why you’ve ever spent money on development any other way. Let us know!