Creating an Agile Transformation Roadmap

An Agile Transformation Roadmap is all about getting people to change and having that change be sticky. But getting people to change is hard and resistance to change is often the thing that derails Transformation.

The thing to recognize about change is that it’s usually not that people don’t want to. It’s that they can’t see how to do it. They can’t see how to get from point A to point B safely and pragmatically.

All they can see are the impediments, the dependencies, the resistance, the scope, and the magnitude of what must happen to be successful.

The challenge isn’t to have the right answer. The challenge is to get people to see.

Our Agile Transformation Roadmap, our change model, is all about getting everyone to see what’s possible, creating safety for the people and the business, and building trust at every step of the Transformation.

The Journey to Agile Transformation

The starting point on our Agile Transformation Roadmap is always to understand where your company is today and where it wants to be in the future.

We have a thinking tool called the 4 Quadrants we use to help you visualize what we’re trying to accomplish.

Most of the organizations we encounter are in the upper left-hand quadrant—predictive emergent. This is the quadrant of ad hoc delivery, death marches, heroics, and chaos.

Depending on how Agile an organization wants to be, we’ll move them down and to the right through a series of intermediate steps called Basecamps, which we’ll discuss in a moment.

The critical thing to understand here is that organizations have competing needs. Executives need their teams to make and meet commitments. These executives made promises, and their organizations need to deliver.

That said, these same executives live in a world of uncertainty. They’re responding to change all the time and need their teams to respond to that change with them. The thing to recognize is that the need to be predictable competes with the need to respond to change and be adaptable.

If we optimize for predictability, we make it harder to change. If we optimize for change, we make it harder to make and meet commitments.

Markets have similar dynamics. Some markets are emergent, which means they’re new or don’t exist yet. And so, the requirements are unknown. Other markets are convergent. Companies operating in a convergent market know what they want, and they want it fast, cheap, and on time.  So, your Transformation will look different depending on which type of market you serve.

We aren’t attempting to make a value judgment on predictability and adaptability or emergent and convergent. But, recognizing where you are and what you value is critical to your Transformation journey.

The Agile Transformation Steps

Earlier, we introduced the idea of something called a Basecamp.

A Basecamp is simply an intermediate step along your Transformation journey that allows you to measure progress, claim an intermediate victory, and possibly rest and refuel for the next leg of your Transformation journey.

In our change model, Expeditions moving through Basecamps are the primary unit of progress in an Agile Transformation.

So, what are Expeditions?

Expeditions are groupings of teams that will make the Transformation journey together and consist of all the organizational pieces necessary to fully implement the new operating model.

An Expedition also has all the structural elements necessary to deliver the product, coordinate and overcome dependencies, and make prioritization decisions and economic tradeoffs.

As Expeditions move through the Basecamps, we should see each group of teams achieve a valuable outcome for the business.

We’ve identified five different Basecamps, and each one has its organizational outcome.

• Basecamp 1 – Stabilize the System
• Basecamp 2 – Reduce Batch Size
• Basecamp 3 – Decouple Dependencies
• Basecamp 4 – Localize Investment Decisions
• Basecamp 5 – Invest to Learn/Innovation

Build Trust with Outcomes-Based Planning

Remember when we said that an Agile Transformation Roadmap should build trust at every step of the Transformation? Outcomes-based planning plays a large part in the trust-building department.

Agile coaches and trainers will often look at things like how many teams have implemented Scrum, a decrease in escaped defects, or an increase in throughput as signs that the Transformation is working. We’d suggest that these lagging indicators aren’t the right things to look at.

Ultimately, executives don’t care how many teams have implemented Scrum. They don’t care about escaped defects or throughput either. They only care about those things to the extent that it’s helping them achieve their desired business outcomes.

So, to build trust, we must be able to tie those common lagging indicators to things that executives care about, and that’s where outcomes-based planning comes in.

Every activity the teams do should roll up into a set of outcomes, and those outcomes should demonstrate progress toward an agreed-upon goal.

We won’t know all the activities in advance, so we must begin justifying investments by creating hypotheses, conducting experiments, demonstrating outcomes, and pivoting based on what we learn.

The goal is to get good at sequencing the outcomes that we must achieve and ensuring that the completed activities tie back into the desired business outcomes.

