The next Cynefin retreat will be focused on resilience. In preparation for the retreat Dave Snowden has just published a nice article on resilience.

After publishing “Commitment”, Olav Maassen and myself (and Jabe Bloom in the USA) delivered a number of sessions and keynotes on Real Options. Anyone who attended those sessions will know that resilience is a major theme in Real Options and Risk Management. In our presentation, Olav and I present a simplified, practitioner’s view of resilience.

if (timeToRecover > timeYouCanSurvive)

{

     you DIE!

}

Which means you need more options!

Don’t waste time, monitor the conditions!

Although our presentation focuses on IT systems, the definition applies to many systems including biological systems. Any definition of resilience needs to consider time as a core measure. The human body is resilient within a certain time scale. Humans can survive massive blood loss or loss of oxygen, but only for a very brief period of time.

Consider some other resilient biological systems. MRSA are bacteria that resist even the strongest of anti-biolitics. MRSA are resilient because some bacteria were either mutants that survived the blast or were at the edge of the assault and survived to give themselves time to exapt, adapt or evolve.

An interesting aspect of resilience is identity. If we consider the financial system during and after the 2008 credit (liquidity) crunch, the financial system survived. However, the identities within the system have changed. Many of the people in the system lost their jobs but subsequently found new jobs with a new identity. A few banks failed, most notably Lehmann Brothers, but in reality very few banks actually failed, or ceased to exist. Rather than fail, many banks lost their identity as they were absorbed into other organisations (Bank of Scotland into Lloyds, Royal Bank of Scotland into the UK Government, Merrill Lynch into Bank of America, Bear Sterns in JP Morgan and many others).

As the Cynefin retreaters gather to discuss resilience, they need to consider the important of time. Reducing the time from a threat emerging to it being detected. Reducing the time from identify a threat to making a commitment (Boyd’s OODA loop). The time from decision to action (Liquidity).

The Cynefin retreaters also need to consider the scale of failure of a system. Whether it is individuals, identities or systems.

As a final thought, the human race currently faces a number of species threatening scenarios of our own cause. Whether its the temperature of the atmosphere, micro-plastics in the oceans, estrogen in the food supply or SAFE and LESS, something could threaten the species. Like our MRSA bacteria, some humans are likely to survive. The ones that do are likely to be the most resilient, the most lucky, and the ones with the most options. The ones with the highest centrality in the network are likely to be the ones to react first, the ones that are most likely to lucky. That assumes that their high centrality means they are not the first to be exposed to the threat, like the MRSA bacteria.

Whenever we think of resilience, we oft hear the phrase… “That which does not kill us, only makes us stronger”. I think that that depends on context.

I have been a fan of cognitive-edge technology and techniques for many years. Myself and a small group have been engaged in exapting sensemaker for use on Agile Projects. I did my Sensemaker training with Tony Quinlan. Tony subsequently delivered a fantastic introduction to Sensemaker at QCon which is the material I use when introducing it.

Sensemaker is a fantastic and valuable tool, though its usage in Agile transformations and projects is different to its original context. I will share my experience using the standard report format namely:

1. What is the context?
2. What did you try?
3. What worked?
4. What did not work?
5. What have you learned?

Context for using Sensemaker

In all three cases, there was a situation with a lot of uncertainty and the leaders showed great strength by trying something new.

1. In the first example, a leader heard about sensemaker and very bravely decided to use it to get unstructured 360 feedback from a large group of people.
2. In the second example, the team had scored “poorly” on one question on a company wide survey and the leaders wanted to understand why.
3. In the third example, the leader for an Agile transformation (two thousand people) wanted a survey to understand how people in the department felt about the transformation. A pilot with fifty people was run to test the process.

It was only because I had run the first two fairly small sensemaker exercises that I had the confidence to run the much larger (and personally risky) third exercise.

What we did

In all three cases, the leader sent an e:mail out setting the context for the survey and asking for the team to participate. The sensemaker survey they were asked to fill in was a slide in a powerpoint presentation. In the first example, the survey was also printed and handed out in a team town hall. In each case, the leader introduced the sensemaker survey in the townhall or extended leadership meetings.

The responses were all anonymous. In some locations a “post box” was created for the team to post their response. In some locations, team members would send their response to a trusted colleague who would forward them to the person collating the results. Many people felt comfortable enough just to send a response directly.

