Making the Date

Free, Now, and Perfect

Every project begins with high goals and a short deadline. The CIO of a very large company once told me that his customers wanted everything “free, now, and perfect.” I was encouraging him to move away from his theories that it was possible to plan a software project up front and deliver it, as planned, on the date intended. He was counting on his team to do that, and the results were not pretty.

In my opinion, every project should begin with high goals and a short deadline. And, with rare exceptions, every project should deliver its product by the deadline. Really. Every single project. I know this seems impossible. Stick with me.

Too Much to Do

A project needs to start with more goals than can be accomplished. It’s only by looking at a wide range of possible ideas that we can be sure we’ve got the important ones. Then, we need to decide which ones we really need. And then, informed by reality, we need to decide which ones we can actually have.

A long time ago, on the very first XP project, we were faced with a huge pile of things to do, and it was clear that we didn’t have enough time. We were pretty much in a panic. Then Kent Beck¹ said something that was very important:

It's not that we don't have enough time. We have too much to do.

That change of outlook changed everything. It focused us on what we could do, what we needed to do, what would get done by the date we had in mind, and what would not get done. That enabled us to get creative, and enabled management to start dealing with a picture that was more real than fantasy.

Management? What do they have to do with the date?

Well … just everything. Management is the process of setting objectives and goals, applying people and resources, and measuring results, in order to meet the objectives and goals. Management is not a process of shooting an arrow into the air, to fall to earth we know not where. Management is a process of steering, of guiding business activities to provide the best results possible.

This is the fundamental purpose of management. While delegation of responsibility is a key approach in management, there are two major problems with the idea of delegating “make the date” to the development team. First of all, delegation of responsibility requires delegation of commensurate authority. Second, development teams are not managers, and it’s not a good idea to delegate management responsibilities to them: we should delegate development responsibilities to development teams.

Authority Needed to "Make the Date"

It should be clear that no manager, no architect, no designer, no matter how lofty, can precisely estimate just how many features can be done by how many programmers in how much time. If we shoot that arrow into the air, we have no idea where it’s coming down.

If the primary issue is to “make the date”, and in my experience it usually is, then whoever has that responsibility needs to have the authority to apply people and resources, and to set the detailed objectives and goals. Unless we plan to give our developers the authority to hire and fire, to buy computers, to bring in contractors, we’d better not imagine that they can be responsible for the date. Unless we plan to give our developers the authority to decide which features will be delivered on the date and which ones will be deferred until later, we’d better not suppose that they can be responsible for the date. They can’t: they don’t have enough authority to steer.

To deliver the best possible combination of features by a given date, there must be control over the resources, and over the feature list. There’s no way out of this. If you go to the store with a huge shopping list and twenty dollars, you need the authority to go to the money machine for more cash, or the authority to make changes to the list. And shopping is a lot easier than software development.

Making the date requires managing resources and scope. Those are business functions, not development functions. What’s to do?

Management Needs to Manage

It’s perfectly OK for management to think up some lofty goals and set a date and resource limit for delivery of something approaching those goals. Part of the job. Now what?

Management needs to continue to manage the resources on the project. That doesn’t mean move them around like little pawns on the board, but it does mean that management needs to set a budget, and have people and processes in place to make sure that the project stays on budget. Management needs to be available to make decisions about resource modifications as the project requests them.

For most projects, resources are pretty much fixed. And we’ve already decided that the date is sacrosanct. What’s left? Some managers assume that it’s sufficient to demand that the team work hard, with a sense of urgency, and get everything done. Well, that’s really good fiction writing, but it’s not management. Management is the process of meeting the goals as well as possible, within the limitations of time and resources.

Management needs to put a business person in charge of getting the best set of features done by the date. In XP, we call that person “The Customer”. In other Agile methods, they’re called the “Product Owner”, or other terms. Whatever the term, the idea is simple: the Customer has control over exactly one thing: which features are done next. And their responsibility, with that one bit of control, is to cause the team to deliver the best combination of features possible, by the date.

Development is a Machine

