Two years ago at the Agile conference, I did a talk called "Why Agile Fails in Large Enterprises and What You Can Do About It." In that talk, you see my first clear articulation of The Three Things and the Four Quadrants, but the main point of that discussion was really to assert that transformation isn’t something that is self-organized, it is something that has to be planned and coordinated. That talk introduced how to do that.
One year ago, I did a talk called "The Three Things You Need To Know To Transform Any Sized Organization Into An Agile Enterprise." In that talk, we go deeper into the Four Quadrants and The Three Things, and we spend a bunch of time on why it’s so important to break dependencies. Finally, we introduce the notion of Expeditions and Basecamps as an organizing metaphor for Agile Transformation.
My talk this year explored the mechanics of Agile Transformation and what we’ve learned trying to maintain organizational focus in the face of large-scale change, disruption of the status quo, and significant investment on the part of executive stakeholders. Asking people to trust you when you’re spending millions on coaching, training, doesn’t typically fly in most organizations.
Why a talk for executives and why now?
Executive support for adopting Agile tends to fall into one of several categories. We’ve got the executives that are willing to fund a transformation and want the benefits of agility as long as nothing really changes and we are able to still meet time, cost, and scope constraints established at the beginning of the project. These execs tend to look at Agile as just another way of doing the work.
Some executives realize that adopting Agile goes deeper than just adopting a process. These executives are willing to lead change and can articulate the value prop of agility. They sincerely want to help their organizations get there. That said, many of these executives don’t fully understand the nature of the changes that have to be made or the impediments they’ll face, and are surprised when they struggle.
Executives need to know the specific types of changes they are going to have to make, the specific impediments they’ll face, and the specific kinds of investments that are going to be required before they get started. They have to manage and, to some degree, control the change. They have to incrementally demonstrate progress towards goals and justify the investment they are making within the organization.
You see, the game has changed.
We aren’t talking about grass roots movements anymore. More often than not, I am speaking not just with CIOs, but with COOs, and CFOs, and CEOs. I have met with boards of large banks where the decisions to go agile are really being made. At this level, the conversation isn’t about user stories and teams, the conversation is about return on investment and what can and cannot be capitalized.
At that level, the game is not only about showing progress but about proving it. It’s about maintaining influence and dealing with the politics that inevitably come into play when you hit pockets of resistance and groups of people that don’t want to change. It’s about constantly demonstrating what you are doing is making progress against the broader organizational goals we are trying to solve.
We are no longer speaking to the enthusiasts. We are not speaking to the people that have felt the pain. This is no longer an emotional response to that pain, but a rational investment in finding a better way to build products. If we want to make the changes that are going to really lead toward greater business agility, our executives are the only ones empowered to make the investments required`
To do this, we have to show them what it's going to look like when they are done, they have to see that change - a path forward - is possible. We have to help them get started in a structured and systematic way so they can hold their teams accountable. We have to help them take the first steps, constantly reinforcing the economics of the change, and justifying continued investment.
Given all that, here is where I plan to go with this.
First, I want to go back and deal with some of the thinking tools that make this talk necessary.
- Can we really expect self-organization to happen at scale, especially in the face of constraints and dependencies? Not unless we release all requirements to plan, coordinate, or get things done on a schedule. The short answer is no.
- We have a choice to make with our transformation. Do we lead with culture change or Agile practices? Do we start both simultaneously? My assertion is that we lead with structure and governance, reinforce with practices, and guide culture to emerge.
Next, I want to go over the patterns LeadingAgile has introduced over the past 5 years to help solve these problems and lead large-scale change.
- We believe that transformation starts by focusing relentlessly on three things: forming teams, building backlogs, and producing working tested increments of products. Anything that gets in the way is a dependency that has to be removed. We call this model the Three Things.
- Identifying what an organization values from a planning perspective and comparing that against what its market values can help us understand how to tailor our approach to meet a company where it is and help it get to where it needs to be. We call this model the Four Quadrants.
- We believe that change can be coordinated and planned and that by defining the end state, incrementally and iteratively introducing change, and building infrastructure to sustain change with a tight change management program is what will lead to long-term lasting change.
All that foundation has to go quickly because I’ve done whole talks around these topic areas, deeply explaining the rationale for my thinking.
What’s going to make this talk different is that I want to give executives a meaningful framework for holding their consultants and their organizations accountable during the transformation.
To do this, I am going to fall back to one of my favorite slide sequences in the Three Things talk.
In that talk, I make the case that building backlogs, forming teams, and producing working tested software gives us a model to establish clarity, hold people accountable, and to measure progress.
Our Transformation Execution Framework seeks to do the same three things:
- Give the executive and the organization clarity about where it’s going, what it’s doing, and how it’s adapting to changing conditions on the ground. This means we are going to have a defined end state, a mechanism to pilot the plan, and a means to do incremental and interactive rollout along the way.
- End State Vision
- Create an accountability infrastructure made up of specific people, with specific responsibilities, responsible for maintaining artifacts like the transformation roadmap, rolling 90-day plans, agendas for 30-day checkpoints, and what needs to be communicated in a weekly status.
- Executive leadership committee
- Transformation leadership team
- 90-day plans
- 30-day checkpoints
- Weekly update
- Finally, we want to have a way of measuring progress that clearly shows how the transformation dollars spent are producing better organizational performance, and how the organizational performance is leading to better business performance for the key stakeholders.
- Transformation metrics
- Business metrics
The goal is to provide very specific guidance around the kinds of things that have to be done, what those things look like, and maybe even some downloadable templates that folks could use as a starting point for their own transformation work.
Lastly, I want to at least make a nod to the stuff that gets change leaders in trouble, even if they are doing all the clarity, accountability, and measurable progress stuff right. This stuff is difficult and tough to do correctly but is every bit as important as the technical aspects of the transformation.
- Creating safety
- Being influential
- Dealing with resistance
- Holding space
- Maintaining permission
- Managing change