The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.
Today we are going to talk about the one of these terms in the Scrum Glossary: Empiricism. The glossary has the following description:
Empiricism: process control type in which only the past is accepted as certain and in which decisions are based on observation, experience and experimentation. Empiricism has three pillars: transparency, inspection and adaptation.
We talked about Emergence in my previous article as being the Why, as in Why we do Scrum. If Emergence is the Why, Empiricism is the How in How we do Scrum. The Scrum framework provides us with an empirical approach to product development to cope with the continuous emergence happening as part of this particular type of work. How does this look like? Let’s break down the description again to do an analysis on what the Scrum Glossary says about Empiricism.
process control type in which only the past is accepted as certain
Process control is a commonly a manufacturing approach to use feedback loops on variables to monitor and maintain quality, safety, production rates, or otherwise important variables. In the case of product development with Scrum notable variables will be on the performance of the product. Examples would be business value, return on investment, market share, turnover and customer satisfaction. An empirical approach to product development would mean we implement feedback loops on these important variables for our product development process. Because of continuous emergence of new insights about facts, gut feeling predictions about the future become very unreliable and we want to look at more reliable data to base decisions on. For this reason an empirical approach means we use past data to feed our decision making process.
A very common experience with wrongfully interpreted Scrum is that we do not apply empiricism at all. The events are run, the artifacts are created and the roles are assigned and the team is running Sprints. However, the reasoning behind all these elements of Scrum is to approach our product development in an empirical way. This means the feedback loop needs to take place on this important variables. If for example Business Value is not explicitly measured in every Sprint by creating a done Increment for our stakeholders to increase Business Value for them, we are not actually working in an empirical way. The importance of Done work when using Scrum comes into light here.
and in which decisions are based on observation, experience and experimentation.
The reliable data on what happened in the past is described in more detail in this part of the description. We might have observed market changes happening, our current Increment being used differently than we initially expected, we have validated or invalidated a previous assumption by performing an experiment, etc. Notice how all these bits of knowledge are gained through looking at the past. This is exactly what we’ve claimed in the previous part of the description. This part describes that we should be looking at outcomes from observing, experiencing and experimenting and using those outcomes to enable better decision making. Those outcomes should be in the form of an effect on one of the important variables we mentioned before that are part of process control. When looking at the example of Business Value this could mean that we are checking the impact on Business Value for our stakeholders every time we perform a feedback loop within our process control approach. This can be quite easily translated to Scrum: Every Sprint we hold a Sprint Review to check if what we created is of value to our customers to use this feedback to make decisions on what to create in the future.
Empiricism has three pillars: transparency, inspection and adaptation.
Something I have not yet mentioned as such are the three pillars of Empiricism. The way Scrum is set up is through implementing these pillars through the roles, events and artifacts. The artifacts in Scrum are the way the pillar of transparency is implemented. We use that transparency to enable measurement of the variables that are important to be able to track and steer on in our process control approach. So an Increment could give a good idea of Business Value created every Sprint for example. The events are formal inspection and adaption moments in Scrum where the roles are the inspectors using the transparency we get from the Artifacts and perform measurements to determine how the current state differs from the desired state of the variable. Based on this we can make decisions about what to do in the future.
The importance of the first pillar, transparency, is often misunderstood by organisations and Scrum Teams. If the teams are not able to create something in a state where true measurement on the variables we have in our process control framework can be done, worst case scenario: it’s useless to do Scrum. What I mean by this is: If the state of our Increment is not potentially releasable, stakeholders might give feedback on things that might not even be part of the finished product. Worst case, we start making decisions based on feedback that’ll be steering the team in the entirely wrong direction. A team being less capable of delivering a done Increments correlates with higher risk of wrong business decisions. Because of this, this should be a very high, if not highest, priority impediment to fix in your organisations.
Empiricism is often described as part of the heart of Scrum and I agree with this statement. Without using it as an empirical approach to product development, Scrum is no more than a husk of a framework, with mechanical meetings and roles that don’t provide you with an actual benefit for doing it. I recommend you to explore where the need for empiricism and a process control approach lies within your organisation to identify the real needs for a framework like Scrum so you are able to really convince people with the Why instead of just the How.
Did this article help you understand Empiricism a little better? Or did it just raise more questions? I’m happy to help, discuss and advice so feel free to contact me. Next time we’ll be discussing Engineering Standards.