From the viewpoint of the Customer, the development organization is like a machine. Think of a washing machine. The machine will take a batch of clothes, up to some maximum size, and 30 minutes later, the clothes are washed. To wash that many clothes that well, we can’t get the machine to do it in 10 minutes, or even 20. We can try to jam a few more clothes in, and for a while it will work, but there really is a maximum beyond which the machine starts jamming, tearing up the clothes, and not getting them clean.

If we’re faced with 10 batches of clothes, it’s going to take five hours to get them all done, if we’re totally on top of the machine every minute. If we only have three hours before we have to leave for the wedding, we’ll need to decide which clothes to do, and which ones to defer until next Monday. We can do six batches, no more. No amount of holding the machine’s feet to the fire will make it do any more, and with a little bad luck we’ll burn a wire and it won’t work at all. Plus foot-burning takes time away from getting the wash done.²

Our job as the Washer Customer is pretty simple, once we get over any delusions of having power over the machine. We need to select six batches of clothes that will do the best job of serving our needs at the wedding, and until next Monday. And, if we’re wise, we’ll even front-load (no pun intended) those batches, to put important items in the first few batches, just in case something goes wrong and we only get four or five batches. Maybe we need to go to the store while one of the batches runs. If so, we might want to make sure we get a complete outfit out of the first couple of batches.

The software situation is quite similar. View the development team as a machine that produces nice clean features. Pick features with two things in mind:

1. Make sure we have all the key features by the final deadline.
2. Try to batch features so that usable subsets of the product arise every few iterations.

Now, it’s possible to push the washing machine metaphor a long way, and get some benefit.

• Shouting at the machine won't help. It's going as fast as it can.
• Taking the machine apart in hopes of speeding it up will guarantee that you get less wash done by the time the three hours are up.
• Buying a new machine may help you later, but it won't help you today.
• Keeping the machine well-maintained will serve you over the longer term.
• Small maintenance steps, like cleaning the filter, may even help over the short term.
• If we forget to do something important, like shirts, until the last batch, there's a good chance we're going to look bad at the wedding.

Well, let’s not go nuts here. The point is that if we, as the Managing Customer, focus mostly on getting the batches right, we’ll come close to doing the best possible job of meeting the goals on time. If we’re a bit clever with mixing the features in the batches, we can even have interim releases ready to go, for special needs and opportunities.

Development's Not Off the Hook

Don’t get me wrong here. Development has some very real responsibilities in making the date. Most importantly, if the business is to manage our project, we have to make our project manageable. An activity is manageable if and only if it provides timely information about how things are going, and it provides controls that allow management to change things in order to steer.

How are things going? The best way to inform management of how things are going is to speak in terms of their interests. Their interests are time, resources, and features. As developers, we’re in charge of the features. Therefore, let’s report, frequently (no less often than monthly) in terms of fully implemented, truly available, running, tested features.¹ There will surely be need for more information than this, but in my opinion, reporting in terms of running tested features is our most powerful single move.

What control can we give them? The best way to give management and our customer a sense of control is to work on whatever features they deem important, based on planning sessions held, again, no less often than monthly. We’re a washing machine, so we get to say how big the load is. But we’ll wash whatever they put in.

Now mind you, these two “simple things” aren’t easy. It will require all our skill to work on features in any order, and to keep the software in shape to deliver running tested features every couple of weeks or monthly. But the things we have to do are largely technical, and almost entirely issues within the team and between the team and its customer. The Agile and XP literature will tell us most everything we need to do. We will have to practice until we’re good at it, of course.

The Bottom Line

Over-simplified a bit, but not too much, it comes down to this. Management has the responsibility to set the overall goals, the resources, and the date. The Product Owner, or the Customer, has the responsibility for giving us the best combination of features so that we meet as many of the goals as possible by the date. Development has the responsibility to deliver a smooth sequence of fully integrated software versions, at least monthly, containing an always-growing collection of running, tested features, as specified by the Customer and by Management.

All this doesn’t make successful software development trivially easy. But it does make it possible, and a lot more likely than what many of us have been doing before.

Making the date is not a development responsibility, it’s primarily a management and customer responsibility. Let’s treat it that way.³