Scaling Done Right E-Book

Gereon Hermkes

• Herausgeber: Behendigkeit Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch
• Veröffentlichungsjahr: 2020

Seitenzahl: 240

Beschreibung

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

Leseprobe

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 [email protected].

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 AktasAlexis HueAudree Tara SahotaBob Schatz, DMgtBrock ArgueCarol McEwanCherie SilasErkan KadirFlorian AchermannHuy NguyenJeff Sutherland, Ph.D.Jessica LarsenJ.J. SutherlandJoey SpoonerKim AnteloKoray SenMatthias KrügerMichael SahotaSebastian KrempelSteffen FietzTodd 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 companies1

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.”2 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 also one source of the perennial conflict between Scrum coaches and clients. The customer complains that the coaches sound like a broken record in their exhortation that the problem is that “they are not doing Scrum right.” While there is certainly always room for improvement in how that message is communicated by many Scrum Masters and coaches, the fact is that all parts of Scrum serve a specific purpose. And if you leave them out, that will cause problems.

And the less experienced you are in Scrum, the more likely it is that the solution you devise to compensate for the part of Scrum you are not doing will mimic tumor cells, first growing, then spreading and soon overwhelming your teams, requiring increasingly more band-aid solutions. Unfortunately, it often only becomes apparent that band-aids were the wrong solution when it is too late.

If our goal is business agility, then it should be easy to imagine that building an agile organization on this faulty team-level foundation is bound to fail ignominiously.

Business Agility is More Than Team-level Scrum

The other problem with clients thinking they are doing Scrum is that their Scrum — however “true” it might be — is usually limited to a couple of individual teams.

Simply put, there are three levels of Scrum saturation within an organization:

individual, separate teams doing Scrum;several Scrum teams working together on a product; andthe whole organization doing Scrum.

So when clients speak about doing Scrum, they usually only refer to individual, often unconnected teams doing Scrum. Where several teams are working together on a product, rudimentary self-developed methods for coordinating the teams abound.

Many good Scrum practitioners who work with these self-developed methods have a slight cognitive dissonance, a mental discomfort grating in the back of their heads. They already know the power of Scrum and realize somewhere in the back of their head that the hodgepodge they use to coordinate many teams does not make sense but are helpless to change it. Only having a proper scaling framework will let you avoid the waste of inefficient cross-team coordination.

And one could be forgiven for thinking that just using Scrum on the lowest level of the organization is enough — and indeed some scaling frameworks play it safe and do advocate for the tried-and-failed waterfall project management tools for the whole organization while at the same time arguing the benefits of Scrum teams at the bottom of the organization.

But you are not only leaving vast amounts of productivity (and thus money) on the table by restricting yourself to team-level Scrum, the hounds of the waterfall orthodoxy will perennially hold you at risk.

Because we want to change the organization iteratively, we are okay with this for a time, but make no mistake, unless the whole organization eventually transforms you will always be at risk of the organization’s waterfall immune system casting you out. And just as with an auto-immune disorder, the immune system sometimes fails to distinguish what is actually good for it.

Offense is the best defense.

― Carl von Clausewitz (attributed)

Every defensive line is a Maginot line.

― unknown

Why We Need (Scaled) Scrum

Explaining why Scrum works is not trivial. It rests on a multitude of values, patterns, and practices that overlap and strengthen each other. Similar to a chair with many legs, this is what makes it resilient. A chair only needs one leg to work, such as milk stools of old, but having three or four legs (or more!) makes the contraption much more stable.

Similarly, Scrum rests on many legs and depending on the perspective one takes, there are many ways to explain why it works. Examples would be our customer-focus, continuous improvement, or systems thinking.

On a very high abstraction level, Scrum increases adaptability. In a world that can be characterized as volatile, uncertain, complex, and ambiguous (VUCA) it is normal to perceive the waves of hitherto rare global events such as pandemics, the multiplying consequences of the climate catastrophe, or political instabilities and an ever-increasing rate of technical change as overwhelming for individuals as well as organizations.

Yet this is the world we live in. Changes are not only happening more often, they are also becoming more powerful and unpredictable.

Similarly, we live in a time where the creation of new knowledge has not only increased, but it is generated ever more quickly. And that is a good thing. But it can also add to a feeling of being overwhelmed if yesterday’s certitudes do not hold anymore today.

The rate of change per se is not a problem; it is our inability to deal with it that is problematic. And while there are factors that are more difficult to change in these trying new times, such as our evolutionary-designed brains, one thing that is not immalleable is the way we work. Instead of having to feel helpless, staring frozen into the abyss, Scrum allows us to vibrate at the same high frequency as the environment.

Scrum gives us back our ability to maneuver. We are quicker on our feet and not frozen in place because we have to devastatingly realize that nothing we could do will be quick and adequate enough to deal with what we are seeing. We regain our ability to react.

And Scrum allows us to do that all the while foregoing the classic dichotomy of speed versus quality. In Scrum, we become faster while increasing quality at the same time!

No matter how quickly the environment changes, our capacity to change is just as high. This increased ability to adapt not only allows us to react to changes in the environment, it also allows us to do away with competitors that cannot hum at the same high frequency. This is what John Boyd’s work — one of the precursors to Scrum — was all about: More quickly orienting ourselves to the new environment allows us to beat the opponent to the punch in small ways. Even small steps, but at a rapid pace, will, over time, overwhelm our adversary and leave us not only able to deal with the VUCA environment but also able to outperform our competitors.

* * *

As much as Scrum helps us deal with Chaos with a capital “C,” when Scrum is restricted to the team level, it only helps those teams adapt to the chaos in their environment, which by the nature of their limited area of influence is more product-oriented. This is a helpful first step, but very far from achieving business agility that allows the whole organization to adapt quickly to the environment.

