Teemu Hyyryläinen is an agility guru from Reaktor. In his work he coaches software development teams and trains organisations towards more agile ways of working, and in his free time he balances the combination of six children's hobbies and his own travelling work. In this interview we dig into the nature of different kinds of problems and why agile ways of working exist in the first place.
The Cynefin model contains five domains:
Cynefin - a framework for understanding problems
Cynefin is a framework developed by Dave Snowden to support decision-making and understanding problems. From Cynefin's perspective, the world is divided according to the existence and behaviour of different constraints. The division is not geographical, based on colours or religions; rather, the aim is to model what kinds of constraints exist in our systems, externally or internally.
The Cynefin model contains five domains:
- Simple domain - everything is bounded and things work exactly as they are supposed to work.
- Complicated domain - There are more different factors and pieces, but they still work systematically.
- Complex domain - If the units, things and actors start making their own decisions, like drivers in morning traffic on an icy day, things no longer work in exactly the same predictable way. Then we are in the complex domain. Most software development is complex, and a large part of the organisational world is moving in this direction.
- Chaotic domain - No identifiable constraints. We cannot even know afterwards what happened, let alone analyse the situation in advance. A classic example is a severe crisis situation in a social environment. Then the aim is to carve some piece off the whole that would be manageable in some way.
- Domain of disorder - In the middle of the picture is disorder. That is where we are when we do not know, or have not considered, which domain we are in, and we act "the way we have always acted". The aim is to get out of here, so that we know what kinds of approaches and solutions should be applied to the problem.
The ordered domain
The simple and complicated domains are fundamentally the same domain. The only difference is quantity. Simple means there are two units. Complicated means there are a hundred different units with various lines between them. In the complicated domain the whole is bigger, but both the elements themselves and their connecting factors and context remain the same. Or change slowly enough for us to keep up. The ordered world remains deterministic, that is, the same tricks are done again and the same things happen repeatably. In the ordered world it is also possible to take things apart and redo them. In process language we talk about defined processes. Defined processes, the ordered world, the simple domain and the complicated domain are all the same thing. The only thing that changes is how many variables there are in the equation. The simple world is talked about a bit like a checklist. We see that that goes in that slot and this is what you do with it. When more things come along, analysis is needed, along with a professional who has done the same things before. In this domain there can be several parallel ways of working. Not all pilots make exactly the same moves to get an aeroplane safely to the airfield, but the aerodynamics of flying still work exactly the same way regardless of the situation, equipment, weather or other things. A professional can handle the situation without any problems.
The chaotic domain
Chaos is a state where the familiar, safe environment that behaves predictably disappears from around us. In chaos there are no causalities and no known constraints. In chaos we do not even know afterwards why something happened. For example, if society descends into chaos, you no longer know whom to ally with, which rules apply, and by acting in a certain way you might cause a good thing one day and a bad thing the next. In chaos you cannot see cause-and-effect relationships even in hindsight. For example, some poorly built and much "patched" system or process may be in a chaotic state. A company can drift into chaos. The market does not behave as assumed. Customers do not want this and that after all. Nokia drifted into chaos in a situation where they imagined they were the kings of the world, but no longer were. Suddenly everyone wanted touchscreen phones and everyone fell in love with the iPhone, which Nokia's marketing leadership dissed. Who would want something like that, without even any keys?! A person can live for a long time in the illusion that the constraints are what they are. And that is dangerous.
The complex domain
I prefer to define complexity through what falls outside it: First we remove all problems, processes and regularities that operate in a fully ordered way. They can be simple or complicated. For example, building an apartment block, or building a car in a car factory, where thousands of things affect the whole. A professional takes them into account and acts accordingly. Then we remove the chaotic domain, where no rules apply. In chaos there are no internal or external constraints. This brings us to empiricism, that is, working through experimentation. In the complex domain you have to start experimenting. We have an idea of what kind of problem we are solving, but we are not quite sure the problem is the right one, let alone what its solution would be. Then the ways of working must be based on setting out to study the matter. That does not mean flailing about at random, but making systematic experiments to find out what the truly value-adding question is and what its solution is. Value emerges through the process, rather than speccing a solution and then just implementing it. By creating some structure that supports systematic experimentation, a team is enabled to solve problems more effectively. Or by scoping certain things out of the problem to be solved, focus is directed more effectively at the core of the problem. At the heart of complex problem-solving is identifying the constraints affecting the current situation and, by changing those constraints, steering the work towards finding a solution. In addition, one must take into account that constraints change in a complex environment, so what was known last week or in the last project must be treated with healthy criticism.
Recognise your domain!
Recognising complex problematics matters. It is non-deterministic, which means that making exactly the same arrangements time after time does not necessarily produce a good outcome. Whether it is organising a party or developing software. If we have different things like screws, nails, nuts, wedges and tacks, it is fairly important to understand which is which, so that we know how to apply the right tools. But first they have to be identified. Imagine that an order is now brought to our company requiring a solution to problem X. If it is a complicated problem, we hopefully set about solving it with tools that work sensibly for solving a complicated problem. A screw is brought to us and we recognise that it is a screw. We fetch a screwdriver that fits the screw and start driving it. The opposite alternative would be that our firm only knows how to use a hammer, and we try to pound everything that is brought to us with it. Most of today's systems development is complex. If a complex problem is brought to us and we treat it like a deterministic (simple / complicated) problem and put it into a process pipeline of spec - architecture - ux - back - front, we may easily find that even the question requiring a solution has changed along the way. We just did not know it, because we were actually in a complex environment. That is why it is essential to identify the problem domain. The point is that recognising the different domains matters, so that we can use the right type of problem-solving approaches, the right type of leadership and the right type of organisation.
Agility is problem-solving in the complex domain
Agility is a measure of complex-domain problem-solving, that is, of empirical problem-solving capability. How smartly, effectively, consistently and systematically can we solve complex problems? Agility is the degree to which our ability to function is preserved when something goes wrong. For example, someone from our team may disappear into hospital, on parental leave, or get recruited by another firm. Does our project blow up because of that? Do we lose our ability to function because that was the only person who knew anything about that particular matter? If we are agile, or the more agile we are, the faster our ability to function recovers to a better level after the damage. Agility does not, of course, remove the damage, but recovering one's ability to function after a change is, in my view, quite a good description of what agility means. At the organisational and problem-solving level, agility brings the possibility of survival and success in a situation where the constraints are in constant flux and live, as it were, a life of their own. For example, we may have ten systems that talk to each other. All of them evolve along their own paths. Version updates come. Technology developments come. New frameworks come. Then someone decides this has to go mobile. Then new mobile versions come. One operating system collapses and another rises. These different things, which are supposed to work together, change independently regardless of us. Then the means of survival and success is being able to at least adapt. That is the first thing, surviving. Then perhaps we can adjust and tolerate change. But if we go further in complexity, so that we can exploit the change, that change itself may even become a success factor. When we are in the complex domain, even the framing of the problem itself is not set in stone; instead, we aim to increase our customer understanding, for example by analysing our data. When analysing customer behaviour on our website, we do not yet know, as we set out on the expedition, what we will find there. Agility is the systematic approach with which we go after that kind of animal that we do not really know yet, whose boundaries we do not know and whose behaviour we do not know. What is essential is that we do not go in flailing, but find a systematic way of working for an environment that does not itself follow predictable rules. The complex world is defined by everything changing constantly. If our way of working is such that it keeps our problem-solving power as high as possible even though the world changes, then we are agile. If, on the other hand, every change in the spec, in the customer's opinion, in the market situation or in the organisation is always seen as harmful and is resisted, then we are extremely non-agile.
The domains have no good / bad hierarchy = Sometimes agility is the wrong choice.
There is no better / worse hierarchy among problems and the different domains defined by Cynefin. If the problem is a problem of the ordered world, which can be defined and where certain unchanging basic rules apply, then the most effective way to operate there is to spec and execute. The rules of the ordered domain are not agile, and they are not supposed to be. In other words, "non-agile" can be perfectly sensible. It is foolish to run an empirical process with its experiments if our problem is a checklist. It is a strange idea that every single time a pilot is about to take off, they would try different take-off rituals to see which one might be best this time, and decide whether to check the instruments today or not. There it makes sense to go through a specific protocol exactly and according to clear instructions, which creates safety in that environment. The only exception to this is the domain of disorder, from which it is good to strive to escape by becoming aware of what kind of operating domain we are actually in.
Image source: https://twitter.com/pheiramo/status/1058252321530949634
Agile practices depend on the level of complexity
Cynefin divides complexity into nine sub-parts depending on what type of complexity is in question, and each has its own operating models. Some of them are very close to a chaotic operating model, and by recognising this we can beware of slipping over into chaos, for example. Some of them may be such that we are already so close to the ordered world that, perhaps by investing in some automation, in learning, or by adding a few constraints, we can conclude that that piece of our problem can be moved over to the complicated side. That part then changes from experimental product development into a configurable piece of our product that can be gone through as a checklist. Agility is therefore the capability to react in the right way to the right type of changing environment.
Image source: https://www.scrumalliance.org/learn-about-scrum
SCRUM as a framework sits at the plan-driven end of agile practices. It is, in a way, non-deterministic problem-solving. It aims to be able to break off pieces of at least some size from the whole, which are then always solved. Different experiments are made and we proceed, learn and reflect both on the outcome we are building and on the way of working. Iterative development work is directed at the object of the work. It assumes that we can choose a certain scope, for example for two weeks, during which we can give the team peace to solve a piece of the problem. If we are close to chaos, we cannot know what we will be doing even for two weeks. Then the work is more about putting out fires and reacting to various situations. We are ready for anything, we see what comes and handle it as quickly as possible. The hospital world is somewhat like that: you see what kind of patient happens to come through the emergency room doors next. The hospital has the capabilities to handle the situation, and efficiency comes from how quickly and reliably the patient can be taken through the system and back into the community as a productive individual.
Image source: https://www.reaktor.com/blog/the-kanban-method/
KANBAN as a methodology works more towards optimising flow, so that plan-driven structure is not needed. Then it is enough that an individual ticket is solved as quickly as possible. This is not binary but a spectrum. The closer we are to chaos, the more we move towards celebrating reaction speed. The closer we are to the complicated world, the more we can plan in advance, as in scrum. Somewhere in between sits what constitutes a sensible operating model within complexity.What agility is not
Agile does not mean:- Primarily just working with SCRUM, KANBAN, Lean startup or whatever setup.
- Merely the speed at which things get done, or how quickly we can organise ourselves, or that every day we sit in different places in different offices.
The capabilities of agility
It can be meaningful to divide agility into different parts, which help us perceive all the different areas from which the capability to respond smartly to solving a constantly changing problem is formed in practice:- Adaptability = We realise when it is worth reacting.
- Responsiveness = Reacting is not just about how quickly we can respond, but about responding at the right time.
- The ability to exploit different approaches = For example, the diversity of a multi-skilled team. There are different ideas there, and the more agile we are, the better we can exploit the whole team's pool of ideas instead of some project manager telling us how to do things.
- Resilience = Think of what a rubber band's job is: to stretch. If we stretch the rubber band further, it is still elastic. It does its same job even under strain. And it returns to its normal way of functioning regardless of the strain. Resilience in the context of a team means: if some change, tension or other matter comes our way, can we preserve our ability to function and to solve problems despite it?
What is your organisation's relationship to agility?
At one conference I had an AHA moment when one of the world's top coaches gave a talk on what our cognitive level is as an organisation in relation to agility. The book Reinventing Organizations describes different organisational levels, from a completely dictatorial organisation all the way to a TEAL organisation. We are somewhere on that scale, and our ability to relate to the problems we encounter is determined by how far along that scale we are. It is a kind of learning path, and it also applies to recognising problems. This sounds a bit like a cult, but the point is that the words used to talk about agility mean nothing to a person whose thinking is grounded in organisational models that work in the ordered world. Then not even a coach can say anything that would somehow spark insight in the person. Insight often only arises through one's own experience. Or on the other hand, though this no longer relates to cognitive level, if someone is completely in the chaotic domain, their thoughts are in total panic. Then it is pointless to talk about some fancy knowledge base or the finer points of teamwork or anything else, because the thoughts are where the person themselves is. If the mental model is in the ordered world, then the world is seen as a nail. Then different threads, screwdrivers and bits mean nothing to the person, when only the hammer and the nail are familiar. Another example from the complicated side: A pilot may be the best pilot in the world. Yet would that pilot be able to design a new aeroplane with certain types of flight characteristics? Of course their expertise would be helpful in some team that designs aeroplanes and new aircraft types. It does not, however, mean that the pilot would be at all good at solving the complex problem that is designing an aeroplane. Designing a family car model with an ecological shape that pleases people is a different thing from building it. Design is a complex problem. Assembling the car is a complicated problem. The point is to have more repertoire for taking part in solving different types of problems while truly understanding what is at stake.
"We should have specced it better"
We are only now waking up in a bigger way to this level-of-awareness business. Slowly we realise that we have problems that no longer get solved even with traditional agile methods. It feels like even the IT industry is still somehow mentally locked in that complicated world. If you ask why this project failed or why this IT system failed, the answer is always "we should have specced it better". That describes precisely having no clue that it was not even a definable problem in the first place. The reason for the failure was that a complex problem was treated as if it had been a definable, complicated problem. I stress once more that it is not the case that the complex world is good and the ordered world is bad: There are only different problems and worlds, for which different rules of play work. It is important that there are people who can efficiently do simple and complicated things. It is important that there are people who tolerate a chaotic environment and can function in the midst of chaos without losing their ability to act. There are problems that require understanding the problems of the complex world, and a large part of, for example, organisational development goes there.