Skip to main content

The Executives Guide to Leading Agile Transformation – Intro and Overview #Agile2016

Mike Cottmeyer
Reading: The Executives Guide to Leading Agile Transformation – Intro and Overview #Agile2016

I’ve got most of this week dedicated to pulling together my Agile2016 presentation. This isn’t the latest I’ve ever waited to start writing my talk, so I kinda feel like I am ahead of the game. In reality, this talk is effectively the next step, the next chapter if you will, in the story I’ve been trying to tell for the last 6-7 years. I’m not expecting the content to be super hard to pull together.

So… let’s spend a minute on the evolution of the story.

Two years ago, 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.

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, 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 will explore the mechanics of Agile Transformation and what we’ve learned in 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, 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 its 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.

  1. Can we really expect self-organization to happen at scale, especially in the face of constraints and dependencies. Not unless we release all requirement to plan, coordinate, or get things done on a schedule. The short answer is no.
  2. 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

  1. 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.
  2. By identifying what an organization values from a planning perspective and comparing that against what it’s 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.
  3. We believe that change can be coordinate 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 quick 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 the 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.

  1. Give the executive and the organization clarity around 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 defined end state, a mechanism to pilot the plan, and a means to do incremental and interactive rollout along the way.
    • Roadmap
    • End State Vision
  2. 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
  3. 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.

Last, 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 right, but is every bit as important as the technical aspects of the transformation.

  1. Creating safety
  2. Being influential
  3. Dealing with resistance
  4. Holding space
  5. Maintaining permission
  6. Managing change

I am clearly going to have to prioritize in this talk around what is most essential to cover without losing any of the context necessary to understand where we’ve been and where we are going.

whitepaper-cta 2

Next Encapsulation and Orchestration

LeadingAgile CEO and Founder, Mike Cottmeyer is passionate about solving the challenges associated with agile in larger, more complex enterprises. To that end, he and his team are dedicated to providing large-scale agile transformation services to help pragmatically, incrementally, and safely introduce Agile methods.

Comments (3)

  1. gst
    Reply

    Completely agreed with your opinion,thanks for sharing such nice information…

    Reply
  2. Andre
    Reply

    Can you share the links for the articles/talks that you mention, ‘Why Agile Fails in Large Enterprises and What You Can Do About It’ and ‘The Three Things You Need To Know To Transform Any Sized Organization Into An Agile Enterprise’?

    Thanks!

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

What is the Worth of a Good Product Owner? w/ Tim Wise

This week, on SoundNotes, we’re featuring another question from a student in one of our Certified Scrum classes. The question came from someone who’s working in an organization that doesn’t see value in the role of Product Owner and isn’t convinced that it’s needed as part of the Scrum Team. The question: What is the […]

How Do I Use Scrum on Data Warehouse Projects? w/ Dave Nicolette

In one of my recent Certified Scrum Master classes, I had a number of students who were working on projects involving migrating from a legacy data warehouse to new data warehouses. Figuring out how to apply Scrum to the work they were doing presented a number of challenges and left some open questions.  Here are […]

Maximizing the Amount of Work Not Done

One of the principles of the Agile Manifesto reads: “Simplicity – the art of maximizing the amount of work not done – is essential.” Okay. What does that mean? Does it mean we should avoid doing our work to the extent possible? Well, not exactly. Consistency Between Lean and Agile Principles Without coming at the […]

Prioritizing the Work to Maximize Return w/ Dennis Stevens

This week, on SoundNotes, we’ve got Part 3 of a trio of interviews with LeadingAgile Chief Methodologist and Co-Founder Dennis Stevens. The series focuses on how to build an organization that can embrace change. In the final episode of the series, Dennis and Dave cover how to prioritize work being done to maximize return. During […]