Gradual versus sudden shift from waterfall to agile

Hello readers!

Well, it's time to pick up the thread on my consulting adventures. Too many thoughts to share.

A former client of mine asked me:

"Do you have a quick summary of the plusses and minuses of a gradual versus sudden shift from waterfall to agile for an org? In other words what are the implications of transitioning over 2 months versus 2 years?

And if you have a portfolio of programs, with a common pool of resources, do you let the majority of programs stay on waterfall and move one or two projects to agile, or is it better to move everything to agile?

Do you have any papers, books, case studies to shed light on this topic?"

My experience is this.

Gradual change has the following advantages:

• People have more time to adjust if changes are introduced piece-meal
• People will be less likely to resist change if it's something they can get their heads around
• Each incremental change can be evaluated on its impact and rolled back if it's net negative Incremental changes will have the time to engrain themselves in the daily routine, creating a ratchet effect: once the change is part of daily life, it will be hard to roll back.

The drawbacks are:

• It takes a long time to see a payout from the changes
• When changes are split up too much, they may fail to have a positive effect, causing the organization to falsely reject the change
• The longer the rollout of changes, the more chance detractors have to discredit the change program
• A long-running program of change is at risk of falling victim to business cycle volatility. An economic downturn will surely kill such a program

At a former employer, I introduced changes in packets. When I slowed the rate of change down too much,giving people a chance to catch up, the program stalled under constant criticism of detractors. When the firm had to struggle for its survival, (which it lost), they all but killed the program.

You move one project, or a cluster of dependent projects at a time.

The client responded with:
"Hmmm, hard to imagine an independent project in a portfolio. Shared resources, shared outcomes, shared technology infrastructures, shared release dates. If my assertion is true (there's no such thing as an independent project), would this not say you should go all-or-nothing with agile?

Assume you go "all-in" with agile, then it becomes a question of adoption speed, no?"

Ah, when I say independent, I mean independent delivery assets.

Another way to divide it is to decide a point in time after which new
projects are run in an Agile fashion. From that point on new projects
are properly incepted, storied and tracked.

Going all-in with Agile, or any program of change, is a recipe for disaster. You should approach the introduction of Agile as an Agile project in and of its own.