Scrum’s internal conflict of being a process or a framework
Scrum has single-handedly changed how software development is done in pretty much every large company. It is so popular that it is now used in some form or the other in almost 70% of the companies (~56% reporting pure Scrum, while ~14% some variation like ScrumBan etc.). Its wide adoption can be attributed to its ability of not only injecting agility & speed into the development process, but also by providing a way to report progress back to management.
Each startup starts as a nimble team and flourishes with development heavy processes like XP (Extreme Programming), lean, Kanban etc., but they are very difficult to scale up as the company grows and the number of new features needed become more complicated as well as dependent on coordination amongst various teams. This is where Scrum really shines as the feedback back loop provide a way to streamline the process in real time, generally sprint after sprint. So, it would also not be wrong to say that Scrum has been instrumental in enabling faster development and frequent deployments i.e. faster delivery of new features to customers, esp. by large corporations.
For the longest time, Scrum has provided a framework as well as process on how things need to be done. The framework part of Scrum allows teams to tweak the processes that would best work for them. At the same time, the processes given by Scrum helps by providing teams with a solid foundation to start with, till the teams get into a habit to identify issues and adapt to improve.
Over the years, Scrum has trimmed down the “process” and wants to become only a framework. This is clear because the current Scrum guide is merely 18 pages and the next revision of Scrum guide is widely touted to be even shorter. The question is, why? And, what would be the cost of doing that?
Why make Scrum only a Framework?
The rationale behind why Scrum wants to become only a framework is relatively easy to follow if you have ever been part of a Scrum team or have been a Scrum Master. Even though Scrum today allows for tweaks, the problem is that most Scrum Masters are apprehensive of making changes, as the main argument is some variation of “This is against what Scrum stands for” or “This is not the Scrum process”. So, the easiest solution would be to rid the framework of any rigid processes as this would enable teams to make changes that would work best for them.
But, most experienced Scrum Masters have learned that Scrum is not about rigidity, but about allowing a team develop a process that helps the team to get things “done” with least resistance, even if it is not defined in the original Scrum process. This is exemplified by teams creating hybrid process like ScrumXP, ScrumBan or others. Scrum org’s move to become only a Framework would enable all these forks to again come back under Scrum’s umbrella.
What’s the cost of removing all recommended processes?
Anytime a process is given, even though it might just be an example or a recommendation, it runs the risk of becoming a rigid step which most teams or Scrum Masters would be vary of changing, sometimes just because it is the “official” way of doing things, and at other times, cause it is more work to find a new process, so sticking to a rigid or “inefficient” process is the easier thing to do. So even though Scrum provides a feedback loop and the flexibility to tweak processes that would work best for a team, they can be sometimes get ignored, if the team or the Scrum Master get hung up on the process rather than the fundamentals.
But removing all recommended processes, suggestions and examples from the Scrum guide would mean that new Scrum Masters would have very few “recommendations” to follow. Many will argue that there is a huge community to help a Scrum Master hone his skills, but then, the ones who pay the price of having an ineffective Scrum Master is the development team. Today, the “recommendation” in the Scrum guide are a team’s only help to guide to suggest Scrum Master to give ownership back to the team & to let them find the optimal way to get things “done”. So is removing all that from the Scrum guide really worth it?
The case to have an expanded Scrum guide
In most large companies adopting Scrum, the traditional role played by a Development Manager has now become obsolete. But instead of hiring experienced Scrum Masters, these companies are training the existing Managers to become Scrum Masters. I do understand that Scrum has addressed the problem of too much interference by Scrum Masters by advocating experienced Scrum Masters to coach new Scrum Masters. But, guess what, it is very hard to train old dogs new tricks, and the scrum team is the one who is left licking their wounds.
So now, people don’t leave a company not because of their Managers, but because of their Scrum Masters. Scrum org, if you reduce the guide and remove the processes, that will leave the interpretation in the hands of management. So, how is the Scrum team to get the management to see the problems if there are no recommended processes specified and no examples/scenarios given in the guide.
If Scrum Org’s idea is the enable Product Owners, Scrum Masters and the Scrum team to be able to find the tools to find the optimal way for agile development, then shouldn’t the guide provide more information, more tools, more ideas, hybridized models and more example on ways the framework is used across the world, instead of condensing the information and leaving the Scrum Masters and the Scrum teams to do the research on their own.
