Project Planning: "Can we kill 'em tomorrow?"

What kind of organizations benefit from an agile approach to software development?

I was thinking of this around a year ago while working with a client who was thinking of reimplementing, for the first time, some important applications with .NET. One of the business-interface people started a planning meeting by stating:

Before we do anything else, we need to plan this whole project in detail. We need to know exactly how this is going to be done. Right now.

I don’t recall exactly how I responded out loud, but the monologue in my head went something like this:

Wait a minute, Sally, your department has never done a .NET project before, and yours is a weird runtime environment. Nobody here has any idea how it will come out. I’m the only one in this meeting who has ever written .NET code, and I still don’t know what the final project is going to look like. What makes you think we can realistically plan how to get there?

Honestly, “right now” is always the absolute worst time to plan a software project. You should only do it when there is no other choice. Of all the possible times to make a decision, now is when you have the least information. You will not have less information tomorrow, and if anyone is doing anything you will have more information tomorrow.

A big software project is like war

It reminded me of something President Bill Clinton said when accepting the Fulbright Prize in 2006.

So anytime somebody said in my presidency, “If you don’t do this people will think you’re weak,” I always asked the same question for eight years: “Can we kill ’em tomorrow? If we can kill ’em tomorrow, then we’re not weak, and we might be wise enough to try to find an alternative way.

Why not kill ’em today? There are so many reasons. We might have misunderstood the situation. Something may have changed in the scope of the problem. Resources may become available or go away. We might not even be in charge tomorrow. The adversary could become distracted or discouraged. And so on.

A major software project is like that. You make big, complex plans that include every contingency and:

• Your funding gets pulled.
• A major player is hired in or leaves.
• The technical platform changes.
• Oracle is involved.
  
• Your company is acquired and the project becomes moot.
• Your company acquires one that has the implementation you wanted anyway.
• You hit an unexpected technical obstacle.
• Velocity is lower than expected.
• Velocity is higher than exepcted.

One thing you know for certain is that your developers will be more knowledgeable six months into the project than they are before it starts. So it doesn’t make sense to make firm decisions and commit to things that you don’t have to. You can always make the commitment tomorrow.

Can’t believe I’m saying this

I think Clinton hit upon something important here. You make the big commitment to go to war, or the big commitment to a certain project plan, because the commitment represents strength. Vagueness, generality, keeping your options open? Weak. Decisiveness, snap decisions, clarity? Strong.

Nobody wants to be a weak project manager.

But it’s not about you.

Guiding projects to best outcomes might conflict with what you’d think of as… a self-image. People in leadership tend to be bold, controlling, and sure of themselves. But software development, by its nature, is always a process of exploring and failing. If you knew how to solve the problem, it would be solved already. Being too sure of yourself is a liability; knowing the answers means you are almost certainly wrong; and if you’ve never spent at least a few days on a technical approach that didn’t work, you’re obviously new to this racket.

Larry Wall famously claimed the three cardinal virtues of a programmer are laziness, impatience, and hubris. In the context of implementing designs and cranking out code, he’s right, but I propose–with a certain required diffidence–these cardinal virtues of a project planner:

• Humility: You don’t know what you don’t know. You don’t even know what it is that you don’t know. Yet.
  
• Grace: You will be wrong despite your best efforts. It’s not about you.
  
• Resilience: Things will change, and your plan will fail. Unless your plan is to keep searching for the ways that will work.

That’s another way of stating the Agile Principles. Make things as simple, and as simply, as possible. Working code speaks more than words. Trying and failing means you learned something, or it should.

And most of all, don’t make decisions, big or small, before you have to. Because if you can kill ’em tomorrow, that doesn’t make you weak, and maybe you’ll be wise enough to find a better way.