The voice of business architecture. And more.

Agile Doesn’t Use Critical Path

So this happened.

Recently, I was working with a system integration consultancy, not surprisingly, on a system integration project. The SI decided to adopt a Wagile approach, where Waterfall and Agile methodologies and frameworks are combined.

Skip to the end for the punchline.


It’s always, without exception, a bad idea to choose Agile or Wagile for software projects when a specific outcome is desired by a specific date. Agile makes no such promise. Partner it with Waterfall, and you’ve assuredly got a defector in your midst. I wonder how many people blending Agile with waterfall have ever done Agile in the first place.

The Rest of the Story

This is not a case of perfection being the enemy of the good. It’s no No True Scotsman fallacy. It’s just a bad idea at the start and has virtually no possibility of a successful outcome. I would be willing to bet that the vast majority of people adopting this approach have never seen or experienced real Agile. They have been part of organisations who had adopted this at the start by managers and project managers who wanted to ride the hype curve but didn’t want to escape their own comfort zones. They read a few blogs and books; perhaps they even did a little coursework or took a few classes—maybe even advanced classes. These are the coal tenders training to be jet pilots insisting that coal tendering is integral to the solution and so is necessary to include. Anyone who’s known me in a professional capacity for the past couple of decades knows that I have some strong opinions and preferences—about Agile—, particularly when it comes to blending Agile with Waterfall. I’ve made it clear from the start that mixing the two creates an anti-pattern. The combination makes both frameworks worse. Each has strengths and weaknesses, so a decision framework is necessary to determine which to do, in which context. The answer will never be to do both. Ever.

Mixing Agile and Waterfall is like mixing ammonia and bleach. You may think it’s going to get rid of that stain, but at what cost.

Punchline Setup

So the SI has adopted the language of Agile, even some rituals, including Sprints (if by sprint we mean time-boxed iterations). They’ve also adopted aspects of waterfall. These include a Project Manager, a Gantt chart with timelines, expectations that all requirements are locked, not only at the start of each sprint, but before sprinting even begins. This all but assures that any of the ‘agility’ promised by Agile is non-existent. Seeing the rigidity of this approach, I requested to have the critical path be fully articulated.


“Agile doesn’t use Critical Path”

This was the response to my request to understand the critical path.

Moral of the Story

When Agile gets a bad rap for taking shortcuts, this scenario is something deserving of this accusation. When one defends shortcuts because it’s a part of the other side of the partnership, consider it to be suspect. It is disingenuous to include a Gantt whilst selectively excluding the critical pathing inherent in Gantt charts.

Perhaps my next segment will address the topic of an instrumental software development methodology lifecycle decision framework. Please stand by…

Leave a reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: