Sustaining the transformation - The Fire Burning Model

Gwen Kestin proposed a nice topic at Kanban Leadership Retreat 2016 in San Diego: How to sustain coaching and continuous improvement after consultants leave? I think this is a hot topic for a wider audience and I'd like to share what I'm doing "on the other side" (as a consultant) and maybe this might spike a bigger discussion and evolution.

Background

Back in my "Agile years" one thing that did bear in my mind was "How to sustain Scrum?". A common problem that I experienced doing Agile Transformations with Scrum is "eroding goals" - one of the Systems Thinking archetypes (Donella Meadows). You've heard this story before: teams are excited and engaged after a 2-day Agile training and they think how nice it will be when they become "Agile" and collaboratively start meeting expectations with quality. The Agile Nirvana is a Black-Swan-Farmer Product Owner, an Inspiring Impediment Killer ScrumMaster and an Energetic Zero-Bug Collaborative Team - continuously deploying software that customers love - within a non-hierarchical company structure. The bad news is that only very few companies reach this "Nirvana" state. This is really frustrating. Everybody wants to be Spotify. You'll need tons of energy to push the "Agile" rock uphill. Using the Switch Book metaphor, the rider (you) will get exhausted and then "eroding goals" archetype happens. Things like Flaccid Scrum and Scrum-but take over.

WHY KANBAN IS DIFFERENT - THE FIRE BURNING MODEL

In the last 6 years I have applied Kanban to approximately 100 teams/services in 30 companies in Brazil. Undoubtedly Kanban's success rate to sustain transformations is overwhelmingly high compared to Scrum. There are 4 main reasons for that: 

1. KANBAN CONCEPTS UBIQUITOUSNESS 

Kanban concepts are "ubiquitous". I'm not sure if this is the right word to describe it. By ubiquitous I mean that - no matter the flavor - every process has flow, batch sizes, work item types, steps and purpose. Every process has lead times. Every process you can track with a Cumulative Flow Diagram. The meaning of Kanban metrics don't change for different people, teams, services or companies. Some standardization makes sustaining the transformation easier. These ubiquitous elements, specially metrics, turn out process monitoring easier, create strong warning signals and sharpen your focus to the important things. Compared to Agile, Kanban transformation cares about Flow neither rituals nor details about people's behaviors. Even if all feedback loops, rituals, meetings and collaboration fall apart, Kanban metrics will still be monitoring Flow.

To benefit from Kanban metrics all you need to do is to keep them in place and socialize it during feedback loops. Make the metrics public/explicit and evolution will follow. Kanban Evolutionary Way reliefs you from pushing the rock uphill and gives you room for experimentation respecting the unique characteristics of your environment. Understandable, non-judgmental and public metrics are the key to keep the fire burning.

2. PROCESS OWNERSHIP

My transformation steps are quite simple: Training, Startup and Follow-up. Right after the Kanban Training, the Startup is a 4-hour meeting where I use STATIK to start the fire. STATIK is all about creating a shared understanding of current process status, not the desired future state, and doing it with the entire group delivering a service is energizing and promotes process ownership. One key aspect of STATIK to keep things improving is to raise and revisit the primary internal and external dissatisfactions. The dissatisfactions strongly help guiding the process evolution. Workers need to understand that they own the process and are responsible to maintain the Flow. Socializing the kanban design and encouraging acts of leadership are key to achieve process ownership and keep the fire burning.

3. MANAGERS' LEADERSHIP

Kanban's bargain is quite simple: workers will be freed from overload (abuse) and managers will make more meaningful and wise decisions - to sustain the transformation you'll need both. Unfortunately, in my experience, I see that the fire usually extinguishes because managers are not totally convinced that Kanban is a management method to improve decision making and enable process evolution. I really hate lists, but these are some basic characteristics of managers that succeed with Kanban on my road:

• Pursue guided evolutionary improvement (not revolutionaries)
• Understand that Flow Theory works
• Decentralize control / stop micro-managing
• Agree that the reality is a street fight

I think that the last item deserves a better explanation: managers, don't freak out in the presence of transitory messy circumstances. Unexpected bad things happen without a signal - welcome to our World - and there's nothing you can do about it. Life is not a kata exercise neither a fight on 2-week rounds with a referee guarding the rules. Agile's Shu-ra-hi sounds a really stupid idea to me. Turbulences are inevitable and, in fact, necessary to create an antifragile organization. Leaders must board the transformation boat and nurture the system to keep the fire burning. If you are a worker attempting a bottom-up approach and need to influence your leaders, there are dozens of ways to do it. I'll blog about it in the future.

4. CADENCES / FEEDBACK LOOPS

There's no improvement without teamwork. Meetings and "rituals" mean conversations, agreements, decisions, alignment and fun. However, fixed date, fixed rituals, fixed tribal artifacts every one or two weeks for several months in a row are disengaging, specially for the Millennials. We need to add some diversity, variability and "mess". Kanban decoupled cadences and meetings are perfect for that. Some of the Kanban Cadences / Feedback Loops are also ubiquitous: every process has a Replenishing Meeting and the Kanban Meeting somehow. Every process needs to be fed (commitment point) and every process needs some alignment. The purpose of Kanban Cadences is to create inexistent or reinforce existent feedback loops. If you place a feedback loop to focus on the heart beat of your process, like the Kanban's Service Delivery Review, you'll end up creating a necessary peer-pressure to hold the transformation and keep the fire burning. If you've got several groups running Kanban the Operations Review can also create tension between different groups to keep the metrics up-to-date and Kaizen Events happening. If you observe and track cadences/meetings happening - you can use any calendar on the wall for that - it might be the visualization feedback loop of feedback loops.

These 4 Kanban properties when in place can hold your transformation together easily. Although, keep in mind that the most recent vision of Kanban is to reach fitness for purpose and service delivery focused on the market. Your process evolution must be grounded on quality by the eyes of the customer. By that I mean that a lot of changes happening is not evidence of proper improvement. It's not because it's moving that it's necessarily advancing. The fire doesn't burn to keep you warm and comfortable on your office. It burns to increase EBITDA and sustain innovation.

On my transformation steps listed above the "Follow-up" aims the "Flow State". One thing I observed over the years is that the transformation usually reaches a state where, within the service, WIP limits are respected, bottlenecks aren't clear anymore (it moves up and down stream quickly), people are naturally collaborating via swarming, metrics are more stable, failure demand expedites cease to happen and feedback loops are working (yes, you can call it "Agile"). By the time you reach the Flow State you need to pivot to the quality of the demand upstream. At this point the process is not the problem anymore. Flow State warns that now you need to care about the quality of the liquid flowing on the pipe, not the pipe itself. Easily people get addicted to focus on the process leaving the customer out of the equation. You need to move people's eyes outside the process, to the customer, to the market and to novel opportunities and experiments that arise with a "fixed pipe".

Yellow Flags

When sustaining the transformation there are some yellow flags that indicate problems with the fire:

A. Metrics are not up-to-date and guiding decisions

B. Feedback loops and meetings are abandoned

C. You don't see tangible improvement

If you see any of these happening investigate the root cause. Map the dissatisfactions again. Put people on direct contact with customers. Well, manage it! If you need to restart the fire, use STATIK to revamp the implementation. 

REMEMBER: The consultant/coach is not with you to improve your system. (S)he's there to show you *how* to improve your system. 

I hope this text can help you on your process evolution. I focused here on key points where Kanban can help. There's a lot of other social techniques you can run like coding dojos, mob programming, internal conferences and so on. 

 (*1) "Fire Burning Model" name emerged during KLR16, not sure if it's suitable or coherent. Maybe it's not even a model, probably just random thoughts...