Is Hybrid Agile Project Management Effective?

Is Hybrid Agile Project Management Effective?

It’s interesting to me that the main people who talk about using hybrid agile project management approaches are traditionally trained project managers. They believe there is a special blend of waterfall and agile techniques that will yield better results than either approach alone.

They want to take the best of both worlds. I think they are misguided. They may get better results than using waterfall alone but are unlikely to improve on a more pure agile adoption. They won’t get the business agility that their organization needs to compete.

How Hybrid Agile Project Management Has Evolved

What has happened is that people who are most familiar with traditional project planning and execution approaches have resisted change. Rather than let go of traditional ways of working, they have kept it.

To give the appearance of change, they’ve added bits and pieces from Scrum or other agile approaches. They use the pieces they like or understand and ignore the rest. They begin to call their existing waterfall phases “sprints” and their requirements “user stories”.

They have a meeting that they call the daily standup meeting, but it sounds more like the project manager is conducting an interview of each team member. And occasionally they toss out some phrases they’ve heard like “fail fast”. They even go so far as to call themselves Scrum Masters.

Changing the name of something doesn’t change what it is. I can call myself a world class athlete but that doesn’t make me one. And changing the name of something doesn’t make it a more effective approach, or make it more agile. If the goal is business agility, why settle for half measures?

Hybrid Agile Approaches Don’t Lead to an Agile Mindset

The idea of a hybrid agile project management approach falls somewhere between wishful thinking and outright crazy. It doesn’t address the fundamental mindset change needed to use Agile effectively.

How can you reconcile the project manager as the “single throat to choke” in traditional approaches with the self-organizing teams of Scrum and Agile? How do you reconcile sustainable pace and team commitments of Agile and Scrum with the fixed dates and scope of traditional approaches?

It simply doesn’t work because we are talking about two fundamentally different and oppositional mindsets about people and teamwork.

The people advocating for hybrid agile project management approaches don’t really understand. They think it is cool to mix and match. (BTW, I hate the expressions “Scrumerfall” and “Wagile”! Stop please!)

PMI Promotes Hybrid Agile Approaches in the Agile Practice Guide

Unfortunately, PMI continues to promote the idea of mixing and matching traditional and agile approaches in their 2017 Agile Practice Guide. Whether out of lack of understanding, or a stubborn resistance to let go of traditional approaches, they seem to think it is OK to take bits and pieces and mix them together.

I like that PMI published the guide, I just have a fundamental disagreement with them about how they view the Scrum Framework and the Agile Mindset. You can read about my analysis of PMI’s Agile Practice Guide here.

No Such Thing as Hybrid Agile Project Management Templates

Last year I met with a traditional project manager who was being tasked with leading multiple Agile teams. These teams were going to be using the Scrum framework. We talked for about an hour and in conclusion, he asked me for some templates he could use to manage using what he called Agile project management. That was all he felt he needed.

So this project manager has zero experience with agile, he is taking on a large agile program, and all he needs is a couple of templates? Maybe he slept at a Holiday Inn Express?

Don’t Use the Scrum Framework in Bits and Pieces

Hybrid agile doesn’t work with Scrum. Scrum is a framework for organizing teams and building solutions based on Agile Values and Principles. You don’t change templates to use Scrum, you change your organization!

And you don’t adopt Scrum in a piecemeal fashion. I don’t recommend tailoring the Scrum Framework even in organizations that are transitioning completely to Agile.

It’s not helpful to pick and choose the parts of it that you like or understand and want to implement. Adding bits and pieces of Scrum to something else doesn’t make it Scrum. As Ken Schwaber, co-creator or Scrum says, “Scrum is simple, just use it as it is“.

Is This Simply Resistance to Change?

What’s behind the desire to mix methodologies? It seems like a lack of true understanding, as well as fear and resistance to change. There is a reluctance to let go of what has worked in the past.

And an even bigger reluctance to let go of control. And in the case of the “templates” project manager, it’s a belief that anything can be managed with just the right template.

I am not saying that traditional PM methods aren’t successful. I just don’t think they have a place on a Scrum or agile team, especially if you want to call what you are doing Agile. Stop mixing things up and use the right approach for the goals and culture of the organization.

This Post Has 3 Comments

  1. In light of what you are writing above, you’re book (Agile Project Management) makes little sense. Could you clarify? I have not yet read you book btw, just read the amazon teaser:

    “AGILE PROJECT MANAGEMENT is a detailed guide to successfully applying Agile, Scrum, Kanban and Lean to your next project. Based on years of hands on experience implementing these proven techniques, the book walks through the details of building and Agile team and planning and executing an Agile project.”

    1. Benjamin, I couldn’t agree more. In hindsight, everything I’ve learned in the last 4 years has made me wish I had written a different book, or at least titled it differently. Should I kill the book and remove it from circulation?

  2. Thank you for replying Anthony.
    I have found it really difficult to develop an approach which both allow plan driven approach and allow us to be agile.
    In the company I work we set up new subsidiaries where we implement “our highway” of systems and processes. On one hand the setup needs to be fully plan driven on many tasks, from recruiting managers, getting government approvals, to wiring networks in new office buildings. On the other hand we have a running suite of applications what we continuously develop using more or less full scrum. The issue is how to create a WBS and schedule which also encompasses the “IT stream”.

    Could you share what the key insight you have gained the last four years that you didn’t have at point of writing the book, on how to tackle such a combination of plan driven sequential activities vs implementing applications being developed in a scrum environment. I would think my company is not the only one facing such issues.

    Regarding your book, I think the question is whether or not it can help people in the same situation as I am in. If not, then follow your conscience

    Thank you in advance.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu