This is the fifth of six articles on approaches that try to help to scale Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The following articles are about Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS) and Scaled Agile Framework (SAFe). This article will present the Scrum at Scale framework.
The creator of Scrum at Scale is Jeff Sutherland, the co-creator of Scrum. Jeff’s reasoning is that part of the key to Scrum’s success is that it allows for context-driven solutions and processes – which is why no two Scrum implementations are identical. So why does the conversation about scaling Scrum focus on finding a prescriptive, one-size fit all solution? The conversation should instead be about how to scale the underlying principles of the Scrum framework that have enabled it to be so adaptable.
The Scrum at Scale framework is his first move in that direction. It is a minimal extension of the core Scrum framework that keeps the modular structure at the core of the Scrum framework and allows you to scale a Scrum implementation tailored to the unique needs of your company.
There are four major reasons why Jeff thinks modularity is important:
1. Modularity allows versatility. Scrum has been successful in a wide variety of product and project contexts. It’s been used for everything from traditional software development to designing a new granola bar or designing complex integrated defense systems. No single prescriptive approach could work in all of those different contexts. You need something that is modular to adapt to the specific strategic context of your company.
2. Scrum is modular. At its roots, Scrum is inherently modular. For example the Retrospective ceremony within Scrum doesn’t tell you exactly how you have to implement the retro, it just says that at the end of it, you need to have a plan for improving the team process, puts some bounds around how long that meeting should take, and gives guidance on who should attend that meeting. It leaves the actual practices for how to do that to the team that is actually conducting the retrospective. And as a result, we’ve seen a proliferation of different practices that are successful in lots of different contexts.
3. Deploying incrementally is easier. If you have a modular context and you define all of the interconnections between modules ahead of time (namely what the goal of the module is, what the input to the module is, and what the output of the module is) then it doesn’t matter what happens inside that black box as long as it meets those constraints it still satisfies the goal of the module. That means you don’t need to have an entire solution delivered in one “big bang” at the very beginning of your scaling. It frees you to iteratively use Scrum to incrementally develop the modules that are most important to you and after several iterations have a fully-fledged scaled Scrum.
4. Modularity supports a pattern library. A library of what people have tried in the past, and in what context, is a great way to accelerate the speed with which you can try new scaling experiments. As an agile community, we can quickly build, distill, and capture knowledge so that we can improve the state of the art by borrowing patterns and practices that have been used by other companies in a similar context to ours, and then contribute incremental learnings back to that library. It’s a powerful concept that allows us to crowdsource the development of scaling Scrum.
Context is important
– How important is the speed of delivery?
– How important is innovation?
– How important is team empowerment?
– Where are teams located?
– How complex and/or tightly integrated is the product?
– What is the driving timeframe for becoming agile?
– How severe are the repercussions of a product defect?
Answers to these questions define context, and context is very important when trying to scale scrum. But too often it is neglected in discussions of scaling approach. DAD states the same. There is no one size fits all, and context determines the most suitable approach.
The different modules
The whole framework is described in the picture below.
I will give a short description of the goals each module below:
1. Team Level Scrum Process: Maximize the flow of completed and quality tested work; try to increase velocity a little each sprint; operate in a way that is sustainable and enriching for the team in the long run
2. Strategic Vision: Clearly align the entire organization along a shared path forward; compellingly articulate why the organization exists; describe what the organization will and won’t do to leverage key assets in support of its mission; update and fine-tune vision continuously based on feedback to outmaneuver the competition
3. Backlog Prioritization: Identify a clear ordering for products, features, and services to be delivered by the organization; reflect value creation, risk mitigation and internal dependencies in ordering of the backlog
4. Backlog Decomposition and Refinement: Break complex projects and products into manageable independent functional elements that can be completed by one team in one sprint; capture and distil emerging requirements and customer feedback; ensure all backlog items are truly “Ready” when they reach sprint backlog; parse backlog to individual teams
5. Release Planning: Forecast delivery of key features and capabilities; communicate snapshot of delivery expectations to stakeholders; inform updated prioritization, as needed, based on stakeholder input
6. Release Management: Deliver a consistent flow of valuable finished product to customers; integrate the work of different teams into one seamless product; ensure high quality of the customer experience; capture and communicate feedback on product, process, and schedule
7. Feedback: Understand how customers actually use and interact with the product; define improvements to existing functionality; distil actionable changes in direction from the noise of all responses; capture ideas for new features and functionality not previously identified; update progress towards product/project completion to refine release planning and stakeholder alignment
8. Continuous Improvement and Impediment Removal: Identify impediments that slow teams down and reframe them as opportunities to get faster; maintain a safe and structured environment for prioritizing and removing impediments, and then verifying the resulting improvement;; ensure visibility at the right level(s) in the organization to effect change
9. Cross-Team Coordination: Coordinate similar processes across multiple related teams; manage cross-team dependencies to ensure they don’t become impediments; maintain alignment of team norms and guidelines for consistent output
10. Metrics and Transparency: Provide all decision makers including team members with appropriate context to make good decisions; shorten feedback cycles as much as possible to avoid over-correction; accomplish all of this with a minimal additional effort by teams, stakeholders or leadership.
For each module, you can decide how to implement this best and then start the adapt and improve cycles that form the core of any Scrum implementation.
How does Scrum at Scale relate to the other scaling approaches like DAD, SAFe, Nexus, LeSS?
This question is part of every one of my Scaling Scrum articles but not answered by me. I will try to find quotes from the author(s) of the framework regarding this question. In the final article, where I will compare all the frameworks, I will give my own opinion. Unfortunately, I could not find any quotes except for a few outdated spoken ones of Alex Brown.
Are there well-documented use cases of companies using Scrum at Scale?
Since Scrum at Scale is not really a method but more a help and guidance on choosing your own approach for scaling there is no real clear use case. Scrum Inc is consulting companies whilst using the Scrum at Scale approach, so there are people and companies using this approach, but these cases are not documented and available to the public. When you have one or know where I can find one, please contact me.
