Alt Text
menu

Scrum: When to Appeal to Authority

In general, I find Appeal to Authority to be a fallacy and I think it should be avoided. But as I was reading a colleague's blog post titled Not Scrum, I started to wonder:
  • Why do I encourage teams to not deviate from scrum?
  • Why do I encourage them to say that not being Scrum is a reason to not do something?
  • Why would I advocate for an appeal to the Scrum guide?
  • And is there some point where I think the appeal to Scrum is a fallacy?

Look a little deeper at our example

Let take a second and look at what Scrum is.

format_quote
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
format_quote
The large value that I find from Scrum is the fact that it is the output of centuries of team hours distilled down to a shared framework. They also update it periodically as more projects happen. In a nutshell, they are a good example of an authority, based on heuristics of what has worked.


What Scrum Thinks vs What I Think

We can generalize scrum by saying it is the experience of other teams, and we can compare that to the experience of our team.

At the beginning of our project, our experience is very limited, and as such it offers very little value to us.

As the project evolves we start to learn more about our team this has two effects:
  • it lowers the value of what we can get from the well-conceived generic team experience, (generic experience value is proportional to the amount of uncertainty we have about our team) and
  • it increases the value of our team's experience as the uncertainty of the context of your team decreases.
Alt Text
When I see this graph it makes me think of the concept of Shuhari.
format_quote
Shuhari roughly translates to "to keep, to fall, to break away".
- shu (守) "protect", "obey"—traditional wisdom—learning fundamentals, techniques, heuristics, proverbs
- ha (破) "detach", "digress"—breaking with tradition—detachment from the illusions of self
- ri (離) "leave", "separate"—transcendence—there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms; transcending the physical
format_quote
Wikipedia
During the first part (Shu) of the curve, our team has not generated enough experience so we should do what others before you did (Do Scrum). And we should allow the argument that is not scrum to carry the day.

During the middle part (Ha), we should start to challenge what others do (Scrum) but the burden of proof is us to why we are special.

During the last part (Ri) we must stand on our own. Scrum is no longer an acceptable appeal we must defend the reasoning behind why we should stay with Scrum just as much as why we might leave it.
Alt Text

Wrapping It Up

In the end, it comes down to uncertainty When we do not know about our project and team and the context we find ourselves in, there is a higher chance that a well-conceived generic solution will be better than any specific solution we could dream up.

But as we learn more about our project, our team, and the context in which we are working, the more likely it is that we can do better than the generic solution.

©Erik Summerfield 2022

e2thex.org Last Updated: 3/22/2022