[Podcast] Agile Adoption Is Not Agile Transformation
Listen to the latest episode of The Agile Reformists podcast from MATRIX Agile Coach Todd Sussman below, or keep reading for a summary. Subscribe to The Agile Reformists podcast on Spotify to keep up with our episodes released every other Tuesday.
I have been an Agile Coach since 2012, and that was after a 15-year stint as a developer and architect. Most of that time was spent using some form of Agile practice. I’ve seen a lot in that time, and one thing I see over and over is organizations using the words “adoption” and “transformation” interchangeably as it relates to Agile.
This is a misconception that often leads to disappointment and perceived failure.
Agile Adoption
Let’s start with adoption. You can usually identify if the current engagement is an adoption when someone says, “we will learn to do Agile.” That’s because Agile adoptions focus on process change — to move from a traditional delivery model to one that supports Agile values and principles.
You might even hear the phrase “we are adopting scrum,” because for most adoptions, scrum is the preferred process. If the adoption is successful, the practitioners will have changed the way people accomplish their work. And there is great value in that alone.
Agile Transformation
Now contrast that with the idea of an Agile transformation, where the goal is to transform the culture of an organization. In other words, to reevaluate how a company delivers value to its customers.
Can it achieve true business agility and meet market demands as they change? Transformation is about discovery and the journey to agility. In a transformation, scrum, Kanban, XP, or any other flavor of Agile becomes the vehicle for the journey.
How these terms differ from each other
The first and most noticeable difference is the speed at which the change can take place. When adopting someone else’s practices, time can move extremely quickly.
My first experience with Agile was as a developer. An Agile coach showed up on Monday, we had two full days of training, and on Wednesday we did our first sprint planning. It was ugly.
Let’s use a more recent example —Spotify. I can’t tell you how many organizations I have heard say they are “adopting the Spotify model”, which is ironic given that in that same document they are using to drive their adoption is a disclaimer – Spotify didn’t invent the model – it was simply a “snapshot in time” during their transformation to agility.
That snapshot in time is so vital to a transformation because it involves changing culture, and that can take years. In the spirit of agility, practitioners need to understand how to create smaller increments of value that can be targeted.
As the speed of change can increase, often the reference timeframe decreases. Frequently, organizations moving from a more traditional model to one of the Agile frameworks will view it in the context of delivering projects or some pre-defined output.
They might pull people from their functional silos on a UI team, or the API team, and put them together on a cross-functional team, but they still report to their same managers within their same functional silos.
These types of organization structures can create an environment where managers feel they need to protect their authority or domains. There might be bottlenecks when it comes to making quick decisions that affect the team, and in turn cause the organization to miss out on a new opportunity.
On the other hand, transformations focus on long-running cross-functional and sustainable teams. These teams are aligned with customer experiences and product lines. They expect to measure their alignment by looking at things like rapid innovation, or the ability for continuous delivery in the name of faster market validation.
This is one of the main reasons why transformations fail. It affects the power and control structure that currently exists, and that makes people defensive.
In an adoption, only the team changes the way they work, but in a transformation, the entire organization including HR, Finance, Marketing or Operations will have to change the way they get work done.
While it might sound all doom and gloom if you are in or have completed an adoption, that’s not the case. I have seen some very successful adoptions, where things like predictability and quality were the main benefits desired. By implementing scrum, practitioners put a focus on things like:
Having a product owner who will be accountable for a prioritized backlog
Allowing the team to focus on a single source of work
Fostering team ownership of sprint deliverables with T and Pi-shaped members
Increased transparency and shorter feedback loops
A focus on reducing waste such as context switching or too much upfront planning
This in turn allowed the teams to accelerate and become high-performing, sometimes realizing as much as a 100% gain in productivity. But that is peanuts compared to the productivity gains found in organizations that have succeeded in true transformation.
I have read whitepapers where they claim to see as much as 300% gains in productivity, but that’s still not the greatest benefit of an Agile transformation.
If you want your organization to change its culture, there needs to be something people can believe in, and that’s where transformations stand apart.
Imagine what happens to your employees as they move to self-organizing and empowered teams. You get better employee engagement, leading to higher morale and lower turnover.
You get more creativity and innovation as the teams take ownership, not just of the deliverables, but of the outcomes themselves.
And just like in the Spotify model, you should see a reduction in oversight and managerial layers between the customer and the delivery arm.
In summary, Agile transformations are about changing culture. Agile should not be the goal; it is simply the mechanism that allows you to take advantage of the changes in that culture.