Today I was finally able to connect some dots on something that had been bothering me for a while. As a Scrum.org Scrum trainer, I always tried to convey that assigning value to information has a big risk of obscuring the transparency needed for inspect & adapt.
The reasoning here is that if you are passing judgement based on information, for example the information about the outcome of the sprint, people will feel the need for a positive verdict. They will thus be inclined to game the system, in order to achieve that positive verdict.
What was bothering me about this was that when I shared this, I was unable to give a satisfactory answer to the question that some people then asked: “If we should not assign value to the outcome of a sprint, how do we celebrate success if we delivered a lot of business value in a sprint?”. A valid question that remained largely unanswered by me up until now.
Today I was lucky enough to be able to brainstorm about my issue with a bunch of colleague Scrum trainers in an open space session in which I invited them to explore this with me. Talking about it with them, the fog cleared in my head and I was able to come to an interesting insight.
It is okay to assign value to information, as long as you have all the information necessary to be able to assign value.
Which is very often not the case! First and foremost, Scrum operates in complex environments, in which you usually don’t have all the information required.
The thing you are trying to avoid is the team feeling bad if they did not deliver all of the forecasted functionality for the sprint, if they are not responsible for it. Another thing you are trying to avoid is management seeing the team or members of the team as performing badly, if this is not the case.
And it is rarely the team that is responsible for unfavourable outcomes in my experience. As Deming stated a long time ago, 95% of problems are caused by the system, and 5% by the people.
If everyone is aware of this, and we take the bigger context and the complexity we are dealing with into account, then we can actually assign value to the sprint outcome, and celebrate!
Let’s start celebrating failed experiments and the learning that takes place when that happens as well, shall we? Or is that too ambitious for the time being 😉
Thanks to my fellow scrum trainers for helping me out with this.
I’d be very interested to know what you think about the topic, please post in the comments if you want to.