The pre-project phase is a hot topic that I’ve blogged about before under the header ‘Iteration -1″.
This post is on the ‘pre-iteration-1’ phase, before the project has even started. I’ll explain the contradiction that I’ve found in my experience with starting Agile projects. Preparing a project is not the same as executing a project and therefore the Agile principles don’t apply cleanly to the pre-project phase (oh, dear).
Starting a project is a delicate and risky endeavor. Some projects don’t turn out too well, much money is lost on starting the wrong projects. And yet, projects are the way forward for many organizations, the way to really get things done. So there is a fine line between starting too many risky projects and not starting projects at all (or only doing the ones that have a high chance of success). What would be an Agile way to deal with starting projects? To my knowledge there is not a lot of Agile information on starting or preparing projects, but two principles that apply here come to mind:
- Take action (start the project)
- Decide as late as possible (don’t start the project, yet)
The first principle says: “You’ll never know exactly how the project go, so just start and find out.” The second principle says: “If you can, wait for more information and then start the project (or not)”.
In a project context these principles wouldn’t conflict because they’re about the same thing: making decisions based on result, not speculation. Principle 2 comes from Lean and implies using an options-based approach to decision making. So when during your project you are faced with a complex problem, apply principle #1 and using real experience, do #2. But you can’t take action when you haven’t started your project yet, no team and no software means no real experience to prove viability of the project.
I find principle #1 is the favourite amongst my Agile colleagues, they have an eagerness to get the Agile process started. It has obvious benefits: shorten the project cycle time, get measurements on real world experience etc. So, when the decision to start a project seems too complex, the Scrum principles is applied (quoted):
[…] the values integral to Scrum, such as empiricism, self-organization, and action
But this can-do spirit has a pitfall: you might start too many projects that has no chance of success.
The heart of the matter is, can you make a viable prediction of a projects’ success without actually starting it? Starting projects just to find out how viable they are, is a costly approach. The Agile ‘ready, fire, aim’ principle, driven by the high number of developers pushing for Agile, might not be the best option in all cases. But the alternative might sound all too ‘waterfally‘. But I don’t think it’s the same thing as writing down all your requirements in detail up front. It’s actually not a project yet, so not all Waterfall vs. Agile flamewars apply.
Let’s say we have two options for the project preparation phase:
- Very little preparation followed by starting the project. “Just do it and learn as you go”.
- Doing research on the ROI, the needs of the user, getting buy-in from executives, getting a clear set of requirements, setting up reporting and project management processes etc. And only after getting a green light on all of these, start the project.
I will not say which is best on all cases, there is no such thing. But you might find it interessting to know that the Standish Group, in the book ‘My life is Failure‘ recommends option #2. And yet, they also recommend using an Agile process. The business case and the project plan should be sound and there’s quite a bit of groundwork to be done before even deciding on the start of a project.
You are partly in the land of theory-building, making plans, doing ROI estimates, asking what the user wants. All these things can change when you start the project. The benefit of this phase is that it doesn’t take a whole team and focussed organisation to execute this phase. When you decide not to do the project, only a few weeks of work is lost, but a huge los on a failed project is avoided.
My main insight here is: “Preparing to start a project, is simply not the same as executing a project”. A big difference is the preparation phase does not have a working product as its main deliverable, only plans and decisions. This means not all Agile principles apply and they should be forced onto this phase. The Standish Group gives us a lot of patterns for dealing with this phase, but they are differ from the Agile patterns. So pick the right pattern for the right phase and context. The preparation phase needs its own patterns for success.