When I was first introduced to the word empiricism, I did not know what it meant, so I looked it up. When I ask this question in my Scrum training class, not a lot of people know what this means, so I spend some time while I teach the fundamentals of this topic because this is the essence and foundation of Scrum. According to the Scrum guide, “Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.” What does this mean? Well, I want to focus on this topic in this blog post and talk about why we do things in Scrum the way we do.
What is a process?
The American Heritage Dictionary’s definition of process is “A series of actions, changes, or functions bringing about a result”. I look at it as some input goes through the process and creates an output. There could be several internal processes where an output can serve as an input to another internal process.
A lot of people misunderstand that Scrum is a process. I want to make it clear that Scrum is based on empirical process control. The Scrum guide clearly states that “Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques”.
Empirical process control
Empirical process control or empiricism asserts that knowledge comes from experience, observation and experimentation. Based on this information or data, we can make decisions based on what is known at that point of time. We need to inspect the data at a given point of time and make decisions for further investigation until we see the desired output. Empirical process control works well when the underlying process is inherently complex and/or the process is not well understood or imperfectly defined. The results are not repeatable and are unpredictable. Empirical process control provides exercise and control through frequent inspection and adaptation. The principles of empirical process control are empowerment, self-organization and collaboration.
In order to understand why empirical process control is used for solving certain problems, we need to understand the defined process and when it is appropriate to use this process.
Defined Process control
It is a series of steps to build a product or derive a solution. It is just like following a recipe. The defined process control is used where the underlying process control is reasonably well understood unlike the empirical process control which is used to solve complex problems. The results in this case are repeatable and more importantly predictable. Hence, I consider this as a process of well-defined steps. Corrections are not possible in real-time. This uses a command and control approach in contrast with the empirical process control where collaboration, empowerment and self-organization are key!
Three Pillars of Empiricism
Transparency – Process outcomes must be visible to everyone responsible
Inspection – Frequently inspect for any unacceptable deviations
Adaptation – Adjustment must be made to minimize further deviation
Scrum is founded on empirical process control
Scrum leverages or adopts an empirical approach and accepts that problem cannot be fully understood or defined. It focuses on maximizing the team’s ability to quickly deliver value and responding to emerging requirements. Scrum is best suited for solving complex problems. It is good for high change and unstable environments.
Since we adapt based on knowledge we gain from inspection, solutions evolve as requirements are understood. An empirical process is interpreted as a black box and the composition of the inputs and the characteristics of it’s outputs are evaluated. This can be interpreted in Scrum wherein a sprint is a black box and we evaluate it’s inputs and outputs.
The Scrum guide mentions an example for transparency (one of the pillars of empiricism we discussed):
- A common language referring to the process must be shared by all participants.
- Those performing the work and those accepting the work product must share a common definition of “Done”.
The inputs to the sprint are the product backlog and the Team’s definition of “Done” and the output is a completed sprint backlog items. Sprint is time-boxed (length of the sprint) and the pre-defined checkpoints are the sprint meetings like sprint planning, daily scrum, sprint review and sprint retrospective that happen at a specific time every sprint. The most significant aspect is with each day and each meeting, we inspect and adapt. No new items are added to the sprint since we want the sprint to be protected meaning that the data that we used as input should not be changed.
Scrum – Black box becomes clear as we inspect & adapt at pre-defined checkpoints
Scrum is founded on empiricism or empirical process control. Product development, whether it’s software or any product that has not been created before, is very complex since the problem cannot be fully understood. So, we observe, experience and experiment with the data that we gather during a sprint and make decisions based on those data points. The Sprint is like a black box where we cannot see the underlying processes but with inspection at frequent check points and adaptation, the solution evolves. The black box or the sprint gets clearer throughout the sprint. Scrum, as a framework has become one of the best solutions for solving complex problems.