Project Management 101: Waterfall vs. Agile

All projects go through a similar life cycle.

You start by communicating with the main stakeholders and ensuring that you know what you need to get done and how much it will cost to do it to ensure that the project is viable.

What are the client’s objectives, goals, constraints, and needs of your seedling?

Then you make a plan: you think about what you will do and how you will do it to achieve the project’s goals.

What do you need to achieve for your client? What needs to be delivered and when? What are the needs and estimates for the project?

Then you act on that plan, revising it as needed and ensuring that you have good communication with the client and the team to make sure that you can respond to any changes appropriately because there will be changes.

You help your teammates optimize their workflow, help them keep up with the priorities and deadlines, and look for solutions to any weaknesses your team may have.

You make it happen by adapting to the ever-changing needs of the client.

Once you finish and the client is satisfied, you finalize everything by building any necessary documentation, establishing maintenance plans, and handing over the project to someone else to own it while you manage new projects.

Get feedback, ensure everyone learns as much as possible from the whole experience, and find ways to improve in the future (always keep improving).

Then you celebrate your team’s victories and make everyone appreciate their hard work.

This process applies pretty much everywhere.

And yet, some projects (and some teams, sadly) seem to fail over and over. And it is not because “they are not doing their best.” On the contrary, I can say that most of the time, they are.

People do their best within their limits.

Repeat after me: “People do their best within their limits.”

This sentence means tools, processes, relationships, knowledge, experience, etc., widen your horizons by pushing back your boundaries and those of your teammates.

So to get better productivity, you don’t need to make “more effort” or work “more hours.” Instead, you need to work smarter.

The goal is not to squeeze your employees or teammates but to create the conditions for them to thrive.

A flower won’t grow faster by just getting more light or more nutrients, or more water. Instead, it will grow faster by having the right environment to flourish and thrive.

Or putting it another way: you don’t go faster by working harder, but by working smarter.

Empower your teammates.

Now let’s think about the two main ways of doing things in Projectmanagementland: Waterfall and Agile.

If you are reading this, you probably know at least one of them.

Which one is THE BEST? Waterfall or Agile?

Let’s settle this debate.

Some of you probably just said “Agile” out loud. Most of you probably thought “Agile” after reading this. I know it. 🤓

But it depends.

For example, in construction, you can use Building Information Modeling (BIM) to create simulations of your project during the initial phase. Those simulations are a great way to apply technology to improve an age-old industry.

You can make the first phase of your project more agile, but you still have to work in a “waterfall” way because it is expensive to make changes once you have started.

You can use some technologies to add agility to a very upfront heavy process.

You can use both “Agile” and “Waterfall” simultaneously.🤯

You can splice them.

The same goes for manufacturing products. Even with all the 3D printing and other manufacturing technologies, you still benefit from a lot of upfront design.

“Waterfall” is the way to go a lot of the time. Same for building big expensive boats or a line of manufactured products.

But what about building a race car for Formula 1? Can you anticipate everything? Can you know the driver’s requirements before you make anything?

You are building a one-of-a-kind custom solution to a particular problem with a particular set of conditions for a specific user. It’s the summit of customization.

I guess it is more of a process of building something, driving it, improving it, and iterating over and over.

You may also have people in charge of higher-level innovation, but you must follow some low-level kaizen to reach that dependability and speed.

And in Software projects (which is where most of my experience comes from), the answer is obvious. Changing the design of the code should be easy (if you have high-quality code), and building and deploying your product is EXTREMELY cheap and fast—especially compared to construction and deploying a shopping mall, for example.

Building the software is one of the least expensive parts of making it and getting it to work; we call this “building” process compiling or deploying.

Building a new Saas product may need a bit more upfront discovery and design than building a custom tool for a specific business, but the point still stands: in software projects, we tend to iterate. We prefer Agile.

We prefer agile but still plan, forecast, and follow the same four main steps in our project lifecycle.

We follow “the twelve principles of the agile manifesto”:

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity — the art of maximizing the amount
of work not done — is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

We are simply talking about two frameworks for owning projects through their lifecycles. Two different types of ownership, in some sense. Two sides of the same coin (and you cannot have a coin without two sides).

And each one works better for a different setting and context, and each has its tradeoffs. They are not opposite or incompatible; on the contrary, they are complementary.

It is easier for a blueberry to grow wings and fly than for a project to be led using the wrong approach.

And what is the right approach?

As with building or software engineering, the right approach is the one that uses what works from each perspective and is a good fit for your project’s needs. The right solution depends on the problems that you want to solve.

Again, think “custom” instead of a more general “what is the best x for y.”

Even if you are not working on a custom product, your approach should be custom to the project itself.

Be flexible. Or else don’t expect your teams and projects to be flexible.