Proponents of agile promote and praise it on all possible occasions. Why? And why is it often heard that agile does not work, cannot be used, etc.? Can “both camps” be right? CYNEFIN framework will help with the decision!
The basis is, of course, an understanding of what an agile approach is, and why in some cases it proves to be very useful and in other cases quite inappropriate. Indeed, it is customary that one approach simply does not cover the whole issue. Experienced project and top managers know it well.
Much has been written about the agile or waterfall. However, and somewhat paradoxically, most of the texts do not solve much, what is the nature of projects and in what environment they actually took place. They seem to demonstrate a “conventional” or iterative approach on the same project in the same context. However, this can be very misleading! It is the context and the type of problem solved by the project that is important for making the right decision whether to apply a conventional approach, an iterative approach or perhaps to treat the whole matter completely differently.
CYNEFIN framework
Let us first map out the environment in which we usually move. In addition, CYNEFIN [KUN-iv-in] (a word from Welsh meaning favorite place, locality, domain, etc.), which Dave Snowden of IBM Global Services came up with in 1999, is an excellent framework. It divides the context in which we operate into five domains:
Clear / simple
The first domain of the CYNEFIN framework presents well-known problems and a clear expected outcome and workaround (also known as “known known”). Rules or best practices are known, the environment is stable and the sequence “if A then B” is clear and happens (usually).
The recommendation for behavior in this domain is to “understand, classify, respond”. So, after we understand the situation, it is necessary to correctly classify it and then just act according to the given rules for the situation.
For example, it could be an incoming order. The worker to whom arrives the order classifies it according to pre-defined categories and then applies the appropriate procedure – eg handing it over to the appropriate department to process it and to issue the invoice.
Is that clear enough?
It is therefore clear that this domain is the domain of processes, clearly defined procedures and generally good practice. Eg to always require a prepayment for an X client. In short, it is about finding the appropriate rule and its application.
Unfortunately, sometimes it happens that managers tend to make some problems and situations too light and push them into this domain. This approach can have disastrous consequences with the end in the chaos domain. It is easy to implement a new ERP system, just set it up… 😉
Complicated
The second domain of the CYNEFIN framework consists of “known unknowns”. For a proper response (and an assessment of the if-then relationship) a situation analysis and a choice of possible good solutions (good practice) are needed.
An example of a problem from this domain is the construction of a bridge. There is no single bridge type / design suitable for all environments. However, there are standards and standardized procedures for bridge design and construction.
In this domain, the key players are engineers, specialists, experts, etc., who are able to correctly analyze the situation and propose the right solution. Which is implemented according to the plan, later on.
Complex
In the third domain of the CYNEFIN framework, the uncertainty continues to grow and we work with the “unknown unknown”. If – then it is possible to deduce only retrospectively. It is not possible to determine in advance what is the right solution.
The recommendation for this domain is to “explore – understand – respond”. So try to do something (prototype, probe), understand what happened (gather feedback) and then respond to it.
The distinction between complicated and complex is needed as the difference between aircraft and corporate culture. The aircraft is certainly very complicated, but an experienced technician knows where to look for problems and how to solve them so that the aircraft continues to work. And it is still the same aircraft. On the other hand, changing the supplier of catering services can also lead to very unexpected and unpredictable impacts within the corporation, eg increased staff turnover or reduced morbidity etc.
Complex situations are generally referred to as battlefields, markets, ecosystems, companies and other systems, which as a whole are much more than the sum of the individual parts.
Chaos
The fourth domain of the CYNEFIN framework is represented by the total uncertainty of the relationship if – then. The recommended procedure here is de facto the search for islets of stability. There is no time and space to do a comprehensive analysis to understand the situation.
That is why it is also recommended to act, understand, react. That is, to start doing something, to understand what is and is not stable, and then to react to trying to turn chaos into a complex situation (or complicated or simple).
An example of chaos is the situation just after a disaster or a terrorist attack. In the beginning it is not really clear what actually happened, how big it is etc., however (somewhat simplified), firefighters just start to extinguish, rescuers take away the injured and after some time the situation “gets under control”. First of all, panic must be avoided – and “just start doing something”.
Disorder
The dark fifth domain in the middle is what most people intuitively call as chaos (but CYNEFIN defines chaos as a manageable fourth domain after all). Thus, in the CYNEFIN domain, “disorder” is primarily “no one knows anything.” It is not clear to which of the four domains the problem belongs, people argue with each other, and overall there is a certain cacophony during which “the left hand does not know what the right one is doing”.
The only way out is to divide the situation into sub-parts and to include them in the respective domains.
Movement between domains of the CYNEFIN framework
It is also common that with increasing experience and knowledge, teams and companies can progressively move clockwise – that what was chaos at the beginning is a complex situation after gaining experience, a complex situation becomes a complicated situation with good practice, and it can be reduced to a simple problem with a lot of experience.
The situation itself may develop. E.g. building a branch of an international company can be a complex problem at the beginning, which, after we have built three branches, turns into a complicated (we already have experience and practice) to a simple one (starting the 150th franchise).
Of course, the movement can also be in the opposite direction, for example, when workers with key experience leave the company and their knowledge is lost.
Note: Very good CYNEFIN infographics is here.
Use of CYNEFIN framework in (project) management
The more attentive readers certainly did not miss that the first and fourth or even the fifth domain has little to do with projects. Clear and simple problems are solved procedurally with processes, chaos is more about crisis management and confusion is sometimes primarily in the company itself.
From the management point of view, complicated and complex domains are of particular interest. As mentioned above, an example of a problem situation in a complicated domain is the construction of a bridge. Generally, the complicated domain includes mainly projects that have a relatively clearly defined outcome and are implemented in an environment that is quite stable (the banks of the river usually do not change their location much). It can also be the construction of some technological equipment, machine, clearly (very clearly) specified IT applications, etc. We can look at it from a slightly different angle – the ratio between uncertainty (environmental instability) and uncertainty of the assignment, what should be the result:
Classic PM or Agile?
CYNEFIN’s recommendation for complicated problems is to apply good practice. In the context of PM, these are mainly standards and methodologies for project management (IPMA, PMI, PRINCE2). And because we are in a complicated domain, it should be possible to analyze the problem solved in detail, propose the right solution and then implement it.
Which is essentially a “waterfall” style of project management. And it is right here. And of course, it is right to apply concepts such as rolling-wave planning (PMI) or its application in PRINCE2 in the form of detailed planning of only the upcoming stage, while the others are planned roughly (and hence some indications of iterativity).
But what in complex situations? Here we can try to analyze, calculate and design for a long time and yet the result will not be correct.
Agile approach is excellent in the complex domain. Exactly in the sense of CYNEFIN, the recommendation to “explore – understand – respond”. Be it SCRUM, rapid prototyping, lean startup or another iterative approach. The basis is to do some experiment, prototype, first sketch, get feedback, and proceed to the next iteration accordingly.
So, here is a recommendation of the CYNEFIN framework
When deciding whether to try to create an agile team with all the necessary attributes or to proceed in a “conventional” way, it is very appropriate to consider in what problem domain the problem solved is located. Building a bridge with the SCRUM team will probably not occur to anyone. For IT or organizational projects, however, the situation may not be as obvious.
First of all, in projects that have many stakeholders, many users, etc., we always have a relatively high probability that it will be rather a complex situation. If we design an information system with an impact on a large part of the company, it is almost certainly a complex situation. Approaching it as a complicated or even simple situation will almost certainly lead to very unsatisfactory results. As a consultant in PM Consulting company I had the opportunity to see a number of such poorly implemented IS implementations in person.
On the other hand, if we “only” migrate data from one system to another, even though it may be a complicated process, an agile approach is unlikely to be the best.
Conclusion
Various web portals are also a good idea for an agile project. These may seem simple, but honestly, who is able to put enough detail on the website at all, then not change it and be satisfied and without comments with the solution delivered?
On the contrary – if we are simply to “produce” a power generator with clearly defined parameters, we may have to work in design, purchase, production, etc., but this is probably not a suitable situation for an iterative approach. Why? Because there is a better functioning good practice!
Let’s be careful when applying iterative or conventional approaches, depending on which domain of CYNEFIN framwork is in our problem. At least it can direct us in the right direction.
Add your comment