Agile, Waterfall, Wagile, and All That

I was recently asked a question on what are the weaknesses of Agile as a framework, and what do we have to do to work around those weaknesses. This is a real if somewhat unusual question, and I can imagine many people who grew up with traditional waterfall project-management methodologies asking that question from time to time, especially when they see Agile teams struggling with project delivery.

Let me make an attempt to unpack that question with a possible answer.

At a fundamental level, there are only two key concepts in Agile.

  • The first is about introducing explicit rituals to tighten the feedback loop to make sure project team members are always aligned on the same goals and problems can be discovered as early as possible. The thinking is similar to the ideas discussed in the Team of Teams book by McChrystal.
  • The second concept comes from the Theory of Constraints and says that project team members should mostly only focus on the current project bottlenecks at any one time, because more work happening elsewhere will only worsen the bottlenecks and not contribute to overall project delivery.

That’s it. Two simple ideas.

So if there is any weakness in Agile, it is not so much that there is anything fundamentally wrong with the framework, only that it’s a necessary but not sufficient framework. In almost all cases, we still need the usual concepts we know and love from traditional project management practices to run our projects well, including

  • detailed planning, tracking, and adjustments or replanning when necessary;
  • careful management of stakeholder expectations; 
  • good quality people who can work and deliver as a team; and
  • disciplined budget and timeline management.

I have seen plenty of projects that fail because they follow the strict Waterfall model and can’t adjust to changes in the broader environment. I have also seen plenty of projects that fail despite following Agile practices because they can’t get the basic project-management tasks right. So, in my view, the question is never whether we are doing Agile or Waterfall, which is largely a religious debate, but how can we achieve the outcomes we want using the right combination of ideas from Agile and Waterfall in any specific circumstance.

I will end with something I learned from one of the fathers of Agile, Rob Mees. Towards the end of his career, he only had three advice for people:

  1. Do what’s right.
  2. Do what works.
  3. Be kind.

In that order. I thought that’s a pretty good summary of the Agile philosophy from someone who spent a lifetime working in agile software development.

One thought on “Agile, Waterfall, Wagile, and All That

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s