We live in an environment characterized by companies whose life span is continually shrinking because of an inability to react, which causes high costs of delay (such as missed markets). Without Scrum@Scale, not only are you not adaptive on the organizational level, you are probably also slowing down your Scrum teams that suffer from operating within a non-agile organization as well.

If you are sick of being at the receiving end of an ever-increasing rate of change that makes you fear for your future and if you are tired of being a mere punching bag to your more nimble competitors, and you finally want to go on the offensive, you need to achieve business agility.

DIY Scaling as a Symptom of Organizational Rumination

One major problem in the adoption of scaled Scrum is that too many organizations are addicted to continuously reinventing how work is done in the organization. Symptoms of this are endless meetings, task forces, round tables, and committees that are all focused on how the organization works.

Just as reflecting on oneself is very healthy within limitations, so is focusing on how the organization works a good thing. That is why Scrum has Retrospectives. When it dips into obsessive rumination, however, where thinking about the “how” takes up an inordinate amount of time compared to actually getting things done and leads to analysis-paralysis, it becomes pathologic.

This is closely related to “ScrumBut,” but more excusable given the late start of scaling frameworks. Either way, the waste created by this is almost unfathomable, and it has to stop.3

If you have been in the workforce during the COVID-19 crisis of 2020, think back to who was actually needed during the lockdown and who could just sit at home with no loss of productivity or function. Chances are that the latter are just creating waste.

And interestingly enough, this work is often delegated to people that are the least qualified to work on the most important part of the organization, its operating system!

Presumably, this is part of an old problem: As managers are confronted with choices for a particular problem — each with its pros and cons — they chose the option with the best mix of pros and cons.

However, instead of then accepting the downsides of their choices (and maybe trying to mitigate them a bit) they will then try to get rid of the downsides and thereby giving up the structure of their own best choice.

Once they have either unintentionally moved over to a choice they just recently deemed inferior or once they have created an untenable mixture of several choices, they will then adjust again and choose yet another option that used to be a second or third choice, only to keep repeating the process.

From close by, it might seem that the people involved in this are taking the initiative and making good use of their critical reasoning skills. But by stepping back, we see this for what it is: a dog continuously chasing its own tail, looking very active but achieving nothing.

The answer is to stop trying to come up with self-developed answers for scaling. There is a place for inspecting and adapting how one works, but instead of wasting your time and energy on chasing your own tail, use a scaling framework and save your energy for actually delivering something.

And please do not fall into the trap of thinking that your organization is so special that Scrum will not work. SAP is developed with Scrum. Cars, fighter jets, and large surface warships are developed with Scrum. Oil exploration, banking, and education are being done with Scrum. Your industry is not that special, and you risk that a competitor will let you find this out the hard way.

The Gist: Why You Need Scrum@Scale

1) You need Scrum to cope with the dynamic nature of the world. The rate of change in the environment as well as competitive forces urging you to increase your productivity leave you little choice.4

2) You need to stop the do-it-yourself (DIY) approach when it comes to scaling Scrum. Chances are that you will not invent the next agile system and that your industry is not so unique that you need to invent (and then continually reinvent) your own solution. Take a scaling framework instead and focus on delivering products to your customers instead of reinventing the wheel of how to organize work.

3) You need a scaling framework that allows for true business agility. Scaling frameworks that only address how to operate a couple of teams or that restricts agility to the bottom of the organization will not save you.

1https://en.wikipedia.org/wiki/List_of_public_corporations_by_market_capitalization#2020

2 ScrumBut refers to the syntax of the justification as to why Scrum is not being followed, e.g., “Scrum Retros make sense, but we do not hold Retros anymore as they seem to bring too much conflict to the team.”

3 And we are betting that as you were reading this, some faces or flashbacks to specific meetings came up for you!

4 But you probably already know this, otherwise, you would not be reading this book.

2

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

If you can’t scrum, you can’t scale.

― Dr. Jeff Sutherland

When students come to Scrum@Scale classes, many are surprised by the large amount of attention given to team-level Scrum during the class. Sometimes, there is outright resistance among the students — Scrum@Scale is not a beginner’s class, and they are paying good money to learn scaling and not “basic” Scrum after all!

That is until they come across an exercise where they have about ten minutes to demonstrate their knowledge of Scrum, be it in visually explaining how Scrum works, playing a round of Kahoot, or simulating a teach-back on Scrum to an interested manager.

These exercises do what Scrum does best: revealing the truth. And the truth is that most practitioners grossly overestimate themselves as far as Scrum is concerned.

And while they might be doing passable Scrum that is good enough for a single team, the truth of the matter is that successful scaling demands a higher than average level of Scrum in the teams.

Just imagine two teams, one estimating with points and one with hours. While not ideal, the team that is estimating in hours could still perform significantly better than non-Scrum teams.

But when you require those two teams to work together, you will run into trouble, for example, because the aggregated release planning will not work because of the difference in estimation. And this small example is indicative of all the other little things that might not seem to matter much when operating with a couple of individual teams, but that will spin out of control when you start to scale.

And that is why the first rule of scaling is that your Scrum teams must operate consistently within the Scrum Guide. Otherwise, the mere act of scaling will magnify these small problems to an unimaginable extent and derail your organization.

Conversely, this also means that scaling will not save you. People sometimes hope for a scaling framework to solve their problems with team-level Scrum problems, but scaling will not only not save you, it will also increase your problems until you fix your team-level Scrum first!

To quote Dr. Sutherland: “Why are you trying to scale your inability to deliver?“

* * *

So now that we have established that “if you cannot scrum, you cannot scale,” there is also a converse corollary, namely that “you cannot scrum if you cannot scale.”

A priori, this might seem nonsensical: If your team does good scrum but does not know how to scale, you are, in fact, scrumming,