"Plans are of little importance, but planning is essential" - Winston Churchill
"No battle plan survives contact with the enemy" - Colin Powell
One of the most significant contributions of the Agile community has been the realization that creating software is an uncertain business. Unfortunately, this realization has led some of us to the conclusion that the act of creating software cannot be planned. There is a big part of me that can empathize with this point of view. What's the point of creating a plan if we know the business objectives are going to change, requirements are going to change, and even technologies are going to change? I have worked in many traditional projects where change management was the single biggest part of my job. Why not just get going and see where we end up?
The challenge is that business planning doesn't work that way. Product owners are asked to create their business cases months in advance of the upcoming fiscal year. Once funding is approved those guys are on the hook for the revenue. This is a big part of our reluctance to let go of the big up front planning processes. As businesses, we want some sort of assurance that we can deliver on our revenue targets. To these companies, funding a project with only the promise we'll get the most important features first is not very reassuring. We must KNOW that those features are going to deliver the EXPECTED value. Our jobs depend on it.
When the context we operate in is uncertain, we have to plan for that uncertainty. To do this, let's look at the following three planning alternatives:
Make sure the project will yield an acceptable return with less than 100% of the desired features.
Commit to high level features so team has room to negotiate through the life of the project.
In most corporations, there are at least a few other teams that must know ahead of time what you are going to deliver and when. Marketing comes first to mind, so does sales. For those guys to be successful, they need to know what is going to be delivered much earlier than most of us are willing to commit. Committing to high-level features gives us enough specificity to communicate about the product while allowing the team to fine tune the implementation of those features as the product progresses.
Manage the project's value stream rather than changes to features or tasks.
We know that project requirements are going to change along the way. They should. As we build the product we are going to learn more about what we need and how best to build it. Those changes still need to be managed. The company decided to invest so many dollars to yield a particular return. Do we know how any given change will impact the value of the product? Let's start looking at how our changes impact the metrics we really care about... value.
Let's not be afraid to plan in the name of agility. Let's just be smart about what we are planning and leave ourselves room within the plan to be successful. At the end of the day, it is the value that we deliver to the organization that matters, not how well we followed the plan.
"No battle plan survives..." attrib to Colin Powell is actually a quote from Helmuth Karl Bernhard Graf von Moltke (October 26, 1800 – April 24, 1891), Chief of Staff of the Prussian Army.
And the Churchill quote is a rewording of his "Planning is everything. Plans are nothing".
Reading Mike Cohn's "Agile Estimating and Planning" is educational in many ways!
Posted by: Jeremy Swift | Wednesday, March 26, 2008 at 01:36 PM
Thanks much for the response. I guess it just goes to show that you can't trust everything you read on the internet! I'll check my quote sources more carefully next time!
I agree Mike's book is excellent.
Posted by: Mike Cottmeyer | Wednesday, March 26, 2008 at 02:05 PM