Agile Is Not Intended for Deliverable-Based Projects

Waterfall and Agile solve two different problems and are not interchangeable.

Have you ever worked on a software development project in which the customer expected the delivery of a fully functional system by a predefined date (and often for a predefined price)?

Did your team try to use the Agile process to achieve this end result?

Did the team find themselves in a mad rush to build a large amount of functionality near the end of the project?

Did management try to press the magic button labeled “Mandatory Overtime” (not for them, but for the team) to get the job done?

Did this experience make you think that someone was missing something? That this Agile thing isn’t all it’s cracked up to be? Or that some fundamental principle was missed, but you’re not sure what it is?

You’re not alone. I’ve seen large Agile projects fail more often than they succeed. Not because there’s something wrong with Agile, but because many organizations misunderstand when to use Agile and when to use a different process.

How vs Why

So many organizations are obsessed with “how” to implement the Agile process — what meetings to have, who will attend those meetings, what will be discussed, how to estimate cards, how to manage the backlog, etc. — that they forget to address the bigger, more important question: “why” do we implement the Agile process?

In other words, which situations does Agile fit? And conversely, which situations does Agile not fit?

The Agile hype train has been chugging for so long that many IT customers (and even some IT professionals) have fallen under the impression that Agile is intended to be a universal replacement for all other project management mechanisms.

That’s not the case. Agile is a tool and like all other tools on this planet it fits some situations and does not fit others.

Waterfall, for example, and Agile are two different processes intended for two different situations. They do not attempt to solve the same problem and are not interchangeable.

To understand this, let’s summarize the Waterfall and Agile processes. We’ll quickly see that they’re not intended to meet the same customer expectation.

Waterfall Is Deliverable-Based: “Give me a certain thing by a certain date”

On a Waterfall project, the customer purchases a deliverable — the implementation of a predefined set of requirements, usually by a predefined date, and often for a predefined price.

In other words, if the customer wants the IT project team to be on the hook to deliver a certain thing (e.g., a software system) by a certain date, then that’s a deliverable project.

To satisfy this customer expectation, the project team must follow a deliverable-based process, like Waterfall.

The first step that occurs on a Waterfall project, long before development begins, is that the customer defines all the detailed requirements. This has to be step #1.

After all, if the customer wants the project team to be on the hook to deliver an agreed upon thing by an agreed upon date, the first step is to define that thing — the full set of requirements. This is mandatory.

Keep in mind that these must be the actual detailed requirements — enough information for the project team to build and test the system. References to requirements, such as rows in a spreadsheet or Post-It notes on a wall, are not enough.

Vision statements are also not enough. For example, “We want to replace our legacy system with a modern equivalent while fixing some pain points along the way.” This is a vision statement, not a collection of requirements to estimate, implement, and test.

The detailed requirements are then handed to the IT project team, mainly the developers, who estimate them.

There might be two hundred requirements, just to pick a number, and the developers go through each one, discuss as needed, and arrive at an estimated number of hours. The first requirement might be estimated at 4 hours. The second requirement — maybe 8 hours. The third requirement — 24 hours. And so it goes, through every requirement.

The developers then provide these estimates to the IT project manager who integrates them with the project schedule.

An entire book could be written about how to form a Waterfall project schedule, which is usually done with a tool like Microsoft Project.

But we’ll focus on just a few key principles here, to highlight how detailed the schedule must be to meet the customer’s deliverable expectation.

A Waterfall project schedule includes at least four phases after the collection of requirements: Initialization (aka Ramp-Up), Construction (aka Development), Testing, and Deployment.

1. Every project of a decent size will have an Initialization phase. No one starts coding on day one, except for the tiniest of projects. Time is needed for the team to install software tools, create source code repositories, establish coding standards, gain permissions, spin up environments, etc.

2. The Construction phase includes the implementation of requirements, with all the necessary dependencies among tasks, forming a large portion of the schedule’s critical path. This is the longest phase.

3. The Testing phase uses a Quality Assurance team to test the features and to report bugs. The developers review and fix the legitimate bugs, followed by a retest. A common rule of thumb is that testing a feature will require 30% of the time to build it. So, a feature that required 30 hours to build will require 9 hours to test and certify.

4. The Deployment phase includes the work to push the completed system into production. This may be the shortest phase.

There are two important principles to include in a Waterfall project schedule, which I call the “Rule of 80's”:

a. No task is allowed to be greater than 80 hours. This restriction forces the project team to understand what they must do at a granular level and to create tasks that reflect this detailed understanding. The team cannot allocate large buckets of hours and hope that they will be enough to implement poorly understood requirements. Hope is not a strategy.

b. No team member can be allocated at more than 80%. The hard reality is that (at least) 20% of everyone’s time will be occupied by unexpected & unscheduled work — hidden complexities, hallway conversations, emergency meetings, external delays, rework, outages, etc. A schedule that allocates anyone at more than 80% is unrealistic right from the start.

The end result is that the project manager produces a detailed project schedule that accounts for everything — all the work to be done (no task greater than 80 hours) and all the people to do the work (no one allocated at more than 80%). This schedule clearly shows, in a realistic manner, the day-to-day assignments that will result in this team building, testing, and deploying the system.

The calculated delivery date is then used to calculate a price. If the customer accepts these numbers then you’ve got yourself a deliverable project.

And when the project begins, the project team is in the hot seat. The project team is responsible for the success of the Waterfall project.

The customer provided all the detailed requirements up front. These requirements were locked in place. They became the project scope. They became the core of the project schedule. And the existence of this schedule enables the project team to commit to deliver the locked-in requirements by the calculated date.

Without this level of detailed analysis and scheduling, no such deliverable commitment can be made.

Agile Is Capacity-Based: “Give me your time so I can figure it out as we go”

However, if the customer is either unwilling or unable to provide all the detailed requirements up front then the Waterfall process cannot be used.

A deliverable-based approach like Waterfall immediately falls apart if the customer will not clearly define the requirements prior to the start of development. If the customer cannot lock in the requirements then the project team cannot lock in a delivery date or price.

In these situations, Waterfall is off the table and Agile steps in.

The purpose of Agile is to bypass the rigid up-front definition of the system that is locked in place for the project scope and the project schedule.

Instead, Agile goes in the opposite direction. Agile creates an environment in which the customer can invent and change the requirements as they go, all throughout the project.

For this reason, Agile is a capacity-based approach. The customer does not purchase a deliverable — the delivery of a certain thing by a certain date. Instead, the customer purchases a certain amount of development capacity — a certain amount of the project team’s time.

For example, the customer might acquire three developers for three months — that’s nine months of development capacity. Or maybe six developers for six months — that’s thirty-six months of development capacity.

Whatever the numbers, the customer purchases a certain amount of capacity and the project begins. Throughout that Agile project, the customer and project team follow a straightforward approach:

a. The customer is out in front, leading the way, creating and prioritizing the requirements. These priorities define the order in which the features are built.

b. The project team follows behind the customer and goes wherever the customer leads (from a requirements perspective). Every day, the project team works on the next highest set of priorities that have been put in front of them by the customer. When they complete those items, the team moves on to the next highest priorities as defined by the customer. And then on to the next highest priorities as defined by the customer. Over and over again.

This continues week after week, month after month, until eventually the customer has burned through all the development capacity that they purchased. When that day comes, the project is over — and there will be a piece of software that’s been created.

The state of this software — good, bad, or ugly — will be a result of the priorities that the customer set.

If the customer set the priorities wisely then the software might be sufficiently full-featured and ready for production.

But if the customer set the priorities poorly then the software might be missing mandatory features and therefore is not production-ready. If this happens, the customer’s priorities are at fault, not the project team’s effort.

The project team has no responsibility to deliver a complete system by a certain date. Again, Agile is not a deliverable-based approach.

The purpose of Agile is to give the customer the freedom — the flexibility — the agility — to make it up as they go. To enable the customer to zig and zag, to bob and weave, to create and change requirements at the drop of a hat.

But the trade-off is this:

If the customer falls down a rabbit hole from a requirements perspective — if the customer develops a case of tunnel vision and continuously iterates over the same few features, polishing them to perfection, then it’s possible that they’ll run out of development capacity before completing the system.

The customer must be disciplined enough to avoid this mistake. This is the customer’s burden on an Agile project.

Fortunately, there is a concept in Agile — the Minimum Viable Product (MVP) — to help customers keep their priorities on track. But that’s a conversation for another time.

Waterfall and Agile Are Not in Competition

Let’s summarize.

On a Waterfall project, the project team is in the hot seat. The project team is responsible for the success of a Waterfall project.

The customer documents enough information to build and test the system up front. These requirements are locked in place and they become the project scope and the project schedule.

Then, from day one of the Initialization phase, the project team is in possession of this detailed schedule that accounts for everything — all the work to be done and all the people to do it. This document is the heart and soul of a Waterfall project — it enables the project team to commit to implement the locked-in requirements by the calculated date.

And if the customer wants to change the requirements, they are subject to a change control process. The team will happily build additional features but the customer must pay additional money and extend the delivery date accordingly.

But if the customer is either unwilling or unable to lock in the requirements up front, the team cannot follow the Waterfall process. Instead, Agile enters the picture.

On an Agile project, the customer is in the hot seat. The customer is responsible for the success of an Agile project, not the project team.

In order to free themselves from the burden of defining everything up front, the customer purchases a certain amount of development capacity.

And throughout the entire project, the customer leads the way, creating and prioritizing the requirements. At the same time, the project team follows behind the customer, and works through the backlog according to the customer’s shifting priorities. The “completeness” of the final product depends on the customer’s discipline — their ability to stick to the MVP.

As you can see, Waterfall and Agile are two different processes intended for two different situations. They are not intended to satisfy the same customer expectation and are not interchangeable.

Customer Confusion: “Isn’t IT always on the hook, even for Agile?”

Everything that we’ve reviewed here is entry-level information — the basics of the basics. We could spend all day discussing the details.

But as straightforward as this is, here’s where IT customers have a tendency to get confused.

There are a lot of IT customers — still in the industry today — who have only experienced the Waterfall process.

Waterfall has been the dominant project management mechanism for decades. There are IT customers who have spent the last 25, 35, or maybe even 45 years funding software projects, and every one of those projects ended up being Waterfall.

Customers who are in this situation are very used to a certain set of expectations. They’re very used to a certain arrangement regarding who is responsible for what on a software project.

But because they’ve only experienced Waterfall, they might not realize which of these expectations are due to the use of Waterfall versus which expectations are just the nature of software projects in general.

For example: the expectation that the project team is on the hook to deliver a certain thing by a certain date.

That expectation comes from Waterfall. Waterfall is that process.

But if the customer has only experienced Waterfall, they might not understand that. The customer might assume, without bothering to check with anyone, that that’s how all software projects work across the board. After all, that’s been their only experience.

They don’t have enough IT experience to realize that different processes are intended to solve different problems.

Well, you can imagine the confusion that this assumption would eventually cause. As their organizations transition from Waterfall to Agile, this expectation is eliminated.

You cannot have an Agile project in which the project team is on the hook to deliver a certain thing by a certain date. The whole point of Agile is to not do that.

Agile eliminates the need for the rigid up-front definition of the system that’s locked in place to become the project scope and the project schedule. Agile throws all that deliverable stuff out of the window.

And instead, Agile goes in the opposite direction. Agile uses a series of recurring meetings to create an environment in which the customer can invent the requirements as they go. For this reason, Agile is capacity-based, not deliverable-based.

Project teams — if I were you, my number one goal, far more important than anything else, would be to make sure your customers understand the differences between Waterfall and Agile. These differences are significant. These differences determine who is responsible for the success of your Agile projects — and it’s not you.

Difficult Customers: “I want the best of both worlds!”

Of course, there are customers who will push logic aside and insist on being selfish. You may encounter customers who slam their fists on the table and proclaim:

“Wait a minute! I absolutely must have a commitment from IT to give me the system that I want by the date that I want it. This is not negotiable. I fund these projects and IT is required to do the work to my satisfaction.”

“But I’m not interested in defining all the requirements up front. That takes too long and we never get it right. So, I must have the freedom to invent the requirements as we go, after IT commits to a delivery date.”

“How do we do that, IT? What’s that process?”

That’s an easy question to answer. We don’t do that. There is no such process.

Waterfall and Agile each have a particular customer benefit that is tightly-coupled with a corresponding customer burden. The benefit and burden go hand-in-hand and are inseparable.

On a Waterfall project, the customer benefit is that they know what they’re going to get and when they’re going to get it. This is a fantastic benefit and very valuable to a customer. The customer can make a lot of plans based on the expected delivery of the system.

But the corresponding burden is that the customer must define the entire thing up front, so the project team can analyze, estimate, and schedule the tasks in order to calculate the delivery date.

If the customer wants the Waterfall benefit then they must accept the Waterfall burden. The two go hand-in-hand and are inseparable.

On an Agile project, the customer benefit is that they have the freedom to invent the requirements all throughout the project. No up-front discovery is required. This is also a fantastic benefit. Complete flexibility!

But the corresponding customer burden is that the end result of the project will be a result of the decisions that the customer makes — the priorities that they set. The project team is not on the hook to deliver a functional system in spite of the customer’s decisions.

If the customer wants the Agile benefit then they must accept the Agile burden. The two go hand-in-hand and are inseparable.

There is no Waterfall-Agile hybrid process in which the customer receives the best of both worlds. They have to choose one approach or the other and accept the customer’s burden that goes with their choice.

Agile and Overtime Don’t Mix

Last thing. The concept of overtime does not apply to Agile projects, for the obvious reason that you already understand.

When someone puts in overtime, it’s because they’re on the hook to deliver a certain thing by a certain date, and they’re behind schedule. So they put in extra hours to catch up — to get back on schedule.

This does not happen on Agile projects. The customer purchases a certain amount of the team’s time, not the team’s obligation to deliver a certain thing by a certain date.

On an Agile project, there is no up-front set of requirements that are locked in place to establish the project scope and the project schedule. That’s the point, right?

Therefore, the project team can never be behind schedule. There is no schedule, which means there’s nothing to catch up to.

So, no overtime.

If the team gets near the end of an Agile project and it’s clear that the software won’t be ready for production, then, first of all, that’s the customer’s fault. The customer misspent the capacity. They prioritized too many nice-to-haves and, as a result, will run out of capacity before they’ve built all the must-haves.

It’s a common rookie mistake for Agile customers.

If this happens, the customer has two options to fix the situation.

Option 1: The customer can put the software on the shelf at the end of the project and come back to it later after acquiring additional funding.

Or, Option 2: The customer can acquire additional funding right away and immediately purchase more capacity. Then the project team will launch into phase 2 as soon as the original project ends. In phase 2, the customer will need to be more disciplined. They’ll need to use the new capacity just to fill in the gaps — to build the missing mandatory features. No more rabbit holes, no more tunnel vision, no more polishing to perfection, no more nice-to-haves, otherwise they might need phase 3.

But there will be no overtime. Overtime implies that the project team is on the hook to deliver, which is incompatible with the capacity-based nature of the Agile process.

Moving Forward

If you’re about to work with a customer who is very used to Waterfall but is transitioning to Agile, watch out.

The customer might assume, without checking with you, that the project team will be on the hook to deliver everything the customer comes up with during the project. Left unchecked, the customer could easily come up with twice as much work as the team can do in the allotted time.

Get on their calendars right away to ensure they understand their own responsibilities on an Agile project. They’re purchasing your time and it’s up to them to use it wisely.

Good luck!