In this article, I want to invite you to review the context for which Scrum is most suitable.
To do this, you can use the Cynefin framework of updated terminology, initially published in 2003, to understand the different situations where you may find yourself in and what is, according to this approach, the most efficient way to respond to each of these situations when making decisions.
The Cynefin framework compares the characteristics of five different complexity domains: clear, complicated, complex, chaotic, and confused, in the center. Let's analyze each of them.
Clear Domain
Within the Clear domain, you encounter simple problems that are known in advance (or "known knowns").
It is straightforward to identify causes and their effects. Usually, the correct answer is clear, known to all, and indisputable. In this domain, there are clear rules and best practices and known solutions to known problems.
The most efficient processes in this domain are those that specify a logical series of steps and run repetitively, over and over again. Examples of this domain are serial production and installation, for many clients, of the same system.
People inside this Clear domain use checklists and how-to manuals to solve the same problems repeatedly.
While Scrum may work partially in this context, well-defined step processes are much more efficient, such as waterfall.
Complicated Domain
In this domain, you will find complex problems, good practices, and expert profiles. Here you face issues that you know in advance that you do not know. There are multiple correct solutions for the same problem, but it requires experts’ involvement to identify them. A typical example of this scenario is the solution of a performance problem in a software or database, the synchronization of traffic lights at a three-way avenue intersection, the search for efficiency in the logistics distribution of goods, the construction of a waste processing plant, etc.
Although Scrum could be used, it is not necessarily the most efficient way to solve these situations, where a group of experts in the field would work better to assess the situation, investigate different alternatives and propose the solution based on best practices.
Complex Domain
When faced with complex problems, results become more unpredictable. You are facing issues that you do not know that you do not know. There are neither best nor good practices cataloged for the situations you may encounter. You simply don't know in advance if a particular solution is going to work. You can only examine the results and adapt. This is the domain of emerging practices.
The solutions found are rarely replicable, with the same results, to other similar problems. To operate in complexity, you need to generate contexts where there is room for experimentation and where failure has a low impact. High levels of creativity, innovation, interaction, and communication are required.
This is a complex context in which it is preferable to use a working model that allows action, inspection, and constant adaptation of the result and the practices used. For example, many people use their car daily to get from their home to their workplace. The path is the same most of the time, but there are certain occasions when unexpected events arise that make the person look for an alternative route, such as excessive traffic, road works, malfunctioning traffic light, demonstrations, an accident, etc. The person’s new path is not necessarily planned in its entirety before leaving home, but the driver builds it as he/she drives. First, the driver turns to the right, then to the left, drives five blocks, then he/she turns again, and so on, the driver builds that emergent path, just-in-time.
This is where the development of new products or the incorporation of new features into existing products lives. You are building the product (the path) as you discover it.
Chaotic Domain
Chaotic problems require an immediate response. You are in crisis, and you need to act as soon as possible to restore some order. Imagine that the flight dispatch system at a high-traffic airport stops working. This would not be a scenario to use Scrum; here, you must act immediately, take control and move the situation out of chaos. For example, fix the problem immediately (regardless of the technical form), then, once out of chaos, evaluate and apply a more robust solution.
This is the domain for improvisation.
Disorder Domain
You move within a confused space when you don't know which domain you are in. It is classified as a dangerous area since you cannot measure situations or determine how to act.
In this domain, it is typical for people to interpret situations and act based on personal preferences. The great danger of the Confused Domain is affecting adversely to what it takes to solve specific problems.
For example, many people in software development are used to sequential, phased development, carefully planned using industry best practices, and this approach, which corresponds to the clear or complicated domain, is often applied within the Complex domain.
If you find yourself in a disordered or confused space, everything you do should be focused on getting out of that space towards a better-identified domain and then acting in the way that said domain requires.
When to Use Scrum?
As mentioned before, the application of Scrum makes sense when you are faced with complex situations: when there are no certainties, and you expect changes. Since it is a framework, it not only allows you to build the product but at the same time, it also allows you to discover what that product you need to build is.
In my experience, I have identified three key questions to decide whether to use or not use Scrum:
How much certainty do you have that the product you have in mind will solve the need you intend to solve?
How much certainty do you have that the chosen technology will solve the need you intend to solve?
What is the nature of teamwork: primarily mechanical work or primarily cognitive work?
Product or Technological Uncertainty
Without the certainty that the product that you are going to build or the technology that you are going to use will solve the need, even if you know in great detail the scope of the product, in reality, I would dare to say that you do not know what to build or how to use technology to solve that need. In this context is where it makes sense to use Scrum.
On the other hand, if you are sure that the product to be built and the technology to be used will solve the problem, it does not make much sense to use Scrum.
Nature of Work
Regarding people and the nature of their work, if it is primarily mechanical or physical, then using Scrum does not make as much sense, but if it is cognitive or creative, then there is a high probability that Scrum is an appropriate approach. Having gone through the theory behind Scrum, I propose that we move entirely to its definition and structure.
References
- SNOWDEN, D., KURTZ, C., 2003, The new dynamics of strategy: Sense-making in a complex and complicated world, IBM Systems Journal, n42, 452-483 ↩
