Can agile produce reliable plans?
If you are a CTO, CIO or CDO and responsible for the parallel implementation of multiple large scale transformation programmes then it’s not unreasonable for you to ask each of them for a plan – it gives you an expectation of timelines and budget and helps you to ensure the business will be ready to receive that transformation once it’s complete.
So the Programme Directors huddle with their team leads, they crunch the numbers and possibilities and after several weeks they proudly present their long term plan. The world is a better place, you have a commitment and you know what the next X years will look like. All you now need to do is check progress regularly to ensure it aligns with the plan in your hand.
The problem is it’s all a lie. A comfort blanket produced to stop you persistently asking for a plan.
What do you mean? I hired experienced professionals, they in turn have hired great people, they have all done this before so how on earth could they not be able to produce a plan of work to deliver their scope?
Here’s the truth they didn’t want to tell you…. Reliably planning more than 3 months ahead is impossible, think about it:
- No matter how many bright people you put in a room, thinking of every possible variable and understanding the impact for your plan is next to impossible.
- Estimating how long something will take without any real data or experience is guesswork. It’s fine to say “well they’ve done this before” but the variables in each implementation are so different e.g. technology choices, ways of working, people, scope etc. that they might as well be doing it for the first time. Sure, they can use their experience to get in the right ballpark but the reality is that it’s still a guess.
- Up front designs and blueprints are great but easily misunderstood. How many times has someone explained a concept to you, you both walk away thinking you have communicated perfectly but actually what they said and what you heard are completely different
- No one can plan for unexpected external events but you can pretty much guarantee they will occur, so most people add contingency which isn’t unreasonable but isn’t that a guess too? You’re either adding too much or you’re not adding enough but the chances you have added precisely the right amount is slim.
- There is a political battle between being optimistic, pessimistic and realistic. You know that if you tell your boss how long you really think it’s going to take they will hit the roof so you take an optimistic approach that they might buy, but then you know unplanned things are going happen so you need to be pessimistic too. Okay, let’s just work out what we really think it will take and add 20%, that should cover it. I’ve been there, it didn’t come close to covering it.
- We know, we absolutely know, that priorities and needs will change throughout the programme. It’s possible to lock down scope and manage it rigidly but in reality it’s likely to produce something which misses the mark because the world changed and no one thought to alter the scope of the programme.
So what’s the answer?
One of the myths I love to dispel is that agile projects cannot produce plans, I think it’s the complete opposite. Not only can agile projects produce plans but they are more reliable than waterfall plans, it’s obvious:
- You start ‘doing’ far earlier so you immediately begin to prove your assumptions, not only that but you generate real data that can be used to refine estimates
- You immediately start to uncover all the things you forgot when you projected how long it might take so you are de-risking the plan and resolving problems early
- The pure nature of agile means that you are allowing for continuous improvement across a longer period, delivery should get faster over time
- Not only are you delivering benefits early, you’re getting feedback from users so you know that what you’re producing is what they want and if not then you change it right there rather than impacting the programme later on
So, where does that leave us? You want a long term plan but your teams can only provide a short term view… well that’s not strictly true. If you have worked through your scope, broken it down, prioritised it and given rough sizings to each large chunk then you have a pretty simple model that can project forward for as long as your backlog allows. Provided everyone looking at that longer term view knows it’s an illustration of what is possible rather than a guarantee then we’re in business:
- Produce an accurate short term forecast
- Start ‘doing’ and gather some data
- Elaborate, size and prioritise your backlog then use the data to produce a forecast
- Repeat regularly (ideally every 3 months)