Scaling Done Right: How to Achieve Business Agility with Scrum@Scale and Make the Competition Irrelevant

By Gereon Hermkes, Luiz Quintela and Jeff Sutherland

In Scaling Done Right, Scrum@Scale trainers Gereon Hermkes and Luiz Quintela show how organizations can dramatically improve their productivity and adaptability, and finally achieve business agility.In a time where the mortality of large organizations is rising in lockstep with a constantly increasing rate of change, it is not surprising that many of the world’s most valuable companies are using Scrum to succeed.

Scrum@Scale, which was developed by Scrum co-creator Dr. Jeff Sutherland, naturally extends Scrum to the whole organization. By mimicking patterns seen in nature and focusing on a “minimum viable bureaucracy”, it is possible to install an agile operating system that aligns the whole

• Language: English
• Publisher: Behendigkeit Publishing
• Release date: Aug 25, 2020
• ISBN: 9783982197005

Book preview

Gereon Hermkes & Luiz Quintela

Scaling Done Right

How to Achieve Business Agility with Scrum@Scale and Make the Competition Irrelevant

First published by Behendigkeit Publishing (behendigkeit.com) 2020

Copyright © 2020 by Gereon Hermkes & Luiz Quintela

All rights reserved. No part of this publication may be reproduced, stored or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise without written permission from the publisher. It is illegal to copy this book, post it to a website, or distribute it by any other means without permission.

Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book and on its cover are trade names, service marks, trademarks and registered trademarks of their respective owners. The publishers and the book are not associated with any product or vendor mentioned in this book. None of the companies referenced within the book have endorsed the book.

Gereon Hermkes & Luiz Quintela assert the moral right to be identified as the authors of this work.

Gereon Hermkes & Luiz Quintela have no responsibility for the persistence or accuracy of URLs for external or third-party internet websites referred to in this publication and do not guarantee that any content on such websites is, or will remain, accurate or appropriate.

Behendigkeit Publishing, Gereon Hermkes, Berliner Str. 39a, 14169 Berlin, Germany

Scrum@Scale is a trademark of Scrum, Inc., 1 Broadway, 14th Floor, 02142 Cambridge, MA

The Scrum@Scale guide by Dr. Jeff Sutherland is licensed under CC-BY-SA 4.0 and can be found at https://www.scrumatscale.com/scrum-at-scale-guide/

If you have questions or would like to get in touch, you can reach us at [e-mail].

Version 1.2.0

First edition

ISBN: 978-3-9821970-2-9

This book was professionally typeset on Reedsy

Find out more at reedsy.com

Gereon

To Sylvia, Linda, and Liam — per aspera ad astra

Luiz

To my dear friends that gave me strength to keep fighting a brutal battle.

I could not have survived without you!

docendo discimus

Contents

Foreword

Acknowledgement

1. Are We There Yet?

2. If You Can’t Scale, You Can’t Scrum

3. Scaling the Scrum Master

4. Waste Truly Is a Crime

5. Scaling in Context

6. Pioneers Take All the Arrows

7. Alignment Is a Force Multiplier

8. Product Owner Practicalities

9. Deploy or Die

10. Things That Go Bump! in the Night

11. Distribute Teams, Not People

12. Doctrine, Not Dogma

About the Authors

Foreword

to Scaling Done Right by Jeff Sutherland

Scaling Done Right is the first book on Scrum@Scale, so it is a privilege to write a foreword. In October 2016, I was delivering a keynote on scaling at the Construx Executive Conference in Seattle. During a break, the Agile leaders from Intel Corp cornered me and said that scaling frameworks had slowed teams down at Intel and that I needed to fix it.

I later found out that one division of 500 teams had increased productivity by 18 times over twelve years, so I was not surprised that a scaling framework would slow them down. And I was told by Agile leaders at a later conference that Intel management was so upset by the slowdown that they had thrown out all scaling frameworks and did not want to hear the word Scrum used at the company anymore!

I had been scaling Scrum since 1983 at Mid-Continent Computer Services, where we developed a prototype with small cross-functional teams, a Product Owner with a Product Backlog, weekly Sprints, and burndown charts for an entire business unit. This organizational operating system created the most profitable business unit in a company running 150 banks within six months. For the next ten years as CTO, President, or VP of Engineering, I implemented similar practices in other banking companies, object database companies, software tooling companies, and consultancies.

