Successful teams value planning over plans. However, things are really broken when the reverse is true. We’ve all been there before, trapped within the mother of all project plans. You don’t need a sixth sense to see what’s coming – we see dead projects! Jeff Goldblum in Jurassic Park sums up beautifully the typical phases within a plan-only project:

“Ooh, aah, that’s how it always starts, and then later the running and screaming… “

About eight years ago I joined a project to seed Java knowledge. The team was new to both the language and object technology. After an initial requirements discovery phase and some preliminary high level designs, the project manager called a team meeting to discuss the plan. We all sat down ready to start planning. I love planning sessions. Instead, in true Blue Peter fashion, out came a completed Gnatt chart that the project manager “had prepared earlier”. My heart sank as he handed out the “final” plan with all the final steps to success. Upon closer inspection, things were much worse than I had first feared. Armed with the initial designs, add a generous sprinkling of Java for Dummies, and our friendly neighbourhood project manager added every class as a line item within the plan.

Then, he did it. Oh boy, did he do it. He asked us to estimate each class on his project plan. So for the AbstractDataFactory class, 1 day, StringUtils, 2 days. And so it began, every day at 4pm GMT, we had a status meeting where each team member provided an update on % Complete for every class that they were responsible for. After 3 of these 2 hour daily meetings the team rebelled. Our project manager was suffering from a bad dose of plan-blindness. He could NOT see past the plan. The plan was the deliverable. The project been relegated to being the dark horse of the family. We no longer planning. Am pretty awful place to be really.

Fruitless discussions between the team and the project manager brought about no change. Time was a premium so we made a decision. Project over plan we agreed. The team started scheming. From our perspective, the plan was total project waste. I won’t even tell you what happened to the plan when we re-factored the code base on day two. So we looked at all the classes on the plan, wrote a simple application that sent an email that bumped along our % complete to successfully deliver the plan. The email basically told our project manager want he wanted to hear, delivered the plan, and immediately re-claimed a valuable 2 hours per day per developer. We then set about successfully delivering the project.

So what? First of all, I’m not saying you don’t need a plan, but the plan is not as valuable as the act of planning. Secondly, continuous planning is essential. If you sat down with your team now, handed them a piece of paper and asked the following questions:

1. What is your next deliverable?
2. When is it due?
3. Are you on track?

If your team members come back with different answers, something is broken. Finally, some people are good programmers, others are not. Same for planning. Some people are just not wired up to plan ahead and prefer to just do it. That’s not a big deal but you just need to be aware of that and encourage them to participate in planning sessions.

The timing of this talk was spooky for me. Recently, I’ve been running a number of internal projects where I’m the customer. As the customer, it was the first time I was beaten across the head with the agile developer’s weapon of choice – cutting scope. When the developers unleash this weapon of mass destruction, it’s typically on customers who don’t know what they want. We say, “Those silly customers, they are always changing requirements. They never know what they want.”

Luckily, because I have a little bit of technical knowledge, I was able to articulate my requirements in a different way so that the team understood (still not the right way round, because the dev team should be trying to understand it in business terms, so stuff to work on there I suppose). I was able to do this because I pretty much knew what I could get from technology. However, consider a real, non-technical customer. Just put yourself in their shoes for a moment. Here you’re expected to communicate business value and features, to a team to implement, but you don’t have a damned clue about what you can or can’t get from technology. Furthermore, the team responsible for deriving business value from technology do not really understand the business, or communicate in business terminology. Instead the dev team break things down into technobabble.

Now of course this scenario never occurs, right? But humor me. The next time you find yourself in the situation where you’re cursing the customer, ask yourself, is this because they don’t know what they want or that they don’t know what they can get? If its the latter, its your job to inform them.

Also, when you say to the customer, sorry but you’re just going to have to cut scope, be sympathetic, because what your actually telling the customer is that they cannot get what they need. And as Alexia alluded to in the talk, when cutting scope is not an option, this is the place where creative solutions can be found. But if the agile scope cutting hatchet man is allowed to chop without challenge, these creative solutions will never be explored and customers never get what they need. Let’s not go there…