The Planning Fallacy

You know... sometimes I can't help but think that us agilists create unnecessary grief for ourselves when we talk about agile to our more traditional counterparts.

My friend Angeline Tan (@agilemeister) launched a Twitter campaign this week to get the Agile Alliance to show some West Coast love and move the 2013 conference to San Francisco. There was quite a bit of interesting discussion, but in the end Diana Larsen (@dianaofportland) closed the debate... Agile 2013 will be in Nashville, the contracts are signed.

I thought that was kind of funny. A bunch of agilists planning far enough in advance to have contracts signed, what... two years in advance? I thought we were all about emergent outcomes? What happened to just in time planning? I thought we were all supposed to just show up in Nashville and self-organize a conference right there on the fly?

Wouldn't that be fun, just show up in 2013 start conferencing! (actually, that might be fun)

There is always some level of up-front planning necessary to pull off a big event. Likewise, there is always some level of up-front planning necessary to coordinate the efforts of dozens of developers trying to pull together a large enterprise class software system. Software at this level doesn't emerge. There is a ton of room to plan and design as we go, but the core structures and patterns have to be in place early.

I think we'd do ourselves well... as a community... to popularize some language about how we deal with this kind of planning. It seems that somehow... in our day to day discussions about agile... we've given the mainstream project management and development community the wrong impression about us. We value "responding to change OVER following a plan"... that doesn't mean we don't plan.

I bet the first contract in Nashville was signed two years in advance also. None of us showed up in Nashville to a flooded hotel, did we?

Subscribe to Leading Agile

At Peace with Paper

I am an admitted Blackberry addict and I love new gadgets. That said, there is just something organic, something spiritual about scribbling on a piece of paper. I just can't seem to shake my attraction to paper planning. I love jotting down ideas and circling key concepts. Being able to draw a line between two related concepts is powerful. Using different colors to show transitions and to communicate emphasis richly expresses what words do not. There is a place in my soul that won't be satisfied with a little electronic checkmark next to a finished task. I need to write.

But as much as I love my planner, it does have its limitations. If I want to share my ideas with anybody, I have to either photocopy them or rewrite them electronically later on. No one else is able to see my calendar so coordinating schedules becomes a pretty labor intensive task. I am never totally sure if my wife has me booked someplace and I just forgot to write it down. I have yet to figure out a way to make it receive email and it won't automatically remind me of anything. Did I mention that I am totally screwed if I leave it on the roof of my car?

I've been fighting this internal battle for the better part of 20 years. I would go through periods of time where I did nothing but paper planning but inevitably the limitations we just discussed would pull me back to using something electronic. When I would decide to go paperless that part of my soul in search of free form expression would pull me back to handwritten notes. After all this time, I've come to the realization that neither approach is going to give me everything I need in a planning tool, so for now, I am going to use both.

I think there is a lesson here that we can apply in our agile projects. It doesn't have to be one or the other when it comes to planning. If we are all in the same room collaborating, exploring new ideas, and everyone is able to see and touch the same information; paper and whiteboards are the way to go. When the job requires us to manage large amounts of data, to coordinate over distance, or an ability to look at data from many different angles; software can do that much more effectively than paper.

It is really just a matter of blending the two approaches in a way that allows us to be most effective as a team and deliver the most value to our customers.

Here is a link back to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/at-peace-with-p.html

 Subscribe to this blog

Subscribe to Leading Agile

Planning for Value

"Reduce your plans to writing. The moment you complete this, you will have definitely given concrete form to the intangible desire" - Napoleon Hill

"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.

Sure… I want a crystal ball too. Problem is we don't have one. If we have a firm date, a firm cost, and a fixed set of features; odds are we are going to fail. If time and cost are king, we have to be flexible on features. We need to know up front that we can go to market with less and still produce acceptable value to the company.

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.

Here is a link back to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/planning-for-va.html

 Subscribe to this blog

Subscribe to Leading Agile