Unlike the sensemaker method which starts the signifier creation process with a literature search, the triad signifiers were created using terms commonly used in the environment. For the 360 degree feedback, the leader incorporate the six headings in the corporate leadership assessment. For the Agile transformation, phrases common to agile and software development were used (Technical Debt, Architecture, Deadline, Business, Leadership, Culture, Mastery, Autonomy, Purpose, Business Value).

The results were collated manually. Each dot on a completed survey was collated onto a large triad, one per powerpoint page.

The sentiment (positive, negative, neutral) was depicted using colour (red, grey, blue respectively) and strength of sentiment ( normal, very) by shape (dot, circle). Red / Blue was chosen as traditional red/amber/green are difficult to differentiate for those with colour blindness which is common in technology.

The results were summarised. The summary and original survey sheets (or scans of physical paper) were included as an appendix to the summary. The individual stories were ordered by sentiment, and a hyperlink was placed on each summary diagram to the first story of each sentiment to speed up finding the stories.

The results were played back to the leadership team and then to the participants and the wider group. Each was invited to interpret the summary triads for themselves for before discussing them, and to read the stories associated with each cluster.

What worked

Sensemaker works! It provides useful and actionable insights.

One of the key experiences is that sensemaker shows you what people are not telling stories about. The gaps are as telling as the positive or negative clusters. For the first example, the leader was a very accomplished practitioner in the technology, however their other abilities outshone their technical skills. Armed with this knowledge, they were able to “create more stories about their technical abilities”.

One of the most powerful aspects of Sensemaker were the conversations that the exercise prompted each time. It provided a focus for some very difficult conversations that were based on data points (stories) rather than opinion. It enabled the group to make sense out of situations. Many of the things that Sensemaker revealed were already known, however they were difficult to discuss as opinions without “Hippos” closing down the discussion. Getting data to support a hypothesis with a traditional likert scale survey would have been politically unacceptable however the Sensemaker reveals the data without conflict. Once revealed, the stories can be discussed.

When you do a Sensemaker exercise you realise how beautifully it fits with the Cynefin framework. Discussions easily reveal things that are obvious or have multiple hypotheses. Sometimes, the discussions reveal it is necessary to dig deeper or bring in an expert. There were also stories that simply require action without understanding. Sensemaker helped us shape the transformation and resulted in several specific changes.

The three exercises only involved a few dozen stories rather than the massive number of stories that Dave Snowden and Tony Quinlan describe. Even though they numbered a few stories, they still provided valuable insights. Sensemaker works on the small scale as well as the large scale. Within organisations, culture tends to be determined at the tribe level (dunbar number of one hundred and fifty or less) with a dominant individual or group of individuals defining the culture.

Starting small helped me learn about Sensemaker. The first sensemaker exercise was small and fairly low risk. The experience at this level gave me the confidence and case study to refer to for the riskier second exercise. My experience with the first two exercises exercises helped me better understand the issues and provided me with stories that enabled me to convince the leaders for the third exercise. Starting small was safer for the leadership team and let them experience the approach before they tried it on a wider group outside of their area of control. My main practical advice would be start small and grow.

The leadership team said they would like rerun the Sensemaker exercise on a regular basis to track the progress of sentiment in the team.

What did not work.

Although the manual exercise was incredibly useful and valuable, reviewing the results was clunky and required a lot of effort. The manual approach is certainly limited in terms of scale. Above one hundred stories, it is likely that it would start to fail, and it would be necessary to use Cognitive Edge’s sensemaker tool. Ideally I would have preferred to use Cognitive Edge’s sensemaker tool but unfortunately that requires spending money. Spending money is the one thing that managers in large organisations do not like to do. The hope is that sharing the experiences with executives will lead to them to freeing up the funding for larger exercises. This is particularly difficult in an environment where people are used to getting their software for free (open source).

Although the results were insightful and valuable, we got stories from significantly less than half the people asked to participate. I worry that we got the “CYNics”(1) who cared but there is a large silent majority who have a different set of stories and opinions. I suspect the cognitive edge software would help with this.

(1) See the Dave Snowden’s references to cynics.

What did we learn

Sensemaker is a great tool to provide insights into your organisation when you are planning or engaged in an Agile transformation.

The normal Sensemaker approach (e.g. Literature search for signifiers) isn’t necessarily needed when the language of the culture is already well understood.

Sensemaker facilitates difficult conversations and is useful even if “no one learns anything from it”.

Even though Sensemaker and Cynefin are valuable when used individually, they are even more powerful when used together.

Next Steps

