I had the pleasure of being one of four Agile panelists answering questions at the Tampa Bay PMI Symposium (good turn out with more than 300 registered). One of the other panelists, my friend and respected Agilist Steven Granese, mentioned the Cynefin Model. After that discussion, I felt it would be good to discuss the Cynefin Model and how it supports an Agile process, especially when dealing with complex situations. So, here it goes …
The world is complex and shows no sign of abatement. The military learned this as they dealt with different autonomous Al-Qaeda (AQ) cells. Teams of our military personnel did not have time to contact command to formulate or validate plans. They couldn’t identify many set patterns because AQ would continuously adapt. Our military could not be even relatively sure that the same tactical action would yield the same result in each situation. So, they dropped the silos between teams and departments and opened up communication; empowering the individual teams. Previous information that was on a need to know basis was now available. They let their units make decisions, probe with different tactics and then share the learning later on. This problem area certainly fit in the complex domain of the Cynefin Framework.
Cynefin (pronounced kuh-nev’-in) is a leader’s decision framework developed by David Snowden that aligns things into defined domains. The framework was developed for knowledge management and strategy, but I believe can assist us in identifying the need for Agile software development. Cynefin prescribes the way to act on something is based on the domain it falls in.
The five Cynefin domains are:
Obvious or Simple (the known) – We’ve seen this a million times and as such can categorize and respond according to established best practices. The relationship between cause and effect is well known.
Complicated (the knowable) – Although we don’t immediately know what is happening, we can analyze the situation and come to a conclusion of what must be done. We can enlist experts to analyze, set up constraints and a process addressing resolution.
Complex (the unknowable) – We’re not able to determine what will cause a particular result. The best course of action is to conduct experiments and check if any or all take us in the correct direction. A lot of time when human opinion and decision is involved we could be working in this area; simply because humans are complex beings.
Chaotic (the incoherent) – The situation is very unstable. We don’t have time to experiment or probe since the situation is dire and we need to act. An IT issue that must be taken care of immediately with no delay may be categorized as such. If we have no time to figure out a system deadlock issue, we may opt to get ourselves out of this chaotic state by rebooting the server.
Disorder (not determined) – Anything whose domain has not been determined falls into this domain.
Image provided by: InfoQ.com
The Cynefin Model suggests that we identify the domain type and respond accordingly. Agile (Scrum for example) is geared to operate in the Complex domain. The Agile methodology offers the proper Cynefin response to the uncertainty present in many software development projects. It is inherently adaptive and uses the “probe, sense, respond” method. Waterfall could handle Obvious and Complicated domain issues, but would fall flat when faced with a complex situation.
Software development offers issues that fall into all the domain areas, but if you use Waterfall you will be at high risk delivering anything in the complex domain area. If you use Agile, you could have some minor inefficiencies compared to waterfall in the simple domain, but you will reduce or eliminate the high risk of failure in the complicated, complex and chaotic domains. It seems sound reasoning then if you’ve got any unknowns involved then your software development projects would be minimizing risk by following the Agile methodology rather than Waterfall.