7 Telltale Signs of Waterfall Agile

This is a follow-up article to earlier published Addressing the Irony of Waterfall Agile.

At Agile OD we get called in by client organizations to resuscitate stalling agile transformation programs. Waterfall Agile is a frequent pattern of failure we observe, and holding up the mirror to show why it’s a problem is often a big part of our effort with client leaders. Let’s break it down:

7 Telltale Signs of Waterfall Agile

1. Ex-co exempt

2. Ran by PMO

3. The Map is the Territory

4. KPIs, stage gates, Gantt charts

5. Big Bang

6. Long March

7. Oblivion

1. Ex-co exempt

The first sign that worries me massively is when there’s no willingness from the leadership team to go through the agile transformation themselves. I mean, they’ll say that they’re part of the agile transformation, but if the executive committee is intact in shape and there are no plans to change it, I think it’s safe to assume they are considering the ex-co as sacred zone and left to be untouched.

So this is where I ask our coaches to flex their hybrid executive/agile/organizational coach muscles to the max and influence the whole C-suite to buy into the idea of trying agile.

If the leadership team starts talking about changing the cadence of their meetings (“Shall we try daily standups ourselves?”), reporting (“Shall we put up our own Kanban board too?”) and general attitude to anything (“How might we…?”), literally, now we’re talking!

2. Ran by PMO

In a functional, hierarchical organization, leaders make the strategic decision, and hand them down to the next layer of the leaders. Tactical decisions on how to fulfill this order is devised and decided by these next layer of leaders (middle management), and thereafter it’s their role to manage the execution further down the chain of command.

Taylorism and the vertical organization is forever pervasive. When we see an Agile Transformation Project Management Office (“PMO”) established, it’s, déjà vu.

Yes governance is needed in managing agile transformation that spans across the organization. However, it’s a question of the purpose of this governance. Is it for coordination and facilitation, or control?

Distributed teams, a major purpose of agile, benefit most from agile with autonomy and self-organization. If the agile setup is introduced with a central controlling body, i.e. a traditional PMO, then the teams will be deprived the opportunity to self-organize.

Don’t get me wrong; I’m not smoking anything to believe that agile transformation can “happen” without a coordinating or orchestrating function in the center – there’s a lot we learned from the failure of Teal organizations and Holocracy. It’s more of a question of, is this function in the center facilitating the transformation, or controlling it? PMO in the traditional sense is mainly associated to a controlling function. Might as well not use the label.

3. The Map is the Territory

Have you heard of semantic scientist and philosopher Alfred Korzybski’s 1931 saying “the map is not the territory”? People often confuse models of reality with reality itself – it’s the planning fallacy; the sense of satisfaction that it almost feels like the job is done when you plan out everything well.

Got a great plan so all we have to do is carry it out, and Bob’s your uncle. You might laugh but planning fallacy is an everyday idiocy happening in the office.

Same with agile transformation. You hire or appoint a great transformation lead or send in the cavalry (the consultants!), they spend a few months laying out the plan, come up with a big organization redesign schema, and boom, Bob’s your uncle.

4. KPIs, stage gates and Gantt charts

And that big schema comes with a full step-by-step layout of “this is how we’re going to get it done”. And “to make ourselves credible we’re going to have all the KPIs and stage gates to pass ready”. Solid plan right?

We all know that nothings goes as planned. Then what the hell our we doing??? People, please, this is functional stupidity.

When we start seeing people coming up with the courage to call out the BS, it’s evidence of psychological safety and that now the change and transformation is getting off on the right foot.

Throw out KPIs, stage gates and Gantt charts. Replace them with emerging properties of evidence (OKR is a good framework), Sprint Planning, and Kanban boards.

5. Big Bang

I don’t believe in agile transformation that doesn’t start from pilots. As a matter of fact, I don’t believe in any change, transformation or innovation endeavor that doesn’t start from a pilot or any sort of experiment. You can’t force change; transformation is a very human, gradual, organic process.

So back to the awesome transformation lead and the cavalry that’s been sent in. If they
convince leadership to go for a big bang, let’s go in all together all at once roll-out of their grand schema, stop them with all your might.

6. Long March

And don’t be fooled if they say, don’t worry, we’ll do this in stages. We’ll have milestones put in place to check if we’re ready to roll-out the next phase.

Now leadership, you’ve been committed to the Long March. Six months, twelve months, eighteen months, your whole organization will be trapped in and enslaved to the plan. Gone is the idea that agile is all about growing success in iterations. Staying here powerfully is putting in everybody in the long, single line journey of achieving planned milestones, even when they incur the inevitable delays.

7. Oblivion

At some point the pointless Long March will lose steam. There may be an official announcement of cessation of the program, or often not. Some heads may roll, the cavalry definitely fired, but otherwise it will be a quiet end.

Oblivion is a healing mechanism. Some may look back and think, what was that all about? Others will blissfully get back to the good ol’ ways, finding relief in the thought that now that this has failed and died, it’s going to be a quiet couple years until somebody comes up with the next stupid idea like this.

From a Systems Thinking perspective, there are remarkable similarities between individual human beings and human organizations (corporations, public bureaus etc.). Both are organic systems, and similar principles for change and transformation apply.

It’s helpful to think in analogous terms with our own mind and body. As individuals, when we want to make a change in behavior or adopt a new way of doing things, we just can’t tell ourselves to do it, right? First is the desire, next is the awareness and then the many attempts of trying commences – if personal change and transformation was easy, there won’t be that many of books on habit change out there, right?

Same with organizational change and transformation. First you need a Fair Process to get everyone onboard. Then a good amount of time and effort for learning; learning our current state, learning our desire for a different future state, and learning possible ways to get there (e.g. agile). And then the many attempts of trying commences.

Waterfall Agile runs on the assumption that we can tell the organization to change, and it will. The telling comes in the form of a grand plan and a planned execution enforced by a controlling function. The assumption is wrong, and therefore it won’t work.

If your organization is already in the midst of an agile transformation, it’s never too late to stop, check, reflect, retrospect everyone’s assumptions. That activity is itself agile, and starting from there, you’ll get back on the path for a successful transformation.