I recently spent a day helping the leadership of an organization make the leap from “can we become Agile?” to “now we’re becoming Agile!” The problem was one of mindset: getting people to think less about barriers and more about what actions are possible. My solution involved hands-on experiential learning and structured group debriefing.
I’ve written about it below, but I’m a visual person so I’ve added a lot of captioned pictures if you want the gist, and the how-to “recipe” for doing this mindset-shift yourself is at the end.
Becoming Agile is an Agile Process
We can’t solve problems by using the same kind of thinking we used when we created them. –Einstein
A few months back I had a conversation with Esther Derby about an organization which we both knew was trying to adopt Agile. The problem was that they were trying to adopt Agile in a deterministic way:
- Map the “as-is” process
- Design the “to-be” process
- Determine the steps necessary to go from “as-is” to “to-be”
- Execute the steps and control for variation from the steps
Hmm. Didn’t seem too Agile to me, and it didn’t to Esther, either. I run into this problem with organizations quite often, and I’ve found that talking about it doesn’t cause the necessary mental shift. Rather than focus on always doing what can be done to get better (“Evolving”), people often get hung up on all the barriers to being perfect (“Solving”).
Learning: a Change of Behavior as a Result of Experience
I was asked to facilitate a day-long planning meeting for an Agile Leadership Group. The team had identified many barriers to adopting Agile at their org, and the sheer number and scope of the barriers were starting to make some of the leadership team uneasy. They didn’t have enough experience in working any way other than as described above, and the energy of Solving was high.
I’m a lazy sort, and I hope also a compassionate sort, so rather than debate with the team about their objections or tell them that their fears were silly I thought I’d help them gain some experience… and most importantly, the change of behavior that comes from processing that experience.
Here’s how the day went.
First I spent 5 minutes reviewing the problem of using deterministic methods to manage complex change:
Then I spent another 5 showing how an adaptive transition to Agile might work. The “Agile Working Group” (AWG) here is a Scrum team charged with iteratively evolving the current processes, people, procedures, and corporate policies from “Waterfall” to “Agile.” This is the same as evolving a software product from “what it is now” to “what our stakeholders really want.”
Then the questions started coming. “But what if our tests aren’t automated? But what about managers who manage functional silos? But what if…?” At this point we could have spent several hours in Q&A, and most of my answers would have been variants on “let’s look at your specific concern and determine how to make the situation better than it is now.”
Instead, it was time to give the leadership some experience in the difference between adaptive/agile work and predictive/deterministic work. I had them break into several teams, handed out sheets of newsprint, and set them a problem.
The learning objectives here were for leadership to internalize and be able to apply:
- the value of evolved vs. designed solutions when dealing with a complex domain (one near the upper-right of the Stacey Diagram) such as process change
- the necessity of an extant process to improve upon
- the power of repeated implement-inspect-adapt cycles over plan-once-then-execute when adopting Agile
So we got right to it. The teams got a “process” and “requirements” shown below:
Notice the “process:” no roles, no boss, no Agile terms. Just cycles of build-inspect-adapt. No hard and fast requirements, just a vision for “a bridge that has qualities of load-bearing, length, height, and aesthetics.”
And vicious time-boxes, of course. Right out of the gate, the teams went to town:
We saw all the hallmarks of Agile work: good-enough design, simultaneous work, prototyping, learning by doing and experimentation, rich collaboration, the need for visibility, making the bridge itself part of the team, innovation and adaptation beyond mere requirements… by the wrap-up iteration the teams had created very impressive bridges:
The teams demonstrated their final outcomes to each other, shared a bit of their challenges and successes, and admired each others’ adaptability. Then we sat down for the real mindset-shift.
I led the teams through a structured debriefing. This is the part of experiential learning or “games” that is most often neglected, and as a result people have fun but they don’t make the necessary mental shift to enable different behavior. With 3 teams, we handled each step first in small groups, and then each team shared their findings with the rest of the group before moving on to the next step.
We started with Step 1, Feelings and Facts: let people vent their feelings (e.g. “the time intervals made me panic!” and “this was fun but I’m not sure what it has to do with real life”) and review what observable facts happened in the exercise. No interpretation yet — just facts like “we started with a sketch,” or “we all worked at the same time,” or “we didn’t notice the pylons were mismatched until we lined them up.”
Each team wrote their findings on a flip chart and then shared them with the rest of the group.
Step 2, Interpretation, allowed the teams to think about the implications of their work on the bridge. Here we shifted from purely observable facts to insights and evaluations: “I noticed that even though we didn’t have a leader, we figured out what to do” and “its funny how those requirements were really open-ended and yet we hesitated about not getting them right.” Most interesting to me were “I think we did poorly because our bridge didn’t match our initial sketch” from one team and “our bridge is different than I imagined it, but it’s actually better” from another.
Each team wrote their findings on their flip chart page, posted it next to their “Feelings and Facts” page, and then shared highlights with the rest of the group.
In Step 3, Generalization of the experience to Agile concepts, I provided some key ideas I wanted leadership to consider — chosen especially for this organization and what they were trying to achieve — and asked them to find instances of how they showed up when the teams were building the bridge. This did two things:
First, it helped fix the concepts in everyone’s minds with concrete examples, both as individuals and as a group. Weeks later I heard one person from the group say to another “we don’t know what’s best yet — remember how our bridge design changed only after we created the first iteration of it? We need to get SOMETHING running NOW.”
But more importantly, it helped make the concepts understandable via a concrete, emotional experience.
It would have been one thing to try to get concept #2 across by telling the team “inspecting and adapting on an actual product is better than over-refining a plan” and then tell some stories from my own experiences. But by finding instances of this idea at play in their exercises, the teams were able to discover for themselves the truths they wrote on their flip charts. Truths like “adapting our bridge was easy because we were only making small changes at a time;” and “being able to see each other work reduced communication overhead;” and “having both a mostly-built bridge and general goals actually gave us very clear direction — it was easy to see the next step forward.”
Once again I had the teams share highlights of their findings with the group, then we moved to the final step: applying these Agile concepts to their work of process change.
In Step 4, Application to real life, we tied the learnings from the experience and debrief thus far back to my initial 10-minute presentation about Continuous Improvement vs. needing to solve all barriers up front. I asked everyone to consider what their principles from Step 3 meant to them for how they would evolve Agile at their organization. Each team then picked their top 3 items and posted them on a common piece of paper (shown above).
Outcome: a Change of Behavior
The outcome of all this was that a leadership team which in the morning had been feeling paralyzed by all their perceived barriers to adopting Agile, had a shared understanding and motivation to move forward by lunchtime. They spent the rest of the afternoon choosing their first pilot teams and projects, and identifying which barriers they were going to tackle first.
They were able to do this because they learned a set of key Agile concepts directly relevant to their situation, rooted in a shared experience, which they themselves uncovered.
This whole process took about 2-1/2 hours with breaks:
- 10m – Agile adoption as an Agile process (whiteboard presentation)
- 40m – Agile experience: 10m for Objectives and instructions, 25m for Teams to build a product, 5m for Teams to show off product
- 60m – Structured debrief (~15m / step, with each step being done first at individual teams then whole group)
Debrief has 4 steps:
- Feelings/observable facts from the experience
- Implications of the observed facts
- Generalization of the experience to concepts
- Application of the concepts to real life
I was really pleased to have the opportunity to have this session with the leadership team. They didn’t just demand that the “expert consultant” tell them what to do, they were willing to start off their Agile adoption by finding their own way with a little guidance. (That’s the difference between an organizational consultant and a organizational coach, by the way.)
So after a day, leadership was ready to rock and we all had a great time. How was YOUR last leadership kickoff about Agile adoption?