Scrum@Scale — An Introduction
Scaling Scrum, Part 7
“A framework within which networks of Scrum teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value.”
This is part seven of Willem-Jan Ageling’s series (I’m just visiting :)
Introduction
So you’re thinking about Scaled Agile Approaches. At first glance, Scrum@Scale should be a strong contender for your attention, because the author is a certain Dr Jeff Sutherland.
Sutherland is one of the Very Smart Folks to come up with Scrum in the first place. He worked with Ken Schwaber in some of the very first experimental Scrum Teams, and together they came up with the Scrum Guide. Indeed, these two Scrum Guides go way back: they presented a paper together on Scrum at the OOPSLA conference as far back as 1995.
Sutherland and Schwaber are also two of the 17 middle-aged white guys who went on a ski holiday in 2001, and made a website about Agile that became pretty influential.
To put it another way, Jeff Sutherland has Agile Chops, so his idea of an approach to scaling should start from a place of some credibility.
In this post, I’ll take a look at Scrum@Scale, Sutherland’s relatively new kid on the block of frameworks attempting to tackle the scaled agile question.
Let’s dive in.
Scrum@Scale — Jeff Sutherland’s Project
First question you might ask is: where is the other Scrum guy? The name Schwaber may seem conspicuously absent on the front page of the Scrum@Scale Guide.
As it stands, Sutherland works with Scrum Inc on the Scrum@Scale Guide, and is currently working on a partnership with Scrum Alliance. Meanwhile, over at Scrum.Org, Ken Schwaber continues to work on the Nexus Guide, another alternative to scaling Scrum. Schwaber and Sutherland still collaborate together on the Scrum Guide though...
Confused? You could be forgiven :) But fear not. In fact, when you take a look at Scrum@Scale and Nexus in more detail, you get an idea of how the perspectives of the two men are aligned, and also how they differ.
Core Concept 1— Smaller Teams
Sutherland’s first point of divergence from the Scrum Guide is on team size. Those familiar with Scrum will know that the recommended team size is somewhere between 3 and 9 people. In the Scrum@Scale guide, however, Sutherland diverges on this critical point.
“Experiments with high performing Scrum teams have repeatedly shown that 4 or 5 people doing the work is the optimal size. It is essential to linear scalability that this pattern be the same for the number of teams in a SoS. Therefore, in the above and following diagrams, pentagons were chosen to represent a team of 5.” — S@SG
Images you see throughout this post represent teams as hexagons, to reinforce the point that there should be no more than 5 people in a team. This holds true for any of the teams you see in the images below.
Core Concept 2 — Scaling across the whole Organisation
I referred above to Nexus. Nexus and Scrum@Scale both use Scrum as a foundation. However, Scrum@Scale is significantly more ambitious in scope than Nexus. While Nexus is defined as a framework with which to co-ordinate “three to nine Scrum Teams working on a single Product Backlog”, Scrum@Scale, by contrast, “is designed to scale across the organisation as a whole.”
“Scrum@Scale is designed to scale across the organization as a whole.” — Scrum@Scale Guide
Linear Scalability
In addition, an ambition of Scrum@Scale is to create linear scalability. In other words, if 1 person can complete 1 story in 1 day, shouldn’t 1,000 people be able to complete 1,000 stories in 1 day? This is the holy grail of scaled approaches to work in general.
I have to admire the purity of Sutherland’s ambitions.
Core Concept 3 — Minimum Viable Bureaucracy
To understand Scrum@Scale, it is important to understand Minimum Viable Bureaucracy. One of the underlying principles of Scrum@Scale is Jeff Sutherland’s intention to reduce the time it takes to make decisions in an organisation.
Smaller teams reinforce this at every level of the organisation, as long as they are co-ordinated in a meaningful way.
Reducing ‘Dark Work’
Sutherland believes that organisations without Scrum are spending roughly 75% of their time on dark work. That is, either features that customers neither want or need, or work that has zero value. ‘Because I say so’ stories, or ‘busy work’ accounts for up to 30% of work.
He also reckons Scrum can reduce these negative numbers, and that Scrum@Scale can reduce the numbers even further, by improving decision-making inside an organisation.
I once heard a great definition of business agility as the ability of an organisation “to turn on a dime for a dime.” (Credit for that goes ultimately to Craig Larman, the creator of LeSS.)
This description captures the ability of businesses to set themselves up for success by removing latency in decision-making. Minimum Viable Bureaucracy is Sutherland’s interpretation of ‘turning on a dime’, and there are two parts to this. We have already covered linear scalability, scaling Scrum across the entire organisation. If we are scaling across the entire organisation, we will need to discuss another dimension: hierarchy.
Hierarchy
Bureaucracy slows things down. Sutherland asserts that traditionally, management use project teams in organisations, and Scaling Frameworks are adopted as a ‘translation layer’ for the organisation.
However, this is the very bureaucracy that a genuinely ambitious scaled approach should try to remove from the organisation, as it will slow down decision-making.
If the goal is linear scalability, bureaucracy is a clear impediment to achieving that.
Components of Scrum@Scale
Scrum@Scale contains two cycles: the Scrum Master Cycle (the “how”) and the Product Owner Cycle (the “what”), each touching the other at two points. Taken together, these cycles produce a powerful framework for coordinating the efforts of multiple teams along a single path.”
1. Scrum Master Cycle — the ‘how’
The first component of the Scrum Master cycle is the team level process, which effectively describes the work of Scrum Teams, as defined in the Scrum Guide. This is great news! If you understand Scrum, then this will be a foothold for you. Brace yourself though, there’s a lot of new stuff :)
New Team: Scrum of Scrums
The Scrum of Scrums is a Scrum Team “responsible for a fully integrated set of potentially shippable increments of product at the end of every Sprint from all participating teams”. This means the SoS has roles, artifacts and events, and effectively acts a release team, with a lot of responsibility.
Following the core principles of Scrum@Scale, this would be a team of 3 to 5 people, one person playing a Scrum Master role, and another playing a Product Owner role.
New Role: Scrum of Scrums Master (SoSM).
The Scrum of Scrums Master is effectively responsible for managing impediments that hinder co-ordination across teams. To this end, the SoSM facilitates events to refine impediments. The SoS identifies those that are ‘ready’ to be removed, the team determines how best to remove them and when they are ‘done.’
I imagine the SoS Product Owner prioritising the backlog of the SoS, and deciding which impediments or dependencies should be tackled first.
Interestingly, this implies the need for a definition of ready and a definition of done for impediments…
“Particular attention should be paid to the SoS Retrospective in which the teams’ representatives share any learnings or process improvements that their individual teams have succeeded with, in order to standardize those practices across the teams within the SoS.” — S@SG
New Event: Scaled Daily Scrum:
“At least one representative (usually the team’s Scrum Master) of each of the participating teams need to attend a Scaled Daily Scrum (SDS).” — S@SG
By my reckoning, there could be 5 attendees at the SDS from teams. Add the (up to) 5 members of the SoS, and we could have a reasonable large SDS each day.
The three suggested questions at the Scaled Daily Scrum are an interesting echo of the three suggested questions from the most recent iteration of the Scrum Guide:
- What impediments does my team have that will prevent them from accomplishing their Sprint Goal (or impact the upcoming release)?
- Is my team doing anything that will prevent another team from accomplishing their Sprint Goal (or impact their upcoming release)?
- Have we discovered any new dependencies between the teams or discovered a way to resolve an existing dependency?
The Scrum of Scrum of Scrums (SoSoS)
Where there are more Scrum Teams inside an organisation, there is a need for more Scale. This can be achieved with a Scrum of Scrum of Scrums, another level of co-ordination.
“The SoSoS interfaces with a SoS in the exact same manner that a SoS interfaces with a single Scrum team which allows for linear scalability.” — S@SG
To me this implies that the SoSoS is also a Scrum Team, with events, roles and artifacts. It takes a little imagination to consider the perspective that this team would have on Planning, Refinement, and a Retrospective.
The Executive Action Team
It follows that this structure requires steering and leadership. In Scrum@Scale, this is represented with the the Scrum of Scrums for the entire agile organisation, known as the Executive Action Team (EAT).
“The EAT is the final stop for impediments that cannot be removed by the SoS’s that feed it. Therefore, it must be comprised of individuals who are empowered, politically and financially, to remove them. The function of the EAT is to coordinate multiple SoS’s (or SoSoS’s) and to interface with any non-agile parts of the organization. As with any Scrum team, it needs a PO and SM. It would be best if the EAT met daily as a Scrum team. They must meet at least once per Sprint and have a transparent backlog.” — S@SG
This leads me to imagine a series of Daily Scrums each day, starting at the team level. Then, we might have a Scaled Daily Scrum, with impediments being raised and discussed. Then, we might have a Scaled SoSoS. Last stop for escalations is the EAT. This makes it conceptually easier to understand how impediments could be escalated and resolved in the same day.
Reducing minimal viable bureaucracy.
Outputs/Outcomes of the Scrum Master Cycle
- Continuous Improvement and Impediment Removal
- Cross-Team Coordination
- Deployment.
2. Product Owner Cycle — the ‘what’
Next! Product Owner role in an organisation scaled with Scrum@Scale.
MetaScrum
First up is the base component. Similar to the Scrum Masters, the assumption is that the base work will still be done by Scrum Teams. However, in order to co-ordinate those teams, the Product Owners require a level of co-ordination, in addition to the one facilitated by Scrum Masters. The entity that drives this is called the MetaScrum.
The Scaled Backlog Refinement Meeting, attended by Leadership, Stakeholders or other Customers, is organised by the MetaScrum
“A group of Product Owners who need to coordinate a shared backlog that feeds a network of teams are themselves a team called a MetaScrum.”
The MetaScrum also has someone acting in a Scrum Master role.
“MetaScrums, just like SoS’s, function as Scrum teams on their own. As such, they need to have someone who acts as a SM and keeps the team on track in discussions. They also need a single person who is responsible for coordinating the generation of a single Product Backlog for all of the teams covered by the MetaScrum. This person is designated as the Chief Product Owner.” — S@SG
The main functions of the MetaScrum are to:
- Create an overarching vision for the product & make it visible to the organization
- Build alignment with key stakeholders to secure support for backlog implementation.
- Generate a single, prioritized backlog; ensuring that duplication of work is avoided.
- Create a minimally uniform “Definition of Done” that applies to all teams in the SoS.
- Eliminate dependencies raised by the SoS.
- Generate a coordinated Release Plan.
- Decide upon and monitor metrics that give insight into the product.
Chief Product Owner
This is a new role in Scrum@Scale and describes
“a single person who is responsible for coordinating the generation of a single Product Backlog for all of the teams covered by the MetaScrum. This person is designated as the Chief Product Owner.” — S@SG
A MetaScrum can be scaled to a higher level of co-ordination for up to 25 teams, and this requires a new role: the Chief Chief Product Owner :)
The Executive Meta Scrum
“The MetaScrum for the entire agile organization is the Executive MetaScrum. The EMS owns the organizational vision and sets the strategic priorities for the whole company, aligning all the teams around common goals.” — S@SG
Desired Outcomes of the Product Owner Cycle
- Strategic Vision
- Backlog Prioritization
- Backlog Decomposition & Refinement, and
- Release Planning.
Remember though, those outcomes are at an organisational level.
Connecting the Two Cycles
The connecting mechanisms between the Scrum Master Cycle and the Product Owner Cycle are feedback and Metrics.
Feedback
“Product feedback drives continuous improvement through adjusting the Product Backlog while Release feedback drives continuous improvement through adjusting the Deployment mechanisms.” — S@SG
Metrics and Transparency
“Scrum@Scale does not require any specific set of metrics, but it does suggest that at a bare minimum, the organization should measure:
- Productivity — e.g. change in amount of Working Product delivered per Sprint
- Value Delivery — e.g. business value per unit of team effort
- Quality — e.g. defect rate or service downtime
- Sustainability — e.g. team happiness
Organisational Design
Knowledge and Infrastructure Teams
Sutherland addresses the issue of the teams that don’t quite fit into the two cycles above with the idea of knowledge and infrastructure teams. These teams support Scrum Teams, but they’re not Scrum Teams in their own right.
“Virtual teams of specialists of which there are too few to staff each team. They coordinate with the Scrum teams as a group via service-level agreements where requests flow through a PO for each specialty who converts them into a transparent ordered backlog” — S@SG
The combination of the Scrum Master Cycle, The Product Owner Cycle, the connecting mechanisms and an additional seasoning of organisational design adds up to all the elements of Scrum@Scale. These components are supplemented with the three core concepts of Smaller Teams, Scalability across the entire organisation and Minimum Viable Bureaucracy to form this admirably ambitious framework. The concepts are simple to understand but difficult to master. Just like Scrum.
The Bottom Line
Implementing Scrum@Scale demands re-design to an organisation. It is ambitious in its scope, but I admire that.
I am convinced that smaller teams work better, and I am also convinced that this is an effective way to allow scaling to happen in a more natural way.
The design elements of Scrum@Scale make it easier o manage information flow in an organisation. I can see how a successful implementation would reduce decision latency, and allow the EAT to ‘eat impediments’. In a sequence of short Daily meetings, the most important impediments could make it from Scrum Teams all the way to Executive Leadership for resolution.
If senior leadership are bought into the ambitious framework, and willing to participate, then Scrum@Scale could feel like a natural progression from Scrum. However, a potential challenge here is the fact that leadership might consider agile approaches to be the domain of the IT Department, and irrelevant to their domain.
Another obstacle could be the existence of other roles and hierarchies in organisations. Do you work with Engineering Managers for example? They would be entirely justified in asking where they might fit into this model.
Scrum appears to have a certain myopia to the existence of CTOs and engineering managers, and Scrum@Scale also scales that myopia, giving the Scrum Masters overall responsibility for deployment. I am not sure how that would go over with the engineering managers in my organisation!
Another point that would require some clarity for me: what is the make-up of the higher level teams in terms of personnel? Who attends a Scaled Daily Scrum for example? 5 Scrum Masters, a SoSM and a PO? I feel like the guide could elaborate on this more.
Overall though, I love the purity of Sutherland’s ambitions. Scrum@Scale is inspirational, and loaded with ideas.
What do you think? Have you ever worked in an organisation that attempted a pure implementation of Scrum@Scale? It would be great to hear about your experience!
References:
https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/
https://www.scruminc.com/getting-the-organization-to-buy-in-to-agility-its-all-about-leadership/
