The Problem With Planning
I think I've been pretty successful in my career. But if I was better at planning, I wouldn't have achieved half the things I've achieved in my career! In fact, I wouldn't even have started some of them...
In reality, there are some things you can plan, and some things you can't. The trouble is, in most organisations we've come to expect a plan. And to meet it whatever happens. And that's just not realistic.
Doing detailed planning pre-supposes you know where you want to go and aren't going to be influenced too much by what happens in the meantime - or at least not without a substantial amount of re-planning. This, at least in my experience, has a tendency to give project managers tunnel vision at times.
Now don't get me wrong - I'm not suggesting for one moment you embark on a project that doesn't have a clear and robust vision. And I'm not suggesting for a moment you embark on a project where you have no idea how to achieve it and whether it's a reasonable (although hopefully challenging) goal with the available resources. And forming that into an outline plan to provide some markers to aim for is certainly a good idea, but ideally it's a high level roadmap rather than a detailed plan.
Coming from a traditional software development environment, I realise this sounds slightly mad. And I must admit it takes a certain amount of maturity and experience to recognise that you can't really plan in detail up-front if you want to retain any flexibility, as the real requirements, risks, issues, priorities and opportunities all tend to emerge when you start to build and see the software in action.
Most organisations are not ready to accept such a radical idea - the idea of acknowledging you don't really know what you want - certainly not for sure - and you don't really know what you're going to get for your money, or when. So, as a minimum, a clear vision and outline plan are essential, but be careful to keep them to a high level.
Rather than a detailed plan, I prefer to see a strong vision, a strategy, goals, and a roadmap (high level outline plan). The tactics to achieve this, for example the precise features and all the tasks to deliver them, can vary along the way and are best not articulated up-front. This enables the team to discover the details when they are in a better position to do so, and allows them to change direction rapidly in response to changing circumstances.
This, when you think of it, is the very meaning of agile...
Kelly.
Photo by tanakawho
First published on agilesoftwaredevelopment.com
In reality, there are some things you can plan, and some things you can't. The trouble is, in most organisations we've come to expect a plan. And to meet it whatever happens. And that's just not realistic.
Doing detailed planning pre-supposes you know where you want to go and aren't going to be influenced too much by what happens in the meantime - or at least not without a substantial amount of re-planning. This, at least in my experience, has a tendency to give project managers tunnel vision at times.
Now don't get me wrong - I'm not suggesting for one moment you embark on a project that doesn't have a clear and robust vision. And I'm not suggesting for a moment you embark on a project where you have no idea how to achieve it and whether it's a reasonable (although hopefully challenging) goal with the available resources. And forming that into an outline plan to provide some markers to aim for is certainly a good idea, but ideally it's a high level roadmap rather than a detailed plan.
Coming from a traditional software development environment, I realise this sounds slightly mad. And I must admit it takes a certain amount of maturity and experience to recognise that you can't really plan in detail up-front if you want to retain any flexibility, as the real requirements, risks, issues, priorities and opportunities all tend to emerge when you start to build and see the software in action.
Most organisations are not ready to accept such a radical idea - the idea of acknowledging you don't really know what you want - certainly not for sure - and you don't really know what you're going to get for your money, or when. So, as a minimum, a clear vision and outline plan are essential, but be careful to keep them to a high level.
Rather than a detailed plan, I prefer to see a strong vision, a strategy, goals, and a roadmap (high level outline plan). The tactics to achieve this, for example the precise features and all the tasks to deliver them, can vary along the way and are best not articulated up-front. This enables the team to discover the details when they are in a better position to do so, and allows them to change direction rapidly in response to changing circumstances.
This, when you think of it, is the very meaning of agile...
Kelly.
Photo by tanakawho
First published on agilesoftwaredevelopment.com
5 October 2009 19:21
Couldn't agree more. Detailed, up-front planning is usually a waste of time considering that once we start to get feedback the direction can change considerably. What we think the market or our users want isn't always, or usually, the case. As you say, it's necessary to have goals and a vision, but for some reason, most people see a project plan as set in stone. Working against goals rather than milestones can retain the flexibility we need to remain truly agile.
19 October 2009 11:04
Fear seems to be a factor. Fixed cost is seen as a safety net, so people prefer to have everything planned and costed up front, rather than releasing funding in smaller chunks to allow for the inevitable change in direction and scope.
I often have conversations beginning with "... but Agile can't work with fixed cost projects?". I try to counter that with, "Do you think it is more acceptable to agree a cost, knowing full well that the project will run over budget?", but still they cling... Perhaps we need to convince the accountants?
25 October 2009 14:04
The only thing we have to fear is...change itself. This is what most planning is about. Protecting against change. At least a perception that we can avoid change. Wikipedia.org states that agility means the capability of rapidly and cost efficiently adapting to changes. Let's face it...software development is all about evolving a software product to deliver business value over time. Evolution is not a planned event, it is a guided event. The most important thing you need is an initial vision of the product, a definition of what constitutes business value, an open minded team/organization that can adapt to changes for the sake of TRUE business value, and a culture and processes that expect and embrace change.
Peter DeYoe
www.peterdeyoe.wordpress.com
26 October 2009 19:35
I think I know what you mean. The problem with planning is that it relies on "knowns" and stability of circumstances over time, when more often the back-drop is unknowns (or even unknowables) and dynamic circumstances. So I'd agree that being able to adapt is often more important. I think I blogged on a similar theme a while ago myself
http://blog.capablepeople.co.uk/2008/08/is-long-term-goal-driven-planning-a-waste-of-time/