Our Agile Transformation Metaphors are Broken

I’m getting increasingly uneasy with how I see folks thinking about agile and planning for agile transformations. Too much of how we are thinking about this has to do with the activities of an agile transformation rather than the units of value the agile transformation is trying to achieve for the greater organization.

What I’m seeing is analogous to what lots of us used to do back in the days of waterfall Gantt chart project planning. Load up a bunch of activities into a schedule and start tracking the stuff we are doing rather than the outcomes we are achieving. Activity doesn’t always equate to outcome and even less so for agile transformations.

The ‘Manage the Activities’ Metaphor

Think for a moment all the stuff you might do to help an organization become more agile. You might want to get everyone trained in agile to start. You might want to get all the teams some coaching. You might start counting how many agile teams you’ve formed… or how many of those teams have ScrumMasters or Product Owners… or are doing daily standup meetings. But here is the problem, are any of those things actually the value you are trying to produce? Are they why you are adopting agile?

What would that user story look like? As a transformation lead, I want to run a ScrumMaster workshop, so people know Scrum? The value is at least one hop away. Maybe.

The problem is that I can’t necessarily correlate the number of people trained, or the number of coaching days applied, or the number of teams formed, or the number of ScrumMasters and Product Owners on staff, or even the number of teams doing daily standup meetings to the business outcomes that we promised for going to agile. I’d suggest that there are tons of organizations doing agile things, but not getting the value they want from their transformation. This tracking approach doesn’t work.

The ‘Tracks of Work’ Metaphor

Another pattern I see quite a bit when talking about agile transformation, especially with large traditional companies, has to do with managing the tracks of work that need to be tackled as part of an agile transformation. We know we need to address the executives. We need to address the project managers. We need to address the PMO and the portfolio governance group and the investment decisioning team and the finance folks and the release management teams.

This is similar in kind to the problem we had with creating a transformation activities backlog… what does it really mean if we address the executives, or the project managers, or the PMO or portfolio governance or the finance folks or the release management folks? We can theoretically redefine how all these folks work, create new process documents, create new artifacts, and even get them committed to this new way of working, but does it correlate to value? I’m suggesting that it does not. It’s more about how they all work together.

The ‘Self-Organizing’ Metaphor

While the first two approaches are most common amongst the practitioners we meet, most of what I read on blogs and see at conferences is some sort of variant of the culture first/extreme self-organization point of view. This approach usually involves training everyone in agile and is focused on changing mindset and teaching practices. The idea is that, after mindset is changed and practices learned, the people in the company are prepared to self-organize into an agile enterprise.

This belief is predicated upon the notion that the people closest to the problem are the best ones to solve the problem, and that if we can just get everyone thinking in the right direction, doing the right behaviors, practicing the right practices, that an effective system of delivery will follow. This is probably considered the most agile of all the agile transformation metaphors, but is probably the least satisfying and plan-ful to the non-agile organization trying to get started down the road to greater agility.

That in and of itself doesn’t invalidate the approach, it’s just that I don’t agree necessarily that the people doing the work are the best at organizing the system of delivery for doing the work. I do think that people should be on teams and have autonomy to self-select their work within their team. That said, most folks aren’t inherently systems thinkers and when you factor Conway’s Law into the equation, I believe some intentionality around system design is required.

So What’s Wrong With These Metaphors

The problem with these metaphors is that in some form or fashion, they are all about the stuff you are doing. They are all about things that are tangible like training or coaching or process design. They all are based on activities but fail to measure the value that we are trying to create for the organization. They are analogous to using Scrum to iterate through a waterfall project. What does it matter if I have design, development, or test user stories? None of that necessarily produces working tested software.

It doesn’t matter if I form an agile transformation team. It doesn’t matter if I create a backlog of the activities and plan my activities every two weeks. It doesn’t matter if I write my activities in the form of a user story. It doesn’t matter if my transformation has a ScrumMaster or a Product Owner. It doesn’t matter if I do retrospectives or know my transformation velocity.