In 1993 at Easel Corporation, we adopted the name Scrum, called the facilitative team leader the Scrum Master, wrote down virtually all of the practices we use today in Scrum and Extreme Programming, and promoted these practices in internet newsgroups. Easel was acquired by VMARK in 1995, and I asked Ken Schwaber, CEO of a waterfall project management company, to help introduce Scrum to the software industry. We decided to carve out the team process used by the first Scrum team and leave the software engineering practices to Kent Beck, who had asked us for everything about Scrum. We presented the first formal paper on the Scrum team process at OOPSLA’95.

In 1996 I returned to the first internet news company, Individual, that I had cofounded in the late ’80s. Individual had just gone public. They were hiring hundreds of developers as fast as possible and wanted me to introduce Scrum as CTO. I brought Ken in as a consultant, and we soon had a high performing scaled Scrum that included operations, deployment, and support and delivered new releases and new products every week or more often. This was the forerunner of what today we call DevOps.

From Individual, I was hired by IDX, one of the top three companies in the healthcare software business. They had hundreds of teams, and Ken and I formalized the Scrum of Scrums concept as a delivery team, just as we had done at Individual.

In 2000, I joined PatientKeeper, a healthcare startup, providing mobile devices to physicians. We scaled that into the highest performing set of Scrum teams I have ever seen, deploying 45 releases of enterprise systems into hundreds of the largest hospitals in the United States every year. PatientKeeper was called The Future of Scrum in a research paper at the Agile 2005 conference because, every Sprint, it would deploy four large new hospitals as well as upgrade many more for years without missing a date. Mary and Tom Poppendieck featured it in their book, Implementing Lean Software Development, published by Addison-Wesley in 2006. It was the leanest set of software teams they had ever seen.

So the Intel Agile leaders wanted me to write down how everyone could lean out production, and I published this as the Scrum@Scale Guide soon after we had met in 2016. It incorporated what we had learned from companies like SAP with 2,000 Scrum teams, Amazon with 3,300 Scrum teams, Microsoft with over 3,000 people building all of Microsoft’s development tools, and smaller companies like Pegasystems whose stock price went up 400% while we were implementing Scrum globally in 2009.

It also incorporated my experience as Senior Advisor to OpenView Venture Partners since 2006, where they implemented Scrum in the venture group and developed a management training program for what we know today as Scrum@Scale. We invested in hundreds of Scrum companies like DataDog, who went public last fall and whose skyrocketing stock price during the COVID-19 pandemic has yielded a return on investment of over 3,000%.

To be lean, you need the least amount of overhead possible. So Scrum@Scale builds great companies by implementing a Minimum Viable Bureaucracy across an entire organization based on patterns in our recent book, The Scrum Book: The Spirit of the Game. Many years ago, two of the founders of the software patterns movement asked me to help with a ten-year effort to publish a book on Scrum patterns based on the rigorous process they had developed for software patterns over the previous 20 years. The Product Owner of the book, Jim Coplien, insisted that there would be no scaling patterns in the book because they will just slow you down and are usually specific to only one company situation and not all companies.

As we progressed the patterns, we found that when a team gets to about seven people, it needs to start thinking about splitting, so we created the pattern called Mitosis. As soon as we had more than one team, we needed the Scrum of Scrums pattern that we had used at IDX and the pattern called Product Owner Team.

Then the Product Owners needed to protect the Scrum by creating a regular meeting with management to get them to align with their direction and support their backlog. This pattern was the Metascrum that we had created at Patientkeeper. The only other thing we needed to scale with no scaling patterns was an Executive Action Team to lead the agile teams in an organization. But this team simply followed the pattern of a Scrum team whose responsibility was transforming the organization.

This Minimum Viable Bureaucracy was used recently at Quicken Loans, the largest mortgage provider in the U.S. to achieve a 340% improvement in production in an already scaled agile organization (see our Agile 2020 accepted submission), so we are confident that no matter what agile process you are using in your organization, it can be significantly improved by Scrum@Scale.

I have worked closely with Gereon Hermkes and Luiz Q Quintela and carefully read their book and offered suggestions which they have incorporated. As the first Scrum@Scale book, it should be on the bookshelf of every Agile leader in the world. The ideas in this book could take your organization from good to great by unleashing the ultimate power of agility.

Jeff Sutherland, Founder and Chairman, Scrum Inc.

Co-Creator of Scrum and Creator of Scrum@Scale

Acknowledgement

We would like to thank these friends, teachers, students, and coworkers (sometimes everything all at once) for helping us develop the book and some of the ideas within it:

Aktan Aktas

Alexis Hue

Audree Tara Sahota

Bob Schatz, DMgt

Brock Argue

Carol McEwan

Cherie Silas

Erkan Kadir

Florian Achermann

Huy Nguyen

Jeff Sutherland, Ph.D.

Jessica Larsen

J.J. Sutherland

Joey Spooner

Kim Antelo

Koray Sen

Matthias Krüger

Michael Sahota

Sebastian Krempel

Steffen Fietz

Todd Little

1

Are We There Yet?

It is not the strongest of the species that survive, but the one most responsive to change.

― Prof. Leon Megginson (wrongly attributed to Charles Darwin)

It is not necessary to change. Survival is not mandatory.

― W. Edwards Deming

Why Scaling Matters

Well, we used Scrum and it worked really well for us, so we added more teams …

If you work as a Scrum@Scale Trainer, this is how a surprising number of conversations start. Experienced Scrum Masters and coaches ask for lunch or coffee dates and more often than not, the above phrase will be uttered, invariably to be followed by a description of the mayhem that ensued afterward.

Your next move in that situation is to ask what scaling framework they are using, but you already know the answer to that question.

It is not so much that they chose the wrong framework — even though you can arguably do lasting damage to your organization by choosing the wrong scaling framework — it is that they did not choose a framework at all and just started ramping up.

Welcome to the age of inadvertent scaling.

Are We There Yet?

Given that the first Scrum team started working in 1993, and the Agile Manifesto has been around since 2001, one would be forgiven to ask, are we there yet?

On one hand, just as software is eating the world, Agile is eating the world of work. A look at the most valuable companies on the planet quickly shows that almost all of them are agile, with most doing Scrum. So the answer should be a resounding yes!

the preponderance of Scrum in the most valuable public companies¹

But on the other hand, while some of the most dominant companies in the world are succeeding with Scrum, there are also many organizations that lag behind in its adoption.

This is to be expected as every adoption (think cell phone or electric car adoptions over time) will happen earlier in some places and later in others.

But considering how the Scrum vanguard — companies such as Amazon, Tesla, ING, and Spotify — are upending industries and how long Scrum has been around, surely something else is going on. Why is not everyone doing Scrum?

A significant factor in the discrepancy between the vanguard and the laggards is that many companies have difficulties extending Scrum from a limited number of teams to many, never mind the whole organization.

And it is true: Scrum as a framework in which people can address complex adaptive problems, while productively and creatively delivering viable products of the highest possible value is not limited to single teams per se, but it also does not necessarily address how to organize networks of Scrum teams.

Yet successfully running networks of Scrum teams operating consistently within the Scrum Guide is what scaling is about. And without scaling, your organization will have a hard time attaining the elusive state of business agility, where the whole company will be agile. Even worse, unless the entire organization is saturated with Scrum, the teams at the bottom of the hierarchy will always remain a beachhead — vulnerable to the non-agile rest of the organization striking back like the Empire and sweeping it away.

Why Scaling Often Fails

Besides inadvertent scaling, where organizations just spin up teams without knowing how to coordinate them, there are several other typical reasons why scaling Scrum does not work.

The Scrum That Wasn’t

When doing the initial interview for a coaching engagement, clients often state that they are doing Scrum. This, however, is rarely true.

So let us be honest with each other for a minute: When people say they are agile, usually they are not. What they mean by this is that they use agile jargon to describe what they have always done (more or less successfully).

What is being done under the name of Scrum is usually some form of ScrumBut.² While doing Scrum was maybe the original intention, over time, too many exceptions were made when resistance was encountered, with the result being a system that is often Scrum in name only.

If one understands Scrum to be a system of feedback loops, then dropping one of the loops will eventually lead to an imbalance of the whole system that will at best lead to a subpar steady state, but at worst will unbalance the system in a way that will make it fold in on itself, as the organization will find ever more ways to install more and more fixes for Scrum that would not have been necessary had Scrum been followed more closely in the first place.

This is