We cling to old-fashioned long-term plans because they are familiar and we think they provide certainty, but they don’t. We shouldn’t sabotage Agile by trying to bolt on a (dishonest) long-term plan; we should understand and embrace what we’re getting in place of the plan.
I’m blogging this from 35,000 feet, almost entirely just because I can. I’m coming home from two things I’ve wanted to do for a long, long time: [1] travel on business and [2] get paid to talk. Yes, it was as good as I hoped!
Plus I got two states I needed!
Before
After! (It is ON, North Dakota.)
Anyway, tomorrow I’m slated to deliver the inaugural session of our “Scrum-damentals” Coffee Talk (free! register at scrumdamentals.eventbrite.com!) and I’m taking advantage of Alaska Airlines’ in-flight wi-fi to put my personal touches on an awesome slide deck created by our in-house Scrum Authority, Martin. Scrum-damentals will cover common Scrum adoption challenges and the dreaded ScrumButs. One of the Buts that Martin wrote up is the tendency to try to do long-range scope and release planning in spite of the Scrum directive to plan only the next 3-ish Sprints in any detail.
In fact, this is one of the clearest commonalities between Agile and Scrum.
And my former team did it. I helped.
So why’s that bad? We know upper management is often uncomfortable with Agile, and a little release planning is necessary to keep them happy, right? What’s the problem?
This:
THE CAKE IS A LIE
When we succumb to pressure to project-plan, we’re giving upper management false hope. We are lying to them. We know it. They probably know it, too. We have absolutely no way of predicting accurately what we’re even going to attempt to deliver in a Sprint a year from now, much less what we’re going to accomplish in that Sprint. It’s insulting to everyone’s intelligence to pretend otherwise. And we, the team, participate in our own downfall when we play along.
In tomorrow’s Coffee Talk, I’ll cover some strategies we can use to push back against the demand for the plan. Bottom line: we have to speak up and we have to educate our upper management about the benefits of Agile. When they start to understand how much they gain by doing Agile honestly and transparently and fully, they’ll have a much easier time giving up the dream of the delicious cake.
See?
Does that answer your question? 
I don’t understand, I think that’s the whole point of Agile is that the estimates are nothing more than estimates, simply because of the dynamic nature of software development. How can management expect more and the TRUTH from you if they know that this is what Scrum/Agile all about?
PS: I have published a series on Agile Estimation (consisting of 4 articles) a long while ago, I hope you’ll have the chance to read it.
Hi Mike (?), thanks for this! Your article series is really helpful. I found this:
“4. Know when to stop – estimating an inherently unpredictable process (custom software development with evolving requirements) will never be an exact science. Balance enough effort against the diminishing returns and false accuracies of over analysis. Look for broad consensus between team members at a course grained level and then move on. It is better to save estimation time for periodic updates than over analyze.”
I think our positions are not very far apart. In a new Agile adoption, it can be a real challenge to get the organization to let go of its over-reliance on artificial long-range planning. Your articles recommend the above, plus training management to accept less certainty by accepting probabilistic and ranged estimates and learning that they’re never exact. Makes sense.
My concern is that non-Agile cultures often call things “estimates” already. By retaining the same vocabulary, we run the risk that they’ll retain the same expectations even if they say they understand the change. Agile “estimation” might not be disruptive enough or transformative enough. What I’m suggesting instead is that we embrace the pain, and coach managers to let go of “estimates” entirely at first (especially because we won’t have a basis for any metrics in the early Sprints of a Scrum adoption). Yes, over time we can bring back velocity metrics and, as we improve our team’s T-shirt sizing and relative-complexity-pointing skills, we can start to get more predictive of the delivery of our backlog, just as you describe. That’s exactly the trade we’re offering and that’s why they should take us up on it, even though it’s scary.
Risk: might scare organizations off of an Agile adoption before we even begin. But also a risk: might implement Agile/Scrum half-heartedly, assuring its failure before we even begin. Neither promotes trust or success!