The Sad Truth About Agile Planning

If you’ve read any basic agile stuff, you know that agile teams deliver value in a consistent frequency. The team works on what’s important first, giving the best value for money. When working in a consistent velocity, you can estimate very accurately when features are going to be delivered.

Prepare yourself for a shock.

It is true that when the team has gelled, had enough experience in estimation, and is moving in a constant velocity, life is good. But most people are not there. Chances are, that you’re struggling with inconsistent estimations, varying velocity, some turn over for good measure and enough unknowns to fill  multiple buffers in a Gantt chart.

There’s an old myth: There’s no planning in agile. You’ll find there’s a lot of planning, but if done “right” it’s mostly short term. There’s logic behind it: The bigger the task, a lot can change on the way. It makes much more sense to cut it down to smaller bites, estimate and deliver them, and move on to the next important feature.

However, most of the real world doesn’t work like that. In my former job, I managed software projects of medical instruments that needed to be ready for an expo, after FDA submission. The expo was on a deadline and the competition didn’t wait. The project sponsors needed to know everything would be ready in time, three years in advance.

You might be surprised to learn that answers like: “It will be ready when it’s ready” or “you’ll get what’s the best value every month” were not pleasing to the project sponsors’ ears. See, they needed to know what they’re getting and that it will be on time. Couldn’t face reality, the old geezers – they wanted actual long term plans.

Well, these are the guys who put the money into the project. They may have unreasonable demands, like wanting to know exactly where the project is, but the expo is not moving, is it?

Pure agile may work, but business people are so tired from earlier failures, they don’t trust the team anymore. And they are looking for reassurance or control, by demanding more information. And I’m sorry to say, they are right.

They need answers, so they can make better decisions.

So what can you do when presented with the unreasonable question: “When will it be done?”

You plan, even for the next 6 months, and stand behind your plan. This would be a rough plan, but will present you’re working on the correct features. When progressing, update the plan, and communicate your status. And apart from that, you present working software, showing continuous improvement in the product.

Sounds like the old waterfall world calling you back?

Well, that’s the real world. It requires balance between the long term and the short term. Agile planning is not enough.

11 comments on “The Sad Truth About Agile Planning”

  1. Assaf Stone Reply

    That sucks… (even though it’s true).

    Unfortunately, though Agile planning isn’t enough for (some) stakeholders, waterfall planning, makes promises that can’t be met.

    Perhaps the trick is to make a (less precise) promise at the start of the project, and make sure that *IT* is kept, while filling in details agilely (i.e. vary on scope, not on deadline).


  2. Gil Zilberfeld Reply


    Thanks for the comment!

    I think some people miss out on something important. While the long term may have big unknowns in there (and most people accept that, although more rationally than emotionally) it plays another part: It builds trust that the team know what they are doing.

    If you stick with “I don’t know what will happen next month, let’s focus on this one”, here’s what you sound like to business people: “I can’t plan ahead. I can’t put some thinking into the work, the unknowns and the risks”.

    You can plan, so do it.

  3. CP Reply

    Most of the Agile implementation turn out to be Waterfall, just disguised under standups and whole new terminology.
    Most important thing is maturity of members, “Understanding” of agile.
    When we say we cannot spill over, we have to deliver in this time line, we have to be feature rich at the end of iteration –some tones of waterfall, segregation of concerns at each stage.
    Agile is good, but only when each one reads it the same way, management, client and developers

  4. Gil Zilberfeld Reply


    Thanks for the comment!

    I think the maturity of team helps in commitment to provide value consistently. This builds trust with the other parts of the business, which then can basically know if the project is on track and when it will be done.

    That’s what the dev team can do to help communicate in the same language with the business people. Which really do like deadlines and milestones.

  5. Michael Dubakov Reply

    You have some valid points about future plans. I came to quite similar conclusion, but there is one big difference – I don’t set deadlines. I do roadmapping and roughly set development schedule (these 3 months we will work on Epic 1, next 6 months on Epics 2 and 3). But this is just a Roadmap. It is nearly impossible to forecast real release date with a good precision, otherwise you will have to compromise quality and user experience. It is inevitable. If you have deadlines, you can create good software, but there is a little chance to create great software.

  6. Gil Zilberfeld Reply


    Thanks for the comment!

    Roadmap works internally, but sometimes the deadlines are created for you. Like expos, or even company set deadlines “because they don’t understand”. If you have full control good for you, but that’s not the case for the majority.

    Mmm. Great software == No deadlines.

    I’ll have to think about that.

  7. Chris Reply

    Is it not reality that waterfall does give you the 3-year promise but fails to deliver on it on a regular basis?
    Is it not also true that while the tradeshow dates remain fixed, other things influencing the project like scope and resources and so on hardly do? Especially on a 3 year scale project?
    This used to be my biggest issue in my former job where we did fixed price contracting with fixed dates. Of course all on the project learned about the problem domain through the course of the project and unforseen chances and features emerged. Change requests help only so far and only if there is some budget and time leeway . Again two things were the biggest factors for success, a solid trustfull relationship with the customer/project manager/sponsor, a team skilled and experienced enough to cope with changes on the fly.
    The Agile Methods reflect this experience IMO and take them to the next level. It is missing maturity of the organisations that stands in the way, which still prefer to have the illusion of total control than using the best methods to cope with inevitable emerging constraints and demands. It is also the trust problem that is not easy to solve if you work with contractors and even inside a company there will be issues from time to time. So in your described scenario the ideal way would be to agree with the sponsors to have a core set of functionality ready for the trade show and some exciters along the way that can be agreed upon during the project phase and have them on board for those desicions. But I realise its hard to achieve in reality. I think Michael has taken the best aproach but has a very unique position in comanding his own product (which I am a happy customer form by the way). Just my 2 cents.

  8. Gil Zilberfeld Reply


    Well I’m glad we agree. See my next post for continuation.

    It is very helpful when having an understanding customer, especially one wise in the ways of the Agile. Makes communication, trust and then agile planning better. But not everyone is so lucky. I encourage you to read this post as well.

  9. Vainolo Reply

    Your post reminded me of how Frederick Brooks, in “The Mythical Man-Month” talks about how software development teams should built (third chapter, “The Surgical Team”). This is a MUST read book for any software developer, but sadly most I know have never read it.
    I definitely agree that one of the toughest problems in some agile practices is not only that you can’t have your team all specialize in all fields, but also that there can be very large differences between the strongest and weakest developer in your team and this can cause very big management problems.
    Anyway, thanks for your post!

  10. Gil Zilberfeld Reply


    Thanks for the comment!

    Agile practices (any practices) work best when there’s commitment to accept and adopt these practices by all team members.

    As you say, to get there with differences in the team, takes a lot of effort and patience – both managerial and from peers.

Leave a Reply to Assaf Stone Cancel reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: