Red Green Repeat Adventures of a Spec Driven Junkie

Waterfall vs. Agile

At a company training, I attended a course called: “Agile Project Management”.

The first part felt like a complete waste of time. The speaker discussed what agile is without diving into how to agile. I started multi-tasking, catching up on emails, my time-sheets, etc.

When I heard:

This is the difference between Waterfall and Agile

That immediately got my attention.

There’s so much talk about what agile is that no talks about how to agile. In a way, I am learning that may be on purpose because the agile principles that are more important than how to do it.

When the speaker showed this diagram:

Waterfall vs. Agile

What makes this diagram crystalizes for me is how agile is different than waterfall.

Waterfall vs. Agile

In waterfall, everyone knows how to run a project.

In agile, how do you know you’re not running your project as waterfall? Or even “sprint-based waterfall”? Or even what I call: “crouching-agile; hidden waterfall”

This diagram shows exactly the differences between waterfall and agile at an organization level according to these components:

  • Scope: what are the requirements or features to the solution?
  • Resources: which people involved?
  • Time: when to deliver the solution?

Waterfall - Scope

In waterfall, the key stakeholder defines a fixed scope and lets the contributors define the resources and duration to a solution.

Whenever you hear about a “military project” that has gone over budget and delayed, it’s most likely they are using waterfall for their project management style.

There is a good reason military projects use waterfall. The key stakeholders in that organization care more about scope than resources or time.

Agile - Resources & Time

For an agile project, the key stakeholder defines the resources and deadline while the individual contributors define the scope.

In agile, the solution may be anything that solves the problem. The solution may not be in the form of the organization’s primary output. It just has to solve the problem.

Agile Traps

As agile does not prescribe a set way on how to implement it’s principles, there are traps an organization can fall into implementing agile.

  • Controlling scope, resources, and time
  • Hidden waterfall

Controlling Scope, Resources, and Time

This is where agile can be off-putting to key stakeholders as individual contributors can come up with a solution they did not envision or “align with the organization’s values”, which may be a sign of larger organization issue.

The easiest way for a key stakeholder to take control again is to… define scope. A default way to manage.

In an agile organization, this is where key stakeholders love agile, it’s because they can control all three: scope, resources, and time while under the veil of “being agile”.

How do you know if the key stakeholder is controlling scope?

They define how to do the work. They define what the solution is. They know what the problem is.

This is key, if you don’t know the problem, how do you know the solution addresses it? Can you come up with alternative solutions that may address the problem?

This is the test to see who is controlling scope.

If the organization is running on any kind of time-line, then key stakeholders are inadvertently or purposely controlling all three: scope, resources, and time.

Hidden Waterfall

Another way to test if your organization is in the “agile trap” is to ask key stakeholders when they expect delivery of a solution.

If they cannot give a date, then the team is running as a waterfall project under the guise of agile. “Crouching Agile; Hidden Waterfall”.

In a way, key stakeholders avoid the “time” question because two conversation can happen:

  1. adjusting scope
  2. getting appropriate resources

Depending on where the key stakeholder is in the organization, this can be an easy or uncomfortable conversation.

Be Consistent

Waterfall is a valid project management style. It comes easily to key stakeholders because it’s easy to control and everyone in the organization to understand.

For agile, making deadlines, letting contributors decide solutions - that requires a different management style and organizational culture. As there’s no “how to agile manifesto”, it is tricky for everyone in the organization to understand what their role is.

This is where agile could be getting a bad reputation, this fundamental understanding of the difference between agile and other project management philosophies.

As an individual contributor, nothing is more frustrating than hearing one thing but seeing inconsistent action from the organization.