4 Common Misconceptions About Agile Transformation

As a community, we have developed a handful of team-based Agile approaches over the years; some of which we would consider scaled. But here we are. More than 20 years past the signing of the Manifesto, and we still don’t have this whole thing nailed. Implementing Agile, especially in larger, more complex organizations, still seems to be a black art.

Why is it so difficult? Why is Transformation so hard?

I wasn’t around when things like XP and Scrum were invented, but I have been lucky enough to spend time with many of the original signers of the Manifesto. I imagine it went down something like this.

We have these small teams working on troubled projects. When things hit the fan, often we get everyone in the same room. We pull the customer close. We make everything visible. We operate in a highly collaborative fashion. When we do this, we seem to be able to deliver and test frequently.

Someone along the way came up with writing requirements as user stories and putting them on cards. They hypothesized that estimating the cards and doing burn-down charts would increase throughput. That having weekly planning cadences; daily standups, reviews, and retrospectives would give people a reason to get in the same room and collaborate. Eventually, they landed on the ideas of Test-Driven Development and Continuous Integration and Deployment.

Over time, different roles and responsibilities emerged. All the things we consider hallmarks of a small team, Agile methodology.

As these methodologies emerged, the people inventing them found each other. At one point, 17 of them got together in Snowbird, Utah for a weekend of skiing. In the hunt for what these methodologies had in common, these 17 came up with the values and principles in the Agile Manifesto.

Why is this important?

Well, the methodologies organically emerged as a set of practices. They were codified into a set of values and principles. What is certainly noted, but often not materially emphasized, is the importance of the small, collocated team in direct contact with an actual customer.

I’d suggest small, collocated teams are the secret sauce behind the practices, values, and principles of Agile methodologies.

Fast forward a few years and Agile methodologies have a bunch of success and start to go mainstream. Things really take off with the advent of the CSM certification and PMI finally recognizing Agile as a legitimate way to do software project management. Traditional project management methodologies are process focused and agnostic to organizational design. Agile project management is totally dependent on organizational design.

As an aside, I was in the room when the PMI ACP certification was invented. There was almost no discussion of the importance of teaming strategies to the methodology. Somehow it was out of scope.

So why the history lesson?

I think it’s relevant to how most of us think about Agile adoption or Agile Transformation. And I think it leads to many of the common misconceptions I see about the introduction of Agile ways of working.

Misconception 1: Agile Transformation is About Installing Practices

The most popular misconception is that Agile is a set of practices and can be installed by trainers and coaches.

This is the easy button form of Agile Transformation. You train your teams on Agile, the teams start using Agile, recognize their impediments, and change the systems to be more effective at delivery. In practice, most teams are not empowered to change the systems they operate within, so they bastardize the processes to accommodate the dysfunction. This is where we see lots of teams going through the motions of Agile and not getting the business benefit of doing the approach.

The litmus test for this is as follows. Can any given Agile team claim to have a stable velocity against a known backlog? Can they produce a working tested increment of software every week or two that can be validated by an end customer?

If you are doing Scrum or XP and cannot do that, you aren’t doing Agile very well. Even if you are doing Scrum well. It is possible to do Scrum by the book and not create the results. Same for XP. Same for SAFe. Same for LeSS. Same for all of them.

Misconception 2: Agile Transformation is About Changing Culture

The next most popular misconception about Agile Transformation is that it is a culture problem.

The challenge is that it feels like a culture problem. It feels like Transformation is hard because of command-and-control leaders who don’t want to delegate to or empower the teams. It feels like an attitude and beliefs problem. A behavior problem. But let me tell you, if you understand how and why Agile works, and you understand what will get in its way, these leaders are right to stand in the way of Agile. Implementing Scrum or XP or Lean Startup on top of a tightly coupled legacy mainframe system is a recipe for disaster. Total chaos.

My observation over the past 20 years of doing Agile and transforming organizations, is that if you address the underlying technical and organizational concerns, you put forth a credible strategy for dealing with dependencies, and governance, and audit and compliance, you can often get people to run an experiment. They are willing to give another way of working a try. But often in the early stages, that means compromises to the Agile ideal. Allowing some compensating controls to emerge to deal with unresolved dependencies.

One of my favorite user group questions to ask is this. If you were king for a day, you could do anything you want, you could change anything in the culture or mindset of the organization, what would you do tomorrow? The caveat is that you had to start producing working tested software within a few weeks. What would you change in the org design? The technology architecture? The governance model?

You see, many of us want to believe that the teams know best. And that may be true about building software. But it’s not always true about running a for-profit software company.

Misconception 3: Agile Transformation is a One-Time Event

Another popular misconception is that Transformation is a one-time event.

Transformation itself is a process that takes years. It has a starting place. It has intermediate states. It has a defined end-state. But as customers and markets change, your organization has to change with them. So, the misconception is that the process is linear, and once the process is installed, or the culture has shifted, you will be done.

In my experience, this is never the case. We find that getting an organization to change requires a series of intermediate states that have to be traversed as you systematically improve the organization to enable greater Business Agility and move closer to the ideal.

Frankly though, most of my experience in Agile is in larger, more complex enterprises. My corporate experience prior to joining VersionOne, Pillar, and starting LeadingAgile was in financial services. Large mainframe platforms. Complex business rules. Audit requirements. Governance and control. Dates and requirements that mattered to our customers.

We could do a lot with Agile, but Agility was really difficult. So, I’ve had to make change in large companies since the very beginning. If you’re in a small single team, your mileage might vary.

Misconception 4: Team-Level Agile Creates Business Agility

The fourth and final misconception is that the things you do at the team level are sufficient for running Agile at scale.

My last post was about whether or not SAFe was Agile. SAFe is an approach for doing Agile at scale. In some ways SAFe is not sufficient. In others, it’s way too much. Safe is too willing to accept organizational dysfunction and dependencies as immutable. It doesn’t give us a clear path for change to make the overhead go down over time. It’s too complicated and too complacent with that complication. But SAFe is trying to solve a necessary problem that small teams don’t face. Dependencies and governance.

If you don’t believe that is an issue, you haven’t worked where I have worked, and you haven’t experienced what I have experienced.

Dependencies and governance are a reality. In the presence of these impediments, you have to manage them. But if you don’t have a plan for resolving them, SAFe will limit your ability to be Agile and to operate with Business Agility.

So, Transformation is about creating the conditions to do Agile well. And in large organizations, training teams on how to do Scrum or XP is wholly insufficient. You have to address the overall operating model. You have to address governance and compliance and audit and control. You have to tell the rest of the organization how it fits in and plays, or it’ll get in the way and fight your change efforts.

The Reality of Agile for Large Organizations

So, let’s get back to where we started. The early days of Agile.

In the early days of Agile, teams and customers and continuous deployment was almost assumed. In large organizations adopting Agile nowadays, it almost never exists.

Lifting the practices of a small team Agile approach and suggesting they will work in large, complex organizations is incredibly naive. Training teams working on a large-scale mainframe platform is often irresponsible. Blaming the culture of the organization for the resistance to change is a little myopic. You have to be a deep expert in the impediments that are going to get in the way of going Agile. You have to have a plan to remove the impediments over time and for introducing new ways of solving the same problems. You have to have a credible strategy for what you can do now, and what you can do later, as you improve the system.

I’ve been on record for a long time advocating what we call a systems-first approach.

It is possible to define an organization that minimizes dependencies. That orchestrates the ones that remain. that connects to governance and OKRs and KPIs. That connects to a large investment thesis and generates the data to show we are moving in the right direction. That system can be designed, it doesn’t have to emerge through trial and error. It is not big upfront planning to think through your solution architecture and org design and to create a teaming, governance, and metrics strategy that will lead to greater Business Agility, and most importantly, keep the organization safe and protected while it is changing.

In the presence of such an end-state design, a vision for the system of delivery,  you can start to think systematically about how you would incrementally and iteratively introduce change to the organization. You can start thinking about how to systematically introduce change and process improvement that doesn’t disrupt your business operations. The change plan and the timeline can be visible and accountable. You can come up with ways of engaging the organization to support the change and teach it how to maintain the systems you put in place, over time, as customers and markets shift around.

Over the past 12 years, LeadingAgile has had to learn to separate different sets of concerns when talking about Agile and Agile Transformation. As we have done this for our clients, we’ve centered on the following language.

System of Delivery

The “to be” operating model of the organization. You’ll find that you’ll have several of these depending on the constraints you have to overcome. You’ll end up with your initial state, several possible end-states, and several transition patterns. Agile isn’t one size fits all and change is a process.

System of Transformation

How are we going to introduce the changes. What parts of the organization. How long is it going to take? What are the leading and lagging indicators. How do we know we are making progress? How do we know the change is working and producing the results we desire.

System of Engagement

How do we lead and manage the transformation team. How to do we coordinate work? How do we create shared understanding across the organization? How do we create shared understanding and reduce cognitive dissonance during the change?

System of Continuous Improvement

What capabilities do we need to sustain the change and adapt as the organization responds to its customers and markets? Do we need coaching services? Training services? Business architecture? Value stream analysis? Project or program management.

Systems Over Practices & Culture

So, in conclusion…

To lead an effective Agile Transformation, it has to be more than practices. It cannot start with culture. You have to start with systems design.  Reinforce practices. And coach and develop culture over time within this new operating model. Change is not a one-time event and there will be various Transformation patterns that you’ll want to implement over time as you are able to improve the overall system and lighten up the operating models.

We’ve found it helpful to think in terms of various systems of change. System of Delivery, System of Transformation, System of Engagement, and System of Continuous Improvement. What will the operating model look like when we are done, how will we get there, how will we get people to come along, and how will we keep them there once we are finished with the initial effort.

What Transformation is NOT, is teaching people how to do Scrum or SAFe. Valuable, just not Transformation. Transformation also isn’t telling your leadership they are bad, and they need to trust the team. It’s about establishing reliable systems of delivery that your leaders can trust and know how to operate, over time. That help them run the business, achieve key performance results, and sustain the company into the future.