In November 2017 (or back in November 2017, depending on when you’re reading this), I will have (or have had) the privilege of speaking at the annual itSMF UK conference (ITSM17) on the value of the Cynefin framework to IT service management (ITSM). There is so much that I could say about this topic; in fact, it was all my conference buddy (the sagacious Daniel Breston) could do to prevent my talk from becoming a two-day lecture!
The Cynefin framework has previously received an enthusiastic reception from governments, NGOs, think tanks, and the Agile community. However, surprisingly, there is limited knowledge and adoption within the service management community, which is something I feel needs to be addressed.
I don’t intend to repeat my Cynefin presentation here, so I’ll assume you understand the terms I’m about to use.
While it’s tempting and easy to categorize our organizations and ITSM departments into one of the domains, the reality is rarely that neat – in fact, your organization is likely occupying at least three domains: “Obvious”, “Complicated”, and “Complex”, and has the ability to slip into “Chaotic” when bad decisions are made, or a bad situation is left unchecked. I like to say that the “IT” in ITSM will more likely act in the ordered domains, while the “SM” in ITSM will more likely be in the unordered domains.
Here’s an example of that distinction: in my talk, I describe the difference between technical cause (the event of transaction leading to an incident, which can be discovered with sufficient analysis) and root cause (the underlying “environmental” conditions that allowed the incident to occur). In other words, technical aspects of what we call “root cause analysis” can be considered to be sitting in the “Obvious” or “Complicated” domains, but the human or “environmental” aspects would sit in the “Complex” domain with Cynefin.
But what does it mean to be in the “Complex” domain … or more generically, what is a “complex adaptive system”? There’s a lot of science behind those words, but let’s focus on some commonly accepted properties, and how they apply to the field of service management (and Cynefin):
- The number of “agents” (or parts) in the system are sufficiently large that conventional descriptions are impractical, or may even harm our ability to understand the system. The traditional ITIL® definition breaks a service down into people, processes, products, and partners (the “4P model”). That’s a deceptively small list, which could be expanded to cover IT teams, non-IT teams, contractors, consultants, trainers, tool vendors, auditors, regulators, and various technical systems and components (and that isn’t an exhaustive list, either!) We can’t possibly hope to model or discover every link (and the way those links change over time) between every agent. If we were to run a series of simulations of a complex system, using the same starting conditions, we would get different results every time. Einstein is broadly credited with saying “The definition of insanity is doing the same thing over and over again, but expecting different results.” I wonder if he’d withdraw that quote after reading up about complex systems!
- There is no single leader co-ordinating every agent in a system. Look at that list of agents above – there isn’t a single leader directing their actions (conspiracy theories aside).
- Individual agents follow simple rules. At a micro level, we can predict the behavior of an individual component with relative ease. Consuming a service will increase my bill at the end of the month. A red light on a monitoring dashboard will create a ticket. It’s when we put everything together at scale that we lose the ability to model the system – in other words, the system is greater than the sum of its parts. Cynefin fun aside: in Isaac Asimov’s Foundation series, the technique of Psychohistory depended on the idea that while we cannot foresee the actions of a particular individual, mathematical techniques could be used to predict the general flow of future events.
- The interactions of large groups of agents will generate emergent patterns. The dynamics between agents in a complex system will give rise to novel patterns or structures. Some of the best ways to explain this are in nature – a snowflake looks nothing like water. Unofficial support groups, or shadow IT, emerge as a result of perceived failures in a support organization.
- The system adapts around, or reacts to, interactions, emergent patterns, or alterations. Outputs feedback as inputs. As various agents interact, and as patterns emerge, a complex system will adapt and mold itself around these patterns. For example, changes to your service desk policy will make the business change the way it behaves with customers, with IT, and other agents in the system. This in turn will change the way the IT organization (and the service desk) behaves, and so on. Each little change to an agent has the potential to change the system.
So how can we possibly hope to manage our complex, adaptive IT services? There are many possible techniques that could be used, but I would like to return to the Cynefin framework, where the rule of thumb is to “Probe, Sense, Respond”.
- Probe: Make a small change to an agent under your control. Modify the service desk policy to limit interactions to email-only. Introduce standard, pre-approved changes.
- Sense: Recognize the pattern and behaviors that have emerged from your change. Using the above examples, perhaps the number of service desk contacts have dropped, but business satisfaction has increased (perhaps due to shadow IT … or is it bad metrics?) Perhaps the number of successful changes has increased, but the number of incidents has also increased (perhaps due to lower service resilience … or is it because the larger changes are not being adequately tested as resources are tied up with routine change?)
- Respond: Figure out how you can encourage the behaviors or patterns you want, and discourage those you don’t want. But remember – the encouragement/ discouragement itself will change the system!
There’s a lot of literature describing properties and behaviors of complex systems, as well as writing on relevant management techniques (including Cynefin). I would encourage service management professionals to take a look at Cognitive Edge and the Cynefin framework if you wish to learn more.
Akshay Anand
Akshay Anand is a seasoned ITSM professional, with over 20 years of experience delivering projects and running service management teams across India, UK, and the US. Recently, he served as a Lead Architect and author for the ITIL 4 body of knowledge and was the Product Ambassador for ITIL 4 from 2018-2021. He is a Principal Solutions Engineer at Atlassian working across Sales, Product Development and Product Marketing to promote solutions based on Jira Service Management. He is also a recognised blogger and podcaster, passionate about bringing Lean and Agile practices into IT Service Management, as well as promoting mental wellbeing and human-centred ways of working. He can be occasionally spotted tweeting as @bloreboy.