The Sensemaker and Scaled Agile Practitioner Community need to do more work together to better refine and exapt Sensemaker and Cynefin usage in the Agile Community. A summit focused on the use of Sensemaker in the initiation and monitoring of Agile Transformations would be very valuable. In particular, packaging Sensemaker with Dan Mezick’s Open Space Agility.

One of the cornerstones of scaled agile is transparency. This is particularly true for executive transparency. Unfortunately transparency is a double edged sword and executives involved in transformations normally avoid it like the plague.

Transparency allows executive running a transformation to demonstrate that they are a success.

on the flip side…

Transparency shows when transformations are failing.

If you are an executive and you intend to succeed, the first thing you will do is establish transparency. That way, when you are a success, it can be demonstrated rather than a matter of opinion. Furthermore, if you do not have transparency into the transformation, you cannot identify the things that need your focus to improve. As Jabe Bloom says in his 2017 Lean Agile Conference talk, data should provide an invitation to executives to “Go to the Gemba” (Go and see where the work is done). In other words, the data shows you where to go, and then the executive should go there so that they have total transparency into what is going on, not a view of the world filtered through management updates, excel and powerpoint.

The exemplar of this behaviour is Mark Gillett. I worked for Mark helping to build a dashboard that showed the state of the business. Our top three metrics were “Number of customers”, “Activity” and “Revenue”. Mark invested heavily into the accuracy and coverage of these metrics. What he wanted was not available “off the shelf” so he build a world class group of developers who could deliver what he needed. He could drill down from the number of customers into the customers per product, or drill down into “New Customers” and “Churn”. Overall we had about four hundred metrics. Once these core business basics were in place, Mark worked on the operational metrics to give a better understanding of how effective the business invested in the products… lead time, bugs, performance. The key thing is that these were not executive metrics, they were the metrics that everyone in the business looked at. And this is the key point, everyone in the organisation knew that Mark looked at these metrics regularly, and they behaved accordingly. They cared about the results because they knew Mark could see if they needed help.

Jira is a tool developed to help teams manage their development. It is not a tool to manage across teams or at an enterprise level. In order to create transparency for executives, you need an expert who can extract the data you need to create the views they need. One of the graduates working with us created an app to extract data from Jira into an SQL based database. Once the data was in the SQL database it took a couple of days to create an excel report that gave an executive view of lead time using weighted lead time.

Recently a couple of colleagues and I created the first version of a report that allows executives to drill down to a deliverable and then see view the value stream for the deliverable with colour coding for the different teams. It is possible to drill down from the value stream to a cumulative flow diagram for each team. This was all in a couple of weeks part time. The numbers ain’t great but they are better than nothing and they provide the executives with “invitations to the Gemba” as Jabe would call them. (I will shortly be creating an open source product to give executives transparency into lead time and the value stream.)

If executives want to be successful with a transformation, they will demand transparency.

Executive who do not believe they can deliver a transformation avoid creating transparency like the plague. The problem with transparency is that it no longer the responsibility of the team to deliver, but everyone in the organisation, especially executives. Executives who do not “Go to the Gemba” can be held accountable when there is transparency.

So how do executives avoid transparency? Easy, they do not demand it. Everyone in their risk averse organisations will happily avoid looking at the metrics, especially if the executives can prove that they do not care about the metrics.

The benefits of not having transparency include the following:

• Employees do not need to improve.
• Employees (especially the executives) do not need to learn new techniques or approaches and can continue using the “same old” methods.
• Executives can manage using their opinion rather than using metrics to reveal reality.
• Executives can ignore problems they do not feel comfortable with.
• No one can be blamed when the transformation fails to generate any improvement.
• Good people who wanted to achieve results will leave.

So if you want to be part of a successful transformation, look for an executive who is demanding transparency and has strong (but weakly held) opinions on how they will get it. When you go for the interview, ask the executive to tell you when they have “Gone to the Gemba” based on the transparency they have in their metrics dashboard.

If you want a long term coaching engagement with no expectation of delivery of improvement, look for one where the executives do not care about transparency, especially around lead time.

Why I’m going to create an open source lead time tool.

From my experience, if executives do not have transparency into the lead time of deliverables, they do not care about improvement. If they do not care about the improvements, then neither will most of the people that work for them. This makes it hell for Agile Coaches who are bought in to help people adopt new approaches.

Building an executive lead time dashboard requires specialist experience. Without the dashboard, it is hard to create that transparency. The one thing management controls absolutely is spending money which makes it hard to bring in products you have to pay for. Therefore to help my fellow Agile coaches, I intend to create an open source (free) product to visualise lead time and value streams.

More details to follow.