Adoption and Where to Use Scrum
Scrum was designed for a cross-functional team to building new product incrementally. Using it everywhere follows the mantra “when all you have is a hammer, everything looks like a nail.”
Scrum ignores the potential adverse consequences (e.g., resistance) that forced adoption of a new, predetermined way of working will entail.
Scrum provides no guidance on where it should be used other than to solve complex problems and that people should want to improve things. Of course, nothing works when no one wants to improve things. The statement basically says if a team wants to improve then Scrum will work, implying that when it doesn’t work people weren’t committed enough..
“Scrum would work if people would use it” is circular reasoning. When it’s not enough people will have a tougher time using it and they will fail in their endeavors. But it may have more to do with the lack of fit for purpose than their commitment.
Lack of Guidance and Theory
Scrum intentionally provides no guidance or theory as to why it works. The idea is that it makes it simpler, you can't provide all the choices needed anyway and people will figure things out. Evidence, unfortunately, has shown that people don't figure things out and Disciplined Agile has demonstrated there are ways to provide choices without being complicated.
When Scrum is used outside of where its practices were designed for (cross-functional teams and incremental implantation is straightforward) it provides no guidance on how to achieve these.
Provides no guidance on where it should be used and ignores the issue of fit for purpose
Scrum provides no guidance on skills needed. The preposition that people will figure out what’s missing in scrum is invalided by reality.
The statement that Scrum is intentionally simple and incomplete should not imply that this conscious decision was a good one.
The implication by Scrum practitioners that incomplete makes it easier to understand ignores the possibility that there are ways to design approaches that are easy to understand yet provides information as needed. Simple to use does not imply incompleteness. In fact, the opposite is often true.
While it’s true that nothing is complete, that does not argue for extreme incompleteness.
Difficulty of Scrum Due to Lack of Guidance and Theory
Scrum is both easy to understand and easy to master. It’s using Scrum to master Agile that’s difficult.
The belief that Scrum is easy to understand but difficult to master comes from conflating Scrum with Agile. They are two different things. One is a way of being and doing (Agile) and the other is a framework for developing, delivering, and sustaining complex products.
When the immutable aspects of Scrum are not present, Scrum provides no guidance on how to create them.
The lack of choices in Scrum requires you to re-invent the wheel in many places.
The lack of theory often leads to Scrum But (stopping a Scrum practice in a way that keeps the impediment in place) because there is no way to determine is another known practice is appropriate..
Scrum provides no guidance in how to work in situations where cross-functionality or iterative development are difficult to achieve. Nor does it provide any guidance on how to achieve these.
Because Scrum provides no theory as to why it works (e.g., Flow, Lean, ToC) practitioners doing Scrum must keep trying to do it – whether it is the correct course of action.
Scrum requires its roles, events, artifacts and rules to be immutable because there is no theory presented to explain how to change them. The mindset underneath this is just do Scrum as it is and things will work. But this conflates Scrum with the result (Agile) you want to achieve.
How Scrum Can Become a Framework Prison
Ivar Jacobson wrote an article called Escaping Method Prison where he talks about the methods we use become our prisons. I would suggest that when our method is built around a framework, a prison with a moat around it is created. I call this a "framework prison." A similar article Framework Tunnel Vision predates this. I described how frameworks and methods tend to have people overly focus on certain practices. The way to escape this overly narrow focus is to enable one's approach to expand to include any useful concept. While many people claim that this will make things cumbersome or overly complex, I assert that that's only if you don't know how to design the approach properly. More information is not necessarily more complexity. Wikipedia is an example of this.
While "Method Prison" is to be avoided, "Framework Prison" is a bit harder. The reason is that frameworks are built on top of key values, concepts, practices, roles, etc. These cannot be removed and still have the framework be intact. While you may add things to the framework you can't usually take things out without breaking it. Scrum explicitly states that its roles, events, artifacts and rules are immutable. SAFe may not say that but few options exist to change its fundamental concepts without breaking it.
Because Scrum is based on values and practices and provides no theory as to why it works, those certified in Scrum Guide based Scrum feel compelled to follow these values and practices. However, changing people’s values is difficult. If the practices are not applicable or not "fit for purpose" there will also be problems. When someone leading a Scrum adoption knows only Scrum two problems occur. First, they may not see more useful alternatives. The second is more insidious however. If they were brought in to "adopt Scrum" they may feel some fear in trying to do something else - both outside of their range of certification and not what they were brought in for.
Changing Scrum is risky because there is no theory to tell you if the change you make is a good one. It is psychologically hard to make the change as well if you are only trained in Scrum since you have to go outside of the definition of what Scrum is.
The fact that it is risky to customize Scrum speaks to its poor design/mindset. When one is trained only in Scrum it is often difficult to see better ways to achieve the goals that people adopted Scrum for.