Sense-making can prevent teams from jumping to the first solution that comes to mind. Cynefin helps teams decide what to do in their retrospective after informed sense-making. Facilitators can use Cynefin to enhance transitions from gathering data to generating insights in retrospectives.
Enrico Teotti, an agile coach, spoke about applying Cynefin in agile retrospectives at Aginext 2021
Cynefin is a decision support framework that, according to Teotti, can help the person leading the retrospective and the group to navigate the issues emerging in retrospectives. It also helps to take the next appropriate step, depending on the nature of the issues.
Facilitators can support teams in doing sense-making by helping them collect data during the iterations and slowing down the pace of the retrospective, rather than focusing on the first solution that comes to mind.
In classic circles of influences, there is what the team controls, influences, and the soup with company policies and other factors the team can only react to. Teotti suggests disintermediating sense-making by reducing intermediaries’ interpretation to put decision-makers in contact with raw data. Then the stories or data points emerging from the team retrospective can reach whoever needs that information (outside the team).
Teotti suggests using Cynefin as a set of lenses to help the group look at what’s around them, make sense of it and take an informed next action. As always in retrospectives, reflect and adjust; if the approach doesn’t work for you, shift it.
Info interviewed Enrico Teotti about how Cynefin can be used in agile retrospectives.
InfoQ: What are the limitations of using a traditional approach of data gathering and clustering in retrospectives?
Enrico Teotti: Often when I see teams collect data in iteration retrospectives, they are already solutioning. An example might be seeing a card "stop pair programming" in the stop column, and after a two-minute conversation, pair programming is no more; it’s a jump into "now what?" before looking at "what" and reflecting on it. This can be an adequate approach if the team is new to agile practices & retrospectives, and if the issue is clear.
Getting data, clustering and defining actions keeps the group in a business as usual mindset, where there is no opportunity for diversification in ideas and divergent thinking.
There is also an underlying assumption that all problems are the same and can be solved, when the reality is that some of these are "wicked issues" that can only be influenced.
InfoQ: How can Cynefin help us in dealing with complex issues?
Teotti: The term "complex" is unfortunately thrown around a lot and I want to clarify it for the reader. Complex doesn’t mean very very difficult. It means intractable, a domain where cause and effect is only clear with retrospective coherence; a domain that is disposed towards certain behaviours, a domain where you can only influence.
Think of "fixing bug #1234" in your source code. If you follow best or good practices, and spend enough time on it, then you’re very likely to find the problem in the source code and perhaps fix it.
Cynefin here talks about categorizing, sensing, responding (for a clear problem) and analysing, sensing, responding (for a complicated problem).
Think of reducing bug rates at the organisational level. Now you are looking at a socio-technical system, where people and systems are intermingled. To deal with complex issues, Cynefin suggests an experimental (Agile, dare I say) approach: probe, sense, and respond. To influence the system, formulate a coherent hypothesis supported by some evidence (data of your retrospective), then create a safe to fail experiment with indicators of its success or failure.
I love this quote from APJ’s fantastic book Design Unbound:
"When we look at problems only as scientific or technical in nature, removed from the context to which they are responding, they may be complicated, but they generally can be solved through straightforward, scientific and engineering design models.
But, when we understand these problems as embedded within human contexts that organize themselves through changing social, political, economic, and cultural belief systems, we are in the realm of complexity".
Design Unbound – Designing for emergence in a white water world
InfoQ: How can we enhance transitions from gathering data to generating insights in the retrospective?
Teotti: It depends on the context. I think this transition from data to insights makes the difference between an average retrospective and a powerful one.
As a facilitator you can try and nudge an extra prompt to foster divergent thinking. Some groups are very much opposed to that and I’ve learned that in some groups the best approach is running a ROTI (Return On Time Invested) at the end of retro-- ask between 0 and 4 how well time was spent in this retro, what’s one thing you liked, and one improvement that would have made you vote one point higher (more info in Measure the return of time invested). Let the lack of reflection emerge from them.
Another key point is to state clearly the purpose of an iteration retrospective. I like to use Principle 12:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
And I stress the importance of reflection. This allows time for the group to identify what belongs to what domain and fosters divergent thinking.
The "tradeoff" of this approach is that time is spent making sense of the problem instead of how to respond to it.
InfoQ: Any guidance on how to balance time? What can be done to spend enough time on understanding the problem?
Teotti: It depends. I’d ask what is important to this group? Also visualize what is within this group’s control, influence, or outside in, what Diana Larsen calls the "Soup". Focus on the group’s control first. Outside of that list, have the group visualize the energy they will need to work out those issues. Now we have a subset of items that allow us to focus on the reflection, rather than acting on all items.
InfoQ: What tips do you have for facilitating retrospectives?
Teotti: Tip #1: get feedback from the group on all your retrospectives. This is for the group and for yourself. Look for patterns and outliers; use that to influence your next retrospectives.
While getting this feedback I wouldn’t start long discussions, probably just 5 or 10 minutes before the end (and we really should end on time). There might be no time for adequate reflection on the feedback; those reflections will emerge from the patterns in the data. Usually, if I ask for verbal feedback, I give 30 seconds or I use a silent activity. The important piece is to by default make the last 5 or 10 minutes time dedicated to getting that feedback.
Tip #2: make sure the purpose of the retrospective is crystal clear. I’d start from Principle 12 of the manifest, and stress the importance of the reflection that preceded action.
Tip #3: facilitators will greatly benefit from the theory behind Cynefin; once you see the domains that surround us, you won’t be able to unsee them. Some retrospective participants might benefit from the theory, others won’t. I usually don’t introduce Cynefin theory to the group.
