My immediate reaction is to wonder why everyone is so quick to try adapting Scrum. Then again, I’m just as guilty. As a perpetual dieter, I started a new program a few weeks ago. “Wait! I can’t have any alcohol or sugar? None? Surely this doesn’t apply to weekends!”
Giving up alcohol and sugar is not a hard concept for me to understand, but it’s difficult for me to follow. Likewise, the Scrum Guide states that Scrum is lightweight, simple to understand, but difficult to master.
Below, I’ll answer my students’ question by first focusing on the core elements of Scrum that should not be changed. Then, I’ll focus on the elements that are flexible within the Scrum framework.
Scrum is a Framework Built to Adapt — Within Reason
It’s important to understand that Scrum is lightweight because it is a framework, not a methodology. Scrum offers guidelines to ensure optimal results whereas methodologies require stringent processes be followed with little deviation. A methodology is akin to a strict diet that dictates what you can eat, and how much, every day of the week. Scrum is akin to a diet that provides guidelines of no sugar and no alcohol, but allows for plenty of options for what to consume. If I compromise my new diet “framework,” will I still lose weight? Most likely. Will my weight loss be optimal? Of course not.
Using another analogy, if I compare the Scrum framework to a human body, deviations to the framework would be like breaking an arm or leg. The body is compromised. Does it still function? Sure. Is it optimal? Of course not.
For example, assume that an organization has removed the role of the Scrum Master altogether based on the belief that anyone on the Development Team should be able to fulfill that role. Can the team still function? Sure. Is it optimal? Of course not. The Scrum Master is a distinct, full-time role within Scrum. The Scrum Master is responsible for ensuring that the team and the organization can achieve the maximum benefit of using Scrum. Scrum Masters are “people people.” They help to develop individuals and the team. They help resolve conflicts. They facilitate meetings to achieve desired outcomes. They help remove impediments within and beyond the team to amplify systemic flow of value. A Development Team member will not effectively fulfill all of these duties because they will be focused on delivering working software every Sprint.
Let’s take another example. A team decides that Sprint Retrospectives are unnecessary. They are a waste of time and no one wants to share their feelings anyway. Can the team still function? Sure. Is it optimal? Of course not. If a team eliminates Sprint Retrospectives, it is likely because they don’t know how to effectively conduct one (probably because they have no Scrum Master!) This leaves that team with the experience that retrospectives are unimportant, but they are important. Retrospectives fully embody the pillars of Scrum – transparency, inspection and adaptation – which results in empiricism, the ability to make decisions based on what is known. Teams without retrospectives are denied this opportunity to reflect and continuously improve, and are not Agile teams.
Scrum Roles You Should Not Change
Rather than focus on trying to change Scrum, let’s focus on why the framework exists as it does and what flexibility it provides. The framework consists of three roles — the ScrumMaster, Product Owner, and Development Team. These roles are separate and distinct by design in order to maintain a balance between:
- Delivering value to address the needs of customers and stakeholders and the financial goals of the organization (Product Owner.)
- Optimizing processes supported by motivated and engaged people (Scrum Master.)
- Creating innovative, usable, and quality products (Development Team.)
Any blurring of these roles and/or any conflict of interest due to direct reporting relationships between these roles must be avoided to maintain the desired balance.
Scrum Artifacts You Should Not Change
The framework also consists of three artifacts — the Product Backlog, the Sprint Backlog, and the Product Increment. The Product Backlog is a list of what is known to be needed for the product. The Sprint Backlog represents how the Development Team plans to meet the Sprint Goal. The Product Increment is what the team delivers each Sprint including everything delivered to date. These artifacts promote transparency. Yet teams try to limit transparency by bringing in work from multiple sources, compromising the delivery plan, and comprising the quality of what is being delivered.
Scrum Events You Should Not Change
The framework consists of five events, each of which helps the team embrace empiricism through transparency, inspection and adaptation. The Sprint itself is an event lasting no more than one month to allow for all of the other events to happen in a routine cadence. Sprint Planning is an opportunity to inspect and adapt the Product Backlog and build a transparent plan for the work the team plans to complete. The Daily Scrum is an opportunity to inspect and adapt the team’s progress toward the Sprint Goal and be transparent about impediments and support needed from one another. The Sprint Review is an opportunity to inspect and adapt the product as it exists to date, and for the team to receive stakeholder feedback to shape future iterations of the product. The Sprint Retrospective is an opportunity to inspect and adapt team dynamics and how the team practices Scrum to continuously elevate performance. Skipping any one of these events comprises Scrum because it reduces the opportunity for transparency, inspection and/or adaptation.
Flexible Aspects of Scrum
Now that I’ve explained why the framework exists as it does, let’s explore the flexibility it provides. Note that Scrum does not focus on how to implement the framework. Implementing the framework in the most effective manner is left to the decision of the Scrum Team, and here is where the flexibility lies. For example, Scrum does not prescribe:
- Sprint length (as long as it’s one month or less)
- What days of the week the Sprint starts and ends (avoid Monday to Friday!)
- Who should be on the Scrum Team (as long as it’s cross-functional)
- What time to schedule the Daily Scrum
- When and how often to conduct backlog refinement
- Who attends backlog refinement
- How to conduct Sprint Planning, the Daily Scrum, Sprint Review and Sprint Retrospective
- How to document product backlog items
- How to estimate product backlog items
- What tools to use to document product backlog items
- What tools to use to collaborate with one another
- What development practices to employ
- What development platforms and tools to use
- When to release an increment to customers
As you can see, Scrum leaves a lot of room for teams to experiment, inspect and adapt. Scrum is also difficult to master because it’s tempting to skip the aspects of the framework that seem too hard, but there are certain core elements that should not be changed. Instead, focus on the elements that are flexible to implement the Scrum framework in the best way suited to your team.
Get Outside Help Adapting Scrum to Your Business
If you need guidance as you experiment with Scrum, we’d be happy to coach your teams — and show you alternative frameworks that work. Please drop us a note!