I wrote the other day about the concept of “ruin” as applied to transformation, and I probably ought to start here by talking about what ruin means in that context, and then talk about some strategies to manage what I see as the two key defenses against it.
“Ruin” simply means there ain’t no game no more; either the sponsoring authority declares the game over or you lose your seat at the game. I’m going to assume you lose your seat because you have lost your authority, not because of wrongdoing. You can lose your authority because the funding runs out, or because you’ve lost the ear of the decision-makers, or because the decision-makers you have the ear of lost their seat at the table.
So this transformation project is declared over.
Which leaves us with two questions – now what? And what could we have done?
I’ve got some notions (i.e. they aren’t solid enough to be ideas yet).
…as to “now what?” I’d suggest the following.
Client: Hey Marc. I know this wasn’t in the plan, but we’re not going to have budget to carry the transformation team past end of quarter. Sorry!
Me: I get it. Let’s do three things? 1) Pull together a big retro session where we can look back and make sure we all understand what went well and what didn’t. 2) Do some closeout metrics to define where we’ve left everyone and what they may want to focus on going forward. It’ll also give you closeout data to share with management so we can identify definitive wins. 3) Do a handoff session where we can leverage the first two to define what must continue and we can help you ID the internal folks who can best carry that out.
What do we get if we do those? Well, everyone understands what went well and didn’t; most importantly the people impacted by all the change work get to share how it went for them and leave with a clear sense of being heard (ideally, we’ve been doing this all along, yes?). We define what success we’ve achieved and leave the sponsors and their sponsors with clear data on what’s been achieved. Finally, we make sure that critical ongoing work is covered, and we leave everyone with awareness that there is still work to do – the change work isn’t over.
I’m interested – what to folks think of these? What else should we do?
Before we talk about how we could have forestalled this (i.e. how we could play better), let’s talk for a moment about the advantage of modularity – of ‘chunking our work’ or limiting our bets.
If you’re a part of the Agile community, you’re familiar with the problem of the Big Upfront Planned project where – due to changes in in circumstance, delays or overruns – we have to descope at the last minute. What do we descope? What can we descope – stuff we haven’t done yet. Is it valuable? Who knows – toss it over the side.
So why in the world are we running our Agile transformations as Big Upfront Planned Projects and baking much risk into them?
If you look at a typical Agile Transformation Roadmap, you’ll see very few offramps and very few iteration points that allow for the transformation to pivot. It’s typically one big, hopeful arc of change.
I suggested earlier a way to build offramps in a SAFe transformation:
Decide to go SAFe. Decide what problems/opportunities need to be addressed by doing this. Make sure that the part of the organization that can impact those problem/opportunities are in the change and that their leaders are on board.
If we stop here: We’ve identified the barriers to organizational improvement.
We may decide that the problems/opportunities that are priorities can’t be addressed by going to SAFe. We may decide that we don’t have control of the parts of the org that are needed to address the key problems or opportunities. So we may see if there are other problems worth dealing with that we can deal within inside the decision-makers span of control. Or to delay as we try and broaden the circle of decision-makers.Train the leaders in SAFe; then train them in LPM and Product thinking;
If we stop here: We’ve improved the tools the leadership has to plan and define work.
There’ll be opportunities for incremental improvement in the planning process, and a leadership oriented to improving the organization.Train change agents & stand up a LACE;
If we stop here: We’ve seeded the organization with people capable of and desiring to drive improvement, and given them some runway in the form of a mutually sustaining team.
Ultimately what drives change in organization is the network of committed, aligned people. We’ve stood up a group of people and seeded them into a network. This may be the most important step in the whole process.Build a portfolio of products and services; then build out a portfolio of work to represent the Business Value Increments (BVI) that directly connect to the problems/opportunities identified in #1. Define the sub-products that will be worked on and define value streams around those products;
If we stop here: We’ve improved the connection between strategy and work, clarified strategic decision-making, and strengthened the connection between decisions and value.
After standing up a network of change agents, the next most important change we can make is to improve the work intake process; by building out a portfolio process we can .Stand up ARTs within those value streams, using the well-defined roadmaps and work to simplify their intake process;
If we stop here: We’ve improved organizational alignment to the work to be done.Anchor continuous improvement in these ARTs;
If we stop here: We’ve seeded a future of improvement and change that’s self-generated within the organization and will continue after the formal ‘change process’ is wrapped up.
Expand laterally within the organization if there’s an appetite.
This (or better, a fully developed variation on this) strikes me as the minimally responsible approach.
Better would be to develop an iterative path that allowed – even encouraged – adaptation.
I’m not convinced we can do real “slice of cake” change in orgs the way we can deliver code; there are too many interdependencies and levels within an organization.
One answer – which is my core takeaway from LeSS – is to deconflict the organization to allow just that kind of transformation. Doable, but difficult, and I’m not yet sold on the long-term success of that kind of an organization (but I could be…).
The other as I’m envisioning is a series of parallel, iterative change efforts at (possibly) three levels – the strategic planning level; the coordination level; and the delivery level. In the context of SAFe, imagine that we’re launching the change at the (company, division) portfolio level, defining a quarterly (again arbitrary) cadence of change that in turn feeds the change at the levels below. A quarter later, we start at the coordinating layer (the Solution level in SAFe); a quarter later at the delivery layer (ART’s and teams).
I’ll take some time next and expand on this.