What I care about is working tested software delivered on regular intervals. Using Scrum to deliver a random screen, or a piece of business logic, or a database table doesn’t matter either. What I get credit for is providing value to the customer in the form of something they can use. None of the trappings of agile or Scrum really makes that much difference when leading an agile transformation.

Our transformation then has to track something that our organization can measurably use. I need an analogy for value in an agile transformation. Make sense? If you guys are with me so far… let’s start talking about the unit of value of an agile transformation. What is it that we really should measure if we know we can’t effectively measure activities as a proxy for outcomes.

The ‘Iterative and Incremental’ Metaphor

I think about an agile transformation the exact same way I think about building a software system.

You build software systems in increments while progressively iterating over time to mature the functionality. You might imagine a software product that has 5 major features. Our job is to get the product to our annual trade show by the end of the year. More than likely, we’d build a MVP or MMF of the highest priority feature first, followed by the MVP or MMF of the remaining features in priority order, so we’d be sure of having a working tested something by the deadline.

As we completed the MVP for all 5 features, we might choose to go back and iterate any or all of the features to round out their capability and create a more robust, more fully functional product, one that is closer to our fully realized end state vision. If at any point I have to kill the project, release early, or just simply run out of time… I will have the most functional product I could possibly have given the constraints I was working under.

At all times the product was potentially shippable. Come hell or high water, we’ll have something for the trade show.

Now let’s take this analogy and apply it to an agile transformation…

• The incremental part of the analogy is to think in terms of teams and organizations. Like a feature, teams and organizations are the capability of the enterprise.
• The iterative part of the analogy is to think in terms of getting the organization to a base level of agility fast, something like an organizational agile MMF, and improving agility over time and on regular intervals.

Using this thinking tool then, the backlog of an agile transformation isn’t the activities we plan to do like training and coaching, but is rather the progressive maturity of various slices of the organization as they move through their agile journey.

Organizations and teams are the features and user stories of our transformation. Activities simply become the tasks. At any point in the transformation we might be doing training, coaching, and workshops… or forming an agile steering committee… or doing a retrospective… but all those activities are being done to move a part of the organization to a greater level of agile maturity.

That is how you plan and orchestrate an agile transformation.

Plan in increments of organizations and teams and iterate maturity until you are agile enough to go to market.

The ‘System Refactoring’ Metaphor

Using another metaphor borrowed from actually building software… most organizations have a tremendous amount of (not only) technical debt, but organizational debt, and business process debt that we are going to have to deal with. Most large organizations are not architected very well and a full of dependencies, overlapping value streams, defects, bottlenecks, sub-optimizations and local optimizations that are going to inevitably get in the way of effectively adopting agile across the enterprise.

As you begin the process of defining increments… and a plan for how to iteratively guide maturity… you are going to have to deal with the debt your organization has accumulated over time. That means you’ll have to align business process, technology, and architecture and start organizing around discrete services, putting boundaries around components and products, and wrapping these objects in tests so you know that they are working at all times. You have to start breaking dependencies and increasing local autonomy across the enterprise.

I’d suggest that anything which gets in the way of organizing this way, anything that get’s in the way of breaking dependencies, or governing in a way that respects these boundaries, or allocating resources in a way that makes these boundaries hard to preserve is an impediment that has to be removed to truly become and agile organization. I think that thinking about impediments this way makes them real and actionable and helps us pay more than lip service to real improvement.

In Conclusion

When you think about adopting agile as a process of incremental and iterative improvement… organization by organization… team by team… and removing the barriers to organizational agility as you go… the entire metaphor of using agile to implement agile begins to take on real meaning.

It’s not about using the process of Scrum to coordinate work, it becomes about using good organizational design principles to form teams, keeping the organization always shipping product, focusing on the basics of agile first, and incrementally improving agility over time as you break dependencies and reduce technical, organizational, and process oriented debt.

This to me is what it means to use agile to implement agile. I think until we starting thinking about adopting agile in this way… we are going to see lots of agile in name only type agile transformations.

Further reading:

The LeadingAgile Compass

The LeadingAgile Roadmap