As we start to see progress, outcomes-based planning provides a paper trail that justifies the Transformation activities. In turn, the executives begin to buy in and create more space for the Transformation and clear a wider path for the change to occur.

The Agile Transformation Change Model

The 4 Quadrants, Basecamps, and Expeditions are all about iterative and incremental change. Outcomes-based planning is about agreeing on a set of outcomes and creating demonstrable progress toward those goals.

Those same principles carry over into the way we structure an engagement. Remember—the roadmap should build trust at every step of the Agile Transformation journey, even this one.

So, a typical engagement looks something like this…

Two-Day Workshop

We begin every Transformation with a two-day workshop where we gather 20-30 leaders in a room and collaboratively build a Transformation Hypothesis.

We build the Transformation hypothesis to get key organizational leaders aligned and rallied around a vision for what’s possible.

The first set of goals involves getting agreement around the key business drivers and a shared understanding of the impediments that are likely to get in the way of the Transformation.

The next set of goals involves agreeing on how the team will approach the Transformation, what kinds of things need to change, and how the change can happen safely and incrementally.

The third set of goals revolves around looking at where the organization exists today and determining a possible operating model within the LeadingAgile reference architecture.

It’s essential that the leaders see their organization within the reference architecture. Finally, we need a detailed 90-day plan for what the first 90 days of discovery will look like and a point of view for where we might Pilot to get the most value as fast as possible.

Define the End-State

The advantage of having a small group of senior people in the room is that they can talk candidly and reach an agreement very quickly.

The downside is that you don’t get broad-based consensus and support for moving forward. We call the first step in the change model a Transformation hypothesis because it’s just that, a hypothesis and hypotheses need to be validated.

The Define the End State—or Discovery Step—validates the hypotheses created in the initial step and engages the broader organization.

The mechanics of the Define the End State step are relatively simple. With the Transformation Hypothesis as an input, we begin engaging the people in the target organization in one-on-one meetings and group sessions, as appropriate.

There should be a regular cadence with the leadership team to formally review intermediate deliverables, challenge assumptions, and identify risks. By the time we create the final report, there should be no ambiguity and no surprises.

Pilot

Now that everyone in the organization is engaged and participating in the change, it’s time to start getting to work. The Pilot is a special case of the Expedition One to Basecamp One pattern.

It involves getting a subset of the organization—a single Expedition—to a stable, reliable, and predictable state. It needs to be a beacon to the rest of the organization for how the Transformation may proceed. It needs to be our first reference implementation.We’ll finalize much of the Transformation planning as we exercise the Expedition in conjunction with doing the work. And we’ll immortalize everything we need to do for the rest of the organization in a document called the Transformation Playbook.

General Rollout

Now that we have a working Pilot and a revised Transformation Playbook, it’s time to engage the broader organization in change. The rollout involves moving all Expeditions to Basecamp One and, likely, beyond.

Each new organization you engage will begin by forming a Transformation hypothesis. Then it will Define the End State. Finally, it will move the Expedition to its target Basecamp. The organization is effectively looping through the Change Model steps, progressively elaborating the plan as it goes deeper and deeper into the enterprise.

Assuming the target organization was fully engaged during the Define the End State step, everyone should be clear and ready to go. The rollout involves executing the steps in the plan, which generally involves everything necessary to get the target organization up and running and performant to the organization’s expectations.

As the rollout gets underway, we manage risks, escalate issues, and produce weekly progress reports. Leadership is engaged for the duration of the rollout and is actively involved in helping to remove impediments. Learnings from the rollout are captured and built into the structure and content of the emerging Playbook.

Wrapping It Up

The challenge isn’t to have the right answer. The challenge is to get people to see.

It’s impossible to know every activity we’ll have to do in the beginning. It’s improbable that we’ll know all the impediments we’ll encounter along the way. And so, we must mitigate resistance and uncertainty and create safety for everyone in the organization by crafting a resilient and adaptable approach to Transformation.

We believe in iterative and incremental change. We strive for top-down intent and bottom-up execution. And we’re committed to demonstrating tangible progress toward business outcomes that matter.

So, the next time you’re creating an Agile Transformation Roadmap, compare it to our change model and ask yourself…can you see the change.