Ship complete or ship on schedule: pick one

"Perhaps the main reason we were behind schedule and over budget was because budgets and schedules are based on previous experience with similar projects. We really didn't know how much it would cost to build or how long it would take."—Tom Kelly, Grumman, on building the lunar module for the Apollo program

I read an article that claims Agile Development has now reached the “trough of disillusionment.” It seems that executives and product leaders have started to pine for the good old days of waterfall.

You remember waterfall. We had lots of big documents and checklists and wonderful GANTT charts and status boards. And we were always sure what features would be delivered on certain dates.

Wait. What?

Did we ever hit our dates? The big lie of waterfall was that you could anticipate all requirements in advance. And that requirements didn’t change. And you’d hit your dates. And you could still somehow add features without delaying the project or increasing the headcount.

As we sentimentalize the good ole days, we seem to have forgotten that we rarely (if ever) got what we wanted on the agreed-upon date.

You know what? Waterfall is a perfectly good approach to software development when the requirements are both extremely simple and extremely clear. Are yours?

Many teams today are focusing on roadmapping and estimating, hoping these tools can somehow force teams to deliver more than can be delivered. Or as one marketing manager asked, “How can we get our developers to work harder?”

I suspect your team is already working plenty hard but there are some ways you can get more out of your dev team. They can:

• Stop attending unnecessary meetings… such as all-hands company updates, mandatory charity fundraisers, and those ridiculous insurance coverage sessions (aren’t these always a waste of time?);
• Stop attending bug triage sessions (the support and QA folks should be able to do this without development’s help);
• Stop responding to emails and phone calls from sales and marketing people (the sales engineers should be handling these);
• Stop listening to the latest ideas from executives (the product manager should be the focal point for these); and
• Stop multi-tasking the developers among different projects.

  I’m sure you can think of a few other ways that we can get the dev team focused on delivery instead of participating in the dysfunctions of other departments.

Johanna Rothman’s excellent book Predicting the Unpredictable provides loads of good quotes:

• “Since software is about learning, and we rarely, if ever, do the same project twice, we are always estimating the unknown.”
• “In many ways, estimating project budgets or dates for agile projects turns out to be irrelevant."
• “Some managers want you to estimate the budget as well as the date. And now, you’re off into la-la land.”

  Yet almost every business manager seems to need to know when a project will be completed. The challenge is this: we’ve never done this before. We’re not building hamburgers and hot-dogs—this isn’t factory work. In fact, manufacturing is the wrong analogy.

Writing software is more like writing a book. You can probably give a pretty good estimate for a publishing date if you’ve already written a couple of books, you already have your distribution deals worked out, and you’re passionate about the subject…

Unless…

…You’re working on two or three books at once…

…You’re also researching the topic…

…You’re working another full time job…

…You’re working in an environment with lots of interruptions…

…You’re being hounded by your publishers every few days…

Today’s product teams frequently work on too many projects, attend too many meetings, and have too many interruptions.

When you have a complex project, you have to choose: do you want a fixed set of features to be shipped when they’re available? Or do you want to ship whatever is completed on a certain date? (In my experience, resources and quality are never negotiable.)

Agile development methods give you visibility into the state of the project every two weeks. You can see a demo of what’s working; you can decide if the completed set of functionality is what the market wants and what your company needs to deliver. You can update your plans based on the throughput of the team.

That’s good news for marketing and sales departments. Because you can see working software every two weeks, you can start developing go-to-market materials based on what you know will be released. Marketing and sales materials can be developed in parallel with the software. A key deliverable in your product playbook is a briefing for marketing and sales and executives to show what’s currently working and what’s planned.

A strong product leader maintains a prioritized list of work to be done. The product leader gains more and more confidence when they’ve seen a few successful iterations. Now we can balance features with release possibilities, and focus on delivering the right functionality at the right time.

Yesterday’s methods tried to mandate the date and the feature set, and missed both. With today’s methods, you get to choose: pick a date or pick a feature set.