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.
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.
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. 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.
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.
There is a lot of ground you cover in this post. The strategy needs to be well thought out to such a big decision. The structure is very important to have in place and that as you start out is the right place. I have to say some of the Agile transformations I have seen didn’t take the planning you discuss and suffered because of it.
Hey Tom… I think we have created a myth that most companies can self organize into a high performing Scrum organization by learning the roles, ceremonies, and artifacts of Scrum. Ken Schwaber said one time that Scrum is like Chess. You can’t argue that Chess works, you are either playing Chess or you aren’t. Chess has rules, but it also has a board and players with specific abilities. Without having the proper playing surface, pieces, and rules all working together you can’t do Scrum and you can’t do Chess. To think otherwise, we are fooling ourselves. Thanks for the comment.
I’d like to first compliment you on for your disciplined, no-nonsense approach. Very serious and business-oriented, and this is appealing, making a transformation seem completely tangible, manageable and measurable. Structure, Governance and Metrics – hmmm…
As much as a part of me is attracted to this mechanical approach, I feel that several essential elements are missing, in fact, the very essence of a transformation in my experience: Shared vision and values, communication, collaboration and trust; management who stop blaming some part of the company and who feel the responsibility to lead change.
I don’t deny that the “left brain” aspects of a transformation need to be taken into consideration and are too often given short shrift. Many in the agile community are wide eyed and perhaps naive about what business leaders expect and why they might want to invest in a transformation.
For your approach to comprehensively treat the “what”, I’d like to see more about the people who work together in a group, their shared vision, culture, communication patterns and the business good will of trust and solid relationships that I’ve seen in healthy companies, and I’ve seen lacking in companies that are in death spirals.
I love the analogies you’ve used for Expeditions, Basecamps and Treks.
Please keep up the good thinking and writing!
This post focused mostly on how we do things.. the approach. I did not really focus on why or what we do. I’ve got another few posts brewing, but as par for the course… got distracted on running LeadingAgile and a few other posts I’m working on. More soon hopefully.
Thanks for the comment.
It helps me to have a better understanding about Agile Transformation in term of what key elements of the strategy are, and what I should be aware if I want to apply an Agile approach to my firm. There are several good points in the article, and I strongly agree with the point that you made about the importance of communication with stakeholder. I believe that the success or failure of a project is influenced by the effectiveness of communications, and relationships with its stakeholders. Delivering the right information to the appropriate stakeholders will keep stakeholders engaged.
Looking forward to read about why and how it takes to develop an Agile Transformation Strategy.
This was a great read. I have been talking to colleagues about what a agile transformation vs agile adoption really is . I like that you have described some of the steps that are involved in planning. I look forward to reading your other posts, as it will be interesting to see if our thinking aligns.
I love the analogies of the base camp, very effective. Again thanks for taking the time write and post. We really need to start taking away that ambiguity around this topic. We are all talking to enterprise agile and frameworks for doing it . But we have left out the view of ecosystem of an organization and how we can really answer the longterm needs that presents.
Thanks again for a great article.
You’re welcome, thanks for the comment!
Great read and totally aligned. For me, in particular, I love that you took us back to the Manifesto, because sometimes it seems this only applies to the Squads. You see agile getting heavy over the years with more and more tools and practices for Agile at scale. Although some of these tools/techniques have the objective of provoking a conversation – I feel we should just dare to have these difficult conversations (Individuals and interactions over process and tools) help create psychological safety so they can rumble with vulnerability(reading Dare to Lead – Brene Brown). Because when the coaches are long gone – they will not of their own accord reach out to the use of those tools/techniques to provoke a conversation. Lets not forget the informal conversation go a long way too.