Will Scrum work for our project?
As an Agile Coach and Consultant, engaged to help organizations adopt Agile practices, the single most common question I get asked is “Will Scrum work for our projects?”.
Introduction
There is a common misconception that Scrum works well only for well-defined Web / Mobile / Digital type software projects requiring small teams. Nothing could be further from the truth. Scrum can be applied to many different types of projects including non-software projects. What determines whether Scrum works well for a type of project is not technology, application, custom development, COTS (Commercial off the shelf) etc. type of software projects but other characteristics such as simplicity, complexity, complication, chaos and disorder that impact requirements, development and validation processes.
Scrum is well suited in project situations where business needs working, integrated and tested software that offers value and is delivered fast. Scrum is well suited in a complex world where businesses must quickly adapt to succeed. While Scrum is an excellent choice for many situations, it may not be the best in all circumstances. This article uses the Cynefin framework to explore situations that are best suited for the choice of Scrum.
Cynefin Framework
Cynefin, pronounced ku-nev-in, is a Welsh word that means there are multiple factors in our environment that impact us in ways we can never understand. The Cynefin framework was formulated by Snowdon and Boone in 2007 as a sense-making approach to understand the situations in which people operate and decide on a situation-appropriate approach. The Cynefin “sense-making” framework defines the characteristics of five different domains: simple, complicated, chaotic, complex and disorder. These situations or domains can be related to software development perspectives which then allows us to ascertain suitability of Scrum to specific situations.
The figure below graphically illustrates the Cynefin framework.
The Cynefin Framework
Complex Domain Problems and Projects
Scrum is very well suited for operating in this domainComplex projects have a high degree of unpredictability and a right answer or solution to the problem is usually not known beforehand. This is a domain in which solutions typically emerge with time and trial through exploration. Thus, the sequence of actions to solve problems in this domain tends to be Probe > Sense > Respond. Working in complex domains requires creative and innovative approaches in a safe-fail environment for experimentation. Most product development projects fall into this domain. .
Complicated Domain Problems and Projects
Complicated problems are the domain of good practices dominated by experts in specific fields. While there may be multiple right answers to problems of this domain, expert diagnosis is often required to figure out the solution. While Scrum can work with these type of problems, it may not be the ideal approach. Examples include day-to-day application maintenance and support, Customer service and help desk, etc. falls into this category. Tactical and quantitative approaches like Six Sigma and even Kanban are particularly well suited for the complicated domain.
Many aspects of Software development do not fit cleanly into one of the Cynefin domains of Simple, Chaotic, Complicated, Complex or Disorderliness. Aspects and activities may overlap into different domains.
Simple Domain Problems and Projects
With Simple problems, the cause of effect is obvious and clear to everyone unlike other domain problems. Often the right answer is obvious and undisputed and this is the domain of proven best practices. While Scrum can be used for this domain, it is not often the best approach. Using a process with well-defined, repeatable set of steps that are known to solve the problem is likely to be a better fit. For example, if the same product needs to be reproduced over and over without any variation, an assembly-line process will be a much better fit than Scrum. A good example might be deploying a COTS product such as Microsoft Office into the 100th Customer environment might best be done by following a plan with well-defined steps for installing and configuring the product. Plan driven and Waterfall approaches are best suited for projects in the Simple domain.
Chaotic Domain Problems and Projects
Chaotic problems often require a rapid response usually because it is a crisis and action is needed immediately to prevent further damage and restore some order. For example, let us imagine a problem with a Warehouse automation software that is picking the wrong items due to an issue with the algorithm. Another issue that we often hear about disrupting the Airline Industry is the malfunctioning of Software that handles baggage or even reservations. Problems of this nature have an immediate and harmful impact in the environment they work in. We need the ability to act immediately and decisively to stop the damage and someone needs to take charge immediately and run things. Scrum is not even a choice here as there is no opportunity to prioritise a backlog of work and solve the problem through time-boxed iterations.
Disorder Domain Problems and Projects
Problems fall into the Disorder domain when we don’t know or can’t fit them into any of the other domains of Complex, Complicated, Simple or Chaotic. This is a dangerous place to be in because nobody seems to be able to make sense of the situation. In such situations, people tend to interpret and act according to their personal preference and course of action. The best way to tackle problems in this domain is to breakdown the situation into constituent parts and assign each to one of the four other domains and choose the best approach suited for that smaller domain problem. It is best not to apply Scrum here but it is best to get out of this disorderly domain.
Checklist for ascertaining whether a given situation is “Complex”
The following characteristics provide an opportunity to determine whether the given situation, problem, opportunity or project falls into the “Complex” domain of the Cynefin framework, thereby making it suitable for Scrum.
Is there an opportunity to explore to learn about the problem, then inspect and then adapt? YES / NO?
Does the solution require an innovative / creative approach? YES / NO?
Can we create a safe-fail environment for experimentation to discover patterns? YES / NO?
Can we increase the levels of interaction / communication? YES / NO?
Is this opportunity for a solution to emerge? YES / NO?
Is knowing in hindsight acceptable? YES / NO?
Is the situation more unpredictable than predictable? YES / NO?
Summary
The suitability of Scrum to projects of certain types of technology is not a relevant nor informed discussion. Scrum is well suited for projects that are “complex” in nature and can be tackled through a Probe, Sense and Respond sequence of steps. These type of “complex” projects are characterised by unpredictability, ambiguity, requirement of innovative / creative solutions with lots of interactions and communication. The Cynefin framework is a good sense-making tool to understand the five different types of domains (Complex, Complicated, Simple, Chaotic and Disorder) under which typical situations / projects can be grouped.
