What It Takes to Develop an Agile Transformation Strategy

Okay… this is going to be a precursor to a more fully developed whitepaper, but I want to see if I can tightly articulate the LeadingAgile approach to designing and executing an enterprise Agile Transformation. This post is going to focus on the ‘what’ and leave out the ‘why’ and the ‘how’ for the time being. We’ll get back to those as the conversation progresses.

Any Agile Transformation starts by understanding what the end state of your organization looks like and how that organization will coordinate to produce integrated value for your customers. We do not believe that these patterns are intuitive, or that most organizations will emerge into them. Therefore we define them up front. Think about this as the architecture of your Agile enterprise.

The Roadmap

That architecture is made up of the following 3 key areas:

1. Structure – This is the pattern for how your organization will form teams at all levels of the enterprise. At this point we aren’t being dogmatic about how teams will form, just that whatever teams are defined, are generally permanent, have everything necessary to solve the problem they are assigned to solve.

2. Governance – Governance is simply the way in which your organization intakes work, makes decisions about priority, balances capacity and demand, and handles tradeoffs when things get out of balance… as well coordinating across teams when necessary. You need to have some idea of how you plan to do this… and agree to that plan… before you get started.

3. Metrics & Tools – Metrics are the way we are going to measure organizational performance. We need a way to baseline these metrics, gather the metrics, show improvement, and communicate those metrics to the appropriate stakeholders. We can pretend tooling is not part of this conversation, but at any level of scale, tooling is part of the conversation… so let’s figure it out.

Any large scale architecture, organizational or otherwise, is just a bunch of theory until you exercise it and prove that it works.

I learned from Alistair Cockburn  the notion of a walking skeleton, and that is exactly what we need here. The smallest instantiation of the whole thing that proves it will work in your organization, with your people, and your culture.

At LeadingAgile, we believe in an incremental and iterative approach to adopting Agile. That said, we wanted to stay away from the words “incremental” and “iterative.” We also didn’t want to use words like “phases” and “milestones.”  In part, because they are jargony and overloaded, but also because they can carry connotation that we don’t necessarily want as part of our Transformation approach.

The Journey

Here is how we describe our incremental and iterative approach to an Agile Transformation:

1. Expedition – An expedition can either be a group of people that go on a journey or the journey itself. We are using the word as the group of people making the trip. A LeadingAgile expedition is the group of teams that are going to exercise the architecture we’ve defined for the organization. An expedition will form teams at all levels, use the governance model, and leverage the metrics and tools.

2. Basecamp – Extending our Expedition metaphor, a basecamp is a place on the trail where we have made a predetermined, measurable amount of progress and can therefore regroup, refuel, and rest as we prepare for the rest of the climb. A basecamp in the LeadingAgile framework represents a predetermined amount of progress in the transformation journey and its associated business outcomes.

3. Trek – Different groups within the same company won’t necessarily have the same goals with regard to their transformation, nor have to take the same path to get there. A Trek is one of many paths and consists of many different possible Basecamps along the way. An organization may define one or more Treks made up of one or more Basecamps to move the organization closer to its goals.

What we are basically saying here, is that in the presence of a known set of business goals, a known pattern for achieving those goals, and an established plan for how we can get there… we can systematically increase our chances of success in the transformation process. Furthermore, there is no magic involved.

It is simply a pragmatic understanding of how the organization intends to operate and incrementally and iteratively helping it operate that way.

This kind of journey can be defined, scheduled, put in a Gantt Chart, planned and funded. You can measure progress against the plan, progress against goals, progress against business metrics and 100% determine if the investment that is being made is yielding the business outcomes you are trying to achieve. If it’s not, you can stop.

Our Compass

Speaking of which, that leads us to the next set of steps.

1. Baseline – There are two things that can be instrumented in an Agile Transformation. First, you can instrument the Transformation itself. Then, you can measure that you are doing what you said you were doing.  But, more importantly, you want to measure that you are achieving the goals you set out to achieve. This means you must first understand where you are at in terms of sustaining the practices, and you must also establish a baseline-set of business metrics from which to measure improvement against.

2. Measure – As you go about the day-to-day activities of forming teams, training teams, and coaching teams—you want to be able to understand if the processes and practices are taking hold. The best way to do that is to have the team self-assess if they are able to continue in these competencies once the coaches have gone. You also want to be able to correlate the sustainability of the practices to the improvement of business outcomes, and show progress over time.

3. Improve – If what you are doing at the execution level is not improving the metrics, retrospect as to why and change the plan. If we have the wrong architecture—revise it. If we defined the expeditions and basecamps incorrectly—modify them. If the training and coaching we’ve prescribed isn’t working—do something different.

Summarizing Our Approach

The Manifesto says that we value responding to change over following a plan. It’s not the presence of a plan that is the problem, it’s resisting change when we learn something isn’t working. There is some work to do here to explain the why and the how behind some of this—but from what we are seeing on the front lines by  doing this with real companies—this approach works.

In short:

1. Define one possible end state
2. Incrementally and iteratively implement that end state
3. Measure, inspect, and adapt along the way
4. Change direction as necessary

All I am saying here is that we believe most organizations aren’t going to self-organize into an Agile enterprise operating at scale. On this journey, it is possible to define a roadmap, articulate what the intermediate steps will look like, and communicate what you should be able to expect as you are going down the path.

As a quick aside, I am running my first full marathon next Sunday.  And, I recently read a great book that took me through a week by week explanation of what I could expect to happen and what I would feel as I trained. It told me what week I’d want to give up and what week my toenails would fall off. It wasn’t exactly on point, but it sure helped manage my expectations.

It is knowable when you’re toenails are going to fall off.

I want us to stop thinking that Transformation is a mystical process of self-discovery. We are talking about businesses, with ongoing concerns, that exist to make money. We need to get better at telling people what it will take, how much they will have to spend, and what it will look like when we are done. My take is that this stuff is knowable and can be planned.

More on the why and how over the next few days.