I wrote recently about the need for long-term planning, even (perhaps especially) in an Agile development environment. I left you with a choice: plan or fail.
The fun part about writing on the internet is that you don’t really have to solve problems: you just have to point them out so that other people can agree with you that yes, there is a problem there, and someone should do something about it. I’m a problem-solver by nature, though, so I can’t just leave it at that. If I’m going to tell people they need to do something, then I’m constitutionally required to help them do it. So we’ve already covered why you need a plan for your product development. Let’s talk about how.
Let’s start with a few objections, because I never met a straw man I didn’t like (to poke holes in):
“I can’t tell you when we’ll have a whole feature set done because we’re using Scrum/Kanban/Lean Agile/some other Japanese-sounding development process.”
“I can’t plan because I don’t know how long it will take to build something six months from now.”
“I can’t create a release plan because I don’t want executives to see it and think that my team has committed to specific deliveries way out in the future, where all the uncertainty lies.”
Let’s take these in order:
1. Your development methodology doesn’t matter.
I hate to break it to you, but no matter how proud you are of your particular style of software code widget management (i.e., your methodology), it has no impact on your ability to predict what your team can accomplish over the long run. You see, that delivery method is the micro view, and the little irregularities that can torch a sprint or a Kanban board in the short term all even out over time. Release planning, on the other hand, is an exercise in macro planning that’s almost Seussian in its simplicity:
I have this box.
I have these rocks.
How many rocks can I fit in this box?
It’s somewhere between a little and lots.
(For those who prefer allegory over metaphor, rocks = major features, the box = your release)
Individual vacations, surprisingly difficult features, requirements changes, these are all daily problems that have no place in the long-term plan, and using them to keep you from looking at the big picture is either laziness or a misunderstanding of the viewpoint. Think in big chunks, average velocities, and conservative predictions and the picture will quickly clear up.
Ask yourself:
How much time do we have to build this release?
At a rough order of magnitude, how long will it take to build each major feature that we want to include?
How many of those major features can we get done in the time we have?
Ta-da! Instant release plan.
2. When you estimate has little impact on what you estimate.
There’s no doubt that development teams learn things as they build that make their estimates more precise and their designs more accurate, but claiming that you can’t estimate a feature now because you plan to build it later is a fallacy. How do I know this? Reorder your product backlog and move those features to the top of the list. Go ahead, I’ll wait….
Can you estimate them now?
That’s what I thought.
I understand that there’s complexity here. What if one feature depends upon another? What if building that framework first makes it easier to build all the features that will use it? What if your customers decide that they want another feature that isn’t on the list? These are all things that couldbe true and might change your project. But how many of them actually impact your estimates?
Sometimes development teams become infatuated by complexity. Like that pretty girl you can’t stop thinking about, they see it everywhere they look. But sometimes it’s just a skinny dude with long hair. Rather than making a long list of the things that could happen to blow up your plan, how about making a small list of reasonable assumptions that will help build your plan? Assume that you’ll be smart and build the framework first, then estimate your effort based upon its existence. Build a plan based on what you know now rather than waiting until you know everything (hint: you never will).
3. Learn the difference between planning and presenting
Above all, your release plan is for you. It’s a guide and a goal for your team, helping you understand how long you have to build things and when it’s time to move on. It helps you shape the picture of what this thing is that you’re trying to build and, most importantly, what done looks like. If this were a road trip, your release plan would be the map that tells you whether you’re driving to New York or Hawaii and helps you choose the destination with the highest likelihood for success. Along the way, it also helps you set intermediate goals, plan your next steps, and ensure that you don’t wander too far off the path chasing shiny objects.
Your stakeholders, customers, and whoever is funding your project (read: executives or investors) also want a hint as to what they’ll get for their time and money, and this is where presenting comes in. The smart team lead knows how to set achievable targets that account for the risk inherent in software delivery, then hit every one. Some people call this “under-promising and over-delivering.” I prefer to call it “risk mitigation and expectation management.” Of course, you can’t mitigate risks if you haven’t identified them, and you can’t manage expectations if you don’t know what you’re capable of delivering. In other words, you need a plan (and if you didn’t see that coming, you really haven’t been paying attention). With the plan you’ve built for yourself and your team, you can easily account for the estimates that feel accurate but make you the most nervous or for those parts of the product that present the highest levels of uncertainty in execution. Build contingency into your plan and commit to exceed expectations whenever possible. I like to set stretch features in every iteration or release, giving my team room to deliver everything that we’ve promised, even if we hit some bumps, then give our users a little more when things go as well as we’d hoped.
In other words, if you’re confident that you can get to New York in the time allotted, tell your executives how fabulous Cleveland is in the fall, then try to surprise them with a trip to the Big Apple.
Why Plan?
This still feels like a lot of work, so why are we doing it again? Because:
It sets the expectations for your team and help them understand what they’ll have to show for all the work they’re about to do.
Like the framework of a building, it provides a rough guide for where every feature goes and how long it should take to build it, helping you identify the most efficient path to completion. When features get too big, it warns you before they take over the project.
It helps you identify risks and opportunities before you stumble across them, that you can mitigate them or take the best advantage of them.
It lays a foundation for communicating to everyone who cares about your product — and the more people who care, the better, no matter how annoying they may be — and helps you manage expectations and chart your progress. This is a significantly better approach than saying, “We’ll tell you when we’re done,” an approach that has never in the history of time failed to aggravate the people with the money and always leads to more bad attention, not less.
So forget what your Agile guru said: the sprint is the means, not the end. Sit down with your team and contemplate your glorious future together. It starts with a simple question:
“Does anyone know where we’re going?”
