You Can’t Plan Learning

A question I sometimes get from executives when I showing them where key insights, innovations, and breakthrough occurred on projects is: “That’s great. But why didn’t you just plan a little more and discover those before you started the project?”

I get where they are coming from. They want certainty in an upfront plan. They don’t want any surprises. And they want their software projects to execute just like the power plants and factories they’re use to building.

Except software doesn’t work like that.

You can’t plan the upfront learning that comes from iterating a product or service with a customer, and helping them discover what they really want.

Some customers can tell exactly what they want. But many others don’t. They know they have a need. But they don’t know what is possible, or how to get there.

It reminds me of this story about pottery making (from the book “Art and Fear”).

The ceramics teacher announced on opening day that he was dividing the class into two groups.
All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: 50 pounds of pots rated an “A”, 40 pounds a “B”, and so on.

Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity.

It seems that while the “quantity” group was busily churning out piles of work-and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

So by all means plan. But don’t count on planning alone to get you there. The best results come from building, iterating, and learning. And you can’t plan that.

The way of the Spartan Warrior

There’s more to successful projects than time and money, but if you ask the people with the money, they’ll tell you that time matters a lot.

In this post I am going to show you one sure-fire way to quickly figure out how realistic your budget and schedule are and how to reset expectations like a pro when you need to.

How much can you afford

One of the great strengths of agile development is the leeway you get in building any given feature or story.

You can build it cheap. You can give your customer something with just a few bells and whistles. Or you can build them the Taj Mahal if they want that.

This looseness around high-level stories gives customers a lot of flexibility when making decisions about features. They can go light on user interface spit and polish if they are building a back-office invoicing system. Or they can invest heavily in look and feel for the tablet application insurance adjusters are going to be taking with them to into the field.

The challenge for you (and your customer) is to get a sense of how much they can afford right at the start. We’d all like the deluxe version of whatever it is we are building, but not at the expense of the budget or the schedule. As Steve Jobs likes to remind us, “Artists ship.”

To help our customers figure out this balance, we need a way of quickly confirming that we

• have enough time and money to build the system they want, and
• have a sense of how much they can afford in terms of bells and whistles that would improve the product and experience.

One way to get there is to start Spartan.

The Way of the Spartan Warrior

The Spartan Way is built around one really simple, common-sense premise: If we can’t build the Ford Focus version of the system with the time and money we’ve got, there’s no way we can afford the BMW.

So the way we figure out what we can afford is to build a few bare-bones core features, measure how long that takes, and then take a fresh look at the plan and see how realistic things are looking.

Once you can see clearly that the current plan doesn’t support the scope of what’s on your plate, having this conversation with your customer is much easier.

Yes, we’d like to build the world’s greatest automated invoicing system, too. It’s just that we can’t get the bare functionality in place (much less any of these other whizbang features you’re asking for) with this schedule and timeline—we’ve tried!

No wishful thinking. No guessing. The truth is self-evident.

This is really the crux of agile planning. We don’t know when we are going to be done until we build something of value, measure how long that takes, and then update our plans accordingly. I realize that some people (i.e., executives) don’t like hearing this, but this is the reality of software delivery. All we are doing here is eliminating as much schedule risk as we can up front, giving them a heads-up early on about how things are looking.

What to do if the plan is wrong

If the the plan is wrong, we have two options for bringing reality back into the fold:

1. We can reduce scope (recommended).
2. Or we can flex on the date.

Reducing scope is how agile developers prefer to keep their commitments and avoid the pain that comes from asking for more time and money.

There is always going to be more to do than the time and money allow (that’s just the reality of any interesting project). And if we keep adding features we’ll never ship anything.

So when given the choice we’d rather fix our dates and flex on scope.

If, however, there is a core set of bare-bone features that just have to be delivered as a whole, we can commit to delivering that core set of features. We just have to be a little flexible on the date.

Even in this scenario we will still need to flex on scope a bit (because new things are always going to come up). But we can go in with the understanding that these high-level core features need to be there and that we are going to ship as soon as these are done.

Pushing out the date a little is OK, but it’s not a good habit to get into. For one thing, it’s just too easy. Secondly, it puts your project in danger of delivering no value. Until you get it into production you haven’t an ounce of value, and agile hates that.

Summary

So if you suspect that your project has some scheduling challenges, try building a few spartan core features, see how long that takes, and update your plan to reflect that reality. If things are going well, swell. Keep on truckin’.

Otherwise, work with your customer to set them up for success by either reducing scope or suggesting they be prepared to wiggle a bit on dates.

Doing this early will enable you to have this conversation with conviction in an open and honest way. And your customer will appreciate knowing the facts at the start of the project instead of near the end.