‘Scrum Doesn’t Give You the Kitchen Sink’ is part of the Scrum Whys blog series.
Pop quiz. Which of the following is the most accurate description of Scrum?
- Scrum is a comprehensive approach for product development, and it has the best patterns for success.
- Scrum is a set of recommendations that should be used as needed and discarded when they don’t work.
- Scrum is a minimal set of components and rules that provide a basic structure to employ other practices, processes, and techniques.
Many who are responsible for implementing Scrum in organizations would pick option 1 or 2, and if they would not pick those options, their actions would align with those choices.
The problem with options 1 and 2 is that they both lead to Scrum implementations with lackluster results, often marginally better than what was being done before and maybe even a bit worse. But before I explain why that is, let me explain why option 3 is correct.
Scrum is a framework
“Scrum is a framework for developing, delivering, and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.”
– The Scrum Guide
The first three sentences of the Scrum Guide describe Scrum as a framework, but what is a framework? Before continuing, stop and think about what a framework is for a few seconds. When you see the word framework, what do you think of? What other frameworks are you familiar with?
A framework is a supporting structure that provides an adaptable container for other things. A framework provides the backbone of a system, but it does not define the entire system.
A framework is often compared to a methodology which is heavier than a framework. A methodology doesn’t just give you a supporting structure – it also gives you methods and practices to apply within that framework.
As a framework, Scrum has a minimal set of roles, events, artifacts, and some rules that hold everything together. But beyond those components and rules, there is a ton of space left to implement your own practices, processes, and techniques.
When Scrum is applied as a comprehensive approach…
…people are focused on learning and implementing best practices without really learning the whys behind those practices. There is usually a center of excellence for Agile or Scrum that is focused on finding the best practices and then enforcing those standards throughout the organization. There might even be an Agile or Scrum Playbook that contains standards for exactly how teams can and should operate.
There’s nothing wrong with centers of excellence, finding practices that work well and sharing them, or having a ‘playbook,’ but I’ve seen each of these things used as Tayloristic tools that limit the collaboration and creativity of teams and result in mediocre productivity gains. I explained why people often do this in a recent blog post.
One way I have seen this happen is when teams are required to write a user story for every work item. Usually the people requiring user stories don’t fully understand what they are, how to apply them, or how to measure their benefits. The teams, also not understanding how to apply user stories, comply by describing every work item with something like “as a user, I want a new button on the page so that I can click it.” Needless to say, the organization saw no return on investment for the time spent creating that user story.
I have seen a team spend over 30 minutes in a product backlog refinement session trying to create just one user story for a work item the team already understood. When I asked them why they were so insistent on creating a user story, they looked at me a bit incredulously, wondering how I, as a supposed Scrum expert, didn’t know that user stories were part of Scrum. When I told the team that Scrum doesn’t dictate how product backlog items are created, they looked at me skeptically. I then proceeded to explain what user stories really are (hint: they are more than just a way to format a work item) and what their benefits are. The team then told me that creating a user story for this work item would have no benefit to them, and I agreed. They quickly moved on to refining the next item on the product backlog.
When Scrum is applied as a set of recommendations…
..Scrum adopters are quick to take short-cuts that undermine the purpose of Scrum. Because they don’t understand the whys behind the pieces of Scrum they are shortcutting, they don’t realize that they are slowly chipping away at the core benefits of Scrum. What are those benefits? When applied well, Scrum enables agility, delivers value early, increases visibility, and reduces risk. Organizations that take shortcuts don’t gain all of those benefits.
A very important thing to note is that Scrum is essentially a collection of practices. Scrum is not a silver bullet, and there are many situations where Scrum can’t be applied effectively, like when there isn’t support for it from team members and key stakeholders, when a compatible culture doesn’t exist and there’s no willingness to change the existing culture, or when the organization isn’t willing to invest in the time and resources required for the collaborative nature of Scrum.
Although you probably shouldn’t use Scrum in those situations, you can still evaluate your context and determine what practices from Scrum could be applied. If your goal is to achieve the level of agility that Scrum provides, then take note of every reason you can’t apply Scrum as a framework – those things are impediments that your organization needs to resolve to get the full benefits of Scrum. Most organizations skip this step, and they end up implementing only a few easy practices and don’t see many (if any) benefits from them.
Why you should apply Scrum as a framework
Applying Scrum as a framework gives you the reliability of a basic structure while enabling responsiveness to change. Because Scrum is a minimal set of components and rules that create a basic structure, it provides a baseline level of consistency and reliability. Beyond the basic pieces of Scrum, there is a ton of room to employ other practices, process, and techniques. This gives you the agility to respond to market and technology changes as they arise rather than being tied into a specific approach. The great thing about Scrum is that it provides you with a continuous improvement structure that is used to frequently inspect your process, including all of those ‘other’ things you apply with Scrum.
When Scrum is applied as a framework:
- Team members feel enabled to continually make adjustments to the way they use Scrum to make it more effective.
- There is a strong focus on evaluating the fit and effectiveness of individual practices rather than applying them just because someone declared them as best practices. Not only does this ensure better fit-for-purpose practices, but it enables innovation at the team level, allowing teams to discover new ways of working and share those with other teams.
- Managers are focused on how to measure the results produced so there is empirical data to measure improvement and guide decisions.
- Scrum isn’t blindly applied because “it’s a best practice.” Its fit is evaluated for the problem being solved, and if Scrum is a fit, then it is given the resources necessary for it to succeed.
- When something isn’t working well with part of the Scrum framework, people question the why behind that part of Scrum and why it isn’t working in their context. They then make a future-forward decision in the context of their organization that doesn’t detract from Scrum’s purpose and benefits.
- Scrum Masters and managers are focused on creating an environment where people can easily and seamlessly collaborate, experiment, and work together to accomplish awesome results.
Don’t apply Scrum a certain way just because you’re told to. Apply it as a framework and continually improve your process to make your application of Scrum more effective. Question Scrum itself so you understand what each component and rule of Scrum accomplishes. You’ll be much better equipped to apply Scrum effectively in the real world.