The Zeroth Iteration
09 SepIn the beginning was the project kick-off meeting. And following this, Lo' the developers did say "erm, what are we actually building, how are we building it and where do we start?"
As (or before) the first iteration of an agile development, I'm suggesting that it can be helpful to have a Zeroth Iteration to get some "scaffolding" in place and start things moving.
What am I talking about?
There is a fairly commonly accepted truism that in creative work the hardest part is the blank sheet of paper or canvas, the lump of clay in a bag, or in software - the newly created empty project directory.
Following the initial meetings to get people together on a project, that empty directory looms large in the developers minds. What, practically speaking, are we going to build here? And how?
After a few more discussions and probably some scribbling on whiteboards or paper, the team will hopefully start to get a feel for the overall shape of the intended system, before requirements are formalised, or even a general feature list starts to firm up.
(little fanfare toot) At this point, I propose a zeroth iteration is called for.
What is it for?
If agile iterations are a metaphor for steering a car continuously to a foggily known destination, this iteration is a metaphor for making sure you've got a car that starts, the gears & brakes work and it's on some form of driveable surface.
This is all stuff you're going to find out continuously when you start driving, but it's best to find out as early as possible if any of these basics are missing and get them fixed before things get complicated.
Less metaphorically, we're checking that we can actually complete a development iteration, from start to end (however we define them) and deliver something. It shows we have a team on the project, that they have (at least some of) the tools they need, that the source control, build system, test systems, and delivery process are all in place.
It should also mean we'll share an understanding of how things will happen once our iterations are delivering something tangible. That makes our days more predictable, we can rely more on our tools, life is less stressful and we can focus on the real work.
More pessimistically, this iteration gives us a chance to find out very early on when things are NOT arranged for the project to start, giving us as much warning as possible of the red flags and project & organisational risks we're going to hit later on.
Why do a "nothing" release?
If QA, security, customer support teams, etc won't/can't allow this "do nothing" release to go live, because they haven't been involved, then we can start involving them now. If the infrastructure can't deploy or run this kind of app, we find out before marketing have started focus group testing. If the dev teams have no idea how to use the new release tools the devops team have just introduced, we find out about this training need before the day of the first customer demo.
The plan here is to do a full release iteration of the project, with an app that is just a skeleton - "Hello World", "Do Nothing" - whatever is the minimal thing of the right shape we can produce.
The key point is to exercise all of the release processes, without any actual features to cause complexity.
We want to see all the cogs turning, all the deployment tools firing, all the sign-offs, all the hand-overs, all the red tape & paperwork completed, right at the beginning - so that when they grind to a halt we can start fixing them as early as possible (or maybe even simplifying/removing them - just a thought).
Is this agile?
Although this isn't a formal part of any agile process/methodology I know of, it has been suggested by many people in various forms and sort of combines the ideas of tracer-bullets, prototyping, and process bootstrapping.
Recently I heard that the term "zero function iteration" is mentioned in some XP books, so I guess that's the same thing.
There's a chance some people will say that's impossible, impractical or unnecessary. Or maybe even "not agile".
The bit they are responsible for is probably where to look really hard - because they know where the traps are lurking, where the smoke will emerge when the deadlines bite. So involve them early, they may have a lot of work to do in this first iteration if the situation is dire.
The fundamental point to remember is that if we can't deliver the simplest possible thing in a single agile iteration, there is no chance of being able to deliver anything more complex, so we don't have an agile process yet.