Avoiding Iteration Zero
Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with
- A list of features to be built
- A release plan or timeline for those features
- Setting up development infrastructure such as version control or continuous integration servers
- Studying or practicing skills in new technologies they expect to use
- … and other management, infrastructure, and technical endeavors.
They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.
The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.
And we’ll have burned an iteration without producing any working software that tests our decisions.
My advice is to borrow an idea from Lean and look at the situation from the output point of view. Ask yourself, “what would it take to start delivering?”
The initial backlog really only needs to be one item in order to start delivering. If you’ve got too many unknowns, then just start with one item. Get the business stakeholders, the programmers, the testers, and anyone else who needs to be in on the discussion (User Experience? Ops?) to talks about it. (I call this a meeting of the Three Amigos.) What is the one obvious thing that needs to be done? (Hint: it’s not “login.” Start with the main purpose of the system.) I can’t imagine a situation where a project is started without any ideas at all.
Take that one thing, and slice it into thinner slices. Decide on the examples that represent acceptance of those slices. Some of the slices will have questions that can’t be answered. Put those aside for the moment. Choose the most central slice that travels through the entire concept from end to end, or as close to that as possible. Estimate that as one team-iteration. (Estimates don’t have to be “right.” They’re just estimates.) Start building it.
Learn the necessary skills in the technology while accomplishing real work. Learn the parts that aid building the system, rather than developing the system according to some framework. When you don’t know how to accomplish something, or you think multiple approaches might work, do minimalistic spikes to give the information needed to make a decision.
Along the way, start slowly building your development infrastructure. Set up a local code repository. You can always migrate the code to an “official corporate” repository later. Right now, there’s not much code. Set up a simple build-and-test script so that everyone builds in the same fashion. You can always add other build targets later. If you’ve got time, you can set up a Continuous Integration server. Otherwise, just do it manually. Checkout & build into a clean workspace. Do what’s needed to run the code so that you can show it working.
If you can’t accomplish this slice in one iteration, it’s probably not thin enough. Or, maybe you haven’t yet solved an essential technical problem. Or the goal isn’t yet clear enough. Figure out what impediment is most in your way, address that, and try again.
More likely, you’ll get this slice done in less than a iteration length. If you get this slice done before the end of the iteration, then pull in another slice. Estimate this as “the rest of the iteration.” Repeat as needed. As long as you’ve gotten one slice done, you’ve got a potentially deliverable product increment.
Yes, there will still be development infrastructure to be developed. There’s no particular rush to get that done. Just keep improving it, so that it helps you get more done. Yes, there will still be technical skills to be developed. That should always be the case. Just keep experimenting and pushing your limits.
Yes, there will still be features to be added to the backlog, refined, prioritized, split into stories, and prioritized again. This should continue throughout the project. It’s part of the “steering” process. Yes, there will still be a need for projections to estimate when functionality can be released, or how much functionality can be released by a certain date. When you think you’ve got enough information about what needs to be done, then consider the initial release plan. By then you’ll also have accumulated a little information about how fast things get done.
There will still be a lot of holes in your knowledge of what needs to be done and how fast things get done. Don’t trust your initial release plan to be “right.” It’s just a stick in the sand to help you judge how things are going. Keep planning, and move the stick as needed. And as time passes, you’ll have a better and better indication of how fast the system gets developed. Even when you think the Release Plan is complete, it needs to be continually reviewed and adjusted. Since it’s never done until the release, there’s no particular hurry for a certain level of completeness.
This sort of beginning is very like the Hudson Bay Start that Johanna Rothman describes in her book, Manage It (pp. 52-53).
The Hudson Bay Start approach was originated by the Hudson Bay Company in the 1600-1700s in northeastern Canada. The Hudson Bay Company outfitted fur traders. To make sure the traders hadn’t forgotten anything they needed, they left Hudson Bay and camped just a few miles away. By making camp just a few miles away, the traders ensured they hadn’t forgotten any tools or supplies–before they abandoned civilization. With just a short start to their journey, they had a better idea about their ability to endure the winter.
There’s really no reason (other than “that’s not the way we do things around here”) that this can’t work for the start of any team/project. It’s a great way of learning the right stuff for the current situation while also making a bit of progress. I use this technique in my Agile in Six Months transition plan.
Well said and I agree totally for new development.
I’m curious, though, how you would apply this to an existing group transitioning to Agile? There is a legacy of up-front schedule or cost commitments, existing toolsets and practices geared towards serial development cycles and the perception that requirements must be elaborated at least at a high level and estimated prior to start.
As I said, the only reason it can’t work is “that’s not the way we do things around here.” Perceptions about what “must” be done are a big hurdle. Change is hard within groups of people.
I would still start with asking “what would it take to start delivering?” Many of the existing toolsets and practices may be just fine for a starting point. You can adjust from there as you go. If some of the practices seem obstructionist, try just dropping them. Try something simpler if they also provide benefit.
As for pre-existing schedule and cost commitments, I wouldn’t worry. Either they’re reasonable or they’re not. As you start to build a track record, you can do some forecasting and figure out which they are. You’ll have a better understanding sooner than with pre-planning before building that track record.
If the schedule or cost then looks out of whack, deal with that fact then.
Great article George. I’ve had many a discussion on this very topic and it’s quite contentious.
You say to not worry about a version control or a continuous integration server at the beginning. I agree however at some point the team that doesn’t have these will need them. Won’t they negatively effect their velocity in post-Iteration 1 because doing this work will mean they are not creating business value functionality?
Dave, you’re right that building the development infrastructure will impact velocity. As the developers catch up with this, then their capacity for work delivering business value will rise. This means that the initial estimates of how fast things get done should be rather conservative.
This gradual getting up to speed is, in my experience, preferable to trying to accelerate instantaneously. You can plot the velocity over time and see where it start leveling off (giving you more confidence in your projections) or doesn’t (giving you cause to look around at what’s happening).
In either case, the gradual approach while delivering business value should not take more time than trying to do all the “getting ready” and then trying to do all the business value. In fact, part of “inspect and adapt” is doing more “getting ready” throughout the project. We might as well start practicing that at the beginning.
Right on point here George. +1
I appreciate the focus on delivering, with all else as details. Well said, and great that you pointed out Johanna’s mention of the ‘Hudson Bay Start’.
Great article! But there are many agilists who still believe in the mythical Sprint 0 which they think will solve all problems and make the team ready to work bang on!! Thats really sad and combating these people in an organization is really tough.
Hi, Lata. I noticed your use of the word “combating” and think that it might indicate an ineffective tactic. In general, people are doing what they think best. They may resist some other notion because they’re afraid of losing something valuable to them. Dale Emery’s article, Rewriting the Story of Resistance illustrates this well.
I’m taking the opposite position on this. Firstly, you’re assuming that the only type of deliverable is source code. Not true. Documentation, analysis, data, charts, graphs, epics, stories, etc. are all deliverables. You will need some of these things in place to get started.
As for the Hudson Bay Start, I don’t like the comparison to software development. The Hudson Bay team had the option to return to base, re-group and re-start. Do agile teams have that luxury? If so, is the next iteration called #2 or a repeat of #1?
We need to focus on making progress not defining iterations.
Hi, Vin. Thanks for taking the time to comment.
I certainly agree that some documentation is a deliverable. But other documentation is simply created as a communication medium during the development process. And to whom are you delivering analysis, data, charts, graphs, epics, and stories? These are intermediate work products, not deliverables.
I certainly agree we need to focus on making progress. We need to focus on making actual progress, not the illusion of progress by creating internal artifacts.
Documentation (of which graphs, spreadhseets, etc. are a type on a software development project) are for two actual reasons IMHO: 1) to allow a team to think through a problem, issue, or design (these possibly can be thrown away) or 2) to communicate some issue, solution, or design to others – preferably still in a face-to-face environment. Things like financial reporting, status, etc. fit intot the “issue” category for me. So I see them like George, intermediate work products in a software development project.
The only exception may be user documentation/training or operations manuals, but if a goal of the system is to be ergonomic, these should become very thin to almost non-existent, since my experience is no one reads them anyway.
Yes, Paul. You’ve reminded me of a previous post on documentation: http://blog.gdinwiddie.com/2010/08/06/the-use-of-documentation/
Great post George. Although not coming from the perspective of a complete startup, I can certainly agree with the point that it is ineffective to do too much decision making and planning up front. In my experience many of the requirements driving the solutions that the team need cannot be predicted in advance, and it is only by working in the process that we discover where our highest priority needs are. I’m a great believer that development processes are not implemented, they evolve based on the challenges that teams face as they progress on a project.
I like your point on “spikes to give the information needed to make a decision”. In my opinion, knowledge and shared understanding can be deliverables in allowing decisions to be made which facilitate progress. I’d view documentation and reports as artifacts by which that knowledge and understanding are communicated, not as deliverables in themselves. I think that an effective way to describe research work items is to phrase them in terms of the knowledge that is required and the decision that needs to be informed, it is up to the person working on that item to choose the most appropriate medium to convey the information.
I believe that starting a project w/o doing *some* up front planning is like starting a presentation w/o the end in mind. Where is the team heading?
In my opinion, this is one more application of “test first”. In this case the tests we create as a team are the vision/goals/direction of the solution. Then we start creating to make those tests pass. This helps keep everyone on the same page, going the same direction, passing the tests early, reducing re-work. Iteration zero doesn’t need to be a significant effort, but I think it is necessary. Also, I find that a User Story Map (Jeff Patton) is a good fit as the central activity for iteration zero exercises because of the way it reinforces iterative development, direction, vision, prioritizing, etc. Keeping the end in mind.
Your article reminds of Dave West’s article on backlogs as a “snapshot view of an emerging theory” and not as waste: http://www.infoq.com/articles/backlog-not-waste
Steve, I can’t imagine getting *to* Iteration Zero without some up front planning. I would do that (including a high-level User Story Map) during project chartering.
You’re right that you need vision/goals/direction. That’s not what most people do in iteration zero. They’re doing infrastructure, detailed backlog elaboration, and other “stuff.”
Thanks for the clarification – and sorry for my confusion. Let me add my +1 then 😉
A+ George. This is exactly on point. We don’t need to spend (waste?) time building frameworks and estimating velocity, assigning stories and spikes to get things done. We can just do those things and adjust when we find problems.
Nobody ever sailed around the world without untying the docklines and leaving the harbor.
Adam, nor should they head out around the world without a shakedown cruise. It’s the maritime equivalent of the Hudson Bay Start, and a standard practice of prudent offshore mariners.
Agreed, having made the egregious error of having taken off without said shake-down cruise.
That said, almost every minute of research and preparation I spent studying sailing texts was time wasted that would have been better spent sailing my boat.
Kind of a perfect analogy. 🙂
What you have written about in this blog post describes not just how to do Iteration Zero but a generalized, high-level strategic and tactical implementation of Agile Software Development Life Cycles.
I am including a reference to your blog post in the Agile / SDLC Study Guide: http://bit.ly/r1sVAv
A french translation of this post is available here : http://tinyurl.com/cjzwh8m.