I read this post today about “iteration zero.” It’s a pattern I recognize well.
In fact I’ve been going through a lot of iteration zeros lately. I think the preliminary work, including team selection, tool choice and setup, development environment installation, build and test process, etc., can be a significant factor in the success of a project. Part of the idea of adopting Agile is to help define those processes and types of tools, if not the actual tools used.
There seem to be certain brands of Agile that go hand in hand with certain tools, such as a Java shop with Tomcat + Spring + Hibernate + Junit + Hudson + Confluence + Jira or a Ruby team with Rails + Macs + Basecamp + CruiseControl.RB + FireWatir, etc. Since certain experts (often the authors of specific tools) are strong advocates for their methodology, it’s no surprise that users of specific tools adopt a similar stack and brand of Agile.
I think we’ve learned, if nothing else, that the term “Agile” and the definition of an agile process is slippery enough; much to the chagrin, no doubt, of the Agile “thought leaders” — who are probably as responsible as anyone else for the difficulty in pinning it down. Part of iteration 0 is pinning down agreed upon definitions, but the important part is being able to create your “Hello World” using the tools and process decided upon.
Of course, each time a team repeats the process, it gets easier. That’s the secret of a good agile team. But the reality is that most teams aren’t static, and not surprisingly, neither is the technology. If it were, I think a lot of developers would be looking for different jobs. It’s the challenge of learning something new that appeals to many of them, myself included.
But there comes also time when you just want to “get ‘er done”, and that’s when the iteration zero becomes a pain. Usually that’s a good sign, because it means you’ve got a project you’re interested in working on. I said earlier that a good iteration zero was one contributing factor to success. I think the other major factor is interest in the project. Developer interest doesn’t always transfer to customer interest, but it’s a pretty good substitute.
So what am I most interested in? I’m interested in the interation zero. In finding the tools and process — for testing yes, but also for development, deployment, and project management — that best contribute to the success of projects. Of course, that’s different for everyone, but there should be commonality, and much like Agile, I think there are good and bad patterns to be aware of.
My idea of a “QA Site” (a term I’ve never been completely satisfied with, but have stuck with) is to make iteration zero as painless as possible. To reduce the ramp up time, and to build out the necessary infrastructure as quickly as possible, but keeping it lightweight (so it doesn’t become burdensome) and flexible (so it doesn’t bias to one set of tool preferences.) To recongnize that there are both principles and preferences, and to not confuse the two. I realized that I’m in the business of “Iteration Zero”.
I don’t think enough development shops would consider QA part of iteration zero. Most shops say “Hey, looks like we might finish this before long. Let’s do some QA.” What a concept to think about code quality up front!
I see the iteration 0 challenge with many of my customers before they adopt our very lean platform that incorporates everything you need to deliver a new (web based) application using Agile methods. If you are building web apps go take a look at some of the demonstrations of our Agile Platform – http://www.outsystems.com/demos – seeing is believing.