Do you use Iteration Zero for your agile projects? An Iteration Zero is an iteration where you set up all the servers, make sure you have a release plan, develop a product backlog, and in general do all those things that “assure” you that your project is ready to go.
Some agile project managers do, some don’t. I’m not a huge fan of Iteration Zero, because I’ve seen Iteration Zero turn into turn into iteration minus one, iteration minus two, iteration minus three, and so on. And, then, the architects step in, and then next thing you know, you’ve got Big Design Up Front. If it takes two or three months to start your agile project, your Iteration Zero is not working for you.
But there are times when Iteration Zero can help your project or program.
You Don’t Have Even a Hint of a Backlog
One of those times is when you don’t have a backlog at all. Now, you might be raising your eyebrows, and wondering how you can have an agile project without a backlog. But maybe you are like my colleague Jackie, who described her new project and her new Product Owner, Bill to me.
Bill has never been to any agile training. Luckily, the team was willing to give him the benefit of the doubt, since he is so sincere about wanting to the right thing for the product. He has a ton of experience in the product domain. So, I asked the team if it was okay if we did a 5-day Iteration Zero to immerse Bill in user story writing and helping him see what a walking skeleton would look like.
He was so impressed. He’d never seen a team work like this before. Sure, his first few stories were epics, but once we worked with him and explained how to write smaller stories, and then showed him the results of the stories. He was a total convert. And, we didn’t have to send him away to learn how to work with us.
We might send him to training at some point, but it’s been five iterations now, and he’s in the groove. That five-day Iteration Zero was on-the-job training, and totally worth it for the entire team. We generated a ranked backlog, showed him a walking skeleton, and integrated him into the team.
You can use Iteration Zero to create a ranked backlog and a walking skeleton when you have an experienced team. You might try this approach even without an experienced team.
You Have a Team Who is New to Each Other
In fact, that’s what Stewart did. He had a brand new team, who’d never worked together before. They had no idea how to estimate together, since they had never worked together. Instead of trying to estimate what they could do in an iteration, they decided to take what the product owner claimed were five of the smallest possible stories, and attempt to finish them in a five-day Iteration Zero.
We started our Iteration Zero with a five-story ranked backlog. We had no idea if we could complete the backlog, but we knew that we would gain experience working together, and we would learn what the Product Owner thought was a small story. We thought that was a great investment for a five-day learning.
We swarmed around each story as a team, because how else would we learn to work together? We got through forming, storming, into norming pretty quickly! By the end of the week, we had finished three of the stories, so we learned about our Product Owner. His stories were too big! But we also knew how to help him make them smaller. And, we learned how to estimate together, because we learned how to work together. And, we had running, tested features. Not bad for a five-day Iteration Zero.
You Have a New Environment
Sometimes, when you have a new environment, such as a new compiler, a new type of computer, a new language, the team has no idea how to accomplish anything. In that case, use Iteration Zero as a way to do a Hudson Bay Start. Do just one small feature, from start to end, to make sure everyone knows how to use all the tooling. It doesn’t have to be a big feature—in fact it should not be a big feature. But this way everyone knows how to use everything in the environment, as my friend Colin says:
We used a three-day Iteration Zero to see if we could finish one feature, from soup to nuts. Imagine our surprise when we finished two features in three days! We refactored our test automation from nothing into something that runs with the build system. That way the testers can spend their time on exploratory tests, not just building automation.
You Have a Geographically Distributed Team
You don’t always need an Iteration Zero with a geographically distributed team. But if you are not sure if everyone has the same tools, you might decide to verify that everyone’s tooling works the same way in an Iteration Zero. Or, you might decide to test the communications tools, or the way the communications flow will work. Or how you will move the stories across the board, whatever the board looks like. Giving people a chance to practice and experiment in a short time helps them be more successful in the first iteration. And, you don’t have to wait for an entire iteration before you see problems to fix them.
Lauren, a project manager whose project spanned three continents explained her situation. “Not everyone could access the source code, so we had to change permissions. We had to get people access to virtual machines so they could compile and build, and even then, their machines were too slow. But, at least I knew it was an impediment, so I could track it and fix it before the first iteration. And, some bozo had set the mail servers to only check and send email once an hour. It’s a wonder I still have hair—it took me forever to figure out that one. But imagine if we hadn’t tried to use our Iteration Zero as a Hudson Bay Start. We would have all wondered what was wrong with “them,” all the other people on the project.
There was nothing wrong with the other people. It was all infrastructure problems. Everyone was working as hard as they could. Sure, some people were a little unclear on how you take a card from our board and move it. But I can deal with that. Our organization was so focused on saving pennies, we were wasting valuable dollars of people-time.
What not to do in Iteration Zero
So now that I’ve suggested things you might do in a short, say three-to-five day Iteration Zero, here are things you should never do in Iteration Zero:
- Never predict the duration of the project. You can accept a fixed schedule from your sponsor and work within that. You can try to predict the entire length of the project. But you will be wrong, because the product backlog will change. And, since this is agile, this is good! Remember, agile is all about embracing change, and iterating once we see the demos, right? So, don’t ever bother trying to predict the project duration. Certainly, don’t try to predict at the very beginning of the project. Wait until you have some data and experience with the team.
- Never predict the budget. You can accept a fixed budget from your sponsor and work within that. Because budget is related to date, the same arguments exist. If your sponsor wants to fix the budget and the date, your product backlog is the one thing that will change, because the team has to get to done, right? There is no negotiating on done, right?
- Never try to define the architecture as a framework or frameworks. Unless you have already implemented some features, your architecture work will be wrong. You need experience with the features to know what architecture framework or frameworks you need. You cannot tell in advance. This is more prediction and we know from experience that prediction for projects rarely ends well. If you know the marketing constraints for your architecture, sure, define that, but not the frameworks.
Iteration Zero is not for prediction. Iteration Zero is for learning and gaining experience.
My Iteration Zeros are shorter and shorter these days, and deliver features of some sort, possibly a very small feature or two or three, but a feature. And, once the team sees that they can deliver small features in a three-to-five day time, they are much more likely to down-size their stories, work together as a team and reduce their work in progress.
You don’t have to eliminate your Iteration Zeros. Just make them work for you, not against you.
Note: If you want more information about a Hudson Bay Start, see Manage It! Your Guide to Modern, Pragmatic Project Management.
© 2012 Johanna Rothman. This article was originally published on Gantthead.com, October, 2012.