Intro
You might have already come across terms such as complex systems, complicated systems or complex adaptive systems; especially, if you have read Management 3.0 by Jurgen Appelo or heard about Ken Schwaber’s ideas about the applicability of Scrum. It might sound intriguing, but finding logic in it is difficult without some background theory. This is the point at which Dave Snowden’s Cynefin concept comes in handy. This concept is based on complex systems theory, anthropology, evolutionary psychology and, last but not least, cognitive psychology.
What’s the matter with software development?
For about forty years people who deal with software development have been wondering what it really is. Can we compare it to anything? Initially, people approached it the same way as it was in Ford’s factories, i.e. through classical management methods and tools such as hierarchies, division of work, specialization, plans, etc. It did not work, though. The popular metaphor, according to which software development is like the process of designing and building a building, did not work either. It was Agile that went a step further – it was finally accepted that change is a natural element of any project. Technologies change. Requirements change. Our co-workers change (which is obvious considering the fact that it takes months or years to complete some projects). Therefore, whenever we run a project, we have to take changes into account. And we have to adapt to them. That is how Agile has aroused, including the most popular method Scrum. Sometimes they proved effective, sometimes they did not. People started seeking for a theoretical background that would allow them to understand why Agile really works and what are the criteria that would help them decide whether they should use it or not.
The Cynefin Model
In this respect the Cynefin model comes in handy, as it organizes problem domains that we come across depending on the applicability of approaches used. The basis of this model is the relationship between the cause and its effect. As a result, the following areas of problem (system) complexity can be listed:
·
Simple– systems, in which we can easily associate the cause and the effect. This area includes domains that are well-identified and thoroughly described in literature; they do not require complex interpretation and there is a huge number of resources that deal with them. When you buy a new mobile phone and you want to configure it using the instruction manual, it means that this is a simple domain (of course, as long as the manual is clear enough). In this area you can use recipes, best strategies and models that you can easily and directly put into practice.
·
Complicated– systems, in which there is a cause-effect relationship, but it is difficult to detect it. Finding a solution to problems from this domain often requires expert knowledge, a lot of experience and complex analysis. Apart from that these are usually static systems or systems that are not really vulnerable to changes (if there is a change, you can easily predict and analyze it). Examples of such systems include a watch, a car or a house – they are static, but to create or repair them we need some expert knowledge.
·
Complex– systems, in which there are no clear cause-effect relationships, because they change with time. We can detect them through experiments and investigations into the current state of affairs. Even expert knowledge does not allow us to arrive at a solution, but we can use it to set the direction of investigations. Systems under this category are live, organic and changing. Where there are people, there are usually complex systems. Examples of such systems include a stock market, a brain, the immune system, societies.
·
Chaotic– systems in which there are no cause-effect relationships. We cannot detect them, because they do not exist. Examples of such systems include all emergency situations, fires and disasters.
·
Disorder– a situation in which we are unable to define the type of the system that we deal with.
How does it relate to software development?
Below you will find a couple of examples. We have a simple system whenever we have a first-line support. The client calls us, because he/she does not know how to add another lead in the CRM. First-line support worker leads him/her by the hand and helps solve the problem (which could be solved by the client if he/she spent more time on it).
Another situation. You want to install additional software on your PC. It turns out that it requires drivers. You download the drivers. Next you install them. It works. This is an example of a problems from a simple system. But let’s assume that you work with a Linux-related OS and to install the drivers you have to recompile the kernel. A common user just won’t manage. Thus, we enter the area of complicated systems.
Most of our development job revolves around complicated systems. Container and development system configuration, authorization, authentication. This is expert knowledge that we need to develop software. On the whole, in its basic form design and programming are complicated systems as well, but… Yeah, but that’s not so obvious. Let’s assume that you program for yourself, you are the source of requirements, you write a piece of code that you can complete in 10 hours or so, and your code will mostly remain unchanged. This is a complicated system. Even when we consider a serious long-term project (at least a few months’ long) and we are lucky enough to have requirements that are well-defined, settled and do not change, we still deal with a complicated system.
Talking about maintenance we can also talk about complicated systems, but only on condition that the system that we maintain does not develop (our work boils down to fixing the bugs).
But if the situation is different, i.e. the requirements change, they are specified in the course of the project, or the project participants change, we have a complex system. In such cases programming – both the design and the code – has to be perceived as a complex system. I think that we are all aware of the fact that most development projects fall into this particular category.
Of course, some of them are chaotic systems as well. It is so if there are no rules, the team works ad hoc and most of the work boils down to putting out fires. This is chaos. Both literally and metaphorically.
What does it give us?
Exactly. Theory will always remain theory. There is one important question – what do we need it for? According to the Cynefin model, when we define the system, we can apply means that are context-dependent. These means are:
·
The main strategy
·
Leader’s activities
·
Tools
Context |
Strategy |
Leader’s activities |
Tools |
Simple systems |
1. Sense 2. Categorize 3. Respond |
monitor the process, standardize, delegate, use best practices, |
best strategies, 5 WHYS, manuals, recipes, PMBOK |
Complicated systems |
1. Sense 2. Analyze 3. Respond |
form an expert panel mediate |
processes, standards, expert panels, Kanban, PMBOK |
Complex systems |
1. Probe 2. Sense 3. Respond |
leave space for the team self-organization, improve communication, empower |
trials, experiments, discussion, limited self-organization, Agile, Kanban |
Chaotic systems |
1. Act 2. Sense 3. Respond |
act and conclude on this basis, communicate in a simple and unambiguous manner, command and control |
do whatever, intuition |
Practically speaking, it is impossible to classify a project into one type only. Contexts are mixed, but there is usually one dominant context. If the simple or complicated system dominates, PMBOK tools will be useful. If we deal with a mostly complicated or complex systems, Agile and Lean/Kanban tools might help.
Summary
As we could see, Cynefin gives us a way of seeing the complexity of problems that we come across. It divides them into four main areas and suggests some workable actions to take. Thanks to it we know that a self-organizing team does not have to be the best solution in each development project, and that in the case of chaos the best way is to use command-and-control management. Chaos might result from frequent and unpredictable changes in the project or in the team. Alternatively, it may be a natural consequence of poor skills of the team members. On the other hand, however, in predictable environments you don’t necessarily have to struggle to use Agile as the only justifiable solution and classical methodologies might prove ineffective in complex domains.
Nevertheless, Cynefin is not only a model – this is also a set of strategies that we can use, especially in complex domains.
But... life is not so simple though. The model itself doesn't give you direct answers. Even Dave Snowden is not always sure were to put some software development practices (you can dig into his blog here). On the other hand it is a quite interesting perspective you can take into consideration while making decisions.
