Agile Projects Are Really Waterfall With Agile

Paul Dandurand

Sorry, “agile” die-hards. Most “agile” projects are really agile with some waterfall and process. This is a good thing. I know I may ruffle some agile purist feathers, but please give me a chance to explain. I’ll start with some assumptions.


  • Perpetual projects that never end (ongoing product evolution) do have some sort of planning phase.
  • The definition of “agile” is an iterative approach allowing for change and deploying on a continuous basis rather than just one big deployment at the end.
  • The definition of “waterfall” is a sequential list of tasks where most are dependent on previous tasks.
  • The definition of “process” is a predefined set of tasks or actions to be followed to achieve a desired end.

Why my agile project is really a hybrid

One of the most common uses of agile approaches with scrums and sprints is software development projects, and more specifically those with perpetual product development cycles. My company is a perpetual products company continuously improving our Pie application. At Pie, we use agile methods with disciplined daily scrum meetings and ongoing deployments that can be as often as daily. In addition to the scrums, we’re always interacting with our teams on ideas, issues, and clarity. Our main emphasis is providing working software for our customers, and we continuously collaborate with those users. We are constantly responding to change, as it’s hard to plan in detail more than a few weeks at a time.

Sounds like true agile, doesn’t it?

However, I still call our never-ending development project a hybrid waterfall/agile approach.

Waterfall Part.png

The waterfall part of the project

I’ll use the example of our big project: re-building Pie from the ground up. Before we started to code, there was a clear set of processes and waterfall tasks I knew we needed to accomplish. Not that I’m brilliant. It’s just stuff I’ve learned that works from my years of project management and startup experiences.

The waterfall part of the project looked like this:

  • Define objectives and goal
  • Determine budget scope
  • Draft first-phase application feature requirements with design examples
  • Identify the best modern-day technology
  • Find the right new-technology development team
  • Set up DevOps environments
  • Etc.

This is a high-level example of my planning phase. Most of the steps are very linear and a few were done in tandem. Nothing at this state required agile iteration for constant change and unknowns.

Some startups just wing it, stumble, try something different, and stumble again during the pre-design/coding phase. You could call that being agile, but I call it inexperienced.

Agile Part.png

The agile part of the project

Next came the design and coding phases. This is where agile started. About a few weeks before starting the coding, I narrowed down the detailed product design using tools like Sketch and InVision and broke down my requirements into the smallest components; they became the stories (which we call tickets). We kicked off the scrum meetings and our first sprint. The tickets went through a linear process that included not started, in progress, pull requests (peer review), QA testing, and ready for production. Some tickets get bounced back as rejected, others get leapfrogged. Then the “readies” are deployed on the same or the next day.

This agile part of the project looked like this:

  • Review yesterday’s work, determine today’s targets
  • Discuss challenges and roadblocks
  • Bounce ideas around with a few customers
  • Determine focus for the next couple of weeks
  • Design the next set of features
  • Prioritize
  • Code, test, deploy, and play with Pie
  • Update the next week’s focus based on feedback, enlightenment, and roadmap targets
  • Etc.

This is just a small example of our ongoing agile process. Since Pie is an application in a competitive market, we need to continuously make it better. Therefore we skip the “close” phase found in projects that have an ending.

However, this project does have ready-made recipes as waterfall steps for certain conditions, such as DevOps Amazon Web Services setup or changes, Yellowfin BI tool setup for customers, or certain Stripe transaction processes, all which are part of the project’s sustainability.

When projects are hybrids

There are some projects that are just fine with 100% waterfall, such as those where all knowledge on what to do is predefined, the risk of change is tiny, the project timeline is short, and final deliverable is appetizer size.

What about larger implementation projects that have some unknowns, the risk of change is likely, the timeline is months, and the final output is a big meal? These are common, especially in consultancies providing systems integration, building an IT department, or upgrading a large project or application.

Many of these projects have finite budgets and timelines along with specific deliverables. Of course, projects like these could spur other, related projects or even go into second phases, again with certain budgets and end dates.


Let’s say your company is implementing such a project, and you find you could use agile methods. You may hire agile experts to help or do your own research. You may find evangelists who scream, “waterfall is dead and long live agile!” It will be easy to drink the juice, believing that you must step into the new light. Cool.

Ok, let’s say you do jump in. You make arrangements with your client that delivery will be ongoing throughout the engagement, and the big set-in-stone budget may be broken into smaller budgets based on deliveries with some need for frequent reviews. You then charge your development team to prepare the agile mixing bowl. They choose their own project tools, such as Jira or Trello, and decide the best methods for people collaboration, scrum practices, etc. You’re off to the races.

Are you now fully agile? Hold on, partner!

The agile waterfall sandwich

Your project has a much larger set of tasks, processes, and phases than just the design and development phases. You or your project manager most likely know how to implement these projects. The first steps include your best practices for project inception and planning. This blueprint is pretty solid.

And how about post-development? Even though delivery was done in small chunks and you don’t have a big go-live, you still close out the project. There are steps to wind down, get final signoffs, etc. Again, you’re in the business of doing these projects, and you know what to do in a very linear fashion. It’s in your framework.

See where I’m heading?

You’ve got yourself a hybrid sandwich. You’re working with waterfall at inception and planning, agile for design, development, and mini-deployments, then back to waterfall for close-out.

Full disclosure. The model above is pretty simplistic. In reality, your mix of waterfall and agile could be a triple-decker or more, as you may mix them throughout the engagement as necessary. My point is that, although the development team may feel the project is purely agile, your project team may see it as waterfall; the overall project from start to finish is really a hybrid of agile and waterfall.

Hmm… should we call this “Wagile”?

Although the planning and closing teams have great people-focused collaboration, it’s likely that your project manager is running these phases with tools like Microsoft Excel or Project. You will find that teams are using different tools for different parts of the project. This is not ideal for cross-collaboration, accountability, and transparency.

Individuals and interactions vs. process and tools

The Manifesto for Agile Software Development says to value individuals and interactions more than processes and tools. In the true world of hybrid projects, I believe you need to value them equally. I plan to write another blog on this topic to explain why. Stay tuned.

Finishing off my hybrid development project story, I realized last year how common it is for companies trying to implement agile to end up implementing agile along with waterfall. I found that tools on the market are either one or the other for each project. Therefore, I responded to this market need with a new agile board feature that’s designed to make it stupid easy to combine processes of waterfall and agile together in the exact same project using the exact same tool. I hope you check it out.

This article originally appeared on the Pie blog and is republished by permission.

Paul Dandurand

About Paul Dandurand

Paul Dandurand is the founder and CEO of PieMatrix, a visual project management application company. Paul has a background in starting and growing companies. Prior to PieMatrix, he was co-founder of FocusFrame, where he wore multiple hats, including those of co-president and director. He helped position FocusFrame as the market leader with process methodology differentiation. FocusFrame was sold to Hexaware in 2006. Previously, he was a management consulting manager at Ernst & Young (now Capgemini) in San Francisco and Siebel Systems in Amsterdam. Paul enjoys photography, skiing, and watching independent films. He earned a B.A. degree in Economics from the University of California at Berkeley.