Actually Agile planning is based upon two main principles:
- Just enough
- Just in time
that is, at each stage we plan just enough to get us going and answer the important questions at that stage and than we stop.
In this post Gil talks about agile planning how it mainly focused on short term. Well Gil you missed some important staff about what you call Agile planning.
lets start by saying that talking about agile planning as a concrete thing is basically misleading, agile planning is just a set of very basic principles (which I tried summarizing above). One need to refer to concrete planning practices in order to udge them.Planning is scrum does not look like planning in Kanban which does not look like planning in XP…
The example used is taken from a medical field, in which the stake holders
“needed to know everything would be ready in time, three years in advance.”.
Well sorry there is no such magic in our field. NO one can know what will happen three years in advance.
when you claim to be able to do that you are simply lying, both to your sponsor and probably to yourself as well. You can estimate, you can guess or you can extrapolate based on prior knowledge.
you will never KNOW.
Even when you sign a contract with millions of dollars in fines for being late, you cant know. you are just doing an educated guessing taking all the buffers and safeties you need in order to hopefully meet you goals in the given time. And BTW in most case you don’t (just check out Chaos report if you don’t believe me)
Long Term Planning
Gil is right about one important thing, almost every project need a long term plan. Question is and always will be is just how long do we need our plan and how detailed do we need it to be.
In scrum for example, there are 3 levels of planning:
- the daily planning (done in each daily meeting) – we plan in extreme details what will be done in the next day
- the sprint planning – we plan in details which tasks will be done during a sprint ( a few week ahead)
- the Release planning – we plan the list of stories which we will deliver in the next release (typically 3-6 months)
And here Scrum stops.
That doesn’t mean there are no longer term planning, just that the longer term is “out of scope” for the basic Scrum process. u will still need a product roadmap, you will still need a strategic planning. and maybe just maybe (like in the example Gil gave) you will need to give a list of expected features for the next “big” version. However this kind of planning will always be more vague, will deal in general capabilities we would like our product to have and at the end will always be open to interpretation. it would never be concrete enough to actually start working on.
The nice thing that at the end my recommendations and Gil are the same (well we do basically believe in the same things):
do a release plan (3-6 months ahead) make sure you are working on the highest priority features and make your best to develop them as fast as you can, and always keep your progress visible top your customer.
So lets do a reality check, planning is nice and important, but “responding to change over following a plan” is what makes agile processes works. The longer the time frame you are planning chances are higher that this change will be bigger and come sooner.