Over a million developers have joined DZone.

What It Takes to Develop an Agile Transformation Strategy

DZone's Guide to

What It Takes to Develop an Agile Transformation Strategy

· Agile Zone ·
Free Resource

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 of 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.

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 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’, as well as 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.

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.

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, you can measure that you are doing what you said you were doing, but more importantly you want to measure that you are achieving what goals you set out to achieve. This first means understanding where you are at in terms of sustaining the practices, but also establishing 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 and the best way to do this 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.

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… 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 it’s not likely most organizations are going to self-organize into an agile enterprise operating at scale. It is possible to define a roadmap, articulate what the intermediate steps look like along the way, and communicate what you should be able to expect as you are going down the path on this journey.

As a quick aside… I am running my first full marathon next Sunday. A read a great book that took me through a week by week explanation of what would 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… 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.

Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}