Scrum org defines “ScrumBut” as “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”
Scrum assumes that people doing Scrum stay within the confines of Scrum’s immutable artifacts, roles, events, and rules. However, when problems arise there are times that they can be solved with methods outside of Scrum. Sometimes, the cost of accommodating them is lower than the cost of fixing them. If you want to be doing Scrum you can’t do the first and Scrum gives no guidance on the second.
Scrum is defined with little leeway in this regard. This infers that:
1) Scrum can always result in an optimal solution
2) If you don’t follow Scrum you are doing something wrong and not sufficiently motivated to solve the problem.
While neither of these inferences is correct they allow Scrum proponents to shift failures in adopting Scrum to the adopters. This, ironically, counteracts one of Scrum’s great values – setting responsibilities correctly. And I hate this.
I have written several blogs no ScrumBut and have collected them here.