An Agile pitfall – starting a project too soon

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:

  1. Take action (start the project)
  2. 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:

  1. Very little preparation followed by starting the project. “Just do it and learn as you go”.
  2. 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.

Advertisements
An Agile pitfall – starting a project too soon

3 thoughts on “An Agile pitfall – starting a project too soon

  1. A very interesting dilemma, Machiel. And very well reflected upon. In my humble opion, there’s no real issue here. You can always _kill_ a project right after the first results tell you that it leads to too little value or no value at all. You can always start a project after you finish a business case. You always do have at least a BC before you start, don’t you? Anyway, the real problem here is _killing_ the project. That isn’t done easily. Once people set their mind on creating something, no matter if they have a sense of real value, they commit themselves to either the work or the dream and stopping suddenly isn’t an option anymore.

    My approach would be to institutionalize different ways to kill projects sooner. Or is that just a workaround? 🙂

  2. Machiel Groeneveld says:

    @Patrick Verheij
    Just to make things clear, the pre-project phase is (in my mind) the phase where you draw up, amongst other things, the business case.

    Killing projects is hard and usually you’re not likely to change that. More importantly, Agile doesn’t help us out with project-killing-strategies.

  3. Patrick Verheij says:

    @Machiel Groeneveld
    I agree with the pre-project BC draw up. Agile does support killing projects though. You create results quickly. If you aren’t able to create results you are either not doing agile or the project should be killed. So agile practice is nothing but helpful to unmask projects that should not be projects and thus should be killed. I agree that the killing itself is *not yet* in any agile method I know of. I sense an opportunity…:)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s