I was reading an article on InfoQ, but I could not tell you what the article was about because I was distracted by the shiniest of objects, a comment which seemed to have nothing to do with the article:“Cynefin is taking over the world”
I was fascinated by this word – “Cynefin”. Google led me to the video from Dave Snowden describing his
concept of a sense making framework. The Cynefin Framework is not for categorizing issues or people. It aims to help people make sense of situations where there may be no preexisting model to leverage. None the less, the work “Cynefin” itself and its definition reminded me about the import of role of an Agile Manager in aligning people to the sort of challenges they will thrive on, regardless of whether they are on the team or on the outside looking in at the program level.
Five Domains of the Cynefin framework - by Dave Snowden
People’s Preference for Action – Jumping from Disorder
Cynefin is a Welsh word. It has no direct translation into English. I became fascinated by the notion that its meaning encompasses "multiple factors in our environment and our experience that influence us" or “a place of multiple belongings”. The notion is that people’s response to a situation is influenced by their collective history.
The thought process triggered by reading about the Cynefin framework was probably not the one intended by Dave Snowden. I came across the framework during Context B when we had moved onsite with the client and their management had become overly interested in the day to day running of the development team. What I observed was, when confronted with an issue, they would tend to consistently react in a manner that suited their personal preference for action. If how they reacted did not align with the nature of the issue, it would cause a weird dynamic in the larger team as people shied away from conflict stemming from the confusion in approach. This made me take another look at the different forms of work and issues in play on our project. Not so much from the angle of trying to make sense of them but more from the idea that people’s preference for action should be matched to the type of challenges their role would encounter.
Operating in the Simple Quadrant
There were only a few folks on our project that lived in the Simple quadrant. Any task given to them tended to be categorized as a needing to fit into a standard procedure. If it didn’t they tended to criticize or reformulate the issue until it did. They didn’t want to treat an issue on its merits and learn new ways to deal with it. Alternatively we would see a transition from tranquility to panic caused by someone oversimplifying. In the Cynefin diagram, it captures this behavior with a little ledge or wave that drops from the Simple quadrant to the Chaotic.
Complacency with repetitive, mostly automated, tasks such as build and deployment is its own form of hidden evil. We found putting developers in the Build Manager role was actually counterproductive where you would normally expect better results. After a time, developers would tend to discount critical deployment steps as optional trying to up the challenge. Management would see failure where there had recently been success, leaving an overall dent in the trust we had been trying to establish with the move onsite. They would tend to step in with the heavy hand of someone smelling chaos.
Developing in the Complicated Quadrant
Most of the development team dealt with situations that fit into the Complicated bucket. They gravitated to the challenges that required thinking and analysis. The developers and testers were happiest when the big hairy problems were first analyzed and broken down by senior people but still wanted enough autonomy to determine how to implement the code or test. They felt insulted if solutions were spoon fed to them but often needed the team to swarm if the problem ended up being more complex then they initially thought. This was the sweet spot for the team. If a problem could be broken down so that the Sense-Analyze-Respond mode was appropriate it was best we stand back and let the team do its Agile thing.
Meeting Challenges in the Complex Quadrant
Our product owner and senior technical people showed the most enthusiasm when presented with problems that followed the Complex approach to sensing a solution. If a story was based on an existing pattern, they delegated them to others in the development team. In Context B there were brand new frameworks that needed to be thought about well in advance of implementation to give the client a chance to look at the consequence of alternatives. The really big and hairy problems, such as ensuring we designed for performance early on, tended to have that battlefield commander model, given as a typical example of the Complex quadrant. The options and a recommendation were only assumed to exist. The senior members would take various scenarios and play them out as best they could with concrete scenarios from the “field”. Initial ideas would be presented, debated, changed and changed back until the team started to sense the right direction. With this level of uncertainty, the restrictions implied by a fixed sprint length became our friend. If the perceived complexity fell short of the actual, the inevitability of the sprint end made sure we failed early. The team was given the opportunity to reflect on where their thinking fell short in an accepting environment that took the failure in stride.
Conflict in the Chaos Quadrant
The most perplexing quadrant into which select senior management liked to jump into was “Chaos”. What I found puzzling was the way certain people saw all problems as if they were chaotic when they were often something far less and were never presented as such. What I came to appreciate from Cynefin was that maybe they have always been rewarded by taking control of situations and forcing a path to resolution without engaging the team in a meaningful way. Unfortunately these people loved command and control, looking to the first sign of failure as their opportunity to step in and take over, thinking they were saving the team. I noticed these people tended to use language implying problems were “a disaster” or as being “out of control”. It seemed to give them the justification to force a solution rather than letting the team probe the issue. Where they did serve the team was in removing organizational impediments by laying siege to external teams, that we had critical dependencies on, raining down the equivalent of boulders and fire until reasonable terms had been established.
Channel Behaviors for Mutual Benefit
A healthy team will thrive on diversity. However you can never expect an ideal alignment of people and their natural group-like behaviors to what an Agile setting would prefer. Recognizing their natural predisposition means at least you can have them dealing the type of problems most appropriate to how they react. From there you can convert an adversarial relationship to a productive one. On our project I have witnessed the transition of individuals to a team as they got into their own state of flow. Building that appreciation of how they tick and sending them in the best direction will no doubt give them a sense of place, no longer strictly where they have come from but one present with the team and where it is headed to. As an Agile Manager this responsibility goes beyond the team into the program. In Agile, this outer realm is assumed to be an audience to be restricted. I see them as unused experts waiting to be engaged and challenged.
As to the intended use of Cynefin and what it can do to help out in dealing with complexity in software development, keep an eye out for CALM Alpha events. Thought leaders from both sides are trying to mash Agile and Cynefin to see what new ideas can be generated. Check out the Cynefin framework out for yourself; because if it does indeed take over the world, you may need to join its ranks.