Cynefin and Software Testing — The Complicated Domain

At the top right of the Cynefin sensemaking framework is the domain of the Complicated. Like the Obvious domain it describes an ordered system, in that cause and effect can be predicted with a high degree of accuracy. The major distinction here is that understanding the rules and relationships that make up a Complicated system is not straightforward. They are discoverable, but not without sufficient expertise to analyse and interpret them. In the complicated space, there may be one or more useful solutions to a particular problem. You might define a playbook to respond to situations that arise, but the onus is on those with knowledge and experienced to determine which course of action is most prudent.

Let’s use a hypothetical form on a website as an example.

An end user fills in the form, hits submit and receives an error message. To a lay person, they may conclude that the site is broken or the form doesn’t work. If they don’t have a grasp of client-server architecture then that may be as far as their comprehension of the problem goes.

Someone with software development expertise might recognise what is going on from an http error code (whether on screen or through the browser development tools), or be able to troubleshoot the issue further. They might look at http requests, responses and payloads, trace the route of the requests, possibly manipulate the requests to see what changes, check ping times. If they have access to the server they might check logs for the app and anything that connects to it (upstream services, database etc). The root cause of the problem and what to do in response may not be immediately apparent, but is discoverable given the right expertise.

A Brief Note on Constraints

Constraints form the boundaries between the various domains of Cynefin. On the right side (Obvious & Complicated), you have governing constraints. If you think of an exoskeleton, you have the possibility of variance within a specific boundary. On the left (Complex & Chaos), you have enabling constraints, or to extend the analogy, an endoskeleton that forms a coherent structure, but allows significant variance around it. A great deal of Cynefin’s utility is in the movement between domains, so it is worthwhile understanding constraints as they relate to the framework.

Given a lack of constraints, people will tend to behave in a manner that is most comfortable for them. Within given constraints, the same will occur and behaviour will differ depending on the nature of the constraints, whether or not they conflict with what is comfortable and amount of energy (and/or discomfort) involved in ignoring/breaking them.

Constraints might be deliberately put in place or they may be environmental or grown organically over time (e.g. company culture). When you are aware of these constraints, you can act to change them or redesign them to engender different behaviour.

Let’s take a look at an example in the complicated domain:

Applied strictly, Agile ceremonies (standup, retrospectives, demonstrations, story refinement sessions, WIP limit etc) can be examples of governing constraints. Before you grab your pitchforks over the ‘applied strictly’ thing, let me give you an example where this might be appropriate. Imagine you were coaching a team who has done waterfall projects previously, but is unfamiliar with agile development principles. In order to help them reach a stage where they can be self-directed, you might initially advocate fairly strict adherence to ceremonies (in effect, treating them like rigid constraints). This is not to be prescriptive about ‘doing agile properly’, but to provide bounds within which to work. It allows coach and team to focus on things like identifying the next most valuable thing to work on, how to create a well formed story, when to run spikes for more information, actual delivery and presentation of value, communicating with stakeholders and so on. Once the team finds a rhythm and naturally start to focus on short feedback cycles and regular delivery of value, you might then relax the ‘rules’ a little and let them flex to suit the team’s specific context. They become guidelines that govern team norms and what they can expect from one another. As the team continues from iteration to iteration, you might pay attention to the ‘why do we have to do X?’ and ‘I don’t get why we Y’ sort of comments and questions and encourage the team to explore them. It’s natural for people to probe constraints and question and seek to improve.

Inauthentic adherence to constraints

If however, you were to try and maintain these constraints beyond where they were useful, then you might start to see them fail in interesting ways. You would in effect be treating a complicated domain as though it were obvious. Your team might start paying lip service to your ceremonies, but acting counter to them in order to actually get stuff done. An example might be working on stories still in the backlog because WIP limits are in place and all in-play stories blocked. This might be a legitimate action to take, depending on the circumstance, but if the focus is on ‘following the rules’, then you drive this behaviour underground and foment dissatisfaction.

The observant will notice that spanning the boundaries of each domain is Cynefin’s fifth domain — Disorder. This is the state of not knowing which of the other domains one is in. Inauthentic adherence to constraints is one way of finding yourself in a state of disorder. You may think that the guidelines you have in place are working for you and the team only to discover to the detriment of things like team harmony of project progression that this is not the case at all.

Dynamics

It is difficult to talk for very long about Cynefin without running into dynamics — that is moving from domain to domain or cycling between them. Dynamics in Cynefin are deserving of their own post (and for the impatient, see Dave Snowden’s musings on the subject). For now though, it is worth briefly touching upon.

It is overly simplistic to say ‘I am an expert in software development and therefore I work in the complicated space’. There is no need to cleave to one area as being ‘better’ than the others. Each of them is useful and may be appropriate given the right circumstances.

The complicated space is where experts excel. They have specialist knowledge that is applicable in a way that is predictable and repeatable. Trying to apply the same approach in the complex space however is no guarantee of success. In the complex space, causality can only be comprehended retrospectively. It is probably more accurate to say that failure in the complex space can be comprehended retroactively. You tend to be able to trace the elements of failure. Tracing success is far more difficult. There is significantly more to say on the subject of dynamics, but I will leave that for another post.

For now, I shall point at James Christie’s excellent post on Cynefin , and in particular in which he details the important differences distinguishing the Complicated and Complex domains.

Originally published at http://testjutsu.com on June 19, 2017.