A kick in the ScrumBut
How to counter defects in how Scrum is applied at your organisation.
So, your organisation is adopting Scrum. Awesome. You’re on a journey that involves battling organisational defects, breaking through status quo’s and opening up rigid mindsets. Toxic power plays are exposed like never before.
Is your organisation adopting or exercising Scrum?
Adopting Scrum can be frustrating, infuriating and exhausting. It is completely natural that, when we first encounter all the nasty stuff that comes along with organisational change, we tend to challenge that which is driving that change, rather then admit we simply aren’t that good at changing. But one can hardly blame Scrum, as much as anyone can blame the game of Chess for the frustrations that come along to learning how to play it right. And let’s face it, Scrum is hardly ever exercised correctly.
ScrumButs!
In an earlier post on ScrumButs and Invisible ScrumCows I collected and shared some defects in how Scrum may be applied, which was received with a storm or recognition by fellow Scrum practitioners, who are bravely engaging the daily struggles to better their environment.
So to you, out there in the trenches, I hope to share a fresh supply of ammunition. I hope you do your part too, and help us fellow trenchmen out, by passing helpful, practical advice onto others.
So, how to counter ScrumButs?!
This is the first part in a series that will provide helpful counters to ScrumButs. Every episode I will cover one topic area.
This first episode covers dealing with those who ‘challenge Scrum’ and whose who do not yet understand the value of Scrum in its entirety.
We do Scrum but… it’s our own version of it that we never seem to be able to agree on.
Have you ever tried playing a board-game in which everyone allows their own rules and interpretations to be applied during its play?
Conflict… chaos.
Scrum isn’t a process that can be modified to fit the enterprise. Allowing Scrum itself to be modified, because it doesn’t fit a practise or process applied by the enterprise, allows the actual dysfunctions of those practices to be obscured and will introduce more.
We do Scrum but… don’t understand the difference between Framework, Methodology and Process.
Scrum is a framework that can hold a canvas on which various processes, methodologies and techniques can creatively be applied, inspected and adapted.
Understanding and applying the framework properly is a route to freedom and a way to prevent miscommunication and the resulting conflicts. Use the freedom within the canvas; do not meddle with changing the supporting structure that is carefully designed to hold it all together and provide stability.
The supporting framework is the key requirement to be in place for self-organisation to thrive.
“If a team is to self-organize and deliver value successfully, then discipline will be key.”
The framework and supporting Scrum Guide are there to make sure that the best practices can be universally understood and applied.
The Dogma Defense
If you, or your counterparts in the organisation are struggling with this rigid, dogmatic view on how the framework is to be applied, I would kindly refer you to the Dogma Defence.
We do Scrum but… do we really?!
Scrum Defects and Violations
When encountering defects and violations, put transparency in place over them. Map them out. Call it a Damage Report or include them in an Enterprise Transition Backlog if you will. Just make it clear to everyone where Scrum isn’t applied properly and how the benefits of Scrum will be lost.
Point out how these defects impact Scrum’s Values and Product Value Delivery. Identify anti-patterns and counter them through demonstrations of better practices. Explain how those defects, or apathy towards them, impede the teams capability to solve complex problems, and how they are allowing waste in the product and process. But most of all, guide the organisation in taking small and simple steps towards a better way.
Taking the time to get it right
When the individuals in the organisation are reacting and adapting to Scrum, it must be understood that it will take time to get it right. There won’t be instant gratification; which makes changing habits very hard. Instead they will be confronted with hardships. Their inability to getting the expected results from freshly attempting new practises are made uncomfortable transparent. This sucks; awwwrrrr! but the team should understand they just haven’t mastered it yet, and should keep trying to become better at it. Don’t quit because you aren’t getting Olympic results on your first run. Scrum on.
