97 Things Every Scrum Practitioner Should Know

Collective Wisdom from the Experts

Gunther Verheyen

97 Things Every Scrum Practitioner Should Know

by Gunther Verheyen

Copyright © 2020 O’Reilly Media, Inc. All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.

- Acquisitions Editor: Melissa Duffield

- Development Editor: Corbin Collins

- Production Editor: Deborah Baker

- Copyeditor: Holly Bauer Forsyth

- Proofreader: Piper Editorial Consulting, LLC

- Indexer: Angela Howard

- Interior Designer: David Futato

- Cover Designer: Karen Montgomery

- Illustrator: Rebecca Demarest

- May 2020: First Edition

Revision History for the First Edition

- 2020-04-27: First Release

See http://oreilly.com/catalog/errata.csp?isbn=9781492073840 for release details.

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. 97 Things Every Scrum Practitioner Should Know, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.

The views expressed in this work are those of the authors, and do not represent the publisher’s views. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

978-1-492-07384-0

[LSI]

Preface

I am pleased to present to you these 97 essays about Scrum. This is not a book from which to learn Scrum. Instead, it offers insights into the rules and roles of the Scrum framework and their purpose, as well as tactics, strategies, and patterns to apply with Scrum, stories from the trenches, and some perspectives on Scrum that go beyond...Scrum.

Although Scrum (which debuted in 1995) gradually became the most adopted definition of Agile (which came about in 2001), there remain plenty of important challenges for us Scrum practitioners. Not only do we face the ongoing task of correcting the many misunderstandings that exist regarding Scrum — we also keep looking for the best possible ways and channels to provide information for those who are new to Scrum, and for those who want to improve their understanding of the Scrum framework.

Thanks to the wide adoption of Scrum, with millions of practitioners around the world, there is an enormous wealth of knowledge and real-life expertise available. At the same time, there are countless people and organizations new to Scrum who are looking for insights, advice, and stories, and there are practitioners hoping to get deeper insights. With this book, we aspire to connect the world of seasoned practitioners to the world of seekers.

Scrum is known to be simple, yet not easy. Scrum is a simple framework designed to address complex challenges, with complex product development being an important subset of such challenges. Scrum leaves much room to apply diverse practices and tactics and can wrap many such practices and tactics. What better way than collecting and making available stories from leading Scrum practitioners to depict the many shapes that Scrum can take?

Here, you will learn how seasoned practitioners have dealt with problems and challenges, and what they believe is an important Thing for you to know. Stand on their shoulders. Improve your understanding of Scrum based on their insights. Be inspired to find your own way of Scrum by applying, tuning, and tweaking how these practitioners have used it.

The collective intelligence expressed in these 97 essays represents an immense variety of ideas. You might not like every single one or agree with all of them. You might find contradictions, deviant perspectives, and forms of ambiguity. Welcome to the world of complexity that Scrum helps us navigate: a world where little is black and white. May you find plenty of value to better navigate the complexity of your particular situation.

How This Book Is Organized

Beyond chasing people, collecting and reading essays, and providing authors with editorial suggestions, I enjoyed looking for commonalities and shared themes as essays poured in. This part of my work, ordering the essays, finally resulted in grouping our 97 Things into 10 themes. It was a way to create some flow across the book, although, fortunately, no essay is limited to one theme only, and every essay can be read separately:

Part I, Start, Adopt, Repeat

In Part I, you will find 11 small and major Things worth considering and reconsidering along your journey of adopting Scrum. Because adopting Scrum is more than just a one-time effort of introducing Scrum; it is a continual exercise of thinking, rethinking, and discovery.

Part II, Products Deliver Value

In Part II, you will find 11 Things highlighting the focus of Scrum on products and services and why value trumps volume. Because in a complex world of unstable requirements and ever-evolving technologies, “product” provides a minimal form of stability to organize your work with Scrum.

Part III, Collaboration Is Key

In Part III, you will find 10 Things that explain why Scrum is all about collaborative teamwork, where communication and interaction are crucial. Because creating, sustaining, and evolving complex products and services in complex and changing environments requires collective intelligence, skills, and expertise.

Part IV, Development Is Multifaceted Work

In Part IV, you will find 12 Things to exemplify how “Development” in Scrum encompasses all work to create tangible, demonstrable working results no later than by the end of a Sprint. Because development of complex products (in often complex circumstances) requires more than technically producing work (like coding or programming only).

Part V, Events, Not Meetings

In Part V, you will find 10 Things to help you grasp the collaborative intention and nature of the Scrum events and see how they are forward looking and not about the past, reporting, or status updates. Because what are commonly called the Scrum meetings are actually events that provide specific opportunities for inspection and adaptation.

Part VI, Mastery Does Matter

In Part VI, you will find 12 Things for anyone looking for what mastery in Scrum entails, what to look for, and what to look out for. Because mastery matters not just for Scrum Masters, although they are quite important as masters of ceremony.

Part VII, People, All Too Human

In Part VII, you will find 8 Things that highlight the human side of work in Scrum, even touching on anthropology and neuroscience. Humans are not resources (robots, cogs, or replaceable pieces of machinery). Because development is done by people, often resulting in work for people. And people are...people.

Part VIII, Values Drive Behavior

In Part VIII, you will find 6 Things based on the understanding that there is more to Scrum than the rules. Scrum is — by design — an incomplete framework that invites people to engage, interact, and collaborate. Because Scrum is a framework of rules, principles, and...values. And values drive behavior.

Part IX, Organizational Design

In Part IX, you will find 9 Things with viewpoints, practical cases, and lessons learned about the impact of Scrum on organizational structures. Although this is not necessarily the same as scale, the organizational impact is much more apparent in large organizations. Because introducing Scrum is not possible without impacting the organization and existing organizational structures.

Part X, Scrum Off Script

In Part X, you will find 8 Things about Scrum, its use, and potential use in ways and domains that are not typically associated with Scrum, including a few grassroots stories that go back to the days before it was called Scrum. Because for Scrum practitioners to help shape the future of Scrum, we need imagination combined with historical awareness.

At the end of the book, you will find a Scrum Glossary, which lists and explains the terms used in this book in the simplest way.

Throughout the book, you’ll find many quotes from the Scrum Guide, all taken from the November 2017 edition.

Acknowledgments

I am fortunate to be part of an amazing family that inspires and motivates me to do what I do, wherever that takes me. Without my wife and our three kids, I would be nowhere.

I am grateful to Martine Devos for getting me in touch with some great contributors, but even more for her silent trust and encouragement. It means a lot to me because Martine has been around in the world of Scrum since the early days, and she keeps relentlessly promoting Scrum.

I have worked with many people and organizations in my years of Scrum. I have seen people come and go. I thank Hans Lindhout for being an exceptional person in whom I met true business reciprocity and the ability to transcend commercial motives. If only there were more like him.

No fewer than 68 practitioners expended the effort to write one or more essays about Scrum for you. We did not invite them for their titles, ranks, or positions. We invited them because they have valuable insights to share with fellow practitioners like you. I thank every single one of them.

I thank you, reader, for buying the book, but even more for employing Scrum and for sharing and spreading how you make use of Scrum in addressing your specific challenges. Keep being an inspiration to other Scrum practitioners.

This book would not exist without the incredible team of O’Reilly Media. A big thanks to all involved, and especially to Chris Guzikowski and Ryan Shaw for initiating this endeavor and to Corbin Collins for sustaining it.

Enjoy reading, and...keep Scrumming.

— Gunther Verheyen, independent Scrum Caretaker
Antwerp, Belgium

O’Reilly Online Learning

Note

For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.

Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, please visit http://oreilly.com.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

- O’Reilly Media, Inc.

- 1005 Gravenstein Highway North

- Sebastopol, CA 95472

- 800-998-9938 (in the United States or Canada)

- 707-829-0515 (international or local)

- 707-829-0104 (fax)

You can access the web page for this book, where we list errata and any additional information, at https://oreil.ly/97Things_ScrumPractitioner.

Email bookquestions@oreilly.com to comment or ask technical questions about this book.

For news and more about our books and courses, see http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

Part I. Start, Adopt, Repeat

Chapter 1. Five Things Nobody Tells You About Scrum

Marc Loeffler

You’re thinking about transforming your world of work by starting to use Scrum. Here are a few things nobody told you about Scrum before.

1. Scrum Will Not Solve Your Problems

Some people hope that Scrum will magically solve their problems, as if it were a silver bullet. But Agile processes like Scrum are more like a mother-in-law looking over your shoulder all the time: they point out all your problems and mistakes, making them transparent. In the end, you have to solve them and do the hard work yourself.

2. Scrum Offers No Benefits When You Only Follow the Process

I have seen teams that did Scrum exactly by the book. They had daily stand-ups, Sprint Planning meetings, Sprint Reviews, Retrospectives, and even Product Backlog Refinement meetings. However, the benefits they reaped from Scrum were minor because they missed the point that Agile is more about being than it is about doing. Becoming Agile requires a mindset change to accompany the process change. Only by embracing the 12 principles behind the Agile Manifesto and the Scrum Values will Scrum unfold its full potential.

3. There Is No “Scrum Switch”

Sending all your employees on a two-day Scrum certification training is not nearly enough to make you a Scrum company. There is no switch that you can flip to “Scrum” to make your company Agile overnight. Descriptions of the Scrum process make it seem easy, but the opposite is true: adopting Scrum is hard. There is much to learn: maximizing the work not done, eliminating existing meetings, delivering production-ready versions of product every Sprint, tackling tough organizational issues, and more. Yes, you can “switch” to Scrum, but it will be a gradual process — it takes months or even years and is ultimately a never-ending story.

4. Transforming to Scrum Means Transforming Your Organization

Most Agile transformation initiatives start in product development, but they should not remain there. If the rest of your organization happily ignores the initiative, it’s like planting a flower in the desert: it will slowly die. There is no way to introduce Scrum without transforming the organization, in whole or in part. If you are not ready to face that, you are not ready for Scrum.

5. Scrum Is Not Faster

Even though the term “Sprint” implies that Scrum is fast, reset your expectations, at least at first. If you want to have production-ready releases at the end of every iteration, you won’t be able to deliver more in the same amount of time. Scrum will actually help you decrease your time to market, but in different ways:

- Scrum is about gradually increasing the work not done. Focus on what your customers really need rather than building cluttered products that nobody knows how to use with features nobody needs. This, of course, leads to shorter (and clearer) Product Backlogs and faster delivery and thus ultimately to a better time to market.

- Scrum is about building in quality right from the beginning. It will help you create room to focus on creating innovative features rather than wasting time and energy on everlasting bug fixing. Also, the time you’ll need for maintenance will decrease tremendously.

Chapter 2. Mindset Matters Much More Than Practices

Gil Broza

Do your Daily Scrums feel like status meetings?

Do managers and stakeholders treat the Product Backlog as a project plan?

Does the Scrum Master mostly manage tasks and ensure process compliance?

If you’ve answered yes to these questions, let me take a guess at other symptoms of your Scrum. Team retrospectives don’t yield much improvement, members collaborate little, and there is no shared, solid definition of “Done.” If yours is a software development team, their automated test coverage is low, they refactor code superficially (and rarely), and deploying to production involves a lot of planning and caution. While you seem to be following the practices, you’re probably not experiencing much agility. How can that be?

To understand the situation, we need to know why Scrum Teams use particular practices, meetings, roles, and artifacts. Let’s first see what principles are at play when those tactics are used effectively.

Consider the Daily Scrum. It’s most effective from an Agile standpoint when team members collaborate and self-organize in order to get to Done on work that matters. They feel psychologically safe to be transparent and to participate fully and honestly.

Product Backlog is the ordered master list of potentially valuable work. When used as such, this simple artifact focuses the team’s work on meaningful outcomes. They can easily ascertain that they’re being effective and defer many work item–related decisions such as details, splitting, and acceptance tests to the last responsible moment.

The Scrum Master is a servant-leader who helps the team grow into a solid Agile team. They achieve this purpose by creating an environment of safety, trust, and respect and by fostering communication, collaboration, and transparency.

Scrum implements the above-mentioned principles (and a few others) because they support the four Agile values: adaptation, frequent value delivery, customer collaboration, and putting people first. People embrace these values — “optimize for them,” or have them guide everything they do — when they believe that’s how they’ll reach their objectives. Values and principles, along with beliefs, are the three elements of mindset.

When an organization adopts Scrum, it already has some mindset in place. While organizations have different starting points, their mindsets bear some similarity, which we might characterize as “traditional.” Their values tend to include: get deliverables right the first time, commit early, deliver on time and on budget, and follow standards. They act on those values with such principles as: plan the work and work the plan, limit change, and require sign-offs. They determine work centrally, have “resources” (people) hand off work to one another, and maximize their utilization. Pre-Scrum, they implemented these principles with such tactics as project plans, percent complete, frequent status meetings, and code freezes. What happens when such an organization replaces its existing tactics with Scrum tactics without changing its mindset to the one that gave rise to them?

Plan the work, limit change, and maximize utilization make the Daily Scrum a status meeting that ensures that everyone’s loaded; determining work centrally makes it a series of one-on-one exchanges with the Scrum Master. And, since safety and transparency don’t magically appear as a result of teams standing up daily, people will give lengthy accounts of busyness in answer to, “What have I done since yesterday?” and be reluctant to answer, “What’s in my way?” with, “I’m stuck and need help.”

Similarly, an organization’s mindset will color its use of any Scrum practice, role, meeting, and artifact. The further that mindset is from the Agile one that underlies Scrum, the more it waters down the Scrum tactics, leaves team members confused and disenchanted, and reduces actual agility. To achieve real agility, take on the mindset — it matters much more than practices.

Chapter 3. Actually, It’s Not Really About Scrum

Stacia Viscardi

Scrum is a seemingly simple creation that tells us how to run Sprints, create burn-down charts, and define “Done,” among other things. You’ll recall reading about Scrum phrases like, “Scrum is easy on the surface but difficult to implement.” That is because, on the surface, the Scrum façade is simple, like a perfectly lined-up row of bricks. Dig a little deeper, however, and find the gnarly, twisted roots of managing complex and chaotic situations, the cornerstone of people and motivation, and remnants of Lean foundations. They are like ancient aqueducts running under a modern street. Scrum is ultimately a balcony from which we may view reality, whatever it might be, so that people can make higher-quality decisions based on a newer and improved version of that reality.

I tweeted some time ago that “Scrum is a system integration test to see if it’s possible for an organization to deliver value in a Sprint. That test reveals the system’s failures, or impediments, that we then must go and fix.” These “bugs” — bumps in the road, impediments — hold the key to what constrains an organization’s ability to deliver what really matters: functionality to make its users, customers, and/or market happy.

All of a sudden, you go and implement Scrum, this exposer of reality, this big test, and it’s no surprise that you encounter some backlash. Just like in waterfall projects, developers are reluctant to hand over code to the testers after the dreaded “code freeze” milestone. Teams and organizations are reluctant to learn what they may discover when they hand over the reality of the situation to the transparency of this test called a Sprint.

Practicing Scrum is also made difficult by its impact on the decision-making structure in an organization. Now, a Product Owner owns the what and the why, the Development Team owns the how and the how fast of delivery, and a Scrum Master is the facilitator and the “revealer of impediments.” These roles and simple mechanisms were created so that complex projects could be conquered one Sprint at a time and to “make software development a profession again,” wherein people could be trusted and respected and thus could explore solutions and ultimately feel proud of their work. Scrum is a framework that was created with people in mind, first and foremost. This is inherent in its five values and is often difficult for traditionally minded managers to grasp when they falsely believe in methodology as the “breaker of chains.”

This is why I say it’s not really about Scrum. It’s about using a framework to discover what was not known before. So, get started and adapt to what is revealed to you. Use the boundaries of prioritization, time-boxing, and roles to help the team and organization understand what is discovered. People’s fear of failure and the unknown sometimes makes it difficult to do the right thing. An organization doesn’t readily embrace its failures, and it is my hope that, over time, by using Scrum or any empirical method, they’ll improve at doing so as an essential part of a journey of discovery.

Chapter 4. Scrum Is Simple. Just Use It As Is.

Ken Schwaber

Scrum is a mindset: an approach to turning complex, chaotic problems into something that can be used. Jeff Sutherland and I based it on these pillars:

1. Small, self-organizing, self-managing teams

2. Lean principles

3. Empiricism, using frequent inspection and adaptation to guide the work of the teams to the most successful outcome possible

The Scrum Guide is a body of knowledge that explicitly defines what Scrum is (and, by default, what it isn’t). The Scrum Guide doesn’t tell you how to use Scrum, how to implement Scrum, or how to build products with Scrum.

People learned what Scrum was and how to use it by taking courses, going to conferences, reading books and blogs, etc., but primarily by trying to create useful things from visions, concepts, and desires using their understanding of Scrum. As they went at it, Scrum started to make sense. Scrum helped them manage outcomes. But, when people tried to use Scrum, they learned that the difficulty of Scrum was getting a shared understanding of what was desired, what was possible, and what their skills would allow them to create and to work together to do their best.

In 2009, I recognized that we had broken the waterfall mold. People understood (largely) that our “agile, lightweight” approach worked and was appropriate for the emerging complexity in the world. However, just like the telephone-tag game, there were many interpretations of Scrum. Sometimes this was because of poor communication, inadequate mentoring, or other commercial reasons. People who felt that Scrum would tell them how to build a product to solve their needs felt that Scrum was weak because it didn’t explicitly tell them how.

Exactly. As I’ve often said, Scrum is easy. Solving problems with Scrum is very hard.

So, in 2009, when I founded Scrum.org, I wrote a definition of Scrum. This was short but retained all of Jeff’s and my important thinking and learnings. I made sure that it retained Scrum’s identity as a framework and eschewed inclusion of opinions, context-dependent practices, and anything that constrained it to only certain applications. A framework, not a methodology.

This was the first Scrum Guide, and it was the definitive body of knowledge. Anything not in the Guide or contrary to the Guide was not Scrum. Jeff Sutherland joined me to refine, sustain, and maintain it.

The Scrum Guide was created from Jeff’s and my work and the work of everyone else who had tried to use Scrum. We have adjusted it since then. The Scrum Guide has no commercial purpose other than to offer a litmus test of what Scrum is. Jeff and I are indebted to the people who have translated the Guide and to those who help us sustain it.

Remember: Scrum is simple. Stop worrying about polishing it up so it’s perfect, because it never will be. Anyway, there are far too many complex, chaotic situations in our world that you’re skilled to help others address. We do not need to waste our time staring at our belly buttons.

Chapter 5. Start with the Why of Your Scrum

Peter Goetz
& Uwe Schirmer

“Is this correct according to Scrum?” is a question that we get asked frequently. It usually follows a description of a concrete team practice, and the person asking wants to know if they are applying Scrum correctly (i.e., according to the Scrum Guide).

Although the question is valid, we try to understand why it’s being asked. Teams and organizations often focus on the mechanics of Scrum and forget about their real purpose, which is usually to generate and increase value for their customers, their stakeholders, and themselves.

Don’t get us wrong: the Scrum Guide is important to us. It describes the core elements for solving complex-adaptive problems and how they play together. We take it seriously, as it helps us focus on solving our problems collaboratively and creatively — something that goes beyond just reading and applying the Scrum Guide.

There is one reason for Scrum to exist: “delivering a potentially releasable Increment of ‘Done’ product at the end of each Sprint”. All the elements in Scrum support this. The roles divide and share accountability for the people involved in the work. The artifacts create the minimum transparency needed to iteratively and incrementally deliver a releasable Increment. And the events are opportunities to inspect and adapt according to the information collected in the artifacts and create a rhythm of feedback in various areas of interest. This rhythm improves the Scrum Team’s flow of work. The Scrum Values describe a shared mindset that is extremely helpful when continuously reviewing and improving our way of working together.

You can follow the rules as described in the Scrum Guide mechanically. You can appoint a Product Owner, Scrum Master, and Development Team. Install a Sprint and invite the team (and sometimes stakeholders) to the events. Set up a tool for Product Backlog and Sprint Backlog management and tell the Scrum Team to get started. If the why behind Scrum isn’t understood and lived, no real improvements will occur. The Scrum Team might even become annoyed by this new game, as they don’t see the point behind the rules. Worst case, they get burned out by the stress that those new elements create compared to their old way of working.

We therefore suggest a different approach. We encourage organizations to first talk about their challenges and where their current strategy to solve them isn’t helpful or needs to be improved. We can then think about ways to overcome those limitations and explore how Scrum might help. Only then does it make sense to start introducing Scrum.

Two questions should be the North Star in the ongoing journey:

1. Are we able to deliver a valuable and releasable product Increment each Sprint?

2. How can we improve our way of working together?

These questions shift the focus away from the mere mechanics of Scrum. We learn how to use them against clearer goals and problems. We will improve our skills and tools continuously to progress toward those goals. This will increase our motivation and lead to more happiness and a more humane workplace.

And — most probably — we will still be working according to the Scrum Guide. Not because the Scrum Guide says so, but because it makes sense.

Chapter 6. Adopt Before You Adapt

Steve Berczuk

Scrum is a fairly minimal process framework that you adapt to work best for your team. Sometimes, teams adopting Scrum attempt to extend the idea of adaptation and “adapt” the Scrum process so that it’s simply a veneer atop the existing (often traditional) process. Adaptation works best once the team has internalized the principles and values of the Scrum process. Gaining an understanding of a different way of working takes practice and experience.

A common example of premature adaptation during Scrum adoption is that a team will look at the Scrum events and decide that they won’t work for them. Sprint Planning meetings get shortened or don’t include the whole team and result in Sprint Backlogs that contain more work than what past experience has repeatedly shown the team can handle. Daily Scrum meetings become status meetings — or worse, other status meetings aren’t removed from the schedule. Sprint Review and Retrospective meetings are rushed or get skipped. In short, you might have events with the official names, but they’re not informed by Scrum values. This is a bad idea, as it will at best result in the team gaining no value from Scrum and at worst result in worse performance as the pretend or hybrid approach adds unnecessary overhead.

The reasons why this happens vary from organization to organization, but two factors almost always come into play. First, any change is hard and requires work and learning, and in times of stress, people easily revert to old, familiar behaviors. Also, Scrum is easy to learn but difficult to master. There is more to Scrum than simply organizing some of the Scrum events. Everyone on the team needs to be disciplined about making sure that they are doing what they can to help the process work well.

Adopt Scrum practices before you adapt them. The practices will help you understand and internalize the new way of working. Resist the temptation to customize Scrum until the team has a sense of how the practices add value and support Scrum principles. Follow Scrum “by the book” (literally — either the Scrum Guide, or if you want more guidance, one of the many excellent books on Scrum) for three to five Sprints, at least. And be certain to allow time for Sprint Retrospectives. Use the Retrospectives to explore how the process affected collaboration and delivery, thus providing an “a-ha” opportunity as people see the behaviors the Scrum framework enables.

If you truly believe that you understand Scrum values, feel free to adapt out of the box. Since Scrum is a very different way of working than most organizations are used to, most teams need practice to understand the value of the practices. While not essential to successful adoption, having a good baseline to adapt from is best.

Chapter 7. Regularly Revert to the Simplest Thing That Might Work

Todd Miller

To simplify yields a richer result.

Yvon Chouinard[1]

Many years ago, I left a job as a Scrum Master to become a Scrum Master at another company. I was leaving an awesome Scrum Team. They worked well together, had grown in their use of Scrum, had implemented practices that worked wonderfully, and were building a great product. But I was ready for a new challenge.

I became part of a new Scrum team that was going to build a new product. In our first few days as a team, we spent quite some time discussing Scrum. It helped us grow a common understanding and start using the same language while getting to know one another. Everyone was engaged and shared enthusiasm in leveraging Scrum to build that new, complex product.

Meanwhile, there was enough Product Backlog for us to feel comfortable starting our first Sprint. Prior to that first Sprint, we would have a one-day team kickoff. I had meticulously planned an agenda for the day, including sharing and promoting practices that I strongly felt would work for us. I wanted to carry insights and lessons from my previous Scrum Team forward to this team. I went to great lengths to put together and facilitate a day of intense collaboration.

The first sessions went quite well. The Scrum Team discussed the current Product Backlog, making sure the work ordered for the first few Sprints was well understood, and crafted a definition of “Done” that was more than good enough to get going. But when I introduced the next topic — the creation of a team working agreement — things started taking a strange turn. Team members started asking why this was necessary. After all, our first week together was going well. As I sensed the tension in the room growing quickly, I canned the idea and went on to the next item on the agenda. Much to my surprise, I met with similar resistance, and — worse — it increased with each point I tried to work my way into.

Then, suddenly, I was asked a question I came unprepared to answer: “Why are you making things so complicated?” My only response was: “These practices worked for me at my last job.” This felt unsatisfactory not just to the team, but even more so to me. It felt uneasy, but I decided to let go of the plan, my ambitions, for the kick-off day and declare us ready for the first Sprint.

While I initially felt puzzled, the situation actually turned into a great lesson for me. In the complex domain of work, what works in one situation is not guaranteed to work in another. My new Scrum Team went on to do great things and discovered and changed practices along the way.

This experience still works as a personal reminder that what matters most in complex work is empiricism: the process of frequently inspecting and adapting upon transparency. Empiricism in Scrum stretches beyond just discovering product capabilities to the practices you apply within your Scrum. This doesn’t just apply to new Scrum Teams. Existing Scrum Teams often find themselves surrounded by so many complementary practices that it negatively impacts their ability to look inward (inspect), change direction (adapt), or make things known to everyone (be transparent).

Make sure to frequently validate whether the practices you are using in your Scrum still make sense and are optimizing your act of empiricism rather than impeding it.

[1] Yvon Chouinard, Let My People Go Surfing: The Education of a Reluctant Businessman (New York: Penguin Books, 2016).

Chapter 8. Will Scrum Work for Multi-Location Development?

Pete Deemer

(Spoiler alert) Yes! Scrum works great for multi-location development! However, Scrum is not the silver bullet that makes it magically work.

Scrum is a very simple set of practices that, together, produce a high degree of transparency, showing us the reality of our situation more clearly. Scrum creates transparency around what we are able to do in one to four weeks. Scrum enables us to see clearly the quality and rightness of what we produced and the quantity we were able to finish. Scrum confronts us with the effectiveness of our practices, including the patterns of dysfunction and the mistakes we are making. Most importantly of all, Scrum gives us the opportunity to use these insights to improve in the next Sprint. So, the statement, “Scrum works great for multi-location development!” means that Scrum is great at clearly showing us all the dysfunctions and inefficiencies we’re experiencing. And distributed projects tend to have a lot of those!

At its heart, software development is an activity of taking the product of human thought and logical reasoning and making it repeatable in the form of code. For a team to develop software, their ability to commune their thoughts through shared understanding, collaboration, and communication is the key driver of output. In multi-location projects, this activity is made most difficult by the myriad forms of separation faced: physical separation, time zone separation, cultural and language separation, and the difficulties that come with language and cultural barriers. The first Sprint that a multi-location team completes is likely going to be a rich circus of dysfunction — and the likely conclusion is going to be that “this just isn’t working.” That realization is a critical first step on the path to success. The next step is to enumerate everything that did not work well and formulate actions in the next Sprint to make them work better.

For example, it could be that in the first Sprint, the product Increment didn’t meet the definition of “Done.” In the Sprint Retrospective, the Scrum Team identifies the major root causes, such as lack of a clear common understanding of the Sprint goal, lack of communication within the team leading to a lack of coordination, and lack of trust among the team members. As a result, actions are taken on each of these in the second Sprint (for ideas, see the Distributed Scrum Primer), and that Sprint produces slightly better results. As often happens, in the subsequent Sprints, other sets of issues become visible, and whole new sets of improvements are identified every time. The Scrum Team gradually evolves, Sprint by Sprint, to a better and better way of working.

Will Scrum “magically” make every distributed Scrum Team effective? No. In fact, no methodology has this ability, although some make that promise. The radical innovation of Scrum is its rejection of the idea of a methodology-based path to success. Instead, Scrum is a simple framework built around inspection and adaptation that creates continuous transparency around the unique environment and characteristics of a given situation while creating the opportunity for improvement. The only question is how much bold action the team is willing and able to embrace!

Chapter 9. Know the Difference Between Multiple Scrum Teams and Multi-Team Scrum

Markus Gaertner

When applying Scrum to a product with more than one Development Team, there is little guidance in the Scrum Guide, which for the most part seems focused on one-team Scrum. The only hint you get is in the Product Backlog section:

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

We learn that, with multiple teams, we are advised to still use a single Product Backlog. Nothing is mentioned regarding the roles of Product Owner, Development Team, or Scrum Master other than “multiple Scrum Teams” working on the same product.

But how do you decide on priorities? If we take the Scrum Guide literally, there could be more than one Product Owner in each Scrum Team working on that product, or it could be the same person for all the teams involved.

Generally, this is the distinction between “Multiple Scrum Teams” and “Multi-Team Scrum.”

Multiple Scrum Teams

“Multiple Scrum Teams” typically holds that each Development Team has a Product Owner, although there is a single Product Backlog. That means that, potentially, different people in the role of Product Owner need to coordinate with one another regarding their individual priorities and come up with the most valuable items to be worked on for the product.

Sometimes this setup seems connected to having different specializations in the Development Teams, where different teams work only in specific functional product areas. This works well if the workload on each of the specialist topics is evenly distributed across the different teams — and will stay that way for the near future. If that is not the case (which is highly likely), then one team might end up working on lower-priority, and therefore lower-value, work for the product, just because that type of work is their specialty.

This setup generally also reduces the transparency and insights into the whole product. Not only is the in-depth knowledge about the product split across the different Scrum Teams, but also across the different Product Owners. After development on particular features has finished, additional coordination is needed on the different partial results of the product in order to integrate them into a whole product that can be released to the customer and user. Unfortunately, a “Multiple Scrum Teams” setting provides little incentive for cross-team collaboration, since everything will be taken care of by the additional coordination overhead the setup produces.

Multi-Team Scrum

In a “Multi-Team Scrum” setting, there is not just a single Product Backlog, but also a single Product Owner who works with the multiple Development Teams. The sole Product Owner makes product-wide decisions that are fully transparent via the single Product Backlog and the product versions created.

This setting demands a cross-functional approach from the teams. Specialization in the customer domain may still exist but will have to dissolve once priorities and demands start to shift. For example, one team working on accounting functionality will have to shift from accounting features to another type of feature if there are no longer any accounting features as the highest priority in the Product Backlog.

This setting, therefore, lays the demand for coordination with the teams themselves. They have to make sure they deliver an integrated product Increment at the end of every Sprint.

Depending on where you start, this may result in a steep learning curve. It is worth it.

Chapter 10. What Will You Define as “Done”?

Gunther Verheyen

Teams and organizations want to capitalize on business and market opportunities. Scrum offers them this option by assuring a “Done” Increment — i.e., a releasable version of product is available no later than by the end of each Sprint. As a Sprint takes no more than four weeks (and often less), the organization can be faster to market, win an opportunity, and generate value.

Without making transparent what Done encapsulates, Scrum cannot be applied effectively. Via a definition of Done, everyone understands what Done means. This is vital when considering the opportunistic value of the product functionality offered in an Increment. The definition of Done also provides crucial clarity for the Development Team when forecasting work deemed feasible for a Sprint. Throughout a Sprint, the definition of Done guides them in assessing whether work on Product Backlog items and the product Increment is complete.

A professional organization only releases Done Increments; Scrum professionals adhere to the definition of Done. Always. No “undone” work is part of an Increment. No undone work is put into production. Ever. Committed professionals reflect on ways to improve product quality as reflected in the definition of Done.

Many teams across the world seem to be unable to create Increments of product that are actually releasable. Code is entered, and potentially tested, within a team. But the actual Increment remains scattered and hidden in long-lived branches. Or the work delivered at the end of a Sprint still needs to be integrated with the work of other teams. Or — even worse — it needs to be shipped to a different department for that purpose. In those cases, Scrum reveals that there are important organizational dysfunctions impeding the organization’s agility. There is a substantial amount of “Undone Time”: the time it takes to go from an undone piece of work to a Done Increment. This wasteful delay kills the option of opportunistic releases.

The purpose of a Sprint in Scrum is not just to result in a piece of work that can be shipped to another team, functional group, or department. An Increment is expected to be in a usable condition, ready for production. An Increment should be, at minimum, in a production-deployable state. The definition of Done describes that state.

Most often, teams include in their definition of Done the development activities to be performed for an Increment to be considered “releasable”: pair-programmed or code-reviewed; unit-tested; user acceptance–tested; integration, regression, and performance–tested. These are great development standards that enhance transparency, but are they also a great definition of Done? Imagine any non-software industry. Can you imagine “quality” being expressed in terms of the machines, tools, and practices used? Is this not how to create quality, rather than defining quality itself?

Quality is optimally defined through the qualities the product should exhibit. A Done product in Scrum is not just a product on which rigorous, proper development standards were applied. A Done product exhibits the product qualities your organization envisions: the product’s interior construction and the organizational and maintenance standards and conventions respected, with valued functionality only and living up to all applicable usability standards.

Capture in your definition of Done more than the work needed to produce a releasable Increment. Shift it toward guiding you in creating valuable Increments.

Chapter 11. How I Learned to Stop Worrying and Start Using Scrum

Simon Reindl

This story comes from my first Scrum team, which was around 2006. We were building a new system that was complex and challenging, involving scanning and processing documents to be managed from a call center.

Many of the team (including me) had moved on from a project that used many Extreme Programming practices. We were looking to use Scrum to improve our delivery.

We eventually started to sprint, working on a three-week cadence. We had an automated environment that we envisioned would generate the installation files and scripts, copy them to the test servers, and install and run tests overnight. This was pretty good going — or so we thought.

All of this was being done using very new technology, and that technology was a cornerstone of the architecture and the product strategy. A few Sprints in, and things were starting to get tough. We had completed a lot of the foundational work, and now we were trying to include a piece that was not integrating properly. The local expert on our technology wasn’t available in the crunch time we still had in the Sprint leading to the Sprint Review.

The Sprint Review arrived, and we hadn’t been able to add and integrate the piece we envisioned. Actually, we didn’t have anything to show. The last build was broken and wouldn’t even install. It left us with nothing tested, and as a team, we had no confidence to share what was available. Our senior stakeholder, who was the manager responsible for the call center team, was present and had high expectations.

As a team, we knew that we didn’t have an Increment. And that was what we told everyone present. We said we had nothing to show, as it didn’t meet our definition of “Done.”

There was quiet, a tense silence, as there was an expectation for at least something to be shown. We talked about our goal for the Sprint, how our plan turned out, and our challenges. We described what Done meant to us and that the product was not in that state. We discussed our plan to get to a working product version and the next features to bring in.

Having patiently listened to us, we were then told in a very clear way that the project would not continue if we were unable to build a product that worked, and that that something had better be seen soon.

The stakeholders left.

The Sprint Retrospective followed.

There was huge tension as we gathered — we were angry, frustrated, and disappointed. We had spent weeks of hard work, and not only was there nothing to show, we were now threatened with the cancellation of further development. The event was heated, voices were raised. There were accusations, complaints, and arguments. Fortunately, following all that, we had a very focused discussion. Not one of us wanted to be in that space again. Yet there was a sense of fear and panic that our project would be stopped.

At the Sprint Review of a few Sprints later, we had this new feature that was completed, and we were excited — it was pretty neat. We shared it with the same senior stakeholder.

“Can that go live?” she asked.

“Yes, it only requires your authorization, as it needs exec sign-off to make it through the process.”

“Please make sure that it’s live by 9 A.M. tomorrow. That feature is worth real money to my team!”

Because the item was truly Done, we released it in production in no time. It soon turned out to be one of the features that was most loved by the team using the product, and it made a happy manager after all.

That is how I learned to stop worrying and start using Scrum.

Part II. Products Deliver Value

Chapter 12. Successful Projects That...Fail

Ralph Jocham
& Don McGreal

Success is in the eye of the beholder, and depending on whether that beholder thinks in terms of projects or products, the measure of success could vary profoundly. A project is successful by being on scope, on time, and on budget, while a product is successful when it delivers value: happy customers, increased revenue, lower costs, and so on.

In the long run, what is more important for a company? A successful project or a successful product? The answer is rather obvious, as the product is what delivers actual value to customers. Peter Drucker, a prolific author and leader in management thinking, was very direct when stating in his book, The Practice of Management (HarperBusiness, 1954), “The only reason for management to exist is to create customers.”

Here we see the project management triangle, a well-known practice in project management, with the scope being a contract, the schedule a promise, and both being unified through one budget. In this “inside-out” approach, success is measured by internal elements that often drive how outside stakeholders will have to use the product, not always for the better.

On the other hand, a product has a clear focus on customer value. As Almquist, Senior, and Bloch point out in “The Elements of Value”, it can come in many shapes, whether it saves time, connects people, reduces anxiety, provides access, or motivates people.

This is clearly a different customer-first view based on continuous feedback with empirical product development and delivery. This is known as an “outside-in” approach, where success and progress are measured by outside elements that drive what a team does internally.

Understanding that the product mindset trumps a project mindset is only half the battle. Beneath layers of leadership and interconnected systems, teams and organizations may find it hard to even identify what their products are.

A product does not have to be a physical good — it can also be a service. As long as there is a producer (people doing the work) and a benefiting customer (people consuming the work), there is a product. In general, a product solves a customer’s need. This should be the leading motivator. If done well, the customer’s needs are met (happiness: leading) and they consume more of the product. Higher revenue and lower cost follow (profit: lagging).

To sum up, start by defining your product. Who are your customers and what are their needs? What value propositions do you offer that meet their needs? Form a hypothesis around this potential value and identify outside-in measurements that support it. Validate as progress is made, keeping in mind that moving the needle on these outside-in metrics is only possible with an actual release into the hands of the customer.

Chapter 13. Answer This Question: “What Is Your Product?”

Ellen Gottesdiener

Alice, wandering in Wonderland, said it best: “If you don’t know where you are going, any road will get you there.” This certainly applies to software development teams. Even some of the best Scrum Teams can’t answer the simple question, “What is your product?”

Scrum is about continual discovery and delivery of products. For a product to be successful, it must be desirable to customers, viable for the business, and feasible for technologists to build and support. Notice the subject of that sentence: product. Not knowing what your product is manifests itself in numerous ways.

As intuitive as Scrum might be, the Product Owner needs to provide guidance and product oversight. The role of a Product Owner isn’t easy. Failing to define the product leads to all sorts of issues, ultimately impacting team satisfaction and product outcomes.

A plethora of Product Backlogs exist, often with the same customers and the same domain. They overlap and have items that conflict with one another. Moreover, functionality can be duplicated among multiple “products.” Coordinator roles such as release managers and project or program managers are introduced. The customer experience for completing an end-to-end value stream using the product experience is clunky, laborious, and abrasive. Product Owners struggle to prioritize and provide focus. Local optimization exists, resulting in decisions, actions, and structures that impede achieving overall organizational goals. These are but a few of the maladies that come from not having product clarity.

Scrum Masters can facilitate the important work of helping Product Owners, the Development Team, and business stakeholders define their product. Apply these three product definition principles:

Principle 1: Adopt outside-in thinking

Define your product from the perspective of customers — both users and choosers. Users interact directly with the product to obtain some benefit or to solve a problem. Choosers are those who make buying choices. It isn’t unusual for Development Teams to create products based on their — or their Product Owner’s — inside-out bias. Outside-in thinking, on the other hand, is both humbling and enlightening. It allows the entire Scrum Team to approach product work with empathy and curiosity.

Principle 2: Take the long view

Projects come and go. Successful products live a long and healthy life. Products evolve and morph through all stages of their life cycle from introduction, to growth, maturing, and then decline. Products benefit from continuous discovery and delivery. New technology adoption and feature development are critical to improving your product’s value proposition. This principle reduces the need to create separate products. Innovations improve your product’s business viability, customer experience, and product quality.

Principle 3: Define the product as broadly as possible

A broadly defined product gives a Scrum Team more product options, simplifies communication, clarifies roles, and forces prioritization. Refraining from narrowly scoped products enables organizations to optimize people and resources. Broadly defined products have many benefits:

- Organizational systems optimization ensures that high-level goals are met.

- Backlog management and prioritization become simpler to manage.

- Decision making is streamlined.

- Strategic planning and roadmapping become more straightforward to define.

- Customer and organizational communication become clearer.

- The product influences your organizational structure.

Product development with Scrum requires clear product direction. Establishing a shared, consistent, and coherent answer to the fundamental question, “What is your product?” offers a huge benefit. Knowing what your product is provides the necessary foundation to deliver successful products with Scrum.

Chapter 14. Scrum: Giving the Steering Wheel Back to Business

Rafael Sabbagh

In the traditional approach to software development, the promise was that an agreed scope would be delivered within a certain schedule and budget. The combination of scope, time, and budget was the traditional definition of “success.” The delivery date was usually determined after decomposing the scope into small, executable bits of work, estimating them, summing them up, and then adding a generous buffer (a.k.a. contingency). If you were lucky, scope was adjusted as delivery date or budget were fixed. The resulting plan included all work that needed to be performed in order to converge it into the final deliverable, leaving the team to wade through a sea of tasks. For the major part of the duration, actual progress was rather unclear, but by ticking off tasks from the list, all signals were kept green. Closer to the final date, one would inevitably find out about problems that prevented the actual release at the expected date.

It was an “all-or-none” approach that was very risky! Not only did it leave little room for change — there was very little guarantee that the promised result would actually be ready by the promised date.

In this traditional approach, Business not only had no control over the time to market of their products, but they didn’t even have realistic insights into whether product would be releasable (or not) down the road. Business was clearly not at the steering wheel.

With Scrum, we build a product in short cycles — Sprints — and each Sprint is supposed to generate a releasable Increment of that product. The focus is not simply on fulfilling planned tasks, but rather on converging frequently to a “Done” version of the work, which can be released to its actual users, delivering actual value. In each Sprint, we tackle what is believed to be the most important part of the problem the product needs to solve at that particular time. With each Sprint, we make a hypothesis about what is most valuable for our clients and users based on business information and priorities expressed through the Product Owner. We no longer have to do that for a long-term plan, ignoring the many unknowns.

Scrum helps us shy away from the traditional all-or-none black box. Each Increment represents a safe step of work done, offering us not just a delivery opportunity, but also allowing us to get feedback on something real early and often from customers and other stakeholders. We gradually improve our understanding of how the product is actually being used. Analytics tools, heatmaps, A/B tests, counters, and many other tools are available to aid us with it.

All that feedback helps the Scrum Team to create, Sprint by Sprint, product versions that solve the next most important parts of the problem. Progress in Scrum thrives on adapting to feedback instead of following a plan.

It makes sense for Business to deliver early and regularly. No later than by the end of a Sprint is a releasable version of product available. Instead of having to wait and hope for some major release (like in the traditional approach), through Scrum, Business is regularly offered the opportunity to deliver. Releasing, or not, now becomes a business decision. It may be done by the end of the Sprint, it may encapsulate the accumulated result of a few Sprints, or it can be done even within the Sprint.

Time to market is now a business decision, where it belongs. Scrum gives the steering wheel back to Business!

Chapter 15. Beware the Product Management Vacuum

Ralph Jocham
& Don McGreal

Most companies have a vision, an idea about market trends, and strategies to attract new customers as well as to retain existing ones. Most companies using Scrum have a capable workforce experienced in creating, releasing, and sustaining products. In theory, great business strategies executed by great Scrum Teams breed success. In practice, this is rarely the case.

A closer look reveals how a main issue lies with the Scrum Masters’ approach to Scrum. Many Scrum Masters turn their focus inward to the Development Team exclusively. They give priority to team cross-functionality, team building, technology choices, development process, and protecting the Development Team from outside influence. These are important and noble causes, but only addressing Scrum as a team process and overlooking the actual connection to the company’s vision and (product) strategies results in an organizational disconnect. We refer to this disconnect as the product management vacuum in our book, The Professional Product Owner (Pearson, 2018).

All vacuums have an innate tendency to fill themselves. If not actively addressed, the product management vacuum tends to get filled with documents, milestones, project charters, and other process artifacts. This creates an activity-driven, document-based, sequential process with many handoffs, resulting in loss of time, understanding, and quality. This practice has process compliance as its focal point, creating the fallacy of seeking to answer the question: are we on time and on budget? This kind of output measurement leaves aside customer value by ignoring the outcome, as each manager and each team is gauged against their ability to comply with the plan (and the bureaucracy).

To avoid a disconnect between management and the Development Team when planning a new product or working on product enhancements, the Scrum Master needs to work with the Product Owner to make sure that the product management vacuum is filled wisely, with the three Vs: Vision, Value, and Validation, as shown in the following figure.

A product needs a Vision that is clear about solving a customer need. If done well, this will rally stakeholders and the Development Team around a product strategy, increasing engagement and creativity and emphasizing Value.

In Scrum, Value is only determined in the actual marketplace. It requires the product to be released into users’ hands for actual, real-world work. Everything beforehand is hypothesis-driven inventory — a guess. Value is therefore rather subjective and depends on the ability to quickly analyze and synthesize the feedback. Empirical feedback loops should allow Validation by the marketplace for reasons of transparency, inspection, and adaptation. However, Value also requires a tight collaboration between the Product Owner and the Development Team for both to fully understand the purpose of their work and appreciate each other’s concerns. Scrum Masters should help Product Owners understand that until they release, there is no Value, only cost. Even if the perceived Value isn’t there, that is still good Validation that the strategy should likely change direction. The shorter this feedback loop, the sooner and more often we create Value.

The filling of the product management vacuum is in the hands of the Product Owner, as they function as the catalyst between the company’s strategy and product delivery — a task that will only succeed with the true support of the Scrum Master.

Chapter 16. Scaling Scrum to the Entire Organization with the Flow Framework

Mik Kersten

Scrum has been mastered. Organizations have a broad range of practices, tools, and training to enable them to leverage this powerful way of organizing work and delivery. So why is it that the majority of large organizations have so much trouble extending the benefits of Scrum beyond practices employed by individual teams? Over and over, my meetings with business and IT leaders lead me to the same conclusion: attempts to scale the language and practices of Scrum to the business are failing. Instead, we must connect our Agile practices to the language of the business in order to see Lean thinking applied across the organization.

The barrier between business leaders and technologists is one of both language and culture. Business culture speaks in terms of revenue, costs, and customers. Scrum culture speaks in terms of user stories, iterations, and the customer. One fundamental concept ties both together: the focus on delivering value to the customer. The problem comes from the layer that organizations have formed for translating between the language and culture of Scrum and that of the business. Most commonly, the business side applies the practice of project management in order to bridge the gap. This is a grave mistake.

By wrapping a project management layer around Scrum, we turn it back to a waterfall process, which defeats the purpose of Scrum by disconnecting the Scrum Teams from the business through this layer of indirection and its associated handovers. However, expecting business leaders to directly apply an Agile team’s practices to managing thousands of staff is an equally futile idea. Beyond growing Product Owners to bridge both worlds, we need a new managerial model to connect the way that Scrum works to the business with a language that the business side can understand.

The goal of the Flow Framework is to bring Scrum and Agile concepts to the business while providing a higher level of abstraction than Agile teams work with day to day. User stories and story points are layered over by the four Flow Items: Features, Defects, Risks, and Debts. This translation serves an improved understanding in both directions by forcing the business side to understand the dynamics of software delivery, such as forcing the understanding of technical debt and the need to trade off architectural investment over feature delivery.

Most importantly, rather than measuring or managing a single team’s work, the Flow Framework creates a new organizational layer between the business and the Scrum Teams based on the most important key concept shared by both: the customer. Organizing delivery into product value streams ensures that both sides are aligned around the flow of business value and on removing bottlenecks and impediments to flow. In large organizations, a meaningful product value stream typically requires more than one team to deliver, hence these abstractions should be put in place at the Scrum-of-Scrums levels. By defining, measuring, and managing flow across your customer-centric product value streams, the practices that you’ve grown to know and love will finally help your entire business scale to this new way of working.

Chapter 17. Put Business Value Front and Center

Alan O’Callaghan

The job of a Scrum Team is to deliver the highest possible business value to the customers of the product it is building. In the most fundamental terms, this means the Scrum Team is a business unit, not just an implementation/execution group. As a self-organizing team, the Scrum Team as a whole assumes the responsibility of ensuring that all of its decisions are in alignment with business missions and goals.

The Agile community is well aware that the product is “discovered” throughout the development process. At the beginning, there is hopefully a vision, but not the specific details of the final system. These emerge iteratively and incrementally. There seems to be less awareness that this is also true of the business value enshrined in the product. The specifics of business value also emerge iteratively and incrementally as assumptions are either validated or invalidated. The product vision provides a value compass for the Scrum Team. Each of its decisions can be evaluated against that vision, whether it moves the team closer to realizing the vision or takes them further away from it.

It is primarily the Product Owner role, of course, that gives the team the capability of validating its assumptions concerning the value of its work. The Product Owner is charged with maximizing the value of the product and the work performed by the developers. As a full member of the Scrum Team, the Product Owner will collaborate intensively with the Development Team to achieve consensus, but they also — uniquely in the Scrum Team — have the independent authority to make decisions on business issues. The decision process might otherwise time out before full agreement can be reached. It is, however, a poor Product Owner who relies solely on that authority. The best ones understand that the Scrum Team needs to be seduced by a common purpose if it is to be truly self-organizing.

This means putting the question of business value front and center in your Scrum Team. Product Owners need to get answers to three questions from stakeholders: What is the goal? Why is it important? How will you know when it has been achieved? The answers to the first two of those questions reveal why the product is being developed in the first place. Communicating to the rest of the Scrum Team (and, indeed, the wider stakeholder community) what the most important thing is to be worked on next is fundamental. But the Team will be far more effective if it also knows the why behind the items at the top of the Product Backlog. The third question (“How will you know when the goal has been achieved?”) allows the meter by which value can be measured to be discovered.

The answers to these questions are gathered not just at the beginning of a development initiative, but throughout the process. Things change. While the overall goal is likely to remain stable, and the product vision is less volatile than detailed requirements, change is the one constant we can rely on in a complex world. And change can be distracting. The Product Owner who opens every Sprint Planning meeting with a reminder of what the goal and the vision are and where the latest Increment stands in relation to them, as well as pointing to the items currently at the top of the Product Backlog, is much more likely to keep the team focused on business value than one who does not.

Chapter 18. Product Owner, Not an Information Barrier

Markus Gaertner

Most of the Scrum Teams we see out there in the wild have Product Owners who fulfill the role in such a way that they become a communication bottleneck. They spoon-feed information from stakeholders and subject-matter experts to the Development Team. Whenever the Developers have a question that the Product Owner can’t answer directly, the Product Owner has to go back to the particular expert on the topic, get the answer, and deliver that to the Development Team. By doing so, the Development Team’s speed is limited by the communication abilities of that one Product Owner, pretty much as in the telephone-tag game.

An incredibly effective communicator might fulfill the role of Product Owner well according to this interpretation of the role. Unfortunately, we haven’t seen too many people living the Product Owner role successfully in this way.

Before taking a look at a better approach, let’s look at how companies are getting Product Owners to become such communication bottlenecks in the first place. Most often, it’s driven by the fear that programmers can’t talk to subject-matter experts directly. Companies also fear that these experts might slip additional features into a Sprint if Development Team members speak directly to them or stakeholders, for example, with no Product Owner around. If that happens, functionality might take longer to implement than initially anticipated, or the development might not deliver the Sprint Goal or the work planned for the Sprint. Also, since the Product Owner did not take a closer look at that functionality that crept into the development cycle, the Development Team might be building lower-priority functionality.

While all of this may be true, it usually takes just a few such instances where features are directly negotiated between Development Team members and stakeholders. At the end of every Sprint, the team will show what they finished, and the Product Owner will certainly notice the non-agreed and lower-priority features that were finished. If they then bring that unpleasant surprise up during the Sprint Retrospective, the Scrum Team is invited to find a rule on how to deal with such situations in the future.

So, basically, companies fear a dynamic that will become transparent soon enough in Scrum, and they’ll get the team to come up with a better approach. And what would be a better approach to the role of the Product Owner?

The most important thing a Product Owner brings into a Scrum Team is the prioritization of what’s important to be built next and what can be postponed. Detailing individual Product Backlog items can be done by the Development Team if they have access to subject-matter experts and stakeholders directly. Of course, the Product Owner, and probably also the Scrum Master, should pay attention if this leads to unwanted features creeping into the Sprint. In that case, they can educate team members about the drawbacks this entails and have them present additional stakeholder requests to the Product Owner for prioritization in the Product Backlog next time.

On a final note, I want to add that it is highly recommended that Development Teams know about upcoming Product Backlog entries. In their direct contacts with experts and stakeholders, they can share information about those upcoming features and use that to keep everybody’s focus on the limited scope they are currently implementing. In other words, the more the Development Teams know about future Product Backlog entries, the better. They can help keep future requests for the future. Thus, the Product Owner is well advised to work on the Product Backlog with the Development Team quite regularly.

Chapter 19. Mastering the Art of “No” to Maximize Value

Willem Vermaak
& Robbin Schuurman

Number 10 of the Principles behind the Agile Manifesto is a key phrase for any Product Owner working with Scrum:

Simplicity — the art of maximizing the amount of work not done — is essential.

Over the years, we’ve seen many cramped Product Backlogs, endless walls of stickies, and roadmaps containing years’ worth of ideas. The many Product Owners we meet understand the problem. They all nod in agreement: “Yes, I should have more focus” (there is a reason it’s a Scrum Value!), “and I should keep Product Backlog in a manageable state.” So how come most Product Owners let the Product Backlog become this huge list of user stories?

In a majority of cases, it seems they just can’t say no, or their stakeholders don’t take no for an answer. For every request, there seems to be some reason to say yes, add it to the Product Backlog, and increase the amount of work to be done.

We want to help Product Owners start mastering the art of saying no.

We start by asking Product Owners the following questions: can you explain what type of stakeholders you have? Which ones are very important to you, and which ones should you interact with less? Because, in the end, not every stakeholder is equally important, and Product Owners should not feel obligated to spend the same amount of time with every single one. A way to visualize this is to divide stakeholders into four groups:

- Stakeholders you merely need to monitor (the minimal effort of sharing information in intervals keeps them at a distance).

- Stakeholders you need to keep informed (proactively planning something or sending them information keeps them at a distance).

- Stakeholders you need to keep satisfied (sending them only information that’s relevant to them).

- Stakeholders you need to manage closely. It goes without saying that the bigger this group, the busier you are, so you want to limit the number of people in this group to a minimum (interacting with them frequently).

Next, create a communication strategy for each group (who they are, what their objectives are, the type of messages you’ll send them, and channels you’ll use to send them). Make sure you understand their context and background so you can provide answers relevant to their perspective. For example, give the IT manager an IT answer.

As Product Owners start practicing saying no to their identified and grouped stakeholders, they should keep the following considerations in their minds:

1. Who is asking the question? What type of stakeholder are they?

2. What is the actual question? Do I truly understand what is being asked and why?

3. Intention. Am I going to say yes, no, or maybe (where the latter effectively is also no, but might not be perceived as such)?

4. Say no in a way that relates to the question and/or stakeholder.

5. Listen carefully to whether the stakeholder understood and accepted the no. Is additional information needed? If a discussion starts, decide whether this is the right time to have that discussion. Sprint Reviews are often great opportunities for open discussions.

Act according to the Agile Manifesto and the Scrum Values. Stay focused on your vision and have the courage to say no, but be transparent to your stakeholders about your why. Start maximizing the work not done by saying no!

Chapter 20. Communicating Prioritized Requirements Through the Product Backlog

James O. Coplien

Well, guess what: the Product Backlog is not how Scrum communicates needs to the team; it is neither priority-ordered nor built around requirements. Yet many Scrum teams carry over practices and artifacts from the waterfall world and fail to realize all that the Scrum way has to offer.

Perhaps the best way of thinking of the Product Backlog is as a register for all decisions made between the Product Owner, Developers, and stakeholders. So, first, it is not so much a communication tool as a tool to remember decisions. People write for two reasons: to communicate and to remember. To a first approximation, we don’t use writing as our primary communication mechanism in Agile. We speak person to person. We do write to remember.

Second, it’s a Product Backlog, not a requirements backlog. It is divided into Product Increments that are cogent units of delivery that appear at the end of each Sprint cycle. The backlog is further broken down into Product Backlog Items (PBIs), which are independent units of delivery sized to reduce risk by increasing the frequency of feedback and by reducing leakage. They are usually not the advertised features of delivery but should be thought of as internal divisions of work to reduce risk and mark progress. The focus isn’t on delivering a percentage of the PBIs but on delivering the Sprint Goal. The Product Increment should always deliver a coherent function, which is most often tied to the Sprint Goal. Correspondingly, there are no user stories on the Product Backlog! (Think about it.)

Each of these Product Backlog slices represents some aspect of a deliverable that the Product Owner has envisioned. They represent solutions to be built rather than requirements to be addressed. Yes: we can annotate PBIs with requirements, but the Product Owner who relates only requirements is shirking their responsibility to own the product — not just its requirements. Hence, the catchy title.

Third, the Product Backlog is ordered by delivery — not priority. Mismanaged dependencies are the bane of complex development. By designing the delivery plan around delivery order, the team can easily plan to reduce dependency surprises up front. Further, customers know the order in which they will get things (unless feedback causes everyone to agree to change things), and, in the best developments, know about when they will be getting them. This supports flow through the process at a macro level. Product Owners may of course keep a list of either requirements or Product Increments ordered by priority. It’s just that that list is not the Product Backlog.

This has profound repercussions for the process. In old-style development, the Product Manager would clarify requirements to the Developers, who would design a business solution and create a technical implementation of that solution. In Scrum, Product Owners take business requirements and shape a business solution that follows their Vision and communicate it to the Developers, who in turn craft an implementation using tools and technologies of their choice.

So, when you think “Product Owner,” think Steve Jobs for the iPhone, or Linus Torvalds for Linux, or Lee Iacocca for the Mustang. It’s that person with the Vision — the Vision of the product.

Chapter 21. Why There Are No User Stories at the Top of Your Product Backlog

James O. Coplien

Words mean things. The words “user story” suggest something that is a story and in the user space. The term has come to mean a formatted sentence of the form: As an X, I want Y because of Z. Some Agile folks take that literally and dutifully write stuff in that format. But, more insightfully, Ron Jeffries once correctly pointed out that this shorthand is just an invitation for a future conversation between an end user and a developer. We can breathe a sigh of relief at having restored the possibility of storytelling.

Stories are priceless in understanding end user needs. The Sprint Goal should probably be a potential title or moral of the key user story. But user stories are, so to speak, just the beginning of the story. Perhaps they should be called “User Riddles.” The job of design is to solve the riddle and to deliver an implementation commensurate with the answer.

Scrum follows the Lean practice of eliminating muri (i.e., overburden) and instead smoothing out flow. Though a user may come to us with a need, we don’t just transform that need into a solution overnight or at some meeting called Sprint Planning. Business solution design takes time, dialogue, exploration, and feedback. A solution eventually emerges and works its way to the top of the Product Backlog as an Enabling Specification.

The Product Owner owns specifications: that is, it is the Product Owner’s responsibility that they be there. They are not specifications of the problem, but of solutions. The Product Owner doesn’t maintain a requirements backlog, but rather a Product Backlog. The products serve the Product Owner’s vision of the product Increments that will generate value — not just of the problem that provides a market opportunity. A single solution might support several user stories, but the opposite isn’t true. A good Product Backlog documents the agreements between stakeholders about what will be delivered, particularly in the near term. The Product Owner may socialize user stories with stakeholders to create Product Backlog Items (PBIs) and may tag them with user stories, but a proper Product Backlog Item is not a story. It’s something the team builds.

If a product has a long backlog (six or seven Sprints), then some bottom items may be user stories. It’s too early to nail down a specific implementation yet. As they come to the top, they become Enabling Specifications. Good Scrum practice recommends reducing muri by striving to make the top three Sprints of the backlog into Enabling Specifications. And a great, agile Scrum Team usually does not have a long backlog, but instead looks three or four Sprints ahead. Anything else is guessing. If a product can look six months ahead with certainty, waterfall probably suits them better than Scrum.

So, if your backlog is seven Sprints long, or if it is a list of user stories, you have some kaizen to do — to look beyond a casual understanding of Scrum to something that really rocks.

Chapter 22. Mind Your Outcomes. Pay Attention to Value.

Jeff Patton

Focus on Outcome

Think of a product you use — one you’d tell others about. What makes that product good, great even? I’m pretty sure you’ll say things like it’s easy to use, it solves a problem, it’s fun to use, or it makes money. Notice how the things you thought of are the benefits to you as a customer of the product, or maybe even the financial benefits to the company that funded the product.

Notice how you didn’t think delivered on time or delivered under budget or created happy stakeholders. That’s because those aren’t product success factors; they’re project success factors.

Being more product-centric means you’ll need to focus on and measure what your customers and users do after you deliver them what you built. We hope they see it, try it, really use it, keep using it, and hopefully say good things about it. Those are the outcomes because they are what happens after you release. And if customers and users do those things, that usually results in some impact for the organization that paid for the product to be built — for example, return on investment, increases in market share, or cost savings for things built for internal use.

Bad Scrum Focuses on Output

Well-intentioned people using Scrum can easily lose sight of outcome and impact. It’s easy just to focus on the output in Scrum. We start each Sprint by predicting how much potentially releasable software we can build. We fix the time to the length of a Sprint. We fix the cost to the number of team members on our team. And then, we ask the team itself to fix scope by promising what they will deliver in the Sprint. We talk every day about the progress of building that stuff. At the end of every Sprint, we review what was built, argue about whether it’s really “done-done,” discuss if our velocity was what we expected, and maybe even get feedback from our stakeholders, who usually aren’t the people actually using the software.

It’s odd that the things that matter most to product success aren’t the things we spend time worrying about. So, you’ll need to fix that.

Keep Effort and Outcome Visible

You might have noticed that it often takes several Product Backlog items to produce a feature or capability you can actually release. It’s those actually releasable chunks we can measure outcomes on. So, every time you release a chunk that users can use, stop and celebrate that. Discuss how long it actually took. Did it take days? Weeks? Months? Quarters? Build a simple visualization that organizes them left to right by actual effort. Tag the features that took longer than expected and discuss why.

Now the hard part. You’ll need to wait for users to actually see, try, use, and keep using that feature or capability. Because if they don’t, I promise you won’t get the business impact you’d hoped for from building it. Make your visualization two-dimensional by adding an actual outcome axis. Items start in “don’t know” because you won’t after you first ship them. The buckets after that are “awful,” “OK,” and “awesome.” Make it a continuum. You’ll end up with something that looks like this:

Every Sprint Review, discuss those features you shipped in prior Sprints and what you know so far about their outcomes. Discuss whether you could or should make improvements to those features to improve outcomes. Really celebrate awesome outcomes, because that’s where the value really comes from.

Part III. Collaboration Is Key

Chapter 23. Is There Anything to Learn from Football Hooligans?

Jasper Lamers

You see, what it does is this: it gives violence a purpose. It makes us somebody. Because we’re not doing it for ourselves. We’re doing it for something greater — for us. The violence is for the lads.

Mark, Manchester United supporter, Among the Thugs

The cultural anthropologist in me got me into reading the book Among the Thugs (Vintage, 1990) by journalist Bill Buford, where he described his field research amid the most violent core of Manchester United hooligans. While reading it, however, the Agile and Scrum coach in me kept poking for potential lessons about operating as a team, if there were any.

More than once did Bill Buford participate in fights that put him in the hospital. Initially, that didn’t stop him from participating again. He described how he experienced the ecstatic feeling of being part of something much bigger, the aura of invincibility. He felt friendship and solidarity. The glory, the heroism, and life flooding through his veins drove him when he and “the lads” faced larger groups of rivals and decided to stand their ground anyhow.

It might sound crude, but on a meta level, these hooligan firms have some traits from which teams in general can learn.

The Scrum Guide states that Scrum is lightweight, simple to understand, and difficult to master. Organizing the Scrum events is easy. But to get the most out of them? To be effective as a team? To continuously improve and deliver as much value as possible? That requires more than just sitting through Scrum’s events. That involves dedication, team dynamics, purpose, mindset, culture, behavior, and…values.

The Scrum Guide poetically states about the Scrum Values:

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.

In Artyom Vorobey’s 2018 documentary, Football Beasts: An Inside Look at Europe’s Football Hooligan Subculture, a leading Stuttgart hooligan says: “What’s so great about it, is the team spirit, when you know you can rely on the man to your left or right.” In other words, running away might get your mates in serious trouble.

Apart from the violence, there is a similarity with Scrum Teams. The Scrum Values can support us in standing our ground when the conditions turn bad. We show courage, remain focused and committed, and are honest and respectful to one another. We cover one another’s back.

As Scrum Teams, we obviously serve a very different purpose than hooligan firms. We are committed to our Sprint Goal, meaning we will do everything within our means to achieve it. We get work “Done” within the Sprint without undercutting quality and value. If the ability to get work done is endangered, team members will help one another out. The entire team should stand its ground. Running away is not an option.

In Lexi Alexander’s 2005 movie, Green Street Hooligans, Elijah Wood plays an American student who engages with the Green Street Elite, a fictitious hooligan firm of West Ham United Football Club. After his transformation from an insecure student into one of the lads, his character says: “I’ve never lived closer to danger, but I’ve never felt safer. I’ve never felt more confident, and people could spot it from a mile away. And as for this violence? I have to be honest — it grew on me. Once you’ve taken a few punches and realize you’re not made of glass, you don’t feel alive unless you’re pushing yourself as far as you can go.”

Chapter 24. And Then a Miracle Occurs

Konstantin Razumovsky

So, what is the essence of Scrum?

I apologize for such a long letter — I didn’t have time to write a short one.

This famous Mark Twain quote reflects the idea that you have to spend time on understanding some concept in order to explain its essence concisely.

I used to work with an Agile Coach who liked this idea so much that one of his favorite interview questions was always, “In your opinion, what is the essence of Scrum in a maximum of six words?” The keywords he was mostly looking for were feedback, experiments, empiricism, inspection, adaptation, and value.

I don’t think the interviewer realized that his question surprisingly has a very direct answer in the Scrum Guide:

The essence of Scrum is a small team of people.

“I take a deep breath, close my eyes, and write this word: team. Those who say that this doesn’t work for people above 14 just have never seen how this works. And it’s really hard to believe in something you’ve never seen.” This is a quote from Hanna, a member of a Scrum Team from Minsk, Belarus. I would love to attribute Hanna’s inspiration to using the Scrum process only, but I can’t. Her motivation and happiness mostly come from working shoulder to shoulder on a daily basis with four geeks called her team. Geeks who, after six months of joint victories, failures, and quarrels, became very important to her; they became her second family and provided a reason to come to work.

In books, teams are supposed to be created around a common goal and get motivation out of pursuing it. However, organizational goals are often arbitrary or meaningless. Working in a great team is what drives many people. Instead of serving an external goal, the team becomes a goal in itself. Members of a good team get motivation and energy from the team.

One of the most helpful tips I personally know for Scrum practitioners is to generously invest time, energy, creativity, and empathy into getting a team to really jell. Once you do that, many good things in Scrum happen “by themselves,” almost automatically. You will see the better side of every individual on the team. Most of your concerns about involvement, responsibility, and collaboration will fade away. You will understand how collective responsibility works. The favorite mantra of all Scrum Masters — “take it to the team” — starts working great for you.

In a classic cartoon by Sidney Harris, two scientists are going through the steps toward proof of an important theorem. One of the transitions on the way to the goal requires a miracle.

Similarly, on your path to professional Scrum, there is a hard but necessary step: growing a team. And no one knows exactly how this happens.

We do know that for this step to happen, you’ll need to find enough empathetic people with strong intrinsic motivation. Create a safe environment for them — an environment rid of formal “leads,” hierarchy, and demotivators. And listen carefully to the words of people like Hanna who have experienced this: “Somehow, in an unexplainable way in the middle of our collaboration, respect, help, support, and friendship, on some wonderful (really wonderful!) day, a miracle occurs. And you can’t really influence it. You can observe, enjoy, even get benefits out of it, investigate, and try to understand — not for reproducing, but for not breaking it down.”

Chapter 25. Put Customer Focus at the Top of Your Decision-Making Stack

Mitch Lacey

At the risk of sounding like a curmudgeon, most company cultures nowadays seem too heavily focused on individuals. The biggest problem with this is that, when everybody is busy making sure their own needs are met and trying to sell their own ideas, the organization cannot hear the voice of the customer. And when a business doesn’t know what its customers want, that business will fail. To create room for the customer, business leaders need to enforce new rules of engagement.

I say new, but these rules have been around for a while. I’ve played soccer (football, for the rest of the world) all my life. When I was young, players were mostly interested in who scored the most goals and not as concerned about whether we won or lost. As I got older, the reverse was true: players didn’t care who scored as long as we won.

Scrum Teams do share one trait with successful sports teams: they win or lose together. The only way Scrum Teams win is to deliver value to customers. That’s why every successful Scrum implementation I’ve worked on has customer focus at the top of the decision-making stack. Two friends of mine, Scott Densmore and Brad Wilson of Microsoft, created a decision sequence that works well.

We do what is best for <X> in the following order:

1. Customer

2. Company

3. Group or organization

4. Team

5. Self

To develop this mindset, team members must first learn accountability. Accountability is owning your mistakes, even when it might be easier to blame others. My son discovered accountability when he forgot his homework one day and I refused to bail him out by taking him back to school to get it. He was furious at me, saying it was “all my fault.” But I stood my ground. I knew it was better for him to learn how to admit a mistake than it was to save him from temporary embarrassment. Similarly, a developer who sits back, smugly thinking, “I’m finished,” while the team struggles to get through a Sprint, needs a hard lesson in being accountable to the team.

Once team members demonstrate accountability, they can nurture a growth mindset. A growth mindset happens when we accept that we cannot possibly know everything by ourselves and that there is always more to learn when we let go of our own ideas and begin listening to others. Teams that develop solutions together, with their customer in mind, experience success — and that success feels so good that a growth mindset quickly becomes ingrained in their team culture.

If leadership establishes and promotes customer-first rules of engagement, the company can focus on its main goal: exciting and elating its customers and creating experiences that are out of this world.

Chapter 26. Is Your Team Working as a Team?

Rich Hundhausen

Of the many teams I’ve met, most were practicing Scrum. Others were considering it. They all wanted to become more Agile. When asked if they were working as a team, they always answered in the affirmative. Each member of the team was busy doing something, and the team usually got something done. And they would stand up every day, too.

Great, but were they working as a team?

There are many ways to work as a team. Some ways are highly collaborative. Some maximize learning. Some minimize cycle time. Unfortunately, there are ways that are all about individual specializations and output. To the untrained eye, they can look like a harmonious team. However, they actually maximize the risk of not delivering, as today’s complexity requires combining skills and even cross-learning of skills to succeed.

Over the years, I started identifying and classifying the various styles of teamwork and assessing their impact on the collective.

There are four ways that are dysfunctional in terms of the ability to collectively deliver and to transcend being just a group of individuals:

Hoarding

After Sprint Planning, a Developer claims ownership of multiple Product Backlog items to do all the work on those items in isolation. Intra-team dependencies (such as knowledge) and external impediments get the Developer to cherry-pick among the selected items, ending the Sprint with all items open but nothing “Done.”

Hogging

After Sprint Planning, a Developer takes ownership of a single Product Backlog item to do all possible work, moves on to do the same with the next Product Backlog item, and so on. Dependencies and impediments are similar to hoarding, but the single-piece focus slightly increases transparency, reducing the risk of not getting the item Done.

Specializing

Developers work those tasks pertaining to their specialties on different Product Backlog items and “maximize” their specialization across all items. Dependencies are high but remain hidden until toward the end of the Sprint, when late integration greatly increases risk.

Generalizing

A Developer works a few different types of tasks. Not having all the skills required, the person will still start work on a new Product Backlog Item (PBI) when blocked. Dependencies may not be as high as specializing, but integration still occurs late, increasing risk.

Teams that start working in any of the following three ways enter the “Circle of Team Collaboration Goodness,” where mutual learning happens as an opportunity for professional development and is a must to reduce dependencies and risk:

Pairing

Two Developers co-create the same PBI, as a pair, potentially changing the pair composition in search of all expertise to get the item Done. Pairs may be part of a larger swarm on a single PBI.

Swarming

All Developers (alone or in pairs) work on a single PBI, doing whatever is required until the PBI is Done.

Mobbing

All Developers work on a single task of a single PBI until that PBI is Done. Like in swarming, there is no jumping or moving on before the PBI is Done.

I hope this helps you contemplate how your Development Team works. Where would you situate your team on their journey? What patterns have you observed emerging? How can you help the team move forward to become a highly collaborative team, rather than a group of individuals?

Chapter 27. “That’s Not My Job!”

Markus Gaertner

This is a story from a colleague who was providing technical coaching for a client. He was one of the technical coaches working with 40 Scrum Teams to improve on their technical and development practices and bring them on par with 21st-century standards.

At one of these sessions, the technical coaches provided training, mentoring, and coaching about modern development concepts like test-driven development (TDD) and acceptance-level TDD (ATDD). One of the developers involved went to his desk, opened his drawer, pulled out his working contract, pointed at it, and said: “It does not say ‘testing’ in here.”

Clearly, that developer was relying heavily on his paper contract. If it didn’t state to wash his hands after he went to the toilet, maybe he wouldn’t have done so either. Who knows?

But seriously. Does it help if an idle team member points out that something is not their job while the work needs to get done and all the other people involved are too busy to do it? Not really.

Taking a closer look at companies large and small, we see a particular pattern. In smaller companies, it seems to be more accepted behavior to take over work even though it may not be part of your job description or not even your expertise. In larger companies, though, people are more hesitant to do so, as the likelihood of stepping on someone else’s toes is higher and might cause problems, not to mention that it often doesn’t help them advance their career.

Regardless, I don’t think the latter attitude is helpful to solve the complex problems for which we introduce the use of Scrum.

As humans, we are born with few fully developed skills. One of the core things the human brain is capable of is learning new things, which it does continuously for its whole life. We learn to crawl, to stand up, and eventually to walk and run. Each next step of our path of continuous learning frees us from the perceived problems we experienced in every previous phase.

Just because something is not your job, it should not keep you from acquiring the skills to perform that work if it has to be done. And if that work really does not have to be done, then everybody will probably agree to not do it. That is very different from saying, “That’s not my job!”

We learn to improve all our lives long. That’s what distinguishes humans from other species. Use that capability that makes you human to contribute to your team’s efforts while also developing yourself.

“That’s not my job” really is a pretty cheap excuse for not doing the related work. Don’t go there, because it undermines team morale and your self-development.

Chapter 28. Specialization Is for Insects

James O. Coplien

Robert Heinlein has a great quote on the topic of specialization:

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight effectively, die gallantly. Specialization is for insects.

One of our favorite Scrum patterns is “Cross-Functional Team”, but there is much confusion about its meaning. Folks commonly assume it means that everyone should be able to do everything. This is probably ideal for minimizing talent blockages, but folks discount it as unrealistic and too costly from a training perspective. The intent behind cross-functional teams is that they should offer all competencies necessary to complete their work, and in particular, that developers collectively have all skills necessary to efficiently build product.

Why does Scrum call us to this kind of work community? First, to handle variance. You can’t staff a team with exactly the right number of UX designers, testers, programmers, and database people to match the workload ideally. The demand for each specialization changes both during the Sprint and from Sprint to Sprint. Over-engineer a bit to reduce the risk. Second, we want to make sure the team isn’t blocked if one uniquely skilled person is overloaded or on sick leave during a particular Sprint; another team member should be able to pick up the slack. Third, times change. The market calls for one set of expertise today and may call for another tomorrow. Don’t hire team members for what they know today or for how they have applied their knowledge in the past, but rather for their ability to acquire and apply emerging knowledge in the future.

In his book, Drive: The Amazing Truth About What Motivates Us (Riverhead Books, 2011), Daniel Pink reminds us that people love to grow in their area of specialization (Mastery), so these calls to cross-functionality elicit a visceral, negative reaction. The usual claim is that you can’t have an expert in every field within the team’s endeavors. The more sober perspective is that you don’t need world-class excellence — just competence. If necessary, use kaizen to grow from there.

Scrum emphasizes learning as a team. Let’s say that, again and again, you find you are missing some specialized skill set, or that you need more knowledgeable testing people than you have. Fix it — with cross-training (which is cheap and adds value) or hiring (which adds both short- and long-term cost and risks more rapidly bringing your team to a point of diminishing returns on capacity as a function of size). The sooner you fix it, the sooner you’ll be improving again. You’ll suck in the meantime, but that’s OK. Good kaizen bears a bit of reflective regret.

And it’s great to belong to a team where people can learn as individuals. Pink’s admonition about growing in knowledge doesn’t imply a limited number of specializations; it is just as rewarding, or more so, to grow in mastery of a new area. Great team members learn, grow, and diversify their skills.

Chapter 29. Digital Tools Considered Harmful: Sprint Backlog

Bas Vodde

It is unfortunately common to use a digital Sprint Backlog. I say unfortunately because of the negative impact a digital Sprint Backlog tends to have on team dynamics and collaboration. Using a digital tool for a Product Backlog might also be common but is less harmful. Digital Sprint Backlogs should be avoided! I’ve observed four reasons why digital Sprint Backlogs are used, where each reason is a reflection of a team or organizational dysfunction.

1. The Team Is Not Co-Located. Dispersed teams are common, as many companies pretend co-location doesn’t matter and allow organizational stupidity to disperse the majority of their teams. Check out my article related to this, titled “Co-location Still Matters”. Dispersed teams often end up quickly deciding to use a digital Sprint Backlog, yet I’ve known many teams that manage fine with Post-It Sprint Backlogs, white boards, video, and photos.

2. Mandated Sprint Backlog Tool. Although I have often inquired about the benefits of “harmonizing” the Sprint Backlog tool, the reasons to do so are still unclear to me. The most common response is a desire for better in-Sprint progress tracking. This is a clear sign Scrum is being misused for micromanagement purposes, as in-Sprint progress tracking is the responsibility of the team. Another frequent response is to derive metrics from the Sprint Backlog, but metrics that make sense to people and instances external to the team are derived from the Product Backlog and not from the Sprint Backlog.

The Sprint Backlog is for the team — not for the Scrum Master or Product Owner and definitely not for management. It helps the team take a shared responsibility and to manage their work toward creating a releasable product Increment. What tool (or not) to use is up to the self-managing team. Management that mandates a tool doesn’t seem to understand Scrum and how it was founded on self-managing teams. That is the real problem to solve.

3. Sprint Planning with a Computer. Computers cause boring meetings. They centralize discussions, with the typing person becoming a bottleneck. Computer-centric meetings are dreadful events and waste people’s time as they stare at the ceiling while waiting for the typist to finish. They become life-sucking events that make people wish they’d chosen a life as a bus driver.

Computerless meetings can be much more productive and fun. Meetings automatically decentralize when the focus is on conversation and using cards or Post-It notes to invoke collaboration. Everyone writes in parallel. Sub-groups emerge and later merge again. And the cards on the table provide an overview of what was done. Sprint Planning is shared software design and ought to be fun!

4. The Scrum Master Adds Tasks to the Sprint Backlog. Scrum Masters who touch the Sprint Backlog will own it and become fake Scrum Project Managers. Here is a non-digital Sprint Backlog from a team I worked with:

This Sprint Backlog is the software design of the system, with boxes in two different colors representing the current system and the design envisioned, respectively, for this Sprint. The Post-It notes are the tasks that need to be done. This is the “to-do” column of a task board Sprint Backlog.

I’m not suggesting that your teams should work this way. This is how this team worked — they owned it. That is the most important reason for never using digital tools for Sprint Backlog. When using a digital tool, the tool determines the way the team works. Without a digital tool, the team can own and improve their own way of working.

Chapter 30. Digital Tools Considered Harmful: Jira

Bas Vodde

At the time of this writing, Jira is probably the most widely used digital tool in Scrum and LeSS adoptions. Unfortunately, using Jira commonly leads to some predictable dysfunctions.

Scrum Confusion

Many companies start “enterprise-wide” Scrum adoption by mandating Jira. People learn Scrum through Jira, or so they think. However, Jira was never a Scrum tool. It is an issue-tracking tool with many ideas integrated into it, such as Scrum, and many…not-Scrum. Teams end up adopting ideas that they think — or were told — are included in Scrum.

The overall result is anti-Scrum. How? Scrum has a minimum of prescriptions, as it implements empirical process control. Team practices are not prescribed or fixed but are adopted and adapted as context changes. Scrum implies team-owned processes rather than tool-owned processes.

Product and Sprint Backlog Integration

Jira integrates the Product and Sprint Backlogs. This might seem like a good idea, but in practice, it is not. It leads to confusion about their purposes.

The Product Backlog contains items that represent product features or improvement work. The Product Owner uses the Product Backlog for tracking product progress, deciding which features to create next, and making scope/time/cost trade-offs.

The Sprint Backlog is a plan from the Team on how they are going to attempt to achieve the goal of the Sprint. It is valid for one Sprint: it is created at the start of the Sprint, never earlier, and ceases to exist at the end of the Sprint. The Team keeps it up to date all the time. It enables them to take a shared responsibility and manage all the in-Sprint work.

Integrating the Sprint Backlog and the Product Backlog easily leads to the Product Owner and management tracking in-Sprint progress. By doing so, they take over the responsibility of the Team to manage their own progress during the Sprint. The temptation to interrupt the Team during their Sprint is often irresistible. This changes Scrum from a framework for supporting self-managing teams to a micromanagement framework.

No Shared Team Responsibility

Good teams avoid having half-done items at the end of the Sprint. They do so by truly taking a shared responsibility and by working one (or a few) items at a time. They achieve this through fine-grained task splitting so that each team member can pick up tasks related to the same item at the same time.

Creating tasks in Jira is slow. This might be because Jira itself is slow — most of my experiences with Jira were self-hosted installations, and they were all slow. Or it might be because tasks are created in Sprint Planning with one person typing. Whatever the reason for the slowness, all teams I’ve observed minimized their Jira typing time by avoiding small tasks.

Large tasks lead to less shared work, which leads to less shared team responsibility, which leads to a less effective team. How do you know this might be happening? Half-done items at the end of the Sprint and the Team talking about spill-over or carry-over work. The phrases carry-over and spill-over are signs of dysfunctional Scrum.

We’re Stuck with Jira. Now What?

How can you use Jira so that it causes the least amount of harm? My recommendations are:

- Never use Jira for Sprint Backlogs.

- When using Jira for a Product Backlog, simplify it. Make it work like a spreadsheet.

- Avoid any complicated features and avoid workflows. Out-of-the-box Jira is already too complicated.

Chapter 31. The Vicious Effects of Managing for Utilization

Daniel Heinen
& Konstantin Ribel

Allow us to share the vicious effects we have observed when organizations add additional teams (from vendors) to an ongoing product development endeavor because it is not progressing as expected.

Every new vendor team needs to gain a full-system understanding of the product and how it is developed. How much help they need from experienced teams and how long the learning will take depends on the product complexity.

Consequently, Brooks’ law comes into effect (from Frederick Brooks’ book, The Mythical Man-Month [Addison-Wesley, 1995]):

Adding manpower to a late software project makes it later.

Feature output decreases, and management concern rises even further. Action is expected. The most obvious one is to add even more people. Since it is easier to ramp up (and later say goodbye to) external staff in comparison to recruiting internal staff, the hiring rate of (external) vendor teams rises steeply.

The product group size grows as do the differences between teams in terms of system understanding. However, a common expectation is a maximum utilization of teams and individuals. This leads to fragmentation of work along the current capabilities of the teams instead of organizing for customer value, as can be expected in Scrum. The flexibility in work distribution between teams drops, and the workload of a team on particular specializations increases. Work becomes splintered even more, and the adaptability of the Product Development group decreases. The teams specialize in their field of work and become what are known as component teams.

The usual observed pattern is that teams no longer work on highest-priority items but on items with lower priority just because they are in their field of expertise and add to maximizing utilization.

As people start accommodating this situation, Product Backlog items now start reflecting the technical split between teams (and no longer customers’ needs), and a Product Owner no longer prioritizes for value.

This downward spiral can only be broken with teams mastering the full technology stack and focusing on customer value — i.e., teams becoming “feature teams”.

However, integrating external vendor teams is often contractually limited (think of information protection, etc.) and further endangered by contractual demands of utilization. Such contractual conditions translate into having multiple team backlogs, rather than one Product Backlog, and proxy Product Owners trying to better direct their vendor teams.

Consequently, Conway’s law comes into effect:

Organizations which design systems...are constrained to produce designs which are copies of the communication structures of these organizations.

The small clusters of component teams working on different backlogs are the communication structures of the organization. Therefore, the design and usability of the software being produced deteriorates. Furthermore, the cost of adding inexperienced developers is overlooked when the Key Performance Indicators (KPIs) are all about utilization. Collaboration across all teams degrades at the cost of losing organizational flexibility and overall performance.

A better approach is to carefully consider whether scaling up is really needed and whether it needs to be done by externalizing the workforce. Prefer avoiding both.

Otherwise, scale slowly and allow learning, observed by a lot of management GoSee to have full transparency upon contractual agreements that focus on collaboration toward customer value.

Chapter 32. Becoming a Radiating Team

Len Lagestee

The presence of transparency creates an environment for trust to flourish. Without it, small cracks of doubt will eventually become large crevices of distrust. There is a reason transparency is one of the principles of Scrum.

When a Scrum Team isn’t as transparent as can be expected, when the team is not radiating information sufficiently, leaders are left to speculate: “Am I getting a return on the investment we have made in this team?” If there is any doubt in this answer, the next step is probably to request a status report or a leader intervention to force the team to be more transparent.

Becoming a radiating team takes little effort, as a Scrum Team produces a wide range of data over the normal course of their work. We have the antidote to status reports and intervention:

- Radiate intention through the Product Backlog. The Product Backlog declares unequivocally what is deemed important to build and the sequence in which the team will build it. Make it easily visible on a wall or provide access to a read-only version of it so all interested parties can review and discuss.

- Radiate progress through a real-time task wall. The task wall indicates movement. With an ordered Product Backlog, you radiate how this movement goes toward completing valuable work. If the task wall is stale (tasks remain “in progress” for days), people should get nervous. Put the task wall in a public place, or if your task wall is virtual, allow read-only access to it. For most people, the details on the task wall won’t matter, but seeing energy and progress does.

- Radiate commitment through a burn-down or a burn-up chart. This chart will radiate the team’s ability to deliver a product Increment and show when the release of something valuable will likely occur. For most leaders or stakeholders, this is all they need to know.

- Radiate blockers listed in an impediment list. Be open about what is holding you back. Share what isn’t working, fix what you can, and seek help for impediments you can’t fix yourselves. Radiate these so others in the organization can learn from you or even help remove the impediments.

- Radiate improvement by displaying velocity. If a task wall represents movement, velocity means you’re improving in your ability to create and deliver with speed and efficiency. Velocity is simply a relative metric of completion: what have you done in the past, and are you getting better at finishing things? While mostly an internal team measurement, a radiating Scrum Team should be transparent enough to share if they are producing outcomes faster or more slowly.

When a team is transparent with the good and the bad, something magical begins to happen. They are given more autonomy. They become more trusted, and trusted teams are confident teams.

Part IV. Development Is Multifaceted Work

Chapter 33. Agile Is More Than Sprinting

James W. Grenning

Agile transformations often start with good intent but are flawed in the approach. Your development people have been working under the waterfall and a manufacturing mindset for years. Now you want to iterate and do Sprints. They hear the word “Sprint” and think of the Olympics.

You have seen the sprinters after the big race. You don’t expect them to hop up off the ground and start running another sprint, although we expect that with our Agile teams. Developers are told to go to a Daily Scrum or stand-up meeting, which feels like micromanagement. They hear the title Scrum Master and think they are subordinates. They feel they are being rushed. They don’t see the rat race coming to an end. To development, the initial reaction to the two-week cycle is that quality does not matter. All that matters is getting the feature out.

I’ve seen this pattern over and over again. The cause of the pain comes from starting incremental management without investing in incremental engineering and development skills. There are visible problems you will likely see when introducing incremental management without incremental development. You will see that developers do not complete their work in the iteration more often than they do. You will see the bug list grow, shortcuts taken, the code degraded and developer morale going down the tubes.

This pain can be avoided by investing in your development people. Help them grow their incremental development knowledge, understanding, and skill. The skills needed to be successful at incrementally developing a successful product are not a secret. Kent Beck cataloged them in 1999 in his book Extreme Programming Explained (Addison-Wesley Professional, 1999). Extreme Programming (XP), along with continual learning of design, works for incremental development. You will likely see more of your planned content delivered on time. You will likely see a smaller or nonexistent bug list, higher-quality code, and higher developer morale.

Incremental management practice without incremental development skill is a recipe for pain. Great things can and will happen when you combine incremental management with incremental development. Scrum does not prescribe what your development practices should be. However, Scrum does require you to have them in place; as such, standards and agreements are essential in transparency and empiricism.

My advice: start growing awareness, knowledge, understanding, and skill in incremental development. The fact that traditional development does not fit into an incremental management approach is more than a development problem — it is a system problem.

Chapter 34. Patricia’s Product Management Predicament

Chris Lukassen

Fuming, Patricia stomped into the office kitchen, grabbed a coffee cup from the cupboard, and slammed the cabinet door.

“Everything okay?” asked Seiko, the team’s Scrum Master, raising his eyebrow.

Patricia blushed. She hadn’t realized just how visibly upset she was, but David, the Product Owner, had managed to throw her off balance, yet again!

“I’m fine,” she said, with a somewhat forced smile.

“No, you’re not!” laughed Seiko. “What’s up?”

Ever since Julie (the CEO) had convinced them to move to Scrum, Patricia felt more and more powerless in her role as a product manager, and she shared this with Seiko. Granted, she hadn’t had that much influence over the teams in the past either. But at least back then, she could get some things done. Now, everything had to go through the Product Owner, and David had his own agenda.

“I know that having a single Product Owner has created more focus and transparency,” she sighed. “But the Development Team doesn’t have my experience or customer insight — so none of the releases have addressed the customer’s problems properly.”

“I’ve noticed,” said Seiko. “The teams indeed don’t have a great picture of our customers, which probably scares them. Or maybe they just prefer to code.”

“You can code all you want,” Patricia replied. “But it doesn’t matter if the customers don’t like it!”

“That’s David’s problem now,” Seiko smirked.

“Fair point, but he’s stretched so thin that he’ll never be able to work out all the details for all the teams,” Patricia explained.

“Well, you don’t have to be the driver to get where you want to go,” Seiko added with a smile. Patricia thought about their exchange for the rest of the day and even into the evening. Having one product with one owner and one backlog listing all work that needed to be done made too much sense to revert to the old way of doing things. On the other hand, the teams simply didn’t get it, and she felt she had the knowledge to help them get it.

When she woke the next morning and walked into her kitchen, she noticed her daughter Emi was struggling with her lunchbox. She was using great enthusiasm and force to get it shut.

“Oh my goodness, what all have you crammed in there?” asked Patricia.

Still focused on shutting her lunchbox, Emi listed off its contents: “Fruit, sandwiches, and an apple.” Before Patricia could explain that an apple is a fruit, Emi explained, “I will need all of this today, and I don’t want them in separate boxes.” And with a final push, she managed to snap the lid shut.

When Patricia arrived at work later that morning, she called a meeting with Seiko, Julie, and David to discuss the gap between product management and the Development Team.

“The Development Team needs a mix of skills, and that mix should go beyond programming, testing, and designing. I have concluded that people who know the market — like me — have a role to play as well. So, I’d like to join the Development Team.” With a smile, she added, “It doesn’t make sense to put us in separate boxes.”

Chapter 35. The Five Stages of Product Backlog Item Sizing

Len Lagestee

Scrum has been designed to be a pull system. This means that those doing the work decide how much they think can get accomplished in a sustainable and healthy way. The team pulls items from the Product Backlog into the Sprint. No one decides for them how much work they pull in.

But what if the team can’t align on what a Product Backlog Item (PBI) is, or what if they don’t know if they can complete an item within the constraint of a Sprint?

One of the techniques used to guide a team toward making this decision is PBI (or story) sizing using a point system. It is based on relative complexity — easier things have a lower number while more complex things have larger numbers — on an exponential scale.

The actual number or points produced does matter less than the journey of moving the group to a state of shared understanding and improved team cohesion. The estimate becomes much more than just a number.

To achieve this, a team passes through five stages during a sizing exercise:

1. Individual perspective

Because Scrum Teams are cross-functional with various levels of expertise, there is an opportunity to listen and embrace the unique knowledge contained within each team member about a PBI. Individual perspective is crucial. All voices must be heard. Speaking up is required at this stage.

2. Individual understanding

Members of the team receive understanding from each of the individual perspectives and begin to establish their own context for the PBI. Each team member begins to frame the problem set by merging their perspective with those from the rest of the team. Listening is required at this stage.

3. Relativity

With the context for the PBI established, the team can now use relativity to determine the complexity encapsulated in completing the item. Relativity can be determined through sharing:

- Group experience: “We’ve done this before, and we can do it again.”

- Similar experience: “We’ve done something like this before, and we can use what we learned then.”

- Unique experience: “We’ve never done this, but we have the skills in place to figure it out.”

- Individual experience: “I’ve done this before, and I can show others how.”

- No experience: “This has never been done before.”

Options begin to emerge about what is possible through the discussion around relativity. Inquisitiveness is required at this stage.

4. Group alignment

With relativity established, the team begins to choose a point along a scale (using the Fibonacci sequence is extremely popular). There should be a natural gravitational pull to a specific point. The team either unanimously aligns around a number (through multiple rounds of conversation if necessary) or drops the item from consideration. The process of alignment will include negotiating around individual understanding and relative complexity. People should not be forced into a number, but they should also not be stubborn. Empathy is required at this stage.

5. Group wisdom

As the team finishes their sizing exercise, they leave with a shared understanding of what is expected to complete a PBI. The wisdom of the group has been elevated as they begin to build the inventory of group experiences for future sizing exercises. A consolidated team emerges at this stage.

Eventually, the team will get to a place where more items start falling in the “We’ve done this before” or “We’ve done something like this before” categories. Sizing becomes easier and more efficient as group wisdom and group experience expand.

Chapter 36. Three Common Misconceptions About User Stories

Marcus Raitner

User stories is one of the most widely known concepts from Agile software development. Unfortunately, it is also one of the most misunderstood. I want to address three common misconceptions I see when user stories are used.

1. User Stories Are Part of Scrum

Although many Product Backlogs seem to contain user stories, and electronic tools like Jira impose that items in Product Backlog are user stories, the Scrum Guide itself does not mention the term “user story” at all. Instead, it mentions only Product Backlog items as a generic term that is open to holding features, functions, requirements, enhancements, and fixes.

In fact, the concept of a user story originates not even from Scrum, but from Extreme Programming (XP), an Agile development model that was developed by Kent Beck, Ward Cunningham, and Ron Jeffries during the C3 project at Chrysler between 1995 and 2000.

2. User Stories Are Specifications

Particularly in organizations that have been accustomed to plan-driven work for decades, I’ve observed how this pattern is frequently applied. There are customers who have a need and developers who are supposed to deliver on that need. There used to be heavy concepts as an attempt to make both parties understand each other. Today, there are — at best — tiny user stories. What remains, however, is the harmful, customer-vendor anti-pattern.

User stories have their name for a reason. A story is something to be told and to talk about. A user story is an invitation for a conversation to take place between users and developers, and not the new name for a specification to be thrown over the wall. The findings of the conversation are certainly captured, but that documentation is not the story.

Ron Jeffries proposed three Cs as a guideline for a good user story: Card, Conversation, and Confirmation. Card refers to the origins when a story was written on an index card (nowadays, a Post-It, probably). The essential message, however, is that an index card has limited space, which necessarily results in brevity and thus incompleteness. This incompleteness is an invitation for a conversation. The common understanding achieved through the conversation can be formally recorded in the form of acceptance criteria (confirmation), which then serve as the basis for test-driven development.

3. The Product Owner Writes the User Stories

This misconception is often found in combination with the previous one. The customer-vendor anti-pattern establishes responsibilities in terms of handovers. The Product Owner, as representative of the users, “obviously” has to provide the Development Team with comprehensive specifications, which they need to implement. This continuation of the old anti-pattern is even worse, as Development Teams expect a Product Owner to do exactly that. The only change is that these comprehensive expectations are expressed nowadays as user stories, which implies that the Product Owner must write them. As the Product Owner cannot do this alone due to the abundance of stories (turning life into a “story hell”), entire specification teams are created to write perfect user stories, which are then thrown over the wall to the Development Teams.

A user story is a promise for a conversation.

Alistair Cockburn

Ultimately, it’s not about the user story as an artifact and who writes it. It is about connecting users and developers and growing a mutual understanding. Therefore, act as one product development team. Abandon the divisive customer-vendor dogma.

Chapter 37. Introducing Abuser Stories

Judy Neher

A hacker is someone who uses a combination of high-tech cybertools and social engineering to gain illicit access to someone else’s data.

John McAfee

Historically, as software product development teams, we’ve tended to focus on functionality and getting features out the door. When did we think about security? Usually right before it went into production! Seems a bit late to start thinking about how to plug holes and protect precious data from adversaries.

But really...who are our adversaries? What do they want? What motivates them?

This is where “abuser stories” come in. Abuser stories allow us to put ourselves in the mindset of an adversary or attacker. They enable us to stand in their shoes, look at our products, and brainstorm their motivations for accessing our most precious resources: our data.

Before we dive into what an abuser story is, let’s take a look at its functional counterpart: the user story.

According to Mike Cohn, user stories are:

...short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

Typically, user stories are written in the following format:

AS A <who> I WANT TO <what> SO THAT <why>.

User stories are an Extreme Programming (XP) concept. They are, however, generally and widely used as a way to capture requirements for all types of Agile teams: Scrum Teams, XP teams, and Kanban teams. Agile teams tend to like writing user stories for the following reasons:

They keep us focused on the what versus the how.

Historically, as product development teams, we tended to write all requirements starting with, “The system shall...” We thought mostly from the perspective of what the system needed to do. User stories help us stay focused on the problems that we are trying to solve for users and customers.

They are easily understood between business and development.

Because they are written from the perspective of the user, user stories translate nicely between the business side of the house and those who are building the product and foster conversation between those groups. For Development Teams, good user stories provide the why of what they are building, which helps them have empathy for the users.

Abuser stories share a very similar structure to functional user stories. Abuser stories specifically help organizations see their products in the same way attackers do. Abuser stories help us view our products from the perspective of our adversaries, rather than our actual users. They help us understand what types of assets our adversaries would want to get at and what their motivations are.

A typical abuser story looks like this:

AS A <attacker> I WANT TO <intent> SO THAT <motivation>.

For every feature we add to our products, someone in the organization (whether a Development Team member or a security professional) should be looking at the feature from the perspective of an adversary: how could someone exploit this feature?

Chapter 38. What’s in Your Sprint Plan?

Rich Hundhausen

In Scrum, Sprint Planning serves to create the Sprint Goal, the forecast, and the plan for delivering the forecast. The Sprint Goal is an objective that will be met within the Sprint through the implementation of forecasted Product Backlog Items (PBIs). The forecast is the set of those Product Backlog items that the Development Team selects, while assessing what can be accomplished during the Sprint.

Having set the Sprint Goal and made a forecast, the Development Team devises a plan for how to deliver the selected functionality into a “Done” product Increment. This plan should be well understood by the team and must offer a way to track progress.

Here are some ways of expressing a Sprint plan.

Expressing the Sprint Plan Using Tasks

A common way to represent the plan is to use tasks. During Sprint Planning and afterward, the Development Team discusses each forecasted PBI and, as a team, identifies the work to be done in terms of small, actionable development tasks. Each piece of work is captured as a separate task, which may have size or time estimates. Tasks hold preferably no more than one day of work. As the Development Team progresses through the Sprint, tasks can be moved to “in progress” and, ultimately, to “Done.” Progress can be inspected by counting tasks or summing the remaining work.

Expressing the Sprint Plan Using Tests

A less common but powerful way to represent the plan is to use acceptance tests. During Sprint Planning and afterward, the Development Team discusses each forecasted PBI and, as a team, identifies and creates one or more associated acceptance tests. These tests are typically created from acceptance criteria and often use a Behavior-Driven Development notation. As the Development Team progresses through the Sprint, more and more of these acceptance tests will change from failing to passing. Progress can be inspected by counting the passing or failing tests.

Expressing the Sprint Plan Using a Diagram

Teams in a state of higher performance may express their plan as a diagram on a flip chart, poster, or whiteboard. The diagram might be part of a larger, emerging architecture diagram. During Sprint Planning, the Development Team adds new elements to the diagram for each forecasted PBI (for example, a new report or integration with another system). As the Development Team progresses through the Sprint, they change the color of the diagram elements to represent “in progress” and “Done.” Progress can be inspected by reviewing the overall color state of the diagram.

Not Expressing the Sprint Plan

High-performance teams, long-lived and jelled, often need less explicit plans. Their plan can emerge in real time through conversation, building on tacit knowledge and shared understanding. This works well for Development Teams that are highly collaborative by swarming or mobbing on PBIs. Work can be visualized using a Kanban board, and progress can be inspected by counting the PBIs.

How are you expressing your Sprint plan? I hope the preceding examples help you contemplate ways for a Development Team to formulate and express its plan for delivering a forecast of PBIs in a Sprint. If you are currently using one specific approach, why not experiment with another in your quest for improvements?

Chapter 39. Sprint Backlogs Deserve a Life Beyond Your Electronic Tool

Mark Levison

Most Development Teams that I encounter simply use whatever their online Scrum tool feeds them for their Sprint Backlog. This harms the Team’s capacity for engagement because it reinforces the sense that Scrum is happening to them, not something they choose. Since the Sprint Backlog is solely for the use of the Development Team to organize their own work, they are the only ones who create, change, and manage it — not a tool and not an outsider.

A Sprint Backlog consists of a set of Product Backlog Items (PBIs) that the Development Team thinks they can complete in the Sprint, along with the work needed, described in small enough chunks that progress can be tracked throughout the Sprint. One specific and common belief is that a Sprint Backlog must contain tasks, which is not the case at all.

The Scrum Guide doesn’t provide any guidance on the contents or format of a Sprint Backlog. An effective Sprint Backlog contains more than just tasks.

Teams experiment with and choose whatever best helps them to stay focused and self-organize, creating the Sprint Backlog with whatever methods work best for them, such as index cards, whiteboards, or, yes, even electronic tools. (Note: if having to maintain a tool for the Sprint Backlog slows down the Team, that is an impediment, and it’s up to the Scrum Master to help find a better solution.)

To ensure that the Team and the process improve every Sprint, it’s recommended that the Development Team include at least one action item from their previous Sprint’s Retrospective in the Sprint Backlog for their current Sprint. Many also include their Sprint Goal and even notes on Team member vacations. They might also add things to visualize blockages and interruptions and an impediments list.

These additions encourage the Team to focus on more than just delivering a collection of user stories. Instead, they’re achieving the Sprint Goal while making improvements that, in the mid-term, help increase their work quality and effectiveness.

When your Sprint Backlog is designed and prepopulated by an outsider (or electronic tool), it’s unlikely to contain any of these improvements.

The Sprint Backlog is also the Development Team’s forecasting tool. On a daily basis during Daily Scrum, they re-plan their work, helping them assess whether they have taken on more than they can actually complete in the Sprint. They then work with the Product Owner to decide which items to add or to drop as needed.

The Sprint Backlog loses its value if used for external purposes or for micromanagement. When leadership uses it to look over the shoulders of the people doing the work, even if it’s not to direct the Development Team’s actions, it often leads to overloading the Sprint Backlog with details that undermine and eliminate transparency.

At the end of the Sprint, the Sprint Backlog is finished, completed work is deployed, and incomplete work is returned to the Product Backlog wherever the Product Owner deems it should belong. Next Sprint Planning, a new Sprint Backlog is created.

Good Teams know that they own this. Great Teams experiment every few Sprints to find what they can do to make their Sprint Backlog even better.

Chapter 40. Testing Is a Team Sport

Lisa Crispin

Cross-functional, self-organizing teams have super powers to bake quality into their product. Diversity is a boost to innovation. Engaging people with different skill sets, experiences, and unconscious biases is a great way to solve any kind of problem. If you have a problem related to testing, if testing is a bottleneck, or if your product quality sucks, make it a team problem to solve.

As a Team, Commit to Your Desired Level of Quality

Testing is a team sport. Get your whole delivery team together, talk about the level of quality you want to deliver to your customers, and commit to achieving that level. Make that a meaningful commitment — don’t let the inevitable roadblocks tempt you into lowering your quality.

Design Small Experiments for Your Biggest Problems

Use frequent retrospectives to identify the biggest quality problem for your team at that moment. Get a capable facilitator so everyone has a voice. Many books are available to help you facilitate such retrospectives effectively, including Agile Retrospectives (Pragmatic Bookshelf, 2006) by Diana Larsen and Esther Derby.

Design a small experiment to chip away at that biggest quality problem — notice how many problems are related to quality. Write a hypothesis that includes your expected outcome and how you will measure progress. (I recommend Linda Rising’s videos talking about small experiments to get you started.) Check progress frequently. Continue, tweak, or abandon as needed.

Make Problems Visible

The first step in solving any problem is to make it visible. Use big, visible charts to encourage conversations about testing issues. Be creative: stick a big red card on a storyboard, make a heat map showing areas of the product where defects are escaping into production, use a big wall monitor display that indicates problems with changing color, and even — as more than one of my own teams has done — use a flashing police light for bad failures.

Visuals are a great way to promote collective ownership of quality and testing. Keep using visuals as you work together to solve problems. Draw, write, and move things around together while you talk.

Keep Talking

Conversations among team members with different specialties should happen continually as you learn from production use of your product and start building new features to fill customer needs. Practices like Three Amigos meetings and example mapping help build shared understanding of features and stories before development starts. Including testing specialists and other good question-askers up front helps shorten cycle times while avoiding “big design up front.”

Take It Slow

Focus on quality, not speed. Guide development with executable tests that become a safety net and living documentation. Teams that feel confident to change their code find a steady cadence.

Remember: no story is done until it’s tested. Limit your work in progress; focus on finishing one story at a time. If testing feels like a bottleneck, plan fewer stories next Sprint. Make testing tasks — which any team member can take on — visible. Pair and mob to transfer testing skills to one another.

Nurture a learning environment where it’s safe to fail. Remember your team commitment to quality every day. Be patient and take baby steps. You’ll enjoy your work and you’ll delight your customers with high-quality, high-value features.

Chapter 41. Rethinking Bugs

Rich Hundhausen

Issue. Incident. Outage. Defect. Bug. The mere mention of these words can send shivers up the spine of a Product Owner or stakeholder because they imply low quality. This is why I’m passionate about reducing the use of such terms or removing them from a team’s vernacular altogether. Yes, products may suffer undesirable behavior. We’ve all experienced this: a feature that used to work but currently doesn’t; an exception or unexpected halt. We might want to call those things bugs, but how does that help? Undesirable product behavior can have various causes. Are we doing more than using pejorative terms to name, blame, and shame one or more developers?

In Scrum, all work that is performed in a Sprint is called development. It serves to move toward the Sprint’s goal and deliver the forecast of selected Product Backlog Items (PBIs) as a part of that, whatever the type of work — hence, the accountability of a Development Team in Scrum. While in development — i.e., within the Sprint — there is no such thing as bugs in the Increment being developed. Perhaps the build failed due to a compilation error. Perhaps a code quality check failed. Perhaps an automated test failed. Whatever — that’s development. It is hard work with many unforeseeable problems. Within the Sprint, it says nothing more to the Development Team than that the work is not “Done” yet.

More serious problems arise when the Development Team does not have all of the skills within the team to get to Done — for example, when testing is done outside of the team by people who are dislocated by time, organization, and/or geography. This is, however, a communication problem first. A bug-tracking tool is one of the worst communication mechanisms thinkable, especially because, again, you are still in development. The identified problems are not bugs. The team just isn’t Done yet. Mind the “whole team” idea, as we do not recognize titles, sub-roles, or sub-teams within a Development Team. The collective accountability improves collaboration and transparency while reducing risk.

This is not to say that, during a Sprint, a Development Team can’t run into undesirable behavior of the product as implemented in previous Increments that were considered Done. Whether or not the Increment was actually released, I’m OK with using the term “bug.” When discovered, the Product Owner should be consulted, and in the ensuing discussion, the impact, value, and effort of fixing the problem explored. If the Product Owner deems the fix urgent, the Development Team should add it to their Sprint Backlog, with the Product Owner acknowledging that there is a likely impact on the Sprint forecast and possibly a need to reset the Sprint goal.

The Product Owner may, however, decide to wait, deeming the fix not urgent enough to jeopardize the current Sprint. The work is then added to the Product Backlog, allowing the Product Owner to consider it for a future Sprint.

Scrum doesn’t define anything more specific than a PBI as a container with a description, value, and estimate. Whether an item is a “happy” thing or a “sad” thing, it’s still work that is deemed valuable enough by the Product Owner to be performed sooner or later. All work on the Product Backlog delivers value (even if it is avoiding negative value) and has a cost, leaving it to the Product Owner to decide if the ROI pencils out.

Chapter 42. Product Backlog Refinement Is an Important Team Activity

Anu Smalley

One of the most critical needs in Scrum is to have a well-refined Product Backlog. According to the Scrum Guide, Product Backlog refinement is “the act of adding detail, estimates, and order to items in the Product Backlog.”

There is often confusion as to what should happen during refinement and who should participate. Product Backlog refinement is a continuous activity involving the Product Owner and the Development Team to ensure an output of a set of Product Backlog Items (PBIs) ready for the upcoming Sprint, with the outcome being a common understanding of those PBIs.

An anti-pattern in Scrum is where a Product Owner attempts to refine the backlog without the team. The impact of this type of refinement is that Sprint Planning may get derailed or elongated since the team often needs to repeat refinement activities, or worse, the team starts the Sprint without a good understanding of the work needed, risking a Sprint ending in chaos. Refinement must absolutely be done with the Product Owner and the Development Team with the purpose of developing a common understanding of the PBIs across the entire team.

A simple mnemonic to help with remembering the activities needed is REFINE:

R–Review

Reviewing the Product Backlog is a collective activity resulting in prioritization and ranking. The most important items to the customers and stakeholders must be at the top of the backlog. It is possible to add items in from the Development Team. Based on the current Sprint or the last Sprint Review, the ranking can change.

E–Elaborate

The Product Owner walks the team through each PBI to ensure accuracy and detail. I would often send out in advance the PBIs to be elaborated during the refinement session. During the meeting, we would discuss each PBI in detail and resolve any concerns. On occasion, the team would identify a need for additional research to complete the refinement in the next session.

F–Fix

The Product Owner and Development Team break PBIs into smaller elements to allow completion within a single Sprint. When breaking down user stories, care must be taken to slice vertically, not horizontally. (Check out this great Story Splitting Cheat Sheet.)

I–Investigate

The Development Team may need to do some analysis work for a PBI (such as talk to another team, look into code, or do technical research) to ensure readiness for the next Sprint.

N–Negotiate

The Product Owner and Development Team work together to clarify and adjust acceptance criteria. As a Product Owner, I would read out the story and initial acceptance criteria identified with the stakeholders. After discussion with the Development Team, they were allowed to rewrite the acceptance criteria. This ensured we were all on the same page.

E–Estimate

Upon achieving a common understanding of the PBI, the Development Team can estimate using whichever technique works for them. A common approach is to use the Fibonacci sequence as story point estimates, set through planning poker or affinity sizing as techniques.

Following this simple mnemonic can be a good reminder of what to do, since ignoring any of these activities can lead to an organization suffering long Sprint Planning efforts, failed Sprints, vague or nonexistent Sprint Goals, high rework, and even lead to technical debt.

Chapter 43. Automating Agility

David Starr

Modern product delivery systems, typically Continuous Integration and Continuous Delivery systems, are helping teams deliver superior-quality software more quickly than ever. An extraordinary side effect of these systems is how they can change a team’s dynamic, helping it find agility as if by accident. Automated product delivery systems are not only enabling the testing of software, they are changing the way teams work together, bringing the true promise of agility with Scrum almost consequently.

Scrum calls for cross-functional teams. For example, when the product delivery system blocks due to a failing test, it may well be a database specialist who collaborates with a front-end developer to get the test passing again and the system back online. The “don’t break the build” rule improves team collaboration. When a code commit causes a failing test, it is fixed right away, keeping a culture of quality and automation inherent to the team. This brings the team together to focus holistically on the product and its production system regardless of individual specialties.

Teams with such systems may release confidently to production many times per day. “But I thought we can only deliver once per Sprint,” you might be thinking. There is nothing in the Scrum Guide that says a team cannot deliver more than one Increment per Sprint. With a continuous product delivery system in place, this is exactly what the team is doing, regardless of whether they are releasing all the way to production or not.

Teams working this way often take on aspects of Scrum bit by bit. It usually starts with a Daily Scrum (standing or not), which can be invaluable when facilitated properly. The point is to create a plan for the next 24 hours, not to dwell on what everybody did yesterday. A Scrum board will inevitably pop up somewhere, whether physical or digital. Now the team is visually tracking its work and can make observations about its performance.

A team new to Scrum often tries to implement Sprint Planning meetings first; I strongly encourage focusing on retrospectives instead. This invaluable discussion focuses on what the team will improve next, whether it be an improvement in automation or in how the Daily Scrum is conducted. Teams should keep a backlog of things to improve over time. Pulling from this backlog is a perfect way to gradually mature, grow Scrum practices, and improve the craftsmanship in the software delivered.

Over time, successful teams will take on more of Scrum’s artifacts, events, and roles until they are truly a Scrum Team. They separate planning from reflecting in their meetings and insist on an empowered Product Owner. The Scrum Team may even start coordinating planning with other dependent teams. In short, just by doing what is effective can lead a team to Scrum almost by accident, and the Scrum Guide provides the framework upon which to build excellence.

Using an automated production system may seem like a strictly engineering activity. But the tools often set the rules, so combining such a system with Scrum can positively transform a team and the way they build product. Scrum Teams prioritizing automation will deliver high-quality software at a rate considerably faster than a team with less mature and more manual practices.

Chapter 44. The Evergreen Tree

Jesse Houwing

Imagine you’re working on a product that consists of both software and hardware, and it’s big. Imagine that this product can save lives, but — when used incorrectly — could also kill. This is the reality for many teams working on large hospital appliances.

I’ve worked with one such team working on such a product. Rather, I should say teams. Eighteen teams integrated their work into a single codebase. When I first entered the building that hosted some of these teams, I felt like I was entering a research facility from the computer game Half-Life. People were running around, and computers, pieces of machinery, and old versions of the product were everywhere. At some point, yarn appeared everywhere, an attempt by the teams to visualize the many dependencies.

It takes a lot of discipline to not break things with so many people working on the same product across different buildings and countries; to not accidentally introduce new, unwanted, and unexpected “features.” To keep the code at least consistent, we put a Continuous Integration (CI) system in place. While that ensured that much of the code was covered by unit or integration tests, it’s hard to tell whether it does anything it isn’t supposed to if you don’t have 100% of your code and functionality covered by tests.

We made the dangerous situation of a broken integration immediately visible with some old desktops conveniently placed on filing cabinets in the team rooms and in the hallways. Teams would take immediate ownership if that happened, understanding that 199 colleagues would be blocked because of it. By keeping that discipline and not trying to work around such blockades, many problems were solved quickly, and better ways to work together emerged over time.

One thing that is hard to solve with CI is the collaboration between human beings. We tackled that challenge in line with our CI approach.

Leaving a potential problem to simmer without acting on it is much more expensive than dealing with it here and now. With a single email to a special mailbox, anyone could cause all the screens in the team rooms and hallways to go red, stopping integration and pausing the work of all 199 coworkers. This would trigger an immediate response from all teams, sending a representative to address the possible problem. Literally. Team representatives actually met in a designated place, the issue was reviewed, and action was taken.

And if the assumed problem turned out to be no problem in the end, you would still be rewarded for your courage to act anyway. The few times that there actually was a problem, the consequences could not have been tackled sooner, and the impact was guaranteed to be minimized. Failing to pull the cord and then later saying, “I knew it! I’ve been trying to tell you all along!” would lead to a more difficult conversation about trust and courage.

It takes a lot of discipline to keep your code integrated at all times and all your tests passing. It takes even more discipline and having the right conversations to really integrate your teams.

Part V. Events, Not Meetings

Chapter 45. Sprints Are for Progress, Not to Become the New Treadmill

Jutta Eckstein

You are probably aware that Sprints are at the core of Scrum. Sprints are short cycles of no more than four weeks. Therefore, every team that applies Scrum will work in Sprints.

Unfortunately, some organizations do no more than have their teams work in Sprints. The work they perform often seems random, coming from various sources, and Sprints are often just isolated and disconnected chunks in time. Teams experience Sprints as treadmills instead of as a way to help them make purposeful progress. One of the problems these teams face is that they don’t know what the final or overall objective, or even direction, of their work is. They just know what is expected in a Sprint. But without knowing overarching objectives, each and every single Sprint becomes meaningless — and, therefore, a treadmill. I remember a team member once describing this as “continuous Sprints.” This extreme statement actually tells us that their Sprints are neither planned nor measured. Sprints are just boxes in time in which people do stuff.

Yet, by not planning a Sprint and then measuring it afterward, you will never know the real state of your project. You can’t tie your lessons learned (for example, how much can you accomplish during the Sprint) back to the overall objective. Therefore, you will only know at the very end whether or not the overall objective will be reached.

So, you need to plan and measure your Sprints. Team members will split business-selected features into tasks, estimate them, and assess whether the work is doable during the next Sprint. I recommend checking the following:

- Does the availability in the upcoming Sprint look sufficient for accomplishing the work?

- How much were you able to accomplish in the last Sprint, and can you assume that you’ll be able to accomplish the same amount in the next one? (This technique is often called “yesterday’s weather,” and, over time, finding out the average of what you can accomplish during a Sprint makes you — as a team — very reliable.)

If your availability is the same as it was in the past Sprint, it is actually enough to just cross-check with the second bullet. However, sometimes there are major differences regarding availability based on vacation, sickness “season,” further education, or assignments elsewhere.

Then, at the end of the Sprint, you should measure how much you have actually accomplished in the past Sprint. First of all, celebrate the achievements, and secondly, take those measurements into account when planning the next Sprint, as well when updating your assumptions about the overall objective.

Chapter 46. How to Have an Effective Sprint Planning

Luis Gonçalves

Any work that your team will perform is planned at the Sprint Planning. The plan brings together the entire Scrum Team and is created through collaboration. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint and probably takes less time for shorter Sprints.

In Scrum, teams plan by picking up work, often stories, from the Product Backlog and committing to execute on that forecast in the upcoming Sprint. It is the Scrum Master’s responsibility to make sure that the event takes place and that the attendants understand the time box and the purpose of the event.

The objective of Sprint Planning is to organize the work and select a realistic scope for the Sprint.

Attendees of the Sprint Planning meeting include:

- The Product Owner

- The Scrum Master (who acts as a facilitator)

- All other team members

Teams agree on the amount of work they can pull from the Product Backlog. Upon an agreement over this forecast, they define the Sprint Goal(s) together with the Product Owner.

The main outcomes of the event are:

- The Sprint Backlog, consisting of the stories with acceptance criteria that the team will be committed to in the next sprint

- The Sprint Goal

- A team agreement to do anything possible to achieve the goal

Some small considerations can be very helpful in increasing the effectiveness of Sprint Planning.

The Product Owner’s responsibility is to prepare a draft of the upcoming Sprint Goals prior to the meeting — some business objectives that would ideally be met. It is crucial to align with other Product Owners in case the team has dependencies on other teams’ work and progress. It can be very frustrating for teams when Product Owners come to Sprint Planning having given priority to work that cannot be done because of external dependencies.

Team members should do their homework, too. It’s common to have some research tasks that must be done before the Sprint Planning. These tasks usually answer questions related to architecture or future implementation.

Usually, the Product Owner starts the meeting by reviewing the proposed business goals. During the meeting, the team discusses the implementation and different options, elaborates on the acceptance criteria (together with the Product Owner), and estimates the effort required to complete each story. As soon as the team capacity has been established, the team agrees on one or more Sprint Goals, then they agree on the final list of stories.

Note that teams often pick more stories than they are able to achieve. A Scrum Master can challenge this, helping the team avoid frustration and disappointment.

Having a clear agenda has also proven useful. Following is a brief example of a Sprint Planning meeting agenda:

- The team determines how much work they got done in the past (per Sprint) and how much they could achieve based on their capacity. If you use NoEstimates, that would be expressed in number of stories.

- The Product Owner presents the business objectives and ambitions.

- The team discusses each story.

- The team and the Product Owner negotiate and finalize the selected stories. Planning stops once the team runs out of points.

- Everyone commits to the Sprint goals.

Chapter 47. Sprint Goals Provide Purpose (Beyond Merely Completing Work Lists)

Mark Levison

A Sprint should be so much more than just completing a collection of user stories or fixing bugs. If your Sprints are merely about ticking off items on a scattered work list without purpose or direction, your Development Team will take longer to become highly effective and your work will have less value.

The research[1] is clear:[2] people, whether acting individually or as a team, achieve more when working toward goals, and goals themselves benefit from being specific, challenging, and concrete.

In Scrum, we ask a Team to set a goal for a Sprint as an outcome of Sprint Planning. This provides stable direction, with flexibility to reevaluate work, throughout the Sprint to preserve and make the best progress toward the Sprint Goal. It is the why of a Sprint, establishing purpose and commitment.

A clear Sprint Goal helps the Development Team maintain a solid understanding of that why and what they’re attempting to deliver. By participating in setting the Goal, they have a sense of ownership and, on occasion, it helps them find better solutions to the problem than originally planned. The Goal provides focus in the Daily Scrum and an opportunity to refocus if the Sprint goes off track. Finally, the Goal is a key element for growing a group of people from a working group to a true team.

In my experience, most Sprint Goals are not clear. Some poor examples that I’ve seen are:

- Fix 10 bugs.

- Finish 7 unrelated user stories.

- Complete the work assigned to the team in Jira. (Yes, this is remarkably anti-Agile and ineffective; however, I see it all too often.)

None of these examples help focus the Team, nor do they provide clarity on what they’re seeking to achieve.

So, what makes a better Sprint Goal? A good Goal answers questions such as: Why is it worthwhile to undertake this Sprint? Are we attempting to solve a problem? Are we implementing a feature or clarifying an assumption?

Improved versions might include:

- Reduce the shopping cart abandon rate from 50% to 30% by improving usability and performance. This solves a problem. We’re losing sales because we have a poor checkout experience.

- Add filters to the existing product search results so that buyers spend less time finding items that meet their needs. This implements a feature.

- Offer free shipping for orders over $40. This tests an assumption that free shipping will increase the amount people spend per transaction.

Should the Product Owner set the Sprint Goal? No. It’s good for them to go into Sprint Planning with some business or product objective in mind, but it’s through negotiation with the Development Team that the actual Sprint Goal emerges, as all grow toward a shared understanding of what is desirable and achievable in the Sprint. “Achievable” means possible to accomplish while upholding the quality agreed to in the definition of Done.

Bob Galen suggests[3] that you imagine crafting an email to invite your whole company to your Sprint Review. What will you put in the subject line and first few sentences to entice them to attend?

That’s your clue for your Sprint Goal — the shared understanding, created between the Product Owner and the Development Team, of the desired outcome of the Sprint.

[1] Edwin A. Locke and Gary P. Latham, “Building a Practically Useful Theory of Goal Setting and Task Motivation,” American Psychologist, Vol. 57, No. 9 (2002), pp. 705–17.

[2] Edwin A. Locke and Gary P. Latham, eds., New Developments in Goal Setting and Task Performance (New York: Routledge, 2013).

[3] Robert Galen, “Sprint Goals — Are They Important?,” RGalen Consulting (blog), Aug. 3, 2016, https://oreil.ly/5B36I.

Chapter 48. Sprint Goals: The Forgotten Keys of Scrum

Ralph Jocham
& Don McGreal

The term “Sprint Goal” is mentioned 27 times in the Scrum Guide. That marks it as an important concept in Scrum. Yet in practice, it is arguably the least-understood Scrum concept. As the Agile Manifesto says:

Individuals and interactions over processes and tools.

This mindset is a cornerstone of agility and how teams self-organize. However, self-organization doesn’t just happen on its own. Counterintuitively, it requires defined boundaries (rules) and a clear objective (vision). The Scrum framework is a simple set of proven rules to cope with complex problems. Ideally, a clear product vision is established before the first Sprint and continuously communicated throughout. The Product Owner is accountable for this and can leverage the Scrum cadences to reinforce it. A good vision provides a Scrum Team with focus and motivation toward a shared objective. A vision, however, cannot be reached in one step. There will be several smaller stepping stones along the way. These are Sprint Goals.

Arriving at one goal is the starting point to another.

— John Dewey

Sprint Goals are an often-neglected aspect of a Scrum implementation. When not completely ignored, the Sprint Goal often ends up as just a list of random items off the Product Backlog (Goal: “finish Story #23, #45, #48, #51, bug #88”). This isn’t a goal — it is nothing more than showing progress, staying busy, and prioritizing output over outcome.

This commonly happens because the Product Owner does not really “own” the product and is just being told what to do. As a result, the work taken on in a Sprint becomes a random smattering of requests from different stakeholders with no overarching direction.

Here are some tips for establishing a solid Sprint Goal:

- Imagine a Scrum Team member being stopped in the hallway by a stakeholder excited about the next Sprint Review and asking, “What will we see?” They don’t want to hear about the 12 forecasted Product Backlog Items. They want to hear a more concise, higher-level objective being reached.

- An interesting practice is for Scrum Teams to name their Sprints. Instead of naming Sprints with some arbitrary names (like with hurricanes), try naming Sprints after Sprint Goals, such as the “Registration Sprint.”

- Try asking the question, “How does this Sprint get us closer to our vision?” The answer is likely a candidate for a Sprint Goal.

- If there are multiple Sprint Goals for a Sprint, it is likely a sign that we aren’t thinking cohesively enough. Pick one of them and make that the objective. Because, “When everything is important, then nothing is.”

The Sprint Goal provides a North Star for the Development Team, for which they create their own plan: the Sprint Backlog. As the North Star remains fixed, the plan may need to be adapted to changing circumstances, allowing the Development Team to be even more self-organized. During the Daily Scrum, the Development Team assesses its progress toward the Sprint Goal, collectively updating the plan instead of having a tedious status report meeting.

On rare occasions, the Sprint Goal may become obsolete, yielding no value. In this situation, the Product Owner has the right to cancel the Sprint. The Scrum Team can immediately plan another Sprint with a new Sprint Goal.

Setting realistic Sprint Goals is paramount, as sprinting without a clear goal just gets you to the wrong location faster.

Chapter 49. The Daily Scrum Is the Developers’ Agile Heartbeat

James O. Coplien

The core of Agile is the ability to respond to changing product demands. To do that, the folks working on the product need to be interacting closely.

Scrum is agile at several time scales. We have customer collaboration and frequent delivery at the Sprint level. Sprints kick off at Sprint Planning, with the team assembling their work plan for the upcoming development interval. But Sprint Planning isn’t the last word. The team learns about the product — how best to implement its envisioned Increment — day by day. The Daily Scrum is a Scrum Team’s agile heartbeat where Developers re-plan their work daily.

Briefly, the event is an all-hands meeting of Developers that is time-boxed to 15 minutes. Developers re-plan what they will work on next until the next Daily Scrum and perhaps beyond. To be able to do so, they need to quickly develop a consensus view of the current state of the development and of whatever impediments might lie in the way. Some teams, especially new ones, might use the famous “three questions” to inspect the current state and the desired trajectory. However, those are neither sufficient for nor necessary to the Daily Scrum. And standing up? It’s a reminder to keep the meeting short. But the Scrum Police won’t ding you if you sit down: they didn’t stand up in the primordial daily meetings at Borland that inspired the practice.

Change is rarely continuous, but it is discrete at some granularity of time. Simply inspecting and adapting once every two weeks is too seldom. And although the product changes with every atomic development action, synchronizing too frequently is irritating and inefficient. Humans are creatures of rhythm, and days are a natural human cycle.

During the Sprint, the team is on a trajectory to achieve a Sprint Goal: an agreed, measurable benchmark that usually reflects a business imperative. The developers’ Sprint Backlog is a work plan crafted to meet the Sprint Goal. The Sprint Goal is so paramount that the Developers commit themselves to it, but not necessarily to the Sprint Backlog. If they find a better way to implement a feature during the Sprint, they can freely change the work plan. The team consults the Product Owner (PO) to change the forecasted scope if it enhances the chances of meeting the Sprint Goal.

The Daily Scrum is the Developers’ meeting. Should the PO or Scrum Master be there? Maybe. An immature team may need the guidance of the Scrum Master as to the scope and purpose of the meeting and to enforce the time-box and cut off side discussions to solve impediments or about other topics not directly related to meeting the Sprint Goal. An immature team may too easily succumb to micromanagement by a PO, so it may be best to defer any PO interventions until the team builds an adequate degree of trust and maturity.

Too many teams use the Daily Scrum as a plug-compatible replacement for the pre-Agile practices it displaces. It is not a reporting meeting. If there is something that developers need to communicate to the PO or Scrum Master, they can do that any time without having to have a meeting. It is not just to answer the three questions. It is not a group hug. It is a way for the team to mark daily progress and to inspect and adapt their way to delivering value by achieving the Sprint Goal.

Chapter 50. The Sprint Review Is Not a Phase-Gate

Dave West

Teams use Scrum to solve complex problems by breaking work down into small Increments, doing the work to create that Increment, and then inspecting the results to potentially change future work and pursue different outcomes. Scrum helps teams learn and expand their knowledge and capabilities by incrementally learning by doing work and delivering value. This is the essence of an empirical process.

The cadence and flow of Scrum are easy to understand. Work happens in a Sprint, the Sprint Goal and work are planned at the Sprint Planning event, and the outcomes of the Sprint are reviewed in the Sprint Review. The Sprint Review focuses on Product Increment, which is the tangible output of the Sprint.

Many organizations treat the Sprint Review as a phase-gate, at which time work is “approved.” Doing this reduces the value of the Sprint Review by limiting learning that could improve future outcomes. The best Sprint Reviews evaluate from customers actually using the Product Increment. The review is then based on real data and experience. For a software product, that could mean letting customers use it and collecting data and feedback on their experiences.

Treating the Sprint Review as a phase-gate may do two things:

1. Reduce transparency by hiding unexpected or even negative results from stakeholders. If the Sprint Review is a meeting where stakeholders get to decide if the Product Increment is released, and the Scrum Team is measured on the Product Increment being released, the team has an incentive to hide unexpected news from stakeholders. Not only does this reduce the dialogue between the team and stakeholders, but it also may release “stuff” that is harmful to the organization.

2. Reduce the value of learning by reducing the ability for real customers and users to provide feedback. Everyone may think they know how a user will use a feature, but until they get it in their hands, those ideas are just opinions. By getting users using the Increment as early as possible, that feedback can be discussed in the Sprint Review and add more value to the review.

To improve the Sprint Review, teams should increase the speed of learning within the Sprint and focus Sprint Reviews on sharing insights with stakeholders. This increases the value of the Sprint Review, and it also delivers value to customers faster. Sign-offs and other governance tasks should simply become part of the work done during the Sprint. A great way to ensure transparency is to document the required product qualities in the definition of Done.

De-coupling the planning and review from release decisions provides the team with the flexibility to release when they need to. The learning gathered by doing this provides insights that can power more effective Sprint Reviews and Sprint Retrospectives. Releasing more frequently also puts more pressure on the release process, flushing out impediments and driving improvements.

By focusing the Sprint Review on inspection, the focus of the planning process shifts to getting the most learning by delivering value as soon as possible. Challenges such as quality and governance become opportunities for automation, collaboration, or changes to team composition. The result is a continuous learning process. Sprints provide a cadence that helps reduce the complexity of the transparent process.

Chapter 51. The Purpose of Sprint Review Is to Gather Feedback — Period

Rafael Sabbagh

The Sprint Review meeting begins. The Sprint is near the end. The Development Team and the Product Owner show the clients and other stakeholders what they built during that Sprint. The attendants watch and listen but do not say much except to ask a few basic questions during a Q&A session following the demo. At the end, they give their approval over the work done, applaud, and leave. The meeting is over and is considered a success!

An alternative scenario is that clients and other stakeholders do not approve the work, grumble instead of applauding, and go away, leaving everyone with the feeling of a failed meeting.

Do you recognize these scenarios? Honestly, I can imagine only one worse scenario, and that would be for clients and stakeholders not to be present.

Essentially, both scenarios suffer from the same problem. Has the team any clue whether the clients and other stakeholders understood what was shown? Did they even care at that moment about what they saw? Will they still not care once the product is released and it turns out it doesn’t fulfill their needs?

The purpose of Sprint Review in Scrum is not about obtaining a formal approval (or rejection) of the work that was done in the Sprint. It is about something much more important than a thumbs-up or an “approved” stamp on the contract. Actually, it is not even a meeting to deliver or hand over anything. The goal of the Sprint Review meeting is to gather feedback about the product Increment generated in the Sprint. As a team, you want to learn from clients and other stakeholders what they like, what they don’t like, what they miss, and what they think might be great to add. The team wants that feedback in order to tune the product in the next Sprints; add, remove, or tweak features; improve stability; or even change course more drastically, if not pivot, if needed. It is in the interest of the Development Team and the Product Owner — and therefore it is their professional obligation — to encourage clients and other stakeholders to provide feedback at the Sprint Review. Invite them not just to follow a demo, but also to use the product while you observe them and learn about the actual use of the product. Encourage them to ask questions all the time. Spark their creativity by asking for alternatives.

And if clients or stakeholders grumble, show their discontent, or bring up or point out stuff that is not exactly the way they believe is the right way? Don’t be tempted to go into a defensive mode. Be glad. That is extremely important feedback. You have just learned important information about how to potentially improve the product. That is why we build and evolve product little by little, incrementally, with frequent reviews. And frequent releases. It is actually the best risk-mitigation strategy possible, right?

Help anyone invited to your Sprint Review understand its purpose by moving from the question, “Clients, can you approve what we have done?”, to the question, “Clients, this is your time! What do you believe we can change or add to what we are about to share in order to make sure it fulfills your needs?”

Chapter 52. A Demo Is Not Enough — Go and Deploy for Better Feedback

Sanjay Saini

Quite a while ago, I was working with a team using Scrum for a manufacturing client. We were working on a software product to be used in their material handling activities. Our software was to be deployed on the tablets of the tow motor operators. Their job was to move bar-coded hardware material from one rack to another. While doing so, they had to update the new location, where the materials would now be located, and other details of the moved materials. It was a 100% touch-based system with no mouse or external keyboard involved.

The team started development based on an initial set of requirements. We were able to quickly show wireframes to the users, and we got their buy-in. We had great Sprint Reviews and even additional intermediate demo sessions with our customer and the users. We got important feedback from them that we could still take into account in upcoming Sprints. All in all, everything went well, and we made good progress. Everyone involved, including the shop floor manager, was very excited. The day came that the software was deployed on the tablets, ready to be used by the tow motor operators.

Much to our surprise, it soon turned out that the operators were not able to operate the cool new software, although it was technically of high quality and had successfully been reviewed with the team, repeatedly. Everyone, however, had overlooked the fact that the operators, due to security guidelines, had to wear specific gloves. Unfortunately, after deploying the software on the actual tablets for actual use, it turned out that the buttons were too small. Choosing and pressing the required buttons while wearing gloves was simply not possible. We had to roll back to the old software and start redesigning all screens. Nobody ever brought this up in any of the discussions with the Development Team.

It was a long time ago. It was a manufacturing environment. But it left me with an important lesson that I have taken with me in every project since, regardless of the type of environment.

A software demo, in or beyond the Sprint Review, in itself is a good practice for getting early and frequent feedback. But it cannot replace the information gained from real usage by real users. I observe how often in Sprint Reviews the teams, or potentially the Product Owner, are using and controlling the software — not the customers and users. It often results in demonstrating what the team and the Product Owner want to show, which is not guaranteed to be what the customer needs to see or know. At Sprint Reviews, the working software is often demonstrated to customers in a safe environment while the team keeps control.

My humble request for Scrum practitioners is to give the control to your customers/end users. Let them play with your product and provide you with feedback, and this works best in an environment that reflects or is the actual end-user environment.

Chapter 53. Have Sprint Retrospectives and Structure Them

Steve Berczuk

“Inspect and adapt” is pervasive in the Scrum framework; all events in Scrum serve the process of inspection and adaptation. Two of these events mark specific feedback points: the Sprint Review, during which the team “inspects” the product work in order to adapt the plan (Product Backlog), and the Sprint Retrospective, where the team inspects their process and adapts that in the next Sprint. Of all the Scrum events, Sprint Retrospectives are often given the least thought and are the least appreciated, often skipped, compressed, or organized in a way that may not provide the best feedback. They are quickly dismissed as overhead, although, ironically, if any event makes the best use of people’s time, it is the Sprint Retrospective, if it’s well organized.

I’ve been to many retrospectives that were short and unstructured, a combination that almost always ensures that they will not yield useful results. A valuable retrospective is one that captures the challenges and successes a team has and yields actions a team can perform to improve the process. Doing this requires an environment where everyone on the team feels open to participation and where the participants filter topics so that the more important ones get talked about, instead of the first ones mentioned.

Effective retrospectives have a structure and a facilitator. I like the five-part framework described in the book Agile Retrospectives (Pragmatic Bookshelf, 2006) by Esther Derby and Diana Larsen. The five parts are to set the stage, gather data, generate insights, decide what to do, and close. This framework provides a clear structure that contributes to creating an environment where people feel comfortable to actively engage and where the discussion leads to actionable items that lead to solutions of real problems.

Other approaches can also work, but effective Sprint Retrospectives always need three key elements: a way to enable engagement and safety, a way to distill and prioritize ideas, and concrete action items. I also like to end with “appreciations” so that the team understands how everyone adds value.

Opening with rituals that encourage participation and emphasize a focus on improvement rather than blame creates safety for people to raise even the most difficult challenges. Following a structured technique to gather concerns, group related ones, and decide on what to discuss helps ensure that the group addresses the utmost important issues that need addressing, rather than just having a collegial chat. And concrete action items that are doable are the best way to ensure that the team (and management) sees value in the time spent on the Sprint Retrospective.

Managers and technologists often think that capturing feedback and developing plans for change for a process is easy, especially compared to other work like delivery. Developing trust that the retrospective will produce meaningful, actionable change is hard. A good retrospective is harder than simply asking, “What’s up?”, letting people vent, and quickly moving on to the next Sprint. Having some structure helps the team focus and be productive. Building a good retrospective habit takes time. You need to commit to having a retrospective at the end of each Sprint — for a few Sprints — to give the team (and management) a chance to see that they can be valuable, which allows the retrospective to be regarded not just as acceptable, but as highly required.

Chapter 54. The Most Important Thing Isn’t What You Think It Is

Bob Hartman

There are numerous words and phrases that describe Scrum done poorly. We have Scrum-but from the early days of Scrum. We have Dark Scrum. Some people have used the terms Scrummerfall, Water-Scrum-fall, or WAgile. The problems can all be vastly different, but the end result is the same: organizations don’t achieve the results they would achieve if they used Scrum effectively. Most Agile coaches would say, “They are doing it wrong if they aren’t succeeding.” The sentiment may be correct, but what is the solution?

In my experience, there is one key thing that improves the ability to succeed with Scrum. It is obvious, and yet most organizations completely miss it. It is the way Scrum is designed with the transparency, inspection, and adaptation feedback loop from empirical process control. Everything in Scrum revolves around those three pillars of empiricism. The most important thing for Scrum to be successful is to continuously pay attention to those three pillars. Is the team being truly transparent to the Product Owner, stakeholders, and customers? Is everyone honestly inspecting what is being created and how it is being created? Based on the results of those inspections, are adaptations being made to the Product Backlog and the way of working? I generally see teams fail on all three counts. This is why the Scrum Guide says Scrum is simple but not easy.

“What’s the solution?” is a great question deserving an answer. In my Certified ScrumMaster workshops, I make sure to start with an exercise around problems and solutions. I use this exercise to point out that the most important thing in Scrum is to have valuable Sprint Retrospectives. In other words, use the Sprint Retrospective to continually improve. If you don’t use the Sprint Retrospective to continuously improve, then you aren’t adapting, and you won’t ever get the full benefit of Scrum. Many organizations overlook that this adaptation toward continuous improvement is an integral part of Scrum. Scrum is about learning and improving. It is designed to point out flaws that need to be fixed. Ignoring any of the three pillars is disastrous, but this one, adaptation, in my experience, is the most often overlooked and the most valuable when done correctly.

While we are at it, let’s mention the other two pillars. We have problems with transparency and inspection as well. For example, if someone is asked, “We are halfway through the project, what percent completion have you achieved?”, the likely answer is to say, “50%!” It is a fear-based reaction that is unlikely to be truthful. To overcome this tendency, we need to nurture a nonjudgmental environment, an environment that encourages openness because we are all in it together and where no one is judged on individual results.

For inspection, we need to remember to get the right people inspecting things. The CHAOS reports from the Standish Group have consistently rated user, customer, and stakeholder involvement as one of the main keys to having successful project results. We need teams to get closer to users in order for us to get valid feedback from inspections of the work.

Every team should ask how they can be more transparent, improve their ability to inspect, and not be afraid to adapt. It starts with using the Sprint Retrospective effectively!

Part VI. Mastery Does Matter

Chapter 55. Understanding the Scrum Master Role

Luis Gonçalves

A Scrum Master is like a lighthouse in a Scrum Team that consists of (besides the Scrum Master) a Product Owner and a Development Team. The Scrum Master provides guidance to the team based on the tenets of the Scrum framework.

A Scrum Master is responsible for supporting three groups of people: the Product Owner, the Development Team, and the organization.

In doing so, the Scrum Master role encompasses three high-level concepts.

1. Scrum Master as Change Agent

Scrum Master is an important role in any organization. A Scrum Master has a deep understanding of how teams progress on a day-to-day basis.

Scrum Masters are facilitators of Sprint Retrospectives as an opportunity to surface trends and recurring problems.

Although knowing the problem is just one step in assembling change, Scrum Masters know what has to be changed in an organization to help a team improve. Scrum Masters are usually in the position to suggest essential changes in the organization using various problem-solving tools, like an impediment board.

2. Scrum Master as Servant-Leader

The Scrum Guide identifies Scrum Masters as servant-leaders. Being a servant-leader involves having others’ involvement in decision making, having strong ethical and caring behavior, and helping to enhance the growth of the team while improving the organization.

3. Scrum Master as Mirror

It’s important that the Scrum Master acts as a “mirror” for the team. With the help of the Scrum Master, the team checks if what they’re doing reflects the values of Scrum and Agile.

With the reflection of the team in a mirror, team members can receive open questions from the Scrum Master that will lead to the general improvement of the team.

Some small considerations can be helpful for Scrum Masters to increase their effectiveness. There are several first action items you can perform within your first weeks as a Scrum Master in a company, although it is also helpful to consider doing these again regularly:

- Schedule one-on-one conversations with team members to gather insights into their biggest concerns about the team and the company.

- Organize a workshop to help clarify everyone’s role, obligations, and expectations.

- Set up a coaching alliance to reflect your work with the team.

- Do a stakeholder mapping exercise to get to know the people who work in the organization who have a strong connection to the team’s work.

- Install team policies to keep the basic working etiquette.

- Organize a one-day team-building workshop to establish teamwork, principles, values, and product vision in the team.

- Create an achievements wall for the team to celebrate their wins and motivate them to strive for more of them.

- Create a kudos wall to help team members show their mutual appreciation.

- Set an impediment board to visualize the impediments you are addressing in the organization, possibly inviting the team to help you.

- Establish communities of practice as an instrumental framework to reinforce a cross-team learning atmosphere in your company.

Chapter 56. How I Learned That It’s Not About Me, the Scrum Master

Ryan Ripley

There is a hard truth you must face when taking on the role of Scrum Master: it’s not about you.

This realization caused me many sleepless nights as I spent over a year making the transition from project manager to Scrum Master. As a project manager, I used to be the center of attention. I had the plan that was going to get the team across the finish line. I gave the presentations to the steering committee. I was the person demonstrating the working software and fielding questions, occasionally asking a developer to help when I did not have specific, technical details. Anyone having a budget issue? I handled that as well.

As a Scrum Master, my experience taught me I had to change, which I gradually did (much to my own satisfaction and improvement of my stress levels).

The Product Owner is fully empowered to set the strategic, tactical, and financial course of the product. The Development Team is accountable for delivery and for quality. No one, not even a Scrum Master, can tell the Development Team how best to do their work. As they noticed how I started enacting the preceding, stakeholders stopped calling me and went straight to the Product Owner or Development Team with their questions — certainly during the collaborative Sprint Review event.

Looking back, I realize how I needed to become a servant-leader. Following are a few measures of a servant-leader that helped me grasp this better:

- The success of the Scrum Team is far more important than my own individual accomplishment.

- Servant-leaders are measured by how others are thriving and growing.

- Those who choose to follow a servant-leader do so because they are inspired, not because they are told to do so.

When a Scrum Master falters as a servant-leader, anti-patterns emerge:

No ability to experiment.

When a Scrum Master “solves” all the team’s problems, the Scrum Team will not learn how to experiment, and they lose a great opportunity to practice self-organization.

Scrum Team members withdraw.

Apathy sets in when Scrum Masters act as project managers. A disengaged team can lead to intra-team silos of knowledge, turning it into a group of individual contributors instead of a true team.

Whole Team concept compromised.

Every member of the Scrum Team co-owns the product. If a hero Scrum Master is solving all the problems, the Scrum Team becomes dependent on this hero behavior. Coaching others to solve issues and impediments can help make sure that teams grow, mature, and find success together.

The Scrum Master role is complex. If we perform as a servant-leader, great things can happen. If we falter, anti-patterns emerge, and team spirit suffers. There are three things I consider to be essential to becoming a Professional Scrum Master who has fully embraced servant-leadership:

- Love your team from a genuine desire to serve them.

- Share how you want your team to be wildly successful.

- Have zero tolerance for anything keeping your team from being wildly successful.

Consider where you are on your servant-leadership journey. Can you amplify one of these traits? Good, the world needs more people that realize it’s not about you, as a Scrum Master.

Chapter 57. Servant-Leadership Starts from Within

Bob Galen

Here are some snippets about the Scrum Master from the Scrum Guide:

The Scrum Master is a servant-leader for the Scrum Team.

The Scrum Master serves the Product Owner in several ways, including...

The Scrum Master serves the Development Team in several ways, including...

The Scrum Master serves the organization in several ways, including...

Clearly, service is a fundamental part of the role of the Scrum Master. But there is something missing from these service-oriented focal points. And I actually think it’s the most important one.

We talk about Agile leadership being an inside-out job. Leaders need to start inside ourselves and work on serving ourselves, examining our own strengths, needs, and goals, and then align ourselves with Agile principles and Scrum Values. Getting them deep into our DNA, our bones, if you will, puts us in the right mindset to be effective Agile leaders.

I think that the same concept applies to Scrum Masters. They can often become too focused on serving others and forget about themselves.

Here are some examples of what Scrum Masters serving themselves looks like.

They give themselves the opportunity and space for curiosity. For asking questions that lead to improved understanding. For exploring things. For casting a wide net to see what the possibilities might be. And, as they find things, they don’t immediately feel the need for action. That is, they can just revel a bit in what they’ve uncovered.

They give themselves space for renewal. Let’s face it: the role can be incredibly challenging for a variety of reasons. It could be that their team is truly struggling to find their way with Scrum. Or it could be that their organization has “assigned” four teams for them to shepherd. They allow themselves sufficient time for relaxation without guilt. They get enough sleep and take time off for themselves and their significant others.

They empower themselves to ask for help — unconditional help. For example, if someone on their team is really proving to be a challenge, they ask another Scrum Master or leader or coach for help and feel safety and encouragement in doing so. If they don’t know something, they have the courage (and safety) to say: “I don’t know.” And they find a role model and mentor to pair with who is there to help them learn and grow.

They serve themselves by fostering disengagement from their roles. They give themselves the ability to ignore a situation to see what happens. To not take immediate action on a problem to see if someone else might pick it up. To see what might emerge. To not always feel responsible for serving and acting, but instead for creating the opportunity for others to be Scrum Masters, to be masters of Scrum too.

They serve themselves by finding quiet space. For quietness. For getting away — for example, taking a walk in the middle of the day. Space to quietly read a book for an afternoon to find inspiration for new ideas and growth in their role. Or the space to envision a new level of effectiveness for their team.

I believe the key mental model for a Scrum Master is one of servant-leadership. But an essential part of that is serving themselves first. When Scrum Masters do this wholeheartedly, they become a more holistic and balanced member of their Scrum teams.

Chapter 58. The Court Jester at the Touchline

Marcus Raitner

Servant-leadership in general and the role of the Scrum Master in particular are grossly underestimated because the impact of this new form of leadership is rather indirect. Like a gardener, they foster conditions for successful cooperation. The value a Scrum Master adds, standing like a football coach at the touchline during the game, is easily overlooked. Sooner or later, a Scrum Master will therefore be offered “real” work, like a coach being expected to take a role on the field. And the Scrum Masters who are not well aware of their actual accountability or are trying to avoid conflict will accept. The much more important long-term work on the system and the continuous improvement of the organization are then left unaddressed. But nobody notices anymore because everyone is busy with “real” work.

Have you ever experienced this? The Scrum Master being abused as a jack of all trades? Because, after all, a Scrum Master is supposed to “help” the team and the Product Owner. The Scrum Guide says so! For sure, that must include working a little bit within the team or at least taking some of the annoying project management tasks off their hands, such as reporting and documentation.

Even if that were true, is it also helpful?

The Scrum Master is supposed to take care of impediments, right? Yes, the Scrum Guide includes “Removing impediments to the Development Team’s progress.” And the Scrum Master serves the team, the Product Owner, and the organization. Indeed, and again the Scrum Guide clarifies, that this is to be understood as servant-leadership — as help for self-help.

An example of an impediment that we run into regularly is the Development Team being bothered with status reporting. This is an impediment to be tackled by the Scrum Master, but the actual dysfunction isn’t resolved if the Scrum Master devotedly takes over the reporting work from the team. The real challenge is to show that the required reporting slows down the team, doesn’t add value to their development work, and then, together with the recipients of the status report, find a better way to satisfy their real and hopefully legitimate interests.

Inexperienced Scrum Masters are afraid of addressing the conflict between the demands placed on them and the actual accountability of their role. It is by no means easy to disappoint such expectations, especially when it makes a Scrum Master liable to being blamed for letting down the team and avoiding responsibility. Many have never experienced it differently and are more or less happy to be pushed onto the field, for which some urgency can always be called upon. But in doing so, these Scrum Masters forget the seemingly less urgent but more important long-term work on the system.

The job of Scrum Masters is not to seek popularity and avoid conflicts. Scrum Masters can be expected to question and address unhelpful organizational practices and related interactions between the organization and the team. A Scrum Master working the system like a modern court jester can only succeed with the right perspective and the necessary independence. This is why the touchline is where the Scrum Master should be.

My hope for Scrum Masters around the globe is to keep this in mind every time they are tempted or pushed to go do “real” work.

Chapter 59. The Scrum Master as Coach

Geoff Watts

Coaching has forever been a part of the Scrum Master role. This is because servant-leadership of a self-organizing team has always been a part of Scrum. However, back in 2001, when Scrum first began getting traction, few understood what “coaching” meant.

Despite great advancements, there is still confusion about and many inconsistencies in the coaching aspect of the Scrum Master role.

According to the International Coach Federation (ICF) — a leading professional coaching body not associated with Scrum or any Scrum organization specifically — coaching is:

Partnering with clients in a thought-provoking and creative process that inspires them to maximize their personal and professional potential.

The ICF goes on to say, “The coaching process does not include advising or counseling, and focuses instead on individuals or groups setting and reaching their own objectives.”

I find this definition important because to become an effective Scrum Master, I followed a professional coaching pathway, and many great Scrum Masters I have coached have done similarly.

It is my firm belief that any coach should actively work toward the independence of their client — a great coach does not create a need for their services. Similarly, in my book, Scrum Mastery (Inspect & Adapt Ltd, 2013), I expressed two fundamental pieces of advice for Scrum Masters:

1. Ask the team.

2. Make yourself redundant.

Scrum is designed to help teams and organizations deal with complexity. In complex work, where it is difficult to predict what we need to do or how best to go about doing it and where changes occur regularly and rapidly, we need autonomy. There simply isn’t the time for a decision to be escalated up the chain of management responsibilities and back down again.

In such work, it is also unlikely that the person at the top of that chain of command will know more about the work than those doing the work — in fact, it is almost certain that they will know less than the combined brains of the teams doing the work!

Therefore, the job of management is to provide servant-leadership. They need to create an environment where the people who have the skills to get the job done also have the confidence and support to make the necessary decisions and experiments to find out how to do it.

This comes through coaching. Asking the team and the individuals within it questions to help them think it through and make decisions. In my book Product Mastery (Inspect & Adapt Ltd, 2017), I talk about asking CHILD questions: questions that display a genuine Curiosity and Humility, questions that help Illuminate the situation for the team, Limitless questions that challenge assumptions about our constraints, and Direct questions that get to the heart of what we are doing.

A Scrum Master who can engage a team as a coach will thrive in our complex, unpredictable, fast-changing world of work.

Chapter 60. The Scrum Master as a Technical Coach

Bas Vodde

The best Scrum Masters I’ve encountered spend part of their time as technical coaches for their teams. Unfortunately, it seems that most Scrum Masters do not do this. To me, this seems like a lost opportunity, since spending effort on technical coaching for your team can help them enormously, and it will help you with your other Scrum Master responsibilities.

It often comes as a surprise when I suggest that a Scrum Master could (or even should) do technical coaching. It shouldn’t! Technical coaching isn’t explicit in the Scrum Guide, as it was written to be applicable to both technical and non-technical work. Therefore, technical coaching is only mentioned as “Helping the Development Team to create high-value products.” That is unfortunate. However, some other great Scrum resources do refer to technical coaching explicitly, such as Michael James’ Scrum Master Checklist. In the checklist, one of the four focus areas for a Scrum Master is, “How are our engineering practices doing?”

A Scrum Master doing technical coaching has three important benefits:

- It improves the team’s development practices.

- It lets you experience the real problems the team faces. This helps you in deciding where to focus the team, the Product Owner, and organizational improvement work.

- It keeps your technical skills up to date.

There are many activities for a Scrum Master to “do.” Some examples from my own work as a Scrum Master are:

- Pair up with team members. (This is the most common activity.) Just announce during the Daily that today, you would like to pair.

- Set up your computer so that you can build and run tests.

- Refactor some tests and code and have a sharing session with your team.

- Create some unit or acceptance tests.

- Organize a learning session about technical Agile development practices. Use your team’s code as an example.

The biggest risk is of becoming too involved in design decisions, as the team could start depending on your contributions. You can avoid this by:

- Never planning your development time in the Sprint.

- Never picking up a task from the Sprint Backlog.

- Avoiding making decisions. When asked for your opinion, provide many alternatives and keep reminding the team that it is their decision.

It shouldn’t be hard to add technical coaching to your work as a Scrum Master when you have development experience. It just requires you to prioritize and plan for it. One option is to plan one or two days a week to focus on this. As the context-switching might make it hard, alternatively, you can dedicate a Sprint on technical coaching and try to limit other Scrum Master activities.

If you do not have development experience, it will require more effort. It is possible to learn the basics of development and the purpose of Agile development practices while being a Scrum Master of a team. You can ask your team for help. Tell them, “I want to improve my development skills, could you help me with that?” Work out a plan together and dedicate time for learning. Spend a lot of time pairing, but avoid asking too many questions, as it will slow down your pair and they will become annoyed.

Good luck with the technical coaching as Scrum Masters; I hope you will find it as rewarding as I do.

Chapter 61. Scrum Master, Not Impediment Hunter

Derek Davidson

During my two decades working in the Agile space, I’ve experienced some interesting perspectives on the role of Scrum Master. One such perspective is that Scrum Masters should remove Development Team members where applicable — for example, when they become an “impediment” to the rest of the team.

If that sounds odd to you, you’re not alone. I did some research, and the following is what I learned as justification for that type of Scrum Master behavior.

A Development Team that is suffering because of a long-term, ongoing issue with a poorly performing team member has an impediment. When the Development Team is unable to resolve an impediment for itself, Scrum requires that the Scrum Master remove it. Hence, the Scrum Master removes the developer from the Scrum Team.

In theory, the reasoning is valid. It agrees with what is written in the Scrum Guide. But it also makes it seem as if Scrum is being used as a veneer for “command and control” practices and runs contrary to the spirit of Scrum.

When I read the Scrum Guide, my focus goes to the top item under the section “Scrum Master Service to the Development Team,” which states, “Coaching the Development Team in self-organization and cross-functionality.”

In considering how to coach the Development Team in the “remove the developer” scenario, I might suggest bringing in a specialist to help. Why not consider asking for help from a work psychologist or a work coach? Somebody who can share skills so the Development Team can handle the situation for themselves and from whom you, as a Scrum Master, can learn too.

On reflecting upon the initial perspective, I suggest that it establishes a dangerous precedent based on a highly exceptional scenario: the precedent that the Scrum Master has authority to do anything in Scrum. Just label an issue an impediment, express the view that the Development Team cannot resolve it for themselves, and then take whatever action the Scrum Master wants:

- Can’t agree on a definition of “Done”? Impediment! Next: here’s a version that I have created for you.

- Can’t agree on an estimate? Impediment! Next: here’s what the estimate is.

What then do you do when different approaches accord with the Scrum Guide? We’re lucky in that we can ask the authors of the Scrum Guide, and so the last word goes to Ken Schwaber:

The Scrum Master can coach, teach, establish learning situations, enter Socratic dialogue, and parent. However, they weren’t given the authority to manage the other members of the Scrum Team.

Chapter 62. Anatomy of an Impediment

Len Lagestee

The Scrum Guide states the Scrum Master has a responsibility to the team to remove impediments; but just what is an impediment? One dictionary defines an impediment as “a hindrance or obstruction in doing something.” From a Scrum perspective, the “doing something” is the ability to produce and deliver valuable outcomes within an ecosystem of flow and agility. There are different types of “hindrance or obstruction.”

Anything Constricting Flow or Constraining Pull in the System

The measure of success for a Scrum Team is how well and how frequently the needs of their customers are being met. A blanket term for impediments keeping us from serving customers with the least amount of resistance is friction. Friction comes in many shapes and sizes:

- Unnecessary approval gates and defensive processes, such as testing sign-offs or governance committees, are examples of process impediments and characterize an untrusting environment.

- Leadership decision escalations and status reports are examples of legacy impediments and characterize an organization not fully embracing an environment of agility.

- Poor craftsmanship and the lack of decisiveness from the Product Owner are examples of capability impediments and characterize a team without accountability.

Friction impediments are frequently ignored, as they often touch upon sensitive areas, such as quality and leader behavior, so the comfort of the status quo will be a challenge to overcome. This changes with you.

Anything Causing Team Tension to Rise Beyond Constructive Conflict

Whereas friction impediments will slow a team down, tension impediments will drag a team down. Tension impediments bubble up when there is a conflict with personality and working styles and the team does not have the ability to resolve that conflict on their own.

These impediments often manifest when someone on the team is struggling with self-awareness or with breaking old habits. Other team members will attempt to compensate for this person by saying, “This is how they have always been,” or by ignoring it altogether.

Tension impediments exhaust a team and, left unchecked, will create dysfunction and burnout. Step in early before tiny fractures become broken relationships.

Anything Keeping a Team from Self-Healing

Self-healing impediments keep a team from evolving beyond their current condition. Without the ability to sense, learn, and respond, teams will not have the ability to be resilient when stressors hit them.

When retrospectives are not providing the space for a team to wrestle with impediments, it’s just a matter of time before they will lose strength and begin to revert to old habits and behaviors. The team relies on the Scrum Master or coach to be able to foster a safe environment for open dialog required to address friction and legacy impediments.

To conclude, every impediment has a story and a deep-rooted origin in something broken within your team or organization. In fact, the current state of your organizational culture is often revealed through your list of impediments.

But impediments are more than just a list. Research, explore, and listen to what each impediment is telling you, then take action with vigor and bravery. The health of your team depends on you.

Chapter 63. The Scrum Master’s Most Important Tool

Stephanie Ockerman

Throughout my career as a Scrum Master and Professional Scrum Trainer, I have found that transparency is an incredibly helpful — yet much underrated — tool. Scrum Teams and organizations benefit from transparency for almost every challenge, including what they are building and why, how they are building it, and their progress toward goals. Without a sufficient level of transparency, any attempts to inspect and adapt are less effective in achieving desired outcomes. By focusing on increasing the breadth and depth of transparency, a Scrum Master enables effective self-organization, team ownership, and better problem solving. I believe a Scrum Master’s most important tool is transparency.

Transparency is more than just tracking information and making it accessible and visible. Just having a Scrum Board doesn’t make a Scrum Team’s progress transparent. Just having a Product Backlog that is available to stakeholders doesn’t make the plan for maximizing the value of the product transparent. What really counts for transparency is having better conversations, frequently enough and with the right people, that lead to a shared understanding.

One of the tricky challenges for a Scrum Master is to enable and give support without undermining self-organization. Often in the spirit of “helping,” Scrum Masters may point out people’s problems and lead them to the solutions the Scrum Master thinks will work. At best, this achieves a few benefits, but it does not unlock the true power of creativity, collaboration, and bottom-up knowledge creation. At worst, it creates a dependency on the Scrum Master, resentment among team members, and poor solutions.

Whether you are working with a struggling Scrum Team or an experienced Scrum Team encountering new challenges, transparency is the flashlight. Teams don’t need to know the entire path ahead to move forward; they need to illuminate what is in front of them so they can make an informed decision and take the next step in the right direction (certainly knowing that the entire path ahead is full of unknowns anyhow). And if they happen to get it wrong, transparency will help them find that out quickly and course-correct. It’s why we organize work in these short cycles called Sprints.

Scrum Masters can hold a flashlight for the Scrum Team and the organization to inspect where they are and where they want to be — then they adapt to move a few steps forward.

As a Scrum Master, create transparency in the information that helps guide a Scrum Team’s decision-making. What perspectives are missing? Where is there not yet a shared understanding? What is not being said? What is holding the Scrum Team back right now?

Create transparency in learning, progress, and value. What trends does the team see, and what might that mean? What information would help confirm there is a problem or need? What outcomes might indicate a change is successful?

Whether Scrum Teams are struggling with bottlenecks in their process, gaps in skills or knowledge within the team, entering into productive conflict, quality issues, making clear decisions, keeping up with competition or changes in the market, adopting new technology, increasing value delivered, breaking through limiting beliefs, or managing stakeholder expectations — transparency is the key. As a Scrum Master, help them see more clearly; hold that flashlight so they can determine the best way forward.

Chapter 64. When in Trouble...Break Glass!

Bob Galen

One of the challenges when leveraging Scrum is knowing where to go when you’re in trouble. Let’s define trouble first:

- You’re in over your head.

- You’ve encountered a situation for the first time.

- You’ve just gotten back from a certification class.

- You’re not in a safe culture.

- You’ve got many problems hitting you at once.

So, when you’re faced with such adversity or seemingly intractable situations, where do you go? As you dig deep inside yourself, where do you look?

Here’s my secret sauce for handling these circumstances as a Scrum Master and coach.

First, I take a deep breath and try to get quiet. I’ve discovered that reacting quickly, without thinking, is never a good idea, although it is sometimes highly attractive. The counterpoint to this — getting quiet and finding a direction — is counterintuitive.

Second, I review the basics of Scrum. I’ve found that I often react to complex problems with complexity thinking and a sense of urgency and panic, or I’ll consider quite complex interaction patterns that I might apply. In other words, I get sucked into the chaos. When this happens, I remind myself to center on the fundamentals.

But center on what, specifically?

To me, the fundamentals in Scrum revolve around Empiricism: transparency, inspection, and adaptation, combined with the five Scrum Values: Commitment, Courage, Focus, Openness, and Respect.

I try to create transparency so that the system can reflect upon itself. So that, whatever the challenge I’m facing, it becomes clearer. A big part of this is staying curious to discover, rather than to act. So, discover root cause first, then explore possible reactions to it with my team.

I remind myself to reestablish my commitment to the team and dedicate myself to an effort focused on helping first (not resolving). I remind myself of the commitment to our stakeholders and customers, who are depending on us to sort through things, and to commit to myself that I can gather the confidence to guide the team toward a solution.

I remind myself to have the courage to tell the truth. In other words, if I don’t know, then say I don’t know. Or if I need help, I ask for help. Or if the problem is outside the system, then I have the courage to face it head-on and treat it as an impediment.

I remind myself to focus on the challenge at hand. To not be deterred by other, cascading problems or context complexity. To be relentless in the pursuit of a better state or a solution. Not alone, but by engaging the team and the organization. So, helping everyone to have a singular focus.

I remind myself to keep an open mind to whatever happens. To have the mind of a problem discoverer rather than a problem solver. Much of the challenge when dealing with the chaos is that we aren’t open to different possibilities for different solutions. We’re stuck in what has “always worked.” Instead, I remind myself to look beyond the usual.

And finally, I remind myself to stay respectful. Respecting the ability of the system to repair itself from within rather than through outside intervention. And respectful of myself by remaining calm and focused amid the chaos. In fact, I respect everything I encounter and never judge, staying open to the discoveries that empiricism can uncover.

I guess to me, the fundamentals are my Scrum Lighthouse.

If I find myself getting lost, I look to the fundamentals for guidance. They’ve never let me down.

When I react to chaos with chaos, I get sucked into it. But when I react to chaos by centering on the fundamentals, I’ve always found my way. I hope you find yours as well.

Chapter 65. Actively Doing Nothing (Is Actually Hard Work)

Bas Vodde

“What do Scrum Masters actually do all day long?” is a hard question because the behavior of a Scrum Master is very contextual. The answer depends greatly on the maturity of the team, the experience of the Product Owner, and the amount of dysfunction in the organization. I use the “five tools of Scrum Masters” for clarifying what a Scrum Master does, when they do it, and why:

1. A Scrum Master asks questions.

2. A Scrum Master educates.

3. A Scrum Master facilitates.

4. A Scrum Master actively does nothing.

5. A Scrum Master interrupts (in exceptional cases).

These tools require little clarification, except probably the tool I use most: actively doing nothing.

Actively doing nothing means that when you observe non-optimal dynamics or plainly wrong behavior within your team or organization, you chose to not do anything at that moment.

A way to clarify actively doing nothing is to contrast it to its opposite: passively doing nothing. Passively doing nothing means you do nothing, and you don’t care. However, actively doing nothing means you care, you carefully observe what is happening, and decide...to do nothing.

For example, you notice two people from two different teams having a minor conflict about which team ought to do what. You observe and listen carefully, ask yourself whether this will cause permanent team damage, and if not...you chose to do nothing.

By actively doing nothing, you actually do something. You create the space for the team to take responsibility for the situation they are in. By doing something, anything, you are taking the responsibility away from them, and you prevent the team from solving that problem and from growing as a team. Therefore, as Scrum Master, I often observe the situation, think about the team and organizational dynamics, and consider whether not doing anything would cause harm. In most cases, it doesn’t. If it doesn’t cause harm, then there is often an opportunity for team self-learning and growth. Thus, I force myself to not do anything other than to actively continue my observation.

Actively doing nothing might be followed up with actively doing something. For example, ask questions to help the team reflect to solidify the learnings they have from resolving that situation. Or, ask questions to help the team reflect on what they could have done differently so that, next time, they might be able to resolve the situation. Asking questions is often followed up with two of the Scrum Master tools: (1) facilitation when questions lead to interesting discussions and potentially decisions, and (2) education when the questions lead to a learning moment.

Actively doing nothing is hard, and this often comes as a surprise. It is hard because, as a good Scrum Master, you care about your team and you want to help them. You want to resolve the pain they are in by jumping in. However, a good Scrum Master realizes that this will not benefit them in the long run. Building a team means you need to create the space for the team to resolve issues themselves, learn from it, and grow.

A potential problem with actively doing nothing is that it will look like you are doing nothing, that you are not adding any value. Many of the teams for which I was a Scrum Master joked that I don’t do anything. They noticed the team worked better when I was there, but they often couldn’t see why. Indeed, it seemed like I was…actively doing nothing.

Go out and become a better Scrum Master by actively doing nothing.

Chapter 66. Guiding Scrum Masters on Their Never-Ending Journey with the #ScrumMasterWay Concept

Zuzi Šochová

My #ScrumMasterWay concept describes three levels that great Scrum Masters should operate on: My Team, Relationships, and Entire System.

Being Scrum Master at the My Team level feels like being a team member. It means looking at things from the Development Team perspective: explain different Agile practices, facilitate Scrum meetings, help remove impediments, coach the team, and look for improvements. In other words, using all five Scrum Master State of Mind approaches. My Team level is a great start. It will help Scrum Masters demonstrate the success of Scrum and show the team a way to the next level of addressing product success and building an Agile organization. They become not only cross-functional and self-organized, but more productive, always improving, proactive, and they’ll take over the ownership and responsibility for the overall goals. They are no longer a group of individuals, but a great team. You recognize it through a high level of energy, positivity, and activity in the team. If you do it right, and your organization is not too dysfunctional, with people actively fighting against what you build at the My Team level, you will be ready to move to the next level in about six months.

The Relationships level brings a higher perspective where Scrum Masters are not only focusing on the Development Team, but also on the broader system. They look at all relationships their team has with anyone outside of it and use a mix of the Scrum Master State of Mind approaches, focusing on teaching, mentoring, facilitation, and coaching skills, to improve relationships between the Development Team and managers, Product Owner, customers, stakeholders, and other teams. For example, you may coach the Product Owner to build a great vision, facilitate a conversation with other teams, help a manager understand how to change their performance reviews, introduce scaling frameworks, and much more. Whatever helps the bigger ecosystem become self-organized, consistent, and coherent. And if you do it right, and your organization is not too dysfunctional, with a lot of politics and difficult stakeholders, in about three years, the whole ecosystem will be self-organized, and you’ll gradually gain more time to the next level, which is that of the Entire System.

As organizations are complex, you can operate at this level forever. There is always some change that needs your attention, there is always a better way to do things, there is always a better way of work. At this level, Scrum Masters will look at the organization as a system, from a ten thousand–foot distance, searching for organizational improvements and better structure, culture, leadership, and organizational agility. At this level, Scrum Masters become servant-leaders, helping others become better leaders, grow communities, and heal relationships. Bring the Agile values to the organizational level. Address the system in its whole complexity and turn it into a self-organizing network of great teams. At this stage, you can see your organization as a living organism. This living organism has one goal, about which no one has doubts. This system takes experiments and learns from failures. The safety, transparency, and trust are deep in the system’s DNA. The culture values collaboration and trust, which presents an opportunity to come up with more innovative and creative ideas than in hierarchical, traditional structures.

Being a Scrum Master is a never-ending journey. The #ScrumMasterWay concept can guide them.

Part VII. People, All Too Human

Chapter 67. Teams Are More Than Collections of Technical Skills

Uwe Schirmer

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

The preceding quote from the Scrum Guide is often interpreted as meaning, “Have all the skills needed to technically accomplish the work.”

As a consequence, staffing people for a project is often done by only focusing on availability and skills. The impact of the individuals’ personalities on the success of the team is easily ignored, as are other factors that affect how a team works and the outcomes they produce:

- Do they have a shared vision and purpose?

- Are they empowered to do what must be done?

- How is the quality of collaboration and interaction in the team?

The intensity and quality of interaction between team members is important for the interpersonal relationships that the team members develop. It reflects whether the team behaves as a whole, which is crucial for the overall performance of the team.

The intensity and quality of interaction between team members depends on the personalities of the individuals and on the mix and compatibility of the personalities within the team, more than on their collected technical skills.

People who are accountable for building teams often acknowledge this and subsequently aim for the perfect team composition. They categorize potential team members into personality types using assessment methods like Myers-Briggs Type Indicator (MBTI), DISC, Life Orientation (LIFO), Hermann Brain Dominance Index (HBDI), or Insights Discovery.

One interesting fact about all these assessment methods is that they typically use four personality types. This can indeed be used to better understand the behavior of individuals in a team and what drives and motivates them. But you cannot use them to construct a high-performance team at the drawing board. There is simply no recipe for building teams like there is for cooking a meal. No single person perfectly matches one personality type, not to mention that the interdependence between personalities is too complex to be planned.

The personality of a person is not fixed either. People show slightly different personalities in different environments. Even within the same environment, personality may change over time as experience and specific insights grow.

Assessment methods may help to better understand the behavior and needs of the individuals in your teams. However, how effective a team is in a certain composition depends on the work the team has to perform, how much interaction is required for that work, and the intensity and quality of the interaction. What kind of interaction is needed might be different for planning activities, for creative work, or for decision making, and it takes a different mix of personalities in a team to achieve the best performance for each of these tasks. There is no way to optimize for each individual type of work a team needs to perform, and team composition cannot be changed for each and every task. Both approaches will undermine team cohesion and stability, negatively affecting overall team performance and team outcomes.

So, the next time you staff new teams or change an existing team, take more into account than just availability, technical skills, and rigid personality assessments. Try to understand what personalities best fit into your team depending on their context. And, above all, take it to the team. You will feel the difference.

Chapter 68. Are People Impediments?

Bob Galen

A good friend of mine did a survey a while back asking a simple question: Can the Scrum Master “fire” a team member if they’re an impediment?

The word fire in this case was ambiguous. It either meant fire directly, as in termination, or it meant simply removing them from the team, with or without having another place for them to land.

It created quite a stir of comments, and I think the final numbers were 65% against removal and 35% for, with approximately 200 respondents.

It absolutely floored me that 35% of the respondents thought it would be OK to remove a person from the team. I likened it to voting them off the island. I also found it alarming that many of the resulting comments seemed to place operating in Scrum above operating within a human system. That is, it seemed to forget the Scrum Values of respect and courage — in this case, respect for the individual and the courage to coach and mentor them.

As you can probably guess by now, I weighed in on the no side of the fence, for three main reasons:

1. I don’t believe many Scrum Masters have the experience and training to undertake an HR action like this. It’s certainly not in the role’s description in the Scrum Guide.

2. I don’t believe people are impediments. I have the same visceral reaction when folks refer to people as resources. People are people, and they are wonderfully unique. I really don’t care for folks categorizing them in such a way as to make actions appear less severe or impactful.

3. I think there are conditions in organizations adopting Scrum that are beyond the Scrum ecosystem. And people and their performance are certainly one that is on the edge of the ecosystem, if not entirely outside of it.

For example, what if the person has an illness that is affecting their performance and team interactions? Or what if the team isn’t interacting effectively with the person because of a diversity issue? Or what if they recently had a death in the family and are struggling with grief? Or what if…

What about team impediments? I think of impediments as anything that prevents the team from reaching their Sprint Goals. But it excludes the people on the team, as people are not impediments to be excised or removed.

Instead, I think they are coaching and servant-leadership opportunities for the Scrum Master. They require respect and care, without reading anything into their behaviors. And they require the Scrum Master to clearly understand their own situational and experiential limitations.

When they are out of their depth, they need to immediately be willing to go get some help, for themselves and for the team member. And where might that help come from?

It might come from the management/leadership team members and from Human Resources. Even if these folks don’t understand Scrum, they are in a better position to help with the person than the Scrum Master often is. And at some fundamental level, the Scrum Master needs to let go, trust, and allow the system to figure things out.

The role of the Scrum Master is a challenging, rich, important, and often frustrating one. And it includes lots of surface area. But it also includes being vulnerable and knowing when to ask for help. And I believe this is, in essence, one of those situations.

Chapter 69. How Human Nature Overcomplicates What Is Already Complex

Stijn Decneut

Scrum is a framework for developing and sustaining complex products. Unfortunately, there are many misconceptions around the meaning of the word complex. The most common, and at the same time most severe, problem is mistaking complex for (merely) complicated.

It might be hard, but complicated problems can be solved with rules and recipes. With enough analysis, clever people can implement definite solutions. Complex problems are fundamentally different, as they involve too many interrelated factors with a degree of unpredictability. This makes it impossible to tackle complex problems with rules, processes, and best practices, hoping for a guaranteed outcome.

For centuries, empiricism has proven to be the best mechanism known to humanity for dealing with complex problems. It is even essential to the learning process of living creatures. You would not have learned to eat, speak, read, etc., without going through empirical learning processes of trial and error. You would not have progressed without continuous empirical adaptation. Scrum offers exactly that: empirical process control.

When facing complex challenges, up-front analyses and plans offer no guarantee for success. We need to let go of preconceived tactics and trust our ability to learn from experiments often and fast; we need to rely on a combination of expertise, experience, and our human ability to learn.

However, that doesn’t come naturally in a professional environment.

Throughout evolutionary history, guessing what’s going to happen to us in the next moment has been a key survival skill. As a prediction genius, our brain safeguards us from harm by seizing risks and opportunities quickly. Our brain prepares our body and mind for events right before they occur. Furthermore, this enables us to deal with the outside world at a fraction of the energy cost that it would take to process all available signals. We compile what we experience based on predictions, and we scan for small fractions of information to (in)validate our assumptions of what is going to happen. Every time the incoming fractions of information appear to confirm a prediction, our brain rewards us with a good feeling caused by releasing dopamine.

In other words, it costs little energy and feels good to (try to) predict outcomes. And that happens even when it doesn’t make sense. Our ancient survival mechanisms are somewhat at odds with the mindset that we need for dealing with today’s increasingly complex challenges.

For Scrum to succeed, we need to be aware that it takes deliberate effort to treat our (often unconscious) predictions with a healthy dose of skepticism, even when an irrational part of us is fully convinced that we should simply trust our predictions and our ability to predict. Humanly, this is harder than you think.

All of us — even those who fully understand complexity — tend to be overly optimistic about the predictability of our environment, even when it is actually complex and chaotic. We are naturally inclined to undertake analysis and planning to prevent unexpected events from occurring. In complex situations, these are actually irrational attempts aimed at controlling that which is fundamentally uncontrollable. We reuse solutions well suited for complicated problems to deal with complex ones.

Ironically, in that process, we overcomplicate things. Setting up elaborate methodologies, providing extensive templates, going into more details up front, and so on, actually cause us to lose control.

Chapter 70. How to Design Your Scrum for A-ha! Moments

Stijn Decneut

Continuous improvement is an integral part of Scrum. It is explicitly exercised at the Sprint Retrospective, but the ability to generate new ideas and capitalize on them is important at all times.

When it comes to creatively coming up with game-changing ideas and finding intrinsic motivation to execute them, nothing beats the experience that cognitive scientists call “insights,” more commonly known as “a-ha!” or “Eureka!” moments. We then experience a moment of ultimate clarity, connecting dots in a way we never could before. During such moments of insight, we experience high energy, joy, and motivation.

People typically have insights about work when they’re doing anything but working: having a shower, running, going for a walk in the woods (with or without the dog), doing the dishes, and so on.

Let’s build on cognitive neuroscience research to make our Scrum environment more insight-friendly. Although insights seem to appear suddenly and at random, studies have revealed that moments of insight follow predictable processes in the brain and that we can influence the likelihood of having them. We can create optimal conditions for insight moments by being in a relaxed, slightly happy mood; reflecting in meta about the problem; closing our eyes in a quiet place; and not focusing on finding a solution for the problem at hand deliberately.

If that sounds simple but not easy, then consider that we are Homo sapiens sapiens, able to reflect on and direct our thinking. We can make the deliberate choice to think of something pleasant. We can decide to look at ourselves and our problems in a more positive way. This may not make us profoundly happy about our problems in the long term, but it helps a great deal in finding breakthrough ideas with insights. Scrum Teams aware of this can help one another by creating a genuinely positive atmosphere in their team room, throughout their Sprints, and certainly in their Sprint Retrospectives.

Any human endeavor needs slack: time to sit, think, and reflect. Unfortunately, many Scrum adoptions are overly focused on volume — on delivering more — rather than on becoming better at what they do and thus increasing the value they deliver. Scrum Teams should make time available to reflect on their problems and challenges in meta, regularly, by asking questions such as, “How long has this been an issue for us?”, “Where do we see similar patterns?”, and “What would be different if this was no longer an issue?”

Given the importance of a happy mood, a bit of silence, and room for the mind to wander, the impact of the team’s location cannot be overstated. Teams may decide to go for a walk together in a quiet, natural environment or gather in a fun — but quiet — room during the Sprint or for their Sprint Retrospective.

The last condition, letting go, can be especially challenging. It helps to engage in a distracting, cognitively undemanding break activity after an initial conscious attempt at solving a problem, even, and especially, when it was unsuccessful.

Do these conditions guarantee that great insights will emerge? No, but they do increase the likelihood that insights will happen, leading to more creativity, joy, and motivation.

Chapter 71. Use Brain Science to Make Your Scrum Events Stick

Evelien Acun-Roos

I want to share what I learned from Sharon Bowman’s “Training from the Back of the Room” class that helps me increase the liveliness of the Scrum events.

Bowman explains how the human brain processes information and what you, as a trainer or a coach, can do to enhance people’s learning and thinking experience. Bowman defines six “trumps,” based on cognitive neuroscience, to employ in order to help people learn and think better. I now also use these in conference talks, online training, and the Scrum events.

Talking trumps listening.

Talking is a social activity. Talking improves the understanding of a subject much more than only listening. Conversing about new information helps your brain store it better. During a conversation, information is processed three times: by hearing it, processing it, and restating it. Ask people to talk to their peers or to restate something they’ve learned.

Writing trumps reading.

Writing is a physical activity that involves both body and mind. When you write as an addition to reading, you add the sense of touch to the activity. The more senses you use, the better you learn. Help people by asking them to practice drawing, outlining, doodling, or summarizing.

Movement trumps sitting.

When you move your body, you increase blood flow and oxygen. When your brain receives more oxygen, it gets a boost, which enhances thinking and learning. Get people’s blood flowing by standing up and walking around, or have them discuss in pairs or post sticky notes on a wall.

Shorter trumps longer.

Our brains disconnect if nothing exciting happens for 10 minutes. If you split your content or meetings into smaller parts, you’re more likely to keep people’s attention. Change the setting and your facilitation style and set shorter time-boxes for your meetings.

Different trumps same.

Your brain does not pay attention to boring things. To keep your topic or meeting from being boring, you can switch up and vary frequently the way you facilitate, present, or teach. Use surprising, exciting ways to get more out of a meeting or training.

Images trump words.

Images and sounds are stored longer in your brain than words alone. Help people create mental images, metaphors, and stories.

Once you understand how these trumps work and what their benefits are, you can use them in your Scrum events. Do you recognize the trumps when doing the following in your Scrum events?

Daily Scrum

Rotate the order of the team members’ contributions. Have the team members stand up.

Sprint Planning

Write down the Product Backlog Items on sticky notes and put them on a physical board to visualize (draw) the business value.

Sprint Review

Let stakeholders handle the mouse and the keyboard. Let stakeholders write or draw their feedback.

Sprint Retrospective

Try different formats to spark creativity. Stimulate everybody to participate in the discussions.

Sprint

Define short Sprints. Make a visualization of your definition of “Done” and put it on a wall.

I learned a lot from Sharon Bowman and her six trumps of brain-based learning. When you keep movement, vision, writing, images, brevity, and variety in mind, especially in your Scrum events, you stimulate thinking and learning, which can help you work more effectively!

Chapter 72. The Power of Standing Up

Linda Rising

In the early days of Scrum, back in the mid-’90s, the Daily Scrum was the hardest piece to sell. “What, another meeting?” “Every day?” Our preference to do it standing up presented an even more significant hurdle for adoption. Over time, as I began to be aware of the challenges Development Team members were facing due to their work environment, I began to look at the event differently. Not only did it ensure that people were actually talking to each other at least once a day, but it became a way to encourage people to stop sitting. I began to see more companies experimenting with other standing meetings. In one study, researchers found that sit-down meetings are, on average, 34% longer than stand-up ones, and yet they don’t produce more or better results. In an amazing presentation, Micah Martin shared how to pair-program when using a treadmill desk. The presentation referenced an article showing how earlier demise was correlated with more hours of sitting. Today, most workplaces have some kind of standing desk — definitely an improvement. The problem, however, still exists. Even with the introduction of Scrum and other Agile process improvements and innovative office furniture, most of us sit too much during the day.

It seems we need reminders or triggers to help us not sit all day. I recently visited a brand-new office in Europe. Everyone has standing desks, yet no one stands. It’s not that they don’t want to stand, but the default is sitting, and people forget to stand up. We came up with a couple of experiments that they will try. Perhaps you can, too. The first is to apply the Pomodoro technique and set a timer for the amount of time that feels right to sit or stand. Another experiment is to recommend that everyone move their desks to the “up” position when they leave to take a break, eat lunch, or head home, even if they are sitting at that time. When they return, they feel encouraged to stand, at least for a while. I’m curious to hear how such experiments work for you.

I believe we need to build on the heart rather than on a literal interpretation of any Scrum practice. Beyond following a set of rules to get through a mandatory daily meeting, we should add the power of standing and moving to improve communication and collaboration. We love moving together — hence, the history of dance, of running, of swaying at a concert. We have been doing this for tens of thousands of years. Of course, you should never impose standing. Someone might not be able to stand or not feel like standing on a particular day.

We need encouragement. It should be OK to stand during any meeting. It should be OK to move around and maybe even have a walking meeting. I say it at the start of my all-day workshops: feel free to stand and walk around. Don’t disturb others, but stand, move your chair to sit at an angle, lean against the wall, stretch. Don’t just sit and stare and believe that somehow remaining a fixture is the best way to get the most from the experience. This advice will work in your daily workplace as much as it works in my workshops.

Agile is about being responsive. Agile is about experimenting. Agile is about learning. This is how culture change happens. Let’s stand up more!

Chapter 73. The Effects of Working from Home

Daniel James Gullo

We spend more than one-third of our lives working. Over the past few decades, more of that time is being spent working from home. Accordingly, this situation warrants closer examination.

In 2001, a gathering of 17 individuals discussing how to improve the practice of software development resulted in the Manifesto for Agile Software Development, commonly known as the Agile Manifesto. From its overall focus on more valuable problem-solving and delivery, several statements were included to cover communication and collaboration.

Number six of the Principles states:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The Agile movement has essentially codified what has been a topic of interest from the social research field for many years. For instance, the term telecommute was coined by Jack Nilles in 1975. Agile confirms that human beings are inherently “wired” with a propensity toward socialization, learning, experimentation, responding to change, and so on.

Difficulties arise when team members are in different time zones. Email is highly ineffective. On projects where team members communicate solely via email (and other asynchronous formats), there is less team cohesiveness. The increased delays in response time lead to lags in decision making and seizing opportunities. Overall trust throughout the team and organization decreases.

Current technologies, which allow for streaming higher-quality audio and video content, can help teams collaborate, despite the distance. Yet the vast body of research tells us that remote work is inferior to in-person, face-to-face work.

Initially, there is apprehension and resistance in remote teams to being live on video all day. Sometimes there is a “big brother” vibe. Once individuals realize that each team member is in the same situation, the tension lightens. While working this way daily may be OK, it is vital to bring teams together regularly for key ceremonies, such as release planning, iteration planning, reviews, and retrospectives. A critical reason for convening in person is the team building that happens.

Oftentimes, leadership is apprehensive about the idea of working from home. Management feels that they lack control when they do not have direct line of sight with employees and their work. This mindset is a continuation of the 150-year-old paradigm that industrialization spawned with its lack of trust.

Examination of work-from-home situations has revealed how the initial benefits of increased work-life balance evaporate over time. Those who work from home tend to work longer hours with fewer breaks to compensate for the flexibility; they do not want to lose the perk. Working at home also pushes the worker into an “always on” situation as the boundary lines blur between professional and personal life.

When a worker is working from home with limited access to or contact with coworkers, a distorted sense of “normal” can emerge. Workers lack the immediate, nonverbal feedback through body language that signals cultural norms. Individuals often claim to prefer privacy and isolation, and yet they seek out social interaction with those with whom they feel comfortable, from a simple smile as feedback to praise and accolades that are verbally expressed with warmth. Additionally, working from home reduces the number of opportunities for team members to earn the respect and trust of their colleagues through interactions with other individuals. The virtual dynamic does not have the same effect.

Without direct, face-to-face interactions, teams are not able to effectively move through the stages of group development (forming, storming, norming, performing) originally described by Tuckman and confirmed by modern research, as described in Examining Tuckman’s Team Theory in Non-collocated Software Development Teams Utilizing Collocated Software Development Methodologies by John Crunk (ProQuest Dissertations Publishing, 2018). There simply aren’t enough opportunities for cooperation and conflict available for them to grow to a state of high performance.

Chapter 74. The Gentle Way of Change

Chris Lukassen

Making Scrum what you are rather than something you do is challenging for many organizations. In many ways, it’s akin to mastering a sport like judo. Here are six levers that you can adopt from the dojo (a martial arts training place) to ensure that your organization sticks to a discipline or practice.

1. Individual Motivation

The discipline required for change starts with personal motivation. Help people connect the Scrum Values to their personal values. Explore the behavior they invoke and how that is helpful — or not. Discover which practices of working with Scrum are disliked and experiment to tackle the discontent. The trigger you are looking for is the people taking ownership of the change.

True budo cannot be seen in technique, but in the way we live.

Marco Borst

2. Individual Ability

People can build on their motivation to do something to learn how to do it. Judo promotes two techniques for learning: the kata (controlled technique training) and the randori (training the technique in a realistic setting). In business, people are often sent to a training (kata) but are then required to apply new techniques in the old environment without realistic practice (impeding randori).

For new behavior to take root, techniques must be trained in a realistic way. Make sure that what you have learned is mastered in a way that it stands up to reality.

3. Team Motivation

We all have a deeply felt desire to be accepted, respected, and connected to other human beings. That works great within a Scrum Team. But Scrum is not something that happens only at the team level — it needs to be embodied by the entire organization. Human connections, therefore, prevail. A raised eyebrow, a curled lip, or a small shake of the head can wield more influence than town hall speeches.

4. Team Ability

As Scrum becomes the new state of the organization, it makes no sense to tell teams how to execute it. Engage teams for the impact they can create to gain buy-in and create collaboration. More importantly, teams are likely to collectively develop better solutions than a single individual can.

Co-create the “how” of the plan, but be firm on the change itself, and create a “safe” way for teams to get help without feeling embarrassed.

5. Systematic Motivation

Influence behavior by focusing on the non-human factors that support what you value. For example, if you value autonomy, what decisions will you no longer take and delegate or empower others to take? How are the formal rewards and incentives supporting or discouraging such new behaviors?

6. Systematic Ability

If you want teams to actually work together, then make sure they can sit together. If they need to learn from each other, make sure they have the room for that. If they don’t understand the impact of their product, make it easier for them to talk to customers. Changing “things” to achieve the behavior we want is much easier than changing people.

Focus, young Padawan, focus.

Yoda

The second founding principle of judo is seiryoku zenyo. This means “maximum efficient use of energy.” Ask yourself the question, “If everyone just did this one thing, would the rest fall into place?” It’s easier said than done and won’t happen overnight. Conduct experiments (small or large) to see what works, what doesn’t, and change how you work as you go.

Part VIII. Values Drive Behavior

Chapter 75. Scrum Is More About Behavior Than It Is About Process

Gunther Verheyen

Scrum is a framework — a skeleton process — that we complete into a way of working tuned to our time and context. A Scrum adoption requires more than the skeleton of rules, roles, and artifacts. Scrum offers room and opportunities for people to collaborate, explore, and experiment. Scrum is more about behavior than it is about process.

Values drive behavior. Scrum defines five core values: Commitment, Focus, Openness, Respect, and Courage. These values give direction to our work, behavior, and actions in Scrum. We are required to understand these values against the complexity and unpredictability that Scrum enables us to address.

Commitment

Commitment is typically — and wrongly — understood as a hard-coded contract. Exact results, however, are generally impossible to predict in complex challenges in complex circumstances. This is why commitment as an outcome of Sprint Planning was replaced with forecast. Commitment in Scrum is — in line with its true meaning — about dedication and applies to the actions and the intensity of our efforts. It can be illustrated by a team’s trainer stating, “I could not fault my players for their commitment” (although they might have lost a game).

Focus

Focus is increased through the balanced but distinct accountabilities of the Scrum roles. All work in Scrum is time-boxed to encourage players to focus on what’s most important now over considerations of what might potentially become important somewhere in the future. The players focus on what is imminent, as the future is uncertain. They learn from the present in order to gain experience for future work. The Sprint Goal and the Daily Scrums provide focus on the work needed to get things done in four weeks or less and on the simplest thing that works.

Openness

Openness relates to more than the transparency needed for and provided by the empirical process of Scrum. It also implies that all players are open about their work, progress, lessons, and problems and need an environment where such openness is encouraged. All are open for working with people, acknowledging that people are not resources (robots, cogs, or replaceable pieces of machinery). The players are open to collaborate across disciplines, skills, and job descriptions and with stakeholders and the wider environment.

Respect

Respect is an essential trait in a Scrum ecosystem that thrives on people collaborating and sharing their experience, regardless of their varying personal backgrounds. The players respect one another’s skills, expertise, and insights. They respect diversity and different opinions. They respect the fact that customers change their minds. They show respect by not wasting money on functionality that is not valuable, not appreciated, or that might never be implemented or used anyhow. All players respect the Scrum framework. They respect the accountabilities of Scrum.

Courage

Courage is needed to admit that requirements can never be perfect and that no plan can capture reality and complexity. Courage is needed to change direction, to consider change as a source of inspiration and innovation. It is the courage to let go of the illusory certainties of the past. Courage is needed to put quality first and not deliver undone versions of product in Scrum. Courage is admitting that nobody is perfect. The players show courage in promoting Scrum and use empiricism to deal with complexity and unpredictability. They show courage to support the Scrum Values.

Chapter 76. What It Means to Self-Organize

Michael K. Spayd

In Scrum, a team is supposed to be self-organizing, but do we actually know what that means? Self-organizing is a principle found in both nature (chemistry, biology) and computing (robotics, AI). According to Wikipedia, it means the following:

...a process where some form of order arises from local interactions between parts of an initially disordered system. The process [does] not need control by any external agent...The resulting organization is wholly decentralized, distributed over...the [whole] system...the organization is typically robust and able to survive or self-repair substantial perturbation.

Self-organizing is not “do whatever you please,” but rather occurs when there are constraints that a group of agents with professional freedom can collaboratively create around. When we are given lots of constraints — detailed process rules, tightly orchestrated schedules (for example, project plans) — our behavior becomes less intelligent and more bureaucratic (as in a traditional waterfall). When we have just a few, simple constraints — for instance, ones derived from long-term experience and a modicum of wisdom — the resulting self-organization can become emergently brilliant.

For Scrum Teams, the constraint against which they self-organize is the 19-page Scrum Guide, which is itself born of the experience of probably hundreds of thousands of iterations. If teams instead self-organize around their company’s version of Scrum — which is unconsciously designed to hide or protect the open wounds of a dysfunctional system — the result is likely to be less than successful since it is not guaranteed by a lineage of competent practitioners.

Perhaps your organization frequently overrides the decisions of Product Owners rather than taking the Scrum Guide to heart: “For the Product Owner to succeed, the entire organization must respect his or her decisions.” Or perhaps your Daily Scrum has become a 40-minute status meeting: “The Daily Scrum is a 15-minute time-boxed event for the Development Team. At it, the Development Team plans work for the next 24 hours.” The Daily Scrum should be the most exciting, action-packed, and informative 15 minutes of your day! If it is not, you may be organizing against the wrong constraints.

Many years ago, I distilled the Tao of Scrum: a very brief, mock Taoist version of the Scrum Guide. I reprint it here, as a possible inspiration for self-organizing around.

Underlying Tao

The Way is Transparent. The Way should be Inspected. What is Inspected should be Adapted to.

People

The Product Owner decides the what of the Way.

The Team decides the how and how much of the Way.

The Scrum Master serves the Way and tells others when the Way has been lost.

Events

Release Planning defines what users of the Way will find of value and by when.

Sprints are the Way of the Team and do not vary in length.

Sprint Planning defines the Way for this week and for next.

The Daily Standup helps the team Adapt to the Way for today.

The Sprint Review helps the users of the Way Inspect what has been done in two (to four) weeks’ time.

The Retrospective helps the team decide the Way forward by Inspecting the Way that is past.

Tao of Things

The Product Backlog is the Way in order.

The Sprint Backlog is the how of the Way for two weeks’ time.

The Sprint Goal is the Way of the Sprint Backlog and the Team.

The definition of Done must be agreed upon by all who follow the Way.

Chapter 77. Treating Defects as Treasures (the Value of Openness)

Jorgen Hesselberg

One of my favorite characteristics of Scrum is that it is so beautifully simple that it can be neatly summarized in the 19 pages of the Scrum Guide, which is updated periodically by Scrum co-creators Ken Schwaber and Jeff Sutherland. Although the essential elements of Scrum have remained largely unchanged since its inception, the framework continues to evolve, and the Scrum Guide has been updated four times as of this writing.

One of the most significant changes came in 2016, when the Scrum Guide introduced the five Scrum Values: Commitment, Courage, Focus, Openness, and Respect. The reason these values are so important is that they create the foundation for sustainable, high-performing teams. Without values to guide teams’ norms and behaviors, it’s easy to lose intentionality and direction. The five values, therefore, influence the way teams work and help us grow an organizational culture of continuous improvement.

Although each of the values plays a critical role in Scrum, I believe Openness is particularly important. Scrum Teams embrace empiricism, confront reality, and at times deal with inconvenient truths. That requires transparency (one of the empirical pillars of Scrum) and the mindset to view potentially uncomfortable information as opportunities for improvement, not something to avoid or sweep under the carpet.

One of the best examples I’ve seen of embracing Openness as a value was at Toyota, when I visited its lift truck plant in Indiana a few years ago. I felt fortunate to observe the factory and inspect the many techniques, practices, and methods that manifest the deep teachings of Lean. As we were going through the plant, I turned to the chief engineer and asked him about Toyota’s approach to handling defects.

The engineer smiled at me and let me know they were thinking of renaming “defects” to “treasures.” I remember getting confused — why would Toyota re-label their defects? And “treasures”? At first, it reminded me of some of the less-than-successful companies I’ve worked with before that labeled defects as “features” to help everyone look better on status reports.

The engineer quickly picked up on my puzzled look and explained: “We’re considering renaming defects to treasures because they are providing us with immense value. When we find a defect, it is a gift — it is revealing information about the system that will help us improve it. These are flaws we did not know about until the defect ‘told’ us.”

I could tell he was getting excited to explain further. The engineer continued: “We then go to the root of the defect, understand the cause for why it appeared in the first place, and then we fix the problem to ensure it never happens again. The system is now stronger, more resilient, and healthier as a result of this defect telling us this valuable information — it is indeed a treasure.”

The example illustrates the power of Openness: not only does Toyota confront reality by “welcoming” the flaw, they take immediate action on the root cause of the defect so that it does not occur again. As the engineer explained, the overall system has now been improved as a direct result of intelligence provided by the defect.

As you explore the other 96 Things every Scrum Practitioner should know, this one deserves to be near the top of your list: Openness and transparency are fundamental to Scrum and the continuous improvement mindset so clearly evident at industry leaders like Toyota.

Chapter 78. “That Won’t Work Here!”

Derek Davidson

I recall the story of an organization that embarked upon an Agile adoption and engaged a team of six Agile practitioners with proven experience to help. This Agile team was immediately presented with the challenge of using the experience of other organizations to come up with an idea to boost this organization’s adoption of agility.

The team took some time to look around and, from all possible improvements, decided to give utmost priority to stable teams. They found accompanying data that supported their view on how to improve. The idea was proposed to the senior leadership team, who appeared underwhelmed and immediately responded, “That won’t work here!”

Despite this initial rejection, the suggestion remained an important topic of conversation. It seemed this was somewhat to the annoyance of those in the senior leadership team, who were telling the Agile team, “Stop working on the idea of stable teams. That won’t work here. You are wasting time that we are paying for.”

But the Agile team believed absolutely that stable teams would benefit the organization. It addressed the challenge they were presented with, and they wanted to stick to their commitment to meeting the ambitions of the organization with regards to Agile, regardless of the resistance met.

Clearly, however, an open mind was needed for investigating a different approach, as was the courage to stick to their belief. So, the team collated data on staff used in the prior quarter and the work they had done. They constructed a simulation to test whether it was possible to deliver the work of that quarter with stable teams. The Agile team tried it multiple times and proved time and again that it was possible, even in this organization.

Buoyed by this discovery, they asked others in the organization if they could repeat their outcomes using stable teams. Upon their agreement, the Agile team began demonstrating that stable teams actually did “work here.”

The Agile team arranged another meeting with the senior leadership and attempted to overcome the feelings of discouragement from the previous management meeting.

They proposed the simulation to prove the case. The response from the senior leadership team came as a complete surprise, boiling down to, “Go! Let us know how it works out.”

This was one response the Agile team had not expected. But they were to be surprised even further. Remember the prior meeting where they were told, “Stop working on this”? Some of the senior leadership became their biggest advocates. The new phrase became, “Why aren’t we doing this already?”

I enjoy describing this experience to others because there are so many learning points in it. For me, the main learning point was the importance of trying a different approach. It’s no good having all the facts and data that convince you and your peer believers if they don’t convince others. Sometimes, you have to respect their perspective and find a connection with them.

I wonder: which learnings might occur to you?

Chapter 79. Five Sublime Aspects for Being a More Humane Scrum Master

Hiren Doshi

We all understand that every profession has a skill quotient that its acknowledged members need to achieve to be allowed to qualify and deliver. It’s a Doctor of Medicine for someone who wants to practice medicine, be a doctor, cure people, and save lives. An appropriate degree is required for practitioners to perform their work in an accredited way and call themselves members of a profession.

Similarly, there are educational degrees: authentic, time-tested certifications proving real-world, hands-on practical experiences that qualify us as Scrum Coaches, Scrum Masters, Agile Consultants, and so on.

What makes a better artist, beyond the technical skills, is the ability to see the world and empathize with the art it requires. Doctors can have a degree qualifying them as technically the best in their profession, but would you visit them again if they didn’t give you a listening ear? What if they don’t ask open-ended questions from their experience to seek first to understand, then to be understood? What if they prescribe medicine without taking into account your allergies, immunity, and other health conditions?

Similarly, there are some sublime aspects — call them invisible forces — that are needed to be an awesome Scrum Master, Coach, or Consultant and that can’t be ignored.

The five Scrum Values of Commitment, Focus, Openness, Respect, and Courage help create an ecosystem of trust upon which organizations can flourish. Similarly, there are five sublime aspects that helped me become a better Scrum professional and practitioner in today’s ever-evolving, beautiful, but at times chaotic world.

Empathy

Spend time with people to grow trust and respect. Respect cannot be demanded, and certainly not with titles. Be positive, keep an open mind, and believe that everyone is doing and wants to do the best job to their potential.

Humility

Serve people and teams willingly to make a measurable positive difference in their lives. Don’t be judgmental. Be vulnerable and put yourself out there for possibilities and opportunities. Use your experience, evidence, data, and facts as a compass to guide you in your decisions.

Compassion

Be mindful and down to earth, be tolerant, kind, and gentle toward the people around you, and encourage and motivate them. From faith in yourself and belief in your abilities, make some magic that is attractive for others to join.

Authenticity

Be honest, be genuine, and be real. Copying or imitating is easy, but that’s not you. Use your imagination and creativity and contribute something new and useful back to the community and try to leave this world a little better than you found it.

Forgiveness

Everyone makes mistakes. Holding on to hurt, pain, resentment, and anger will harm you more than the presumed offender. Let go, make peace with yourself, and learn the art of forgiveness and move on. Practice collaboration over competition. Practice meditation.

I don’t claim to completely master the preceding, and I honestly feel one lifetime is too short a time to achieve that mastery. But being mindful and practicing these values has helped me be a better Scrum Master and Agile Consultant, and I sincerely hope they can help you, too. If not these five aspects, what do you find are important values in professionals beyond their technical craftsmanship?

I wish you the very best in your agility path and will be very happy to collaborate with you.

Chapter 80. The Sixth Scrum Value

Derek Davidson

In October 2019, I was in the beautiful city of Vienna facing an interview panel consisting of Certified Scrum Trainers and Scrum Alliance staff. The scene for my interview was set with one of their opening questions: “If you could add one more Scrum Value, what would it be?”

That’s a cracker, isn’t it? I’d never considered the question before, and interviews aren’t really environments where you can slowly and reflectively mull things over. So, my answer, after just a moment’s consideration, was: humility.

It occurred to me, even at the time but certainly afterward, that any answer I gave was likely to be a reflection of my own experiences and beliefs rather than a reasoned, considered, intellectual response. It did trigger the process of thinking about why I choose humility.

I believe education is a wonderful thing. It elevates us as a species, and intelligence equips us to deal with our world more capably. However, it has a potential dark side. For a minority, education can lead to aloofness and arrogance. It becomes a way to evidence superiority. With the growing number of Scrum trainings and certification badges to be earned, the tribalistic competition between organizations might lead some to that position of superior thinking and considering themselves an “expert” who knows better than others.

In my experience, Agile coaching and Scrum training relies on connecting people and connecting with people. Arrogance is a significant barrier to achieving that state.

A counter to arrogance is humility, which is why it is my sixth Scrum Value. I constantly remind myself that my single brain is no match for the collective power of a Scrum Team, Scrum class, or coaching endeavor, no matter how much I think I know. And that is irrespective of my years of experience and the variety of circumstances I have been in with Scrum.

I remind myself that people are experts at being themselves. To help them, I need to understand them, at least in part.

A motto I aspire to is: “First, strive to understand.” I hope it makes for a better Scrum Practitioner, Scrum Master, Scrum Trainer, Agile Coach, and fundamentally, human being.

I commend humility as one possible way of improving you and the people you come into touch with.

Part IX. Organizational Design

Chapter 81. Agile Leadership and Culture Design

Ron Eringa

Agile development methods and specifically Scrum have become the mainstream way to develop software-driven products. In the 2019 edition of an annual global survey by VersionOne, 72% of respondents say that they are using Scrum or a hybrid that includes Scrum.

Of those using Scrum, 83% state they are either still maturing or are not mature at all at implementing Agile. For the past several years, the top three reasons for this low level of maturity are:

- The organizational culture is at odds with the Agile values.

- There is general organizational resistance to change.

- There is inadequate management support and sponsorship.

Developing modern products and services requires many skills and disciplines to work together. It requires an ecosystem that stimulates collaboration, knowledge sharing, and connectivity. In order to survive in this digital age, we depend heavily on teams that are driven by goals and their urge to create an impact. When a set of individuals becomes a team, they will change the way they make sense of their world.

As leaders, we need to update our leadership style and design an environment of safety for our coworkers to collectively take on more responsibilities and help our organizations grow more mature. Only then will we achieve what we desire by moving toward Agile to satisfy customers by continuously focusing on delivering valuable, high-quality products and services.

We need to understand how our leadership style, our own behavior, and the environment affect team dynamics. To better understand this relationship, studies have investigated how humanity has developed different leadership styles when they discovered new breakthroughs in their living environment.

These studies show how we humans tend to change the social structures we live in and the way we manage them in line with the larger changes around us.

The Industrial Revolution brought social structures based on achievement, self-expression, and individual performance. Over the last 150 years, schools, enterprises, and governments have used these principles to measure progress and success.

With the development of the internet, social media, and mobile phones, self-organized knowledge and social communities have increased on a global, national, and company scale. These social structures require a people-centered leadership style based on support, inclusion, diversity, and distributed decision making.

The operating system of most traditional organizations, however, is still based on the old leadership principles that stimulate individual performance, efficiency, making a profit, and mass production. These operating systems are not designed for team collaboration, autonomy, self-organization, and fast decision making. That is why many Scrum Teams experience resistance when they want to take more responsibility. They bump into a glass ceiling, and it prevents them from moving forward.

As leaders, we need to question ourselves and figure out how our leadership style invites teams to make more decisions themselves, while gradually shifting our organizational structures to support and promote self-organization.

We need to be one step ahead of the teams by choosing our leadership style and preventing them from hitting the glass ceiling.

Chapter 82. Scrum Is “Agile Leadership”

Andreas Schliep
& Peter Beck

We would like to briefly explain what Agile Leadership is, why and how Scrum works as a framework for Agile Leadership, and how to put it into practice.

Agile Leadership is the way to lead others to decisions in a fast-changing environment following the values of the Agile Manifesto. Scrum is a framework that helps an organization optimize for more agility and transform the existing culture to align with the Agile values. The founders of Scrum also coauthored the Agile Manifesto.

The Scrum framework defines only the absolute necessary rules and artifacts and the leadership responsibilities of three roles:

- Product Owner is a leadership role through making decisions to maximize the value relative to the investment. The Product Owner serves the Teams and the whole organization by giving them focus through prioritization.

- Scrum Master is a leadership role through improving capabilities of the work system. The Scrum Master globally optimizes the organization and supports the Teams and the Product Owner by making decisions on perfection goals. The Scrum Master’s second focus is to develop the Teams continuously.

- Team member is a (shared) leadership role (with the other Development Team members) through developing solutions to increase customer satisfaction. The Team can even be considered the most crucial leadership role because the Team is managing the actual work and producing the actual solutions. Furthermore, the Teams are supporting the Product Owner by balancing opportunities and risks. They are also helping the Scrum Masters in identifying improvements for the work environment.

Scrum as a framework challenges an organization to build a leadership system based on these three forces. This triangle is stable enough not to swing to one side of a force but remain as adaptive as possible. Most important: you cannot not lead. Leading people is done all the time, by everyone.

Bringing Agile Leadership into an organization is a never-ending venture. The following advice helps you to put it into practice:

1. Use Scrum to learn Agile Leadership. You and your colleagues can’t learn the Agile values from a book or a webpage. They must be internalized by a force-feedback loop of acting and experiencing. To do so, old habits must be actively avoided so they can’t interfere and create chaos. It is also wise to start the journey in the complex domain, where change is at home.

2. Use principles as the leading model for leadership. This will help you carry out the understanding of Agile Leadership to areas outside the complex domain. Choose methods — for example, Lean management practices like kanban and kaizen, or Extreme Engineering practices like continuous integration, test first, and so on — that are compatible with these principles.

3. Resist as much as possible the temptation to solve a problem by introducing a new leadership role or adding a new hierarchical layer. Stick to the leadership triangle offered by Scrum to stay as agile as possible. You may name the roles differently, but at their core, they should follow the leadership responsibilities defined in Scrum.

Chapter 83. Scrum Is Also About Improving the Organization

Kurt Bittner

Scrum is commonly considered to be a product delivery framework, and for good reason: Scrum helps teams to deliver a working, “Done” product Increment every Sprint. And there is nothing wrong with thinking of it in this way — frequently delivering value to customers is one of the most important benefits a team can achieve using Scrum.

But only focusing on product delivery actually sells Scrum short. Scrum is really a continuous improvement framework that has releasable product Increments as one of its more visible outcomes. But its real power is in helping both the team and the organization continuously improve their ability to deliver value to customers.

As a continuous improvement framework, Scrum focuses on three aspects:

Improving the product

Ideally, each Sprint delivers a working version of a product that reflects the priorities identified by the Product Owner. Working in a series of Sprints, the Scrum Team gradually but continuously improves the value delivered by the product.

Improving the Scrum Team

Every Daily Scrum is an opportunity for the Development Team to identify adjustments in what the team is working on and how it is working. The Sprint Retrospective takes this a step further, helping the Scrum Team to inspect, adapt, and improve its way of working in the next Sprint.

Improving the organization

The product is a means by which the organization delivers value to its customers. Over time, products and services come and go as the organization learns more about its customers. By helping the organization deliver value via products, Scrum helps the organization to use feedback from the marketplace to inspect and adapt and to improve its ability to deliver value. Each Sprint is an opportunity to advance toward organizational goals, as shown here:

An organization’s goals are cloaked in uncertainties: are they the right goals? Are they achievable? Decisions about which products to offer, which customers to serve, and the desired customer outcomes are all experiments that the organization runs to move toward these goals. Decisions that Product Owners make about their Product Backlog are also experiments to improve the contribution their product makes toward these goals.

Each Sprint is really a set of experiments that a Scrum Team undertakes in pursuit of some greater goal. The Sprint Goal is an intermediate target, a step toward that goal. During the Sprint, they measure their progress toward these goals, and at the Sprint Review, they assess what they achieved. The Sprint Retrospective helps them look for ways to improve their ability to progress toward goals. As they plan the next Sprint, they use what they learned to form new experiments that will take them closer to their ultimate goal.

Scrum is about delivering great products, but it is also about achieving something greater, for which product delivery is just the start.

Chapter 84. Networks and Respect

Paul Oldfield

It may not be immediately obvious, but Scrum is designed for networks rather than for hierarchies. Scrum is designed on the premise of self-organization. Trying to fit Scrum into a hierarchical organization creates many problems. Allow me to highlight one major aspect here.

Hierarchical organizations have a presumption of authority. Even within a team, levels of seniority matter. People further up the hierarchy are taken to be authoritative, no matter their level of expertise. A far better mindset to have, if self-organization is to work well and, in turn, for the network to work well, is that relationships are peer to peer; all people, if not actually equal, are at least treated as such. They do, of course, have different skills and knowledge and different levels of experience. It is these differences that are suppressed in a hierarchy but that make a network so valuable. What we don’t know, someone else in our network might. Similarly, at some other time, we might have the skills or information that others are looking for. Although the flow of information is bidirectional, there might be more going one way than the other. Don’t focus on this seeming inequality; focus on the value that both sides get out of the link.

This can be a particularly difficult change in mindset for people when they are long accustomed to hierarchical thinking. In hierarchies, the differential in flow is a key to advancement, and people are rewarded for making the difference obvious by being promoted higher in the hierarchy.

For a network to work well, we need to establish a principle of respect. See it as a specific elaboration of that Scrum Value. What works for me is telling myself: “Everybody, absolutely everybody, knows something important that I do not know.” Even if at first you don’t believe me about that, observe — look around you with openness. You will likely find out that there is more truth to it than you assumed. Keep telling yourself so that it becomes ingrained in your approach to the world as a whole — into your personal philosophy. Rather than striving to promote one’s own ideas in competition against everyone else, one now strives to develop the best ideas in collaboration with others. When we start with the idea that everybody knows something important, the dialogue turns toward trying to uncover what it is that they know — to elicit the good ideas, the useful thoughts.

Clearly this is helpful within a self-organizing Development Team, and with a bit of extension, it should help relations between Team, Scrum Master, and Product Owner. And yet it is the network outside the team that can add substantial value to the organization. Consider peer-to-peer relationships with other Scrum Teams on the same product but also with teams on other products. Consider relationships with other interest groups within the organization. And possibly most significant, consider relationships with groups outside the organization that have a wealth of knowledge on their various special interests, whether Scrum, software development, business domain, or anything that you need so that you can make your product into a great product and your organization into a great organization.

I want to invite you to think network (even within a hierarchy).

Chapter 85. The Power of Play in a Safe (but Not Too Safe) Environment

Jasper Lamers

I did the field research for my master’s degree in Social and Cultural Anthropology in Lloret de Mar (Costa Brava, Spain). Back then, in the early 1990s, the place had the reputation of being a modern version of Sodom and Gomorrah: a place covered in sex, drugs, and alcohol. I wanted to explore whether youngsters went there to go through some “coming of age” ritual or at least take some big steps toward adulthood.

I used the work of Johan Huizinga as guidance. In his book, Homo Ludens (Random House, 1938), he hypothesized that culture begins in — and is driven by — play, which he defined as “Any free activity which stands consciously outside ordinary life as not serious, and which absorbs the player intensely and utterly.” Huizinga argued that play is older than culture and both the start and the engine of social behavior.

My research largely confirmed my hypothesis. The adolescents I studied spent their holidays in Lloret de Mar “playing” at adult behavior: smoking cigarettes, staying up late, drinking alcoholic beverages, and of course, experimenting with seduction and love affairs. Many experienced ecstatic moments followed by inescapable feelings of misery. Meanwhile, they gained “adult wisdom” at an impressively fast pace, with Lloret de Mar as their “playground.”

Looking back today, I see those Lloret de Mar holidays as a “pressure cooker.” Since the playground is far from home, youngsters are free to experiment, fail, and learn rapidly, without the threat of rumors or the “wrong” people finding out. This makes it an excellent learning experience. Failing severely hurts but is accepted because it happens within the confines of a safe environment. What happens in Lloret stays in Lloret, so to speak.

In Scrum, it should work the same. Every Sprint is a pressure cooker to a certain extent. The team has full focus on achieving a result over a predefined time with as few distractions from normal (company) life as possible. To get the best results, it’s crucial to fail as fast as possible. The longer a team builds on wrong assumptions, the costlier it will be to fix. That’s why Scrum has this lightweight structure. Sprints are relatively short, and Daily Scrums ensure that no learnings are overlooked.

While the Scrum framework might be considered the motor, the Scrum Values would be the fuel. Curiosity, daring to fail, experimenting, continuous improvement, creativity — these are all about mindset, culture, and behavior. The company should help the Scrum environment stay safe. This includes trust and not breaking in. Just like in Lloret, there are things that happen in your Scrum that should stay in your Scrum.

Such a safe, focused environment will boost team culture and behavior. People will find the best ways to cooperate in a matter of days, sometimes even hours. The foundation of team culture is created in a “playground” serving as a pressure cooker. As Huizinga stated, “Culture is not only driven by play, but it also starts with it.”

Consider what safe means, though. You don’t grow wiser by playing it safe. The stakes must be high enough to ensure that people stretch beyond their current abilities. In a professional Scrum environment, the learning experience might be what value is to the team. But Scrum serves another purpose, too: the creation of value to customers, users, and stakeholders.

Our professional “playing field” should take place in our own version of Lloret de Mar — safe, but not too safe.

Chapter 86. The Trinity of Agile Leadership

Marcus Raitner

No matter what you might think of Scrum, the Scrum Guide beautifully describes three aspects of leadership in the context of Agile product development:

- At the center of value creation is the Development Team, which works autonomously and is self-organizing.

- As the “CEO” of the product, the Product Owner manages Product Backlog but — more importantly — leads through vision and direction.

- The Scrum Master, as servant-leader, helps the Product Owner, the Development Team, and the rest of the organization grow ways to work together more effectively.

Scrum defines no role like the traditional manager because many, if not all, of the traditional management tasks are distributed among these three roles.

More than in an additional role, the success of leadership in an Agile environment depends on three aspects that I call the trinity of Agile leadership: self-organization, orientation, and humane leadership.

Self-Organization

Value creation in Agile organizations is done by autonomous teams. Self-organization is not just important in Scrum but is an essential principle behind the Agile Manifesto and ultimately the result of applying Lean principles to the practice of software development. In fact, self-organization as an essential characteristic of effective product development teams is older than Scrum (1995) and the Agile Manifesto (2001) and is certainly not unique to software development. Back in 1986, in their article, “The New New Product Development Game”, Hirotaka Takeuchi and Ikujiro Nonaka described self-organization as one of six characteristics of the most successful product teams they studied. These teams developed products such as copiers, cameras, and even a car quickly and effectively.

Orientation

Autonomy requires alignment. The more self-organization, the stronger the need for orientation via a common vision. It is an alignment strategy that is far more powerful than task instructions. This orientation is an essential leadership task in Agile organizations and is therefore explicitly reflected in Scrum by the role of the Product Owner as “CEO” of the product. Rather than excluding each other, autonomy and orientation complement and even reinforce each other as long as leadership is based on purpose and trust rather than on command and control.

Humane Leadership

In addition to the focus on a common vision that provides orientation, proper leadership always has both a human and a systemic dimension. Leadership fosters a system and an environment in which people can develop their full potential and in which intense cooperation is made possible. This leadership, therefore, primarily serves the human beings, acting like a gardener trying to provide a fertile ground on which people can develop and good results can grow. This is why we have the role of Scrum Master. The role is often underestimated and misunderstood but is actually an implementation of such humane and systemic leadership in Agile organizations.

What Else?

In traditional organizations, the trinity of Agile leadership is all intermingled in a single manager. Depending on personal inclination and the situation at hand, typically, some aspects are overemphasized and others neglected, which creates an imbalance. An essential contribution of Scrum is, therefore, a clear differentiation of leadership through the strict separation of powers between the roles of Product Owner, Development Team, and Scrum Master.

The more rigorously Agile organizations implement this separation of powers at all levels (and also beyond the product delivery teams), the less the traditional type of manager is needed. Perhaps that’s why the implementation of the separation of powers, and thus the abolition of this traditional managerial role, is a good yardstick for the shift of an organization toward more agility.

Chapter 87. The “MetaScrum” Pattern to Drive Agile Transformation

Alan O’Callaghan

The beauty of the Scrum Framework is that all it takes to get going is a self-organizing Development Team equipped with a skilled Scrum Master and an engaged Product Owner utilizing a rigorously time-boxed, inspect-and-adapt cycle. And then the joy begins. The work of the Scrum Team inevitably collides with the legacy processes of the wider organization and reveals, systematically, all the problems in its product development processes. It is often only at this point that it dawns on people that sustainable agility requires either significant changes in the wider organization or giving up on many of the benefits envisioned by the people introducing Scrum and needed to increase the organization’s agility.

Each organization needs to find its own path to Agile transformation, but a pattern occurring in many of them is “MetaScrum”.

The thumbnail for this pattern is well described by Jeff Sutherland, James O. Coplien, and the Scrum Patterns Group in A Scrum Book: The Spirit of the Game (Pragmatic Programmers, 2019):

Scrum Teams are in place, but direction (or the threat of interference) from legacy management structures causes confusion about the locus of control over product content and direction...Therefore: create a MetaScrum as a forum where the entire enterprise can align behind the Product Owners’ backlogs at every level of Scrum in the organization.

The first known use of the MetaScrum pattern was at PatientKeeper in 2003. It was a regular forum for coordination around the entire portfolio of the company’s products by (senior) management. The CEO attended the meetings, without intervening but aggressively removing impediments that were raised. At 3M, a division chief executive takes the role of MetaScrum Product Owner. The Danish company Systematic and the Swedish Saab Defense organization have similar forums at the top of the management hierarchy.

Those examples are from organizations that might be described as fully Scrum. But the MetaScrum pattern works in transitional situations as well. Product Owners of new Scrum Teams often find themselves distracted by deluges of new requests from disparate parts of the organization. Managers try to interfere with Product Backlogs or, alternatively, are too passive in supporting the Scrum Teams that may have dependencies on external vendors.

In these situations, the MetaScrum allows the entire organization, at every level, to align behind the work being done by the Scrum Teams. It is the only place at which managers can raise new requirements and, provided the Product Owners’ authority is preserved (especially the right to say no), it forces individuals to compare the value of their particular issue with those of the wider organization. Often, it is only through the MetaScrum that some managers really get to understand the power inherent in the Product Owner role and the significance of their management of the Product Backlog. Some even begin to consider product ownership as a career move as a result!

MetaScrum is not a body for management control of the direction of products. But the transparency it engenders as the hub for all inter-product decisions sensitizes Product Owners to the strategies defined by executive management. The Product Owners can socialize their own plans, coordinate and resolve portfolio-level concerns, and shift priorities between products in a more assured alignment with the business goals of the wider organization. Senior management are better informed about how the Product Backlogs support corporate goals, and middle managers (often the source of unwanted interference) can more easily understand the overall priorities of their own particular concerns. In short, when applied, the MetaScrum pattern creates fertile ground for the more rapid evolution of the organization toward business agility.

Chapter 88. Scrum and Organizational Design in Practice

Fabio Panzavolta

A company that has been around for more than 30 years, with all its organizational habits and practices that were built up over that time, is much too complex a system to change as a whole over too short a time span.

In my work with such an organization, we did feel the need for change toward increased agility, however. We did not feel the need, nor did we have the ambition, to try to change the whole system in one large “Agile transformation.” Rather, we decided to make the transformation we aimed at implicit. We selected one tangible product and introduced Scrum for its further development and evolution.

Our ambitions were clear and twofold: 1) satisfying the CEO’s objectives of improving time to market, quality, and customer satisfaction for the selected product, and 2) revealing what should be improved in the organization.

After one year of experimentation and discovery, including improving the understanding of Scrum for all people connected to the product by using trainings and workshops, we had substantially improved the Development Team’s focus. Not only did this lead to improved quality and speed, but it also enhanced cross-learning within the team. An important hurdle we had to clear for this was getting the organization to accept that the team was now dedicated only to our selected product.

With regard to our second ambition, we revealed important organizational impediments to Scrum. We kept raising them with board members to keep up awareness. Collaboration between Business and Engineering remained an important improvement area. Product ownership was fragmented among too many people, affecting vision and direction. Management decisions to remove impediments tended to be slow. Employees were spread too thin, which limited their capacity to perform and learn from deep experiments. This was caused and worsened by the compliance pressure on employees: their “success” was measured by how they respected internal processes, rather than by indicators like customer satisfaction.

Our many experiments wouldn’t have been possible without all the people seeing the value of Scrum and relentlessly contributing in many ways to our company journey toward more agility. We know the journey will be long. We are gratified over every little improvement we make.

The support, help, and belief in Scrum by one of the board members has proven crucial, however. It is extremely helpful to have a promoter on your side who knows the organization inside and out, is able to open doors, and is willing to try different approaches to help remove impediments. It has been one of the success factors that raised the bar of experimentation at different organizational levels.

I feel we are the living evidence that improving time to market, quality, and customer satisfaction using Scrum is not possible without updating the organization, although Scrum has no rules on what an organization should look like.

I am curious to find out what is happening in your organization:

1. What’s been the biggest impact of Scrum on your organization?

2. Is there something you’re doing today that could be improved with Scrum?

3. What do you think Scrum couldn’t help to achieve that you were expecting it to?

Chapter 89. Thinking Big

James O. Coplien

Scrum, as originally outlined in the Scrum Guide, is a framework for developing, delivering, and sustaining complex products by a single team.[1]

These days, scaling frameworks promise to make the elephant dance as big organizations seek a slice of the Agile pie. They work in the sense that military hierarchy works, yet hierarchy is hardly conducive to Agile’s individuals and interactions. In a Scrum@Scale team-of-teams hierarchy, where each node has five subordinate nodes (other teams or individual developers), an organization of 625 people features an average of 7.5 hops between Developers. Small world theory[2] proposes that everyone on Earth is connected by, at most, six connection hops. Scrum@Scale establishes connectivity between 625 people that is not as good as society provides for 8 billion people.

But few Scrum developments need to be this big. Excuses for scaling include the assumption that a small group has small intellectual capacity and cannot handle the scope of a complex product. Yet the human mind is boundless. Another excuse is productivity, with Scrum talking heads speaking of increasing velocity by orders of magnitude through kaizen. If it’s between a better process and a larger organization, the choice should be clear. The Borland QPWs,[3] Skypes, and other gems of history testify to the ability of small teams to build large things.

Nevertheless, business is more than just five Developers, a Product Owner, and a Scrum Master. You need distribution channels, sales, and marketing. Good Product Owners have a team that may include a model shop, analysts, and many others. Personnel takes care of payroll and pensions. Support holds customers’ hands. We too often pretend we can divorce these from development, but that’s a myth from the “build it and they will come” days. Many of these folks need a good connection to development; these days, it goes by the name enterprise Scrum. And hierarchy doesn’t cut it.

How does small world theory handle it? With hubs. With the advent of the internet, we found that web pages exhibit a pattern of connection where very few nodes with a very high degree of connection tie everything together. Such networks are called scale-free networks.[4] In Carl Castillo’s figure from Wikipedia, we see the hubs highlighted. Each network has multiple “tops.” So it can be for an organizational structure.

Running an Agile enterprise is a matter of introducing such hubs and nurturing latent hubs, rather than routing communication through the least common manager. Scaled Scrum approaches recognize a few hub structures such as the Scrum of Scrums — far too few in number to be scale-free.

What are good hubs? Guilds. System testing. Architecture. Code stewards. The water cooler. Management is particularly important: weakening the management connection with empowerment programs leaves teams uncoordinated.[5] To be Agile means stepping back from the extreme fads of the moment and honoring what history has shown to work well.

[1] Jeff Sutherland, “The Scrum At Scale® Guide,” Nov. 26, 2019, https://oreil.ly/UKQpB.

[2] “Small-world experiment,” Wikipedia, last updated Feb. 21, 2020, https://oreil.ly/jWpni.

[3] James Coplien, “Examining the Software Development Process,” Dr. Dobb’s 19(11) (Oct. 1994): 88–95.

[4] “Scale-free network,” Wikipedia, last updated Feb. 25, 2020, https://oreil.ly/b-haU.

[5] Charles Heckscher, “The Limits of Participatory Management,” Across the Board 54 (Nov.–Dec. 1995).

Part X. Scrum Off Script

Chapter 90. The Origins of Scrum Might Not Be What You Think They Are

Rafael Sabbagh

If Scrum was applied to software development, it would go something like this: ...you form a team by carefully selecting one person from each [traditional development phase]...You then give them a description of the problem to be solved and...unsettle the team by saying that their job is to produce the system in, say, half the time and money and it must have twice the performance of other systems. Next, you say that how they do it is their business.

Wicked Problems, Righteous Solutions, by Peter DeGrace and Leslie Hulet Stahl (Prentice Hall, 1990)

Scrum, the framework as we know it today, was officially presented to the public in 1995. It captured the way of working that Jeff Sutherland and Ken Schwaber had developed starting in 1992. Sutherland and Schwaber frequently mention the article, “The New New Product Development Game,” published in 1986 by Takeuchi and Nonaka in Harvard Business Review.[1] They refer to it as the main source of inspiration for the Scrum framework. These Japanese business professors had done extensive research in the field of companies developing new products (such as cars, printers, photocopiers, and personal computers). In the article, the authors used the analogy of a rugby game to describe how the development teams for new products in the more successful companies were working. At the heart of it was self-organization and the boundaries that help turn it into a success.

The word scrum, a rugby formation for putting the ball back into play, is used in the article as the metaphor. This is what inspired the creators of Scrum when naming the framework in 1995.

Or, so they say...

There are indications that Sutherland and Schwaber didn’t tell the whole story. The book Wicked Problems, Righteous Solutions was published in 1990. As the earlier excerpt shows, it was this book that introduced the idea of applying the practices described by Takeuchi and Nonaka to software development. And it was in this same book that this new way of working was baptized as Scrum.

To be fair, it’s important to point out that the book doesn’t provide a detailed or usable method to put these ideas into practice. The authors explain why the waterfall model doesn’t work for software development, and they offer possible alternatives, among them (what they call) Scrum.

Sutherland and Schwaber drove forward the creation of the actual Scrum framework in the first half of the 1990s. They defined the rules, roles, events, and artifacts based on their work in practice. They’ve evolved and kept sustaining them since then and deserve all the credit for that.

Jeff Sutherland refers to Wicked Problems, Righteous Solutions in at least two articles he wrote in the early days of Scrum.[2] He highlights this work as a major influence on the introduction of Scrum at Easel Corporation. Unfortunately, the authors of the book were never given the real credit they deserve, and their initial importance got lost over time. But they were the ones who first voiced the idea to apply the approach described by Takeuchi and Nonaka to software development, and they were the ones who actually baptized this approach as Scrum.

[1] Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game,” Harvard Business Review, Jan. 1986, https://oreil.ly/kBq_y.

[2] Jeff Sutherland, “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies,” Cutter Business Technology Journal Vol. 14, 2001: pp. 5–11; and “Agile Development: Lessons Learned from the First Scrum,” Cutter Agile Project Management Advisory Service: Executive Update Vol. 5, No. 20, 2004: pp. 1–4.

Chapter 91. The “Standing Meeting”

Bob Warfield

I started doing daily meetings and most of the rest of what resulted in the Quattro methodology after attending a talk by Stu Feldman while at Rice University (1979–1983).

Feldman had invented Make, the UNIX build automation tool, in 1976 at Bell Labs. At the time, he presented a surprising viewpoint on what Make really was: a way to enable more developers to work together efficiently. His thesis was that we had no idea how to get more than seven plus or minus two developers to work well together. As you may know, phone numbers have seven digits because that’s the average capacity of human short-term memory. Good menu design suggests no more than seven entries, lest we forget the first entry by the time we read the last. As Feldman saw software development as primarily a communications problem, he applied that same sort of thinking to how many developers could work together.

I was reminded of Feldman’s issue of communication as the bottleneck when I began a small startup that had to move quickly. There was no opportunity to write voluminous specs and documentation. We didn’t have the manpower, and we faced some moving targets. The goal was to stay fluid, highly reactive, and highly data driven and not be driven by historical, hazy visions created in the beginning. It drove us toward combating the communication issue head on. We had to check in with all developers on a daily basis.

We called them standing meetings because nobody had to plan or schedule them or even put them on their calendar. They were always on, not because anyone actually had to stand.

Our standing meetings served as quick, informal code reviews, where we asked questions about one another’s systems and why certain design choices were made. We paid specific attention to whether anyone’s code had to communicate with other developers’ code. It helped us greatly in avoiding premature optimizations or selecting under-par architectural decisions. The discussions allowed us to learn more about the design and refine it while also figuring out what to test and how best to test it.

Looking back, we intuitively applied group wisdom to hard problems. All were open about the trouble we were having so we could help one another out while learning from it. It helped us to identify hot spots and challenges to meeting our goals quickly and to jump on them early, before they became too big a problem.

Regardless of what they are called, the Daily is a developer’s meeting — not a place for marketers to try to hold developers accountable. Allowing the latter scenario has been one of the main ways I have seen Agile go wrong over time.

Chapter 92. Scrum: Problem-Solving and the Scientific Method in Practice

Si Alhir

“What is Scrum?” is a quintessential question that deserves a quintessential answer.

Scrum is the fusion of problem-solving in the macro and the scientific method in the micro for working in a complex space. Scrum establishes a framework that fuses problem-solving and the scientific method, with its roles, events, and artifacts, and the rules that bind them for operating in a complex environment, doing complex work, and generating complex results.

Complexity exists where there is a gap between cause and effect — that is, a context where there is a gap between cause and effect in the environment, the work, or the results. There may be unknowns in the environment, in the nature of the work itself, or in the resulting solutions, and these unknowns are only revealed during the work, while enacting problem-solving combined with the scientific method.

The essence of problem-solving is discovering, defining, developing, and delivering a solution to a problem. The essence of the scientific method is experimentation. When combined, the fusion of problem-solving and the scientific method is about performing experiments to realize a solution to a problem and confronting the gaps.

Enacting problem-solving and the scientific method involves Actions, Intentions, and Results (AIR). Nothing will be achieved without Actions. No direction is taken without Intentions. And Results are the outcome of Intentions and Actions.

Allow me to express Scrum through the lens of AIR.

To confront complexity, a Result Owner, Action Team, and Dynamics Owner partner to achieve success in realizing a valuable solution to a problem through experimentation.

The Result Owner champions a Result by engaging the Action Team in discovering and defining a Result of value. Intentions express the intended Result. There is a list of all the Intentions needed in the Result. The Result is the actual realization of Intentions. Essentially, Intentions express a solution to a problem, and a Result is the actual solution.

An Action Team champions Actions by engaging the Result Owner in developing and delivering a Result of value. Actions express how a Result is realized based on the Intentions. The Action Team chooses how best to realize the Result — that is, the team is self-organizing. The Action Team has all the competencies needed to realize the Result — that is, the team is cross-functional. Essentially, experiments are expressed through Actions.

A Dynamics Owner champions the dynamics between the Result Owner, Action Team, and the context in which they operate. The Result Owner and Action Team flow together and pull on one another, and the Dynamics Owner works with the Result Owner, Action Team, and the context to ensure progress toward success.

Events create regularity among the Result Owner and Action Team. An overarching, time-boxed event serves as a container — a bounded window of time — to shift everyone’s focus toward achieving a goal. Each time-box opens with a planning event to launch it, has routine touchpoint events to ensure synchronization, and closes with a review event to demonstrate progress and a retrospective event to improve.

The answer to “What is Scrum?” is more fascinating than calling Scrum just another delivery process. Scrum is the fusion of problem-solving and the scientific method tuned for navigating the complex world. Scrum defines a Result Owner, Action Team, Dynamics Owner, Intention Backlog with Intentions, Action Backlog with Actions, Result, and the events and rules that bind them together.

Chapter 93. Scrum Events Are Rituals to Ensure Good Harvest

Jasper Lamers

If Margaret Mead (1901–1978) were to join a Scrum event, it would most certainly draw her interest as an anthropologist. What is the meaning of this exotic ritual? In which mysterious ways does this gathering of people contribute to group identity? Who is this shaman-like lady, acting as a mistress of ceremony? Does this “Scrum Master” status come with hidden tattoos? And who is this Product Owner person? Which opponents did he have to fight and defeat before calling himself “Owner”?

She would quickly learn that the tattoos were actually badges and certifications that can be earned online and that the Product Owner got a mandate from the overarching company as part of some organizational assessment. She would recognize that Scrum events are recurring rituals. The team uses their time-boxed liminality to inspect their road to awesomeness and adapt as needed. They create and maintain a product for other people, and that product had better be appealing so that it justifies the investment. The Scrum events are rituals that are meant to ensure good harvest.

From an anthropological perspective, rituals bind people. Rituals often address social tensions within a group. Rituals might offer a controlled opportunity to play outside the normal limits. People might deliberately and in a controlled manner cross the borders of their core values, just to emphasize them. In her book, Pieces of White Shell (University of New Mexico Press), Terry Tempest Williams wrote: “Rituals are the formulas by which harmony is restored.” A ritual can be a one-off event, like the start (birth, wedding) or the end (funeral, divorce) of a situation. Or they can be recurring, like birthdays. Many rituals have spiritual roots, like asking the Gods for prosperity. Rituals help groups channel their biggest fears and hopes.

A famous (and curious) ritual to ask the Gods for good yams (exotic vegetables) is Gol, a yearly event on the pacific Island of Vanuatu. It’s also known as land diving. Boys and men volunteer to climb a wooden platform up to 30 meters high. They bind vines to their ankles, and without any other safety equipment, they jump off, frequently leading to serious fractures and occasionally even death. The ritual is meant to please the Gods and in return to be blessed with a good harvest. From an anthropological view, it does something else. Men show their strength, their courage, their masculinity, and hence their status. Boys show that they’re not children anymore. Beyond the focus on masculinity, Gol strengthens group identity as people risk their lives for the greater good of the group. Additionally, there is singing, dancing, food, and drinks! And nowadays…money; because of its intrinsic curiosity, Gol attracts lots of tourists.

The Scrum events, like most rituals all over the world, have a purpose and rules of ceremony. They are performed at a certain cadence and at the same place. Every event offers a chance to reconnect and restore harmony and unity and thus ensure a good harvest. The excitement might compare with the Gol experience, but — fortunately — team members don’t risk their lives, and the Product Owner does not battle other people to ritually claim and emphasize ownership of the product. And, most significantly, Scrum Teams don’t trust the Gods to save the day. They use the rituals to take matters into their own hands as their way of ensuring a good harvest.

Chapter 94. How We Used Scrum to Work with an External Agency

Eric Naiburg

People often say that Scrum Teams must be co-located or that they must all work for the same company. That, however, is not the case. Scrum serves to solve complex problems. Working on a distributed team with people from multiple companies even increases complexity and thus the value of Scrum.

Delivering a new Scrum.org website required us to bring together knowledge and talent from multiple places. Beyond looking for an agency that had expertise in the envisioned technology, we wanted a partner willing to work with Scrum. Obviously.

But paying a little attention to our working conditions, beyond the mere rules of Scrum, helped a lot.

When negotiating a contractual agreement with the selected agency, we did not want to get locked into some 18-month project, up front, without the ability to evolve and learn as we progressed. We did, however, understand the agency’s need for some security. We easily found middle ground in agreeing to purchase a number of Sprints with the option of extending or canceling upon a four-week notice (one to two Sprints) at any time.

Our Scrum Team was cross-functional as well as cross-organizational. It was made up of a Product Owner from Scrum.org, a Scrum Master from the agency, and a Development Team that included people from both. Having developers from both sides helped us to transfer the knowledge and skills needed for the long-term maintenance of the Scrum.org website and allowed our Scrum.org developers to bring their knowledge and understanding of existing systems to the team.

The Scrum Team spanned three time zones, with members from six different states and provinces across both Canada and the United States. That did not stop us from making it work successfully.

Considering how the team was distributed, we needed to have ways to communicate intensely. This included instant messaging, code review and version management, group and one-on-one video meetings with screen-sharing, and a virtual Scrum board. We set them up in a way that allowed individuals from different companies to dynamically share information, daily and instantly.

Beyond getting all involved people on the same page with regard to Scrum, we spent time setting up a clear working agreement. It turned out to be quite important and valuable, with many of the team members not just distributed and coming from multiple organizations, but also new to each other and new to working together. We became “one team” that transcended the traditional vendor relationship. The team scheduled the Daily Scrum to accommodate all team members in their time zones and decided on a two-week Sprint cadence.

To get up to speed on the technology, both new and old, the team decided to go for pairing. In the end, it was so powerful that we kept doing it all the way through. It improved the cohesion within the team, helped with knowledge transfer, and allowed the team members to develop themselves in becoming more “comb shaped.”

What further helped us along the road was the empowerment of the Product Owner to actually own the product and of the Scrum Master to challenge all and everyone involved. While focusing primarily on Sprint Goals, we delivered the new website incrementally, with tons of intermediate feedback from many different types of stakeholders (external users, internal users, partners, and potential users).

Chapter 95. Scrum Applied in Police Work

Sjoerd Kranendonk

Scrum is most known as a framework for empirical product delivery and for developing IT products. But it has also been applied to address other complex adaptive problems: in HR, marketing, police work, education (eduScrum), running a company, and so on.

My work as Scrum Master of a police team working on detection and prevention of cybercrime helped me explore how to look at the Increment, a mandatory Scrum artifact, in a non-IT context.

At first, the Increment feels like a tricky concept, given that most people consider it to be a product version. It is what a Development Team in Scrum creates throughout a Sprint. The Scrum Guide, however, leaves sufficient room for the concept to be applied in a non-IT context:

An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal.

It might come as a surprise, but in no way is the Increment described as a software or IT concept. The description is, however, also quite abstract. Ultimately, it boils down to having an output that:

- Can be inspected

- Is assumed to be valuable

- Is in a “Done” state

- Is part of reaching a vision or goal

When translating these characteristics of an Increment to the context of police work, we discovered that there is no need to substantially change our ideas of an Increment.

Detection work

For the aspect of detection work (leading to convicting criminals), we identified that the police teams create outputs in the form of files and descriptions that should be usable by the prosecutor, including being admissible in court. In the process of constructing such evidence, the police teams need to keep sound and systematic logs and descriptions of how the evidence was constructed. As part of this, relevant changes and data need to be input into an IT system. We set the goal for ourselves that at the end of each Sprint, these files should be in a Done state: no registrations remain or are missing that pertain to useful evidence for the case.

The logs and the resulting case files are outputs that help reach the vision of making the world a little more just and safer while creating a deterrent effect through their application in court.

Crime prevention

The output created by police teams in crime prevention are often events or publications that help educate civilians and organizations to be more resilient against cyber criminals. These types of public information must conform to established communication rules and regulations in terms of content, graphics, and language. We want the event or publication — no later than by the end of a Sprint — to be in such a state that, without any further work, it could be used to support prevention activities. It is likely that changes and additions need to be performed in several Sprints to be able to actually release or publish it.

These teams work against the overarching vision of minimizing the impact of cyber criminals. An important tactic is to share and promote means of prevention, thus making the criminals’ job harder.

As we are only at the start of applying Scrum in this context of police work, much is still aspirational. We look forward to discovering improvement opportunities in creating transparency in Scrum through the Increment.

Chapter 96. Born to Be Agile: A Case for Scrum in the Classroom

Arno Delhij

As an Agile Coach or Scrum Master, you most likely have encountered resistance in your work. We work with people who have established careers in established enterprises and help them to work in an Agile manner, usually by adopting Scrum. And although it can be love at first sight — people immediately and wholeheartedly embrace Scrum — more often than not, we face resistance. We feel we have to teach the people involved new things and to adopt new ways of working. As Agile Coaches or Scrum Masters, it appears that we have to teach people how to be Agile in the sense of being adaptive and self-organizing. But, is that really true? Were we born with no other capability than to act within the traditional context of traditional organizations that know nothing else but a command-and-control way of working? Does our DNA limit us to only being able to follow a plan and instructions imposed upon us?

Did you learn to walk or ride a bike by following a plan? No! You used trial and error: Inspect and Adapt. It is amazing how many human activities until the age of six are based purely upon failing (often) and adapting to the lessons learned. Chances are high that this started changing as you went to school around the age of six. Although schools occasionally use innovative and new approaches, most of them implement a command-and-control style of teaching, leaving little or no autonomy to the kids who have to learn. In a way, we can state that we were all agile (adaptive and self-learning) until we went to school. From that moment on, you had to leave all those agile capabilities at home and do as you were told. Agile Coaches and Scrum Masters now face the challenge of getting people to dig up abilities they intrinsically have but that have been suppressed and buried for a very long time.

What if we preserve those abilities in our children by organizing their learning in an Agile way, while better equipping them for their future jobs? There are numerous initiatives in education that embrace agility and Scrum, and the results of children using Scrum in the classroom are amazing. They take ownership of their own learning and monitor their progress against the official learning objectives with burn-down charts. They know early on if they are behind schedule, which allows them time and room to get back on track. When they are ahead of schedule, they still work hard. The whole idea creates and thrives on intrinsic motivation. Small teams collaborate intensely on the learning subjects while also taking time to reflect on their process and themselves as learners. In eduScrum, one of the better-known frameworks, the definition of “Done” is complemented with a “definition of Fun” (as a working agreement). Much like great Scrum Teams, eduScrum teams often deliver early. They love the autonomy to decide for themselves how they will do the work.

If we want to invest in the agility of our organizations and enterprises, then training people in Scrum as early as possible is worthwhile. Why not start early with our children by not killing their intrinsic agile abilities in the first place, rather than teaching them to be agile again?

Chapter 97. Agile in Education with eduScrum

Willy Wijnands

I believe that Scrum suits the needs of today’s fast-changing markets and, more importantly, implements an Agile mindset. The workforce of tomorrow will have to cope with the challenges of such fast-changing markets and manage the new way of working. Unfortunately, the current educational system is missing out on these evolutions, thus leaving a big gap between what it offers and what the market requires.

I believe that eduScrum, our way of applying Scrum in the educational system, can be the bridge to close the gap between the educational system and market requirements.

The starting principles of eduScrum are autonomy and authenticity. I believe that children are more than capable of taking responsibility and can work together in teams, more independently from the teachers than the traditional system assumes. When students are trusted to take ownership of their own learning process, they become responsible for what they do. As a teacher, I offer them the freedom and the space they need while being there to facilitate and coach them.

For me, it all starts with the development of personality. Building on this foundation, students become far more engaged. Thriving in intrinsic motivation, they are more productive and have improved results while having more fun.

eduScrum is an active, collaborative education process. eduScrum allows students to make assignments according to a fixed rhythm, organizing work in Sprints. They plan and determine their own activities autonomously, which includes independently keeping track of their progress. The teacher creates the assignments against the learning objectives. But rather than become an instructor, teachers in eduScrum coach, teach, facilitate, and give advice. eduScrum turns education upside down! We move from teacher-driven education to education driven and organized by the students. The teacher determines the why and the what, and the students determine the how. And I have been in situations where the students even determine the why, the what, and the how.

They discover who they are from a personality and talents perspective and what their abilities are. It is a wonderful experience to see students developing themselves. I have found that students working with eduScrum go through a strong and positive personal development. They get to know their individual qualities through working in small teams and finding out how to use the resources at their disposal. They discover the power of engagement, commitment, and responsibility. They train to self-reflect but also to give feedback to their classmates and to continuously improve their own and their team’s working process.

As a teacher, I’m only involved when the team gets stuck or moves in the wrong direction. First, I help them understand what they don’t understand. Then I help them get started or get back on track while exploring these unknowns. And now, by fully knowing what they didn’t understand, they look for knowledge, and this is what true teaching should be about, in my view.

Contributors

Evelien Acun-Roos

Scrum Professional

Evelien Acun-Roos is an experienced Agile Coach at Xebia and a Professional Scrum Trainer at Scrum.org. She has a profound knowledge of Agile and Scrum and knows how to transfer that to organizations, teams, Scrum Masters, and Product Owners. Her passion for Agile centers on teams and individuals. She loves to get teams up and running and then help them continuously improve. She has helped many teams at different organizations become more Agile. Evelien loves to give training for beginning as well as experienced Scrummers. Her training courses are filled with brain-based learning activities. In her classes, she lets the learner learn instead of the teacher teach. Evelien lives in Helmond with her husband and three kids.
Use Brain Science to Make Your Scrum Events Stick

Si Alhir

Transformation Leader

Si Alhir is an entrepreneur, author, agility/antifragility and transformation leader, coach, consultant, and practitioner (catalyst) who partners with individuals, teams, and enterprises in integrating business, strategy, leadership, culture, execution, and technology to achieve business outcomes and growth in a disruptive world. Si has over four decades of working with startups and the Fortune 500. He is the author of The Antifragility Edge: Antifragility in Practice (LID Publishing, 2016), Achieving Impact Through Engagement: Ownership, Actions, Intentions, and Results (Self published, 2015), and Conscious Agility: Conscious Capitalism + Business Agility = Antifragility (Self published, 2013).
Scrum: Problem-Solving and the Scientific Method in Practice

Peter Beck

Certified Scrum Trainer

Peter Beck is dedicated to creating companies that deliver value for their customers and employees. In 2004, he first experienced Scrum as a developer in one of the first multi-team Scrum setups in Germany. Since then, he has trained and consulted a wide range of development teams, departments, project managers, and executives in the use of Scrum. He is a Certified Scrum Trainer and cofounder and Product Owner of DasScrumTeam AG.
Scrum Is “Agile Leadership”

Steve Berczuk

Agile Software Developer, Team Leader, and Author

Steve is a software developer and expert in Agile software development. A Certified Scrum Master, he has over 20 years’ experience helping teams work together effectively and has used Scrum since 2005. Steve is coauthor of the book Software Configuration Management Patterns: Effective Teamwork, Practical Integration (Addison-Wesley Professional, 2003) and is a frequent contributor to Techwell. Steve’s articles and blog can be found at http://www.berczuk.com. You can follow him on Twitter @sberczuk.
Adopt Before You Adapt
Have Sprint Retrospectives and Structure Them

Kurt Bittner

Team Member at Scrum.org

Kurt Bittner has more than 30 years of experience delivering working software in short, feedback-driven cycles. He has helped a wide variety of organizations adopt Agile software delivery practices, including large banking, insurance, manufacturing, and retail organizations, as well as large government agencies. His focus is on helping organizations build strong, self-organizing, high-performance teams that deliver solutions that customers love. He is the author of four books on software development–related topics, including The Nexus Framework for Scaling Scrum (Addison-Wesley Professional, 2017).
Scrum Is Also About Improving the Organization

Gil Broza

Agile Mindset and Leadership Coach

Gil is an enterprise Agile coach, trainer, facilitator, speaker, manager, and developer with 20 years of experience in diverse environments. He owns and leads 3P Vantage, which helps organizations increase their agility and team performance with minimal risk and thrashing. Through pragmatic, modern, and respectful guidance, Gil supports leaders and development teams in customizing adaptive work principles. Gil is the author of The Agile Mind-Set (CreateSpace Independent Publishing Platform, 2015), The Human Side of Agile (3P Vantage Media, 2012) and Agile for Non-Software Teams (3P Vantage Media, 2019).
Mindset Matters Much More Than Practices

James O. Coplien

Scrum Teacher, Coach, and Consultant

James O. Coplien is a teacher, author, and researcher, with interests ranging from programming languages and system design to organizational design and development process. The Daily Scrum came from his early process research at Bell Labs. He was co-creator of the DCI paradigm and creator of the Trygve programming language. James is a recumbent E-biker, traveler, and equestrian squire.
Communicating Prioritized Requirements Through the Product Backlog
Why There Are No User Stories at the Top of Your Product Backlog
Specialization Is for Insects
The Daily Scrum Is the Developers’ Agile Heartbeat
Thinking Big

Lisa Crispin

President, Agile Testing Fellowship

Lisa is coauthor (with Janet Gregory) of Agile Testing Condensed (Library and Archives Canada/Government of Canada, 2019); Agile Testing: A Practical Guide for Testers and Teams (Addison-Wesley Professional, 2009); and More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley Professional, 2014); a LiveLessons video course, Agile Testing Essentials; and a three-day live course, Agile Testing for the Whole Team. Lisa was voted by her peers as the “Most Influential Agile Testing Professional Person” at Agile Testing Days in 2012. Please visit https://agiletester.ca and https://agiletestingfellow.com to learn more.
Testing Is a Team Sport

Derek Davidson

Scrum Trainer (CST and PST) and Agile Coach

Derek is a Professional Scrum Trainer for Scrum.org and a Certified Scrum Trainer for the Scrum Alliance. Derek helps people become Product Owners, Scrum Masters, and Scrum Developers. He helps software developers work in an Agile/Scrum way and helps Scrum Teams scale. Derek also helps businesses implement Scrum. Derek writes about Scrum at http://www.webgate.ltd.uk.
Scrum Master, Not Impediment Hunter
“That Won’t Work Here!”
The Sixth Scrum Value

Stijn Decneut

Trainer/Coach with a Passion for Neuroscience

Building on a strong understanding of the biological bases of human behavior, Stijn provides training, mentoring, and coaching on Agile leadership. Stijn cofounded AgileBeyond to take Agile coaching and training beyond anecdotal techniques and unsubstantiated models, building on solid, evidence-based findings from science instead. He helps organizations adopt Scrum and related Agile practices in a way that actually makes sense, because all too often, the way organizations apply techniques and frameworks doesn’t pay off, leading to frustration, and eventually disillusion.
How Human Nature Overcomplicates What Is Already Complex
How to Design Your Scrum for A-ha! Moments

Pete Deemer

CEO of GoodAgile

Pete Deemer is a well-known figure in the Agile software community, having spent the last 25+ years leading teams building products and services at global companies. Pete served as Chairman of Scrum Alliance and is the CEO of Singapore-based firm GoodAgile, providing Agile consulting and training.
Will Scrum Work for Multi-Location Development?

Arno Delhij

Agile Business Coach

Arno Delhij works as an Agile Business Coach and cofounder of the worldwide initiative, Agile in Education. He helps companies grow high-performing teams and adapt to a flexible and value-driven way of working. He has a strong passion for innovation in education. Arno coauthored the eduScrum Guide, and his latest published book is Scrum in de klas (2020).
Born to Be Agile: A Case for Scrum in the Classroom

Hiren Doshi

Professional Scrum Trainer

Hiren is a Professional Scrum Trainer with Scrum.org. He authored the book, Scrum Insights for Practitioners: The Scrum Guide Companion (Practiceagile.com, 2016). He has 24 years of software development experience and has been practicing Scrum for over 13 years. He has helped companies like Tesco, EMC, BACI, BookMyShow, Shell, Schlumberger, BP, Aditya Birla Group, and many more on their Agility path. Hiren lives in Mumbai, India, with his wife, Swati, and two daughters, Aditi and Ashwini.
Five Sublime Aspects for Being a More Humane Scrum Master

Jutta Eckstein

Independent

Jutta Eckstein works as an independent coach, consultant, and trainer. She has helped many teams and organizations worldwide transition to Agile. She has unique experience in applying Agile processes within medium-sized to large, distributed, mission-critical projects. She has shared her experience through several books, including Agile Software Development in the Large (Dorset House, 2004), Agile Software Development with Distributed Teams (Self published, 2018), Retrospectives for Organizational Change (Self published, 2019), Diving for Hidden Treasures: Uncovering the Cost of Delay in your Project Portfolio (Practical Ink, 2016) (with Johanna Rothman), and Company-wide Agility (Self published, 2020) (with John Buck). She is a member of the Agile Alliance (having served on the Board of Directors from 2003–2007) and a speaker, as well as co-organizer of several conferences across the world.
Sprints Are for Progress, Not to Become the New Treadmill

Ron Eringa

Agile Leadership Developer

Ron is driven by the vision to create workplaces where he would trust his kids to work. Ron wants to inspire people to reach their full potential. As Professional Scrum Trainer for Scrum.org since 2014, he guides teams and managers on their professional learning journeys. As Leadership Steward for Scrum.org, he helps trainers deliver a Professional Leadership experience. As an independent consultant since 2016, he helps clients and partners develop leadership at all levels in the organization. You can find more information at http://roneringa.com.
Agile Leadership and Culture Design

Markus Gaertner

Certified Scrum Trainer

Markus Gaertner works as Organizational Design Consultant, Certified Scrum Trainer (CST), and Agile Coach for it-agile GmbH in Hamburg, Germany. Markus is the author of ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Professional, 2012) and contributes to the Softwerkskammer, the German Software Craftsmanship movement. He blogs in English frequently at http://www.shino.de/blog.
Know the Difference Between Multiple Scrum Teams and Multi-Team Scrum
Product Owner, Not an Information Barrier
“That’s Not My Job!”

Bob Galen

Agile Coach

Bob Galen is an Agile Methodologist, Practitioner, and Coach based in Cary, North Carolina. In this role, he helps guide companies and teams in their pragmatic adoption and organizational shift toward Scrum and other Agile methods. He is currently Principal Agile Coach at Vaco and President of RGCG, LLC. Bob regularly speaks at international conferences and professional groups on a broad range of topics related to Agile software development. He is the author of the books Agile Reflections: Musings Toward Becoming Seriously Agile in Software Development (RGCG, LLC, 2012), Scrum Product Ownership: Balancing Value from the Inside Out (RGCG, LLC, 2009–2013), and Three Pillars of Agile Quality and Testing: Achieving Balanced Results in Your Journey Towards Agile Quality (RGCG, LLC, 2015). He can be reached at bob@rgalen.com.
Servant-Leadership Starts from Within
When in Trouble...Break Glass!
Are People Impediments?

Peter Goetz

Agile Coach and Trainer

Peter is a coach and trainer for Scrum and DevOps. He has more than 15 years of experience with software development in different roles and from different perspectives. As a Scrum.org licensed Professional Scrum Trainer, he supports his clients in introducing and implementing Scrum in software development projects.
Start with the Why of Your Scrum

Luis Gonçalves

Managing Director

Luis Gonçalves is an entrepreneur, best-selling author, and international keynote speaker. When consulting, he works exclusively with entrepreneurs, founders, and the senior executives of seven- to eight-figure businesses on the implementation of his game-changing Organizational Mastery methodology. He has been successfully working in the software industry since 2003, and his blog, https://luis-goncalves.com, is considered a “must-read” for everyone in the software development industry.
How to Have an Effective Sprint Planning
Understanding the Scrum Master Role

Ellen Gottesdiener

Agile Product Coach

Ellen Gottesdiener is a Product Coach and CEO of EBG Consulting, focused on helping product and development communities produce valuable outcomes through product agility. Ellen is known in the Agile community as an instigator and innovator for collaborative practices for Agile product discovery and delivery. She integrates skilled facilitation into her product work to enable healthy teamwork and strong organizations. Ellen is the author of three books on product discovery and requirements, a frequent speaker, and works with clients globally. In her spare time, Ellen is Producer of Boston’s Agile Product Open Community and serves as Director of Agile Alliance’s Agile Product Management Initiative.
Answer This Question: “What Is Your Product?”

James W. Grenning

President, Wingman Software

James Grenning trains, coaches, and consults worldwide. James’s mission is to bring modern technical and management practices to product development teams, especially in embedded systems development. He is the author of Test-Driven Development for Embedded C (Pragmatic Bookshelf, 2011). He is a coauthor of CppUTest, a popular unit test harness for embedded C and C++. He invented Planning Poker, an estimating technique used around the world, and participated in the creation of the Manifesto for Agile Software Development. His website is http://wingman-sw.com.
Agile Is More Than Sprinting

Daniel James Gullo

Author and Transformative Leader

Daniel is a well-known and highly regarded servant of the Agile community as well as a lifelong entrepreneur. Daniel is CEO of Apple Brook Consulting (ABC) and the founder of and chief advisor to Agile Delaware. He is a frequent reviewer, volunteer, and speaker for several organizations. He is also cofounder of AgileNEXT, the next-generation Agile talk show, and CoreAgility, a monthly publication. Daniel is a trusted advisor to staff and management of the Scrum Alliance candidates for CST and CEC. A Service-Disabled Veteran-Owned Small Business (SDVOSB), Apple Brook Consulting donates to active-duty, veteran, and retired military members through its discount program on training and via other methods. Daniel is the author of Real World Agility: Practical Guidance for Agile Practitioners (Addison-Wesley Professional, 2016). Daniel is currently pursuing a PhD in Organizational Development and Change (Evidence-Based Coaching).
The Effects of Working from Home

Bob Hartman

Certified Scrum Trainer and Coach, Agile For All, LLC

Bob has served in almost every role in the software industry, including developer, tester, documentation writer, trainer, product manager, project manager, business analyst, senior software engineer, development manager, and executive. Over the past 20 years, Bob has grown from being an early adopter of Agile to his current status as a Certified Scrum Trainer (CST) and Certified Enterprise Coach (CEC) and an expert in training, coaching, and mentoring in all areas of agility, including leadership agility and organizational agility. Bob is a popular speaker, having spoken at numerous major conferences, seminars, workshops, and user group meetings, where his engaging style, holistic view of development, and personal anecdotes are always well received by attendees.
The Most Important Thing Isn’t What You Think It Is

Daniel Heinen

Scrum Master and University Lecturer for Large-Scale Scrum Product Development

Daniel Heinen is a Scrum Master and Agile Coach at the LeSS Huge adoption at BMW Group’s Autonomous Driving division. He also works as a Lecturer at the University of Applied Science in Munich. He believes that successful products can only be developed together, with close collaboration from customer to developer. In his vision, successful organizations foster collaborative learning to build successful solutions, also at scale. Contact Daniel at unityproductdev@gmail.com.
The Vicious Effects of Managing for Utilization

Jorgen Hesselberg

Cofounder of Comparative Agility

Jorgen Hesselberg is the author of Unlocking Agility (Addison-Wesley Professional, 2018) and cofounder of Comparative Agility, a leading Agile assessment and continuous improvement platform. A proven thought leader of numerous successful enterprise transformation efforts since 2009, Jorgen provides strategic guidance, executive counsel, and coaching to some of the world’s most respected companies, both as an internal change agent and an external consultant.
Treating Defects as Treasures (the Value of Openness)

Jesse Houwing

Trainer, Coach, and Tinkerer

Jesse likes to train people in Scrum and the Agile mindset in general as a means to lead them to new insights, epiphanies, and sometimes life-changing inspiration. When people share that a specific training turned out to be a career-changing event, that’s epic. That is one of Jesse’s ultimate Epic $#*! moments.
The Evergreen Tree

Rich Hundhausen

Scrum/DevOps Trainer and Coach

Richard Hundhausen helps teams deliver better products by understanding and leveraging Scrum and Azure DevOps. As a Professional Scrum Trainer, he knows that software is built and delivered by people and not by processes or tools. Richard lives in Boise, Idaho, USA.
Is Your Team Working as a Team?
What’s in Your Sprint Plan?
Rethinking Bugs

Ralph Jocham

Change Agent at effective agile

Ralph has been active in the Agile space for more than 20 years as a programmer, Scrum Master, and Product Owner. He has been a Professional Scrum Trainer for Scrum.org since 2010 and has trained and coached thousands of people worldwide. Ralph is coauthor (with Don McGreal) of The Professional Product Owner: Leveraging Scrum as a Competitive Advantage (Addison-Wesley Professional, 2018).
Successful Projects That...Fail
Beware the Product Management Vacuum
Sprint Goals: The Forgotten Keys of Scrum

Mik Kersten

Founder and CEO of Tasktop

Dr. Mik Kersten is the CEO of Tasktop Technologies, creator and leader of the Eclipse Mylyn open source project, and inventor of the task-focused interface. As a research scientist at Xerox PARC, Mik implemented the first aspect-oriented programming tools for AspectJ. He created Mylyn and the task-focused interface during his PhD in Computer Science at the University of British Columbia. Mik has been an Eclipse committer since 2002, is an elected member of the Eclipse Board of Directors, and serves on the Eclipse Architecture and Planning councils. Mik’s thought leadership on task-focused collaboration makes him a popular speaker at software conferences, and he was voted a JavaOne Rock Star speaker in 2008 and 2009. Mik enjoys building tools that offload our brains and make it easier to get creative work done.
Scaling Scrum to the Entire Organization with the Flow Framework

Sjoerd Kranendonk

Agile Coach, Scrum Master, and Trainer

Sjoerd is a coach and consultant with a drive to help organizations and people find better ways of working. He does so by coaching, consulting, and training in various methods, tools, and practices for continuous improvement, always making sure to start from a good understanding of the why of things. Tools in his toolkit include Scrum, SAFe, LeSS, and other approaches that align with the Agile Manifesto and a growth mindset. Sjoerd publishes irregularly on LinkedIn and www.sjoerdly.com.
Scrum Applied in Police Work

Mitch Lacey

Agile Software Practitioner

Mitch Lacey is an Agile practitioner and trainer. Mitch has been managing projects for over 15 years and is credited with many plan-driven and Agile projects. He is the author of The Scrum Field Guide (Addison-Wesley Professional, 2012–2016), a book targeting teams adopting Agile and Scrum practices. Mitch honed his Agile skills at Microsoft Corporation, where he successfully released core enterprise services. Mitch’s first Agile team at Microsoft was coached by Ward Cunningham, Jim Newkirk, and David Anderson.
Put Customer Focus at the Top of Your Decision-Making Stack

Len Lagestee

Organizational Change Coach

Len Lagestee is an organizational change coach and blogger at www.illustratedagile.com. As a coach, Len interacts with large organizations to connect people, revolutionize leadership, deliver results, and humanize the workforce.
Becoming a Radiating Team
The Five Stages of Product Backlog Item Sizing
Anatomy of an Impediment

Jasper Lamers

Agile Consultant and Cultural Anthropologist

Jasper holds a master’s degree in Cultural Anthropology. Although he ended up working in software development, he never lost his deep interest in the people aspect of work. Having worked in various roles between ICT and business, Jasper is an experienced, enthusiastic, and creative coach and trainer. Jasper is a hobby musician and video maker.
Is There Anything to Learn from Football Hooligans?
The Power of Play in a Safe (but Not Too Safe) Environment
Scrum Events Are Rituals to Ensure Good Harvest

Mark Levison

Certified Scrum Trainer

Mark is now an author, Certified Scrum Trainer, and consultant with Agile Pain Relief Consulting. He has introduced Scrum, Lean, and other Agile methods to a number of organizations, including Government of Canada departments, major financial and insurance institutions, and software companies, as well as individuals across Canada. He also does consulting work with organizations seeking to evolve.
Sprint Backlogs Deserve a Life Beyond Your Electronic Tool
Sprint Goals Provide Purpose (Beyond Merely Completing Work Lists)

Marc Loeffler

Passionate Business Agility Coach

Marc Loeffler is a renowned keynote speaker, author, and Agile coach. Before getting in touch with Agile methods and principles in 2006, he was working as a traditional project manager for companies like Volkswagen AG and Siemens AG. His passion is to help teams implementing Agile frameworks and to transform our world of work. Marc has a passion for helping teams that are struggling with Agile transitions and overcoming dysfunctional behavior. He loves to generate new insights by approaching common problems from the other side and trying to make havoc of the process deliberately. Marc is the author of Improving Agile Retrospectives (Addison-Wesley Professional, 2017).
Five Things Nobody Tells You About Scrum

Chris Lukassen

Product Samurai

Chris has been involved in various projects, from coding real-time operating systems to running nine teams in a multimillion-Euro product development, from garage startups to global giants like TomTom and Saab, from utter failure to CES award-winning products. His mission is to teach people how they can create products in such a way that they can never imagine going back.
Patricia’s Product Management Predicament
The Gentle Way of Change

Don McGreal

VP of Learning Solutions at Improving

Don is a hands-on Agile consultant, instructor, and Professional Scrum Trainer for Scrum.org. He has authored and taught classes for thousands of software professionals around the globe. He is also cofounder of TastyCupcakes.org, a comprehensive collection of games and exercises for accelerating the adoption of Agile principles. Don is coauthor of The Professional Product Owner: Leveraging Scrum as a Competitive Advantage (Addison-Wesley Professional, 2018, with Ralph Jocham).
Successful Projects That...Fail
Beware the Product Management Vacuum
Sprint Goals: The Forgotten Keys of Scrum

Todd M. Miller

Professional Scrum Trainer

Todd has experience as a Scrum Master, Product Owner, Developer, and Agile coach on a variety of technical and creative projects across a multitude of industries. He currently coaches and trains enterprises and teams across the United States on the Scrum framework, enterprise Agile transformation, and professional software development. Todd is the coauthor of Fixing Your Scrum: Practical Solutions to Common Scrum Problems (Pragmatic Bookshelf, 2020, with Ryan Ripley).
Regularly Revert to the Simplest Thing That Might Work

Eric Naiburg

Vice President of Marketing and Operations, Scrum.org

Eric is coauthor of UML for Database Design (Addison-Wesley Professional, 2001) and UML for Mere Mortals (Addison-Wesley Professional, 2004). Eric is currently responsible for all aspects of marketing, support, outbound communications, and operations for Scrum.org. Previously, he held the role of Director of Marketing for INetU (now ViaWest). Before INetU, Eric was Program Director at IBM and Rational Software, responsible for application life cycle management (ALM), DevOps, and Agile solutions. Eric has held product management and marketing roles with other organizations, including Ivar Jacobson Consulting, CAST Software, and Logic Works Inc. (acquired by Platinum Technologies and CA), as well as Product Manager for Erwin.
How We Used Scrum to Work with an External Agency

Judy Neher

Certified Scrum Trainer

Judy Neher is a Certified Scrum Trainer from Indiana, USA. She has coached and trained Agile and Scrum in the government space for decades and was invited to work with government security professionals to help them become Agile.
Introducing Abuser Stories

Alan O’Callaghan

CST, Principal Product Owner, Emerald Hill Limited

Allan O’Callaghan has been a Scrum practitioner for over 20 years. He is a Certified Scrum Trainer with Scrum Alliance and a member of the Scrum Patterns Group.
Put Business Value Front and Center
The “MetaScrum” Pattern to Drive Agile Transformation

Stephanie Ockerman

Professional Scrum Trainer and Author, AgileSocks.com

Stephanie Ockerman is the founder of Agile Socks LLC, an Agile training and coaching business whose mission is to help people build amazing things together so that we can all thrive in an unpredictable and complex world. She brings more than 15 years of experience supporting teams and organizations in delivering valuable products and services as a Scrum Master, trainer, and coach. She is coauthor of the book, Mastering Professional Scrum (Addison-Wesley Professional, 2019, with Simon Reindl), and she blogs regularly at www.AgileSocks.com.
The Scrum Master’s Most Important Tool

Paul Oldfield

Team Member at Youmanage

Paul graduated in Botany in 1978, providing him with a sound scientific basis for coping with very complex systems. Paul moved to computing for paid work, starting in research work, where waterfall development was not feasible. Paul grew his own ways of working that he found later on had a lot in common with the early Agile approaches. Paul now works with Youmanage.co.uk, a small organization that is currently growing out of startup status.
Networks and Respect

Fabio Panzavolta

Professional Scrum Trainer and Owner of Collective Genius

Fabio started his career as a software engineer in 2001. After years of working as a project manager and applying traditional project management, he discovered and embraced Scrum, a way of working that perfectly fits his mindset. Fabio is a Professional Scrum Trainer with Scrum.org and the founder and owner of Collective Genius, a service company that helps people and companies deliver better products with Scrum. By the way, Fabio loves to hear from you if you like motorbikes as well.
Scrum and Organizational Design in Practice

Jeff Patton

Product Design and Process Coach

Jeff Patton helps companies adopt a way of working that’s focused on building great products, not just building stuff faster. Jeff blends a mixture of Agile thinking, Lean and Lean Startup Thinking, and UX design and Design Thinking to end up with a holistic, product-centric way of working. Jeff is the author of the bestselling book User Story Mapping (O’Reilly, 2014), which describes a simple, holistic approach to using stories in Agile development without losing sight of the big picture.
Mind Your Outcomes. Pay Attention to Value.

Marcus Raitner

Corporate Jester and Agile Coach

Marcus is convinced that elephants can dance. Since 2015, he’s been accompanying the BMW Group IT on its journey to an Agile organization as an Agile coach and Agile transformation agent. After receiving his doctorate in computer science at the University of Passau, Marcus started as a project manager at msg systems, a large IT service provider. In 2010, he started from scratch and joined esc Solutions, a small startup with a focus on project management and coaching. Marcus is the author of Manifesto for Human(e) Leadership: Six Theses for New Leadership in the Age of Digitalization (Self published, 2020). Marcus regularly writes about leadership, digitization, new work, agility, and much more in this blog, “Führung erfahren!”.
Three Common Misconceptions About User Stories
The Court Jester at the Touchline
The Trinity of Agile Leadership

Konstantin Razumovsky

Agile Coach and Professional Scrum Trainer

Konstantin is an Agile practitioner from Minsk, Belarus. He combines training activities with practical work for organizations and teams that want to benefit from using Lean and Agile principles. Konstantin has a background in Java Development and also worked as Project Manager, Scrum Master, and Agile Coach. He believes in teams and considers them to be the true source of most great things in product development.
And Then a Miracle Occurs

Simon Reindl

Professional Scrum Trainer

Simon is an experienced coach, speaker, author, trainer, and technologist with over 20 years’ experience helping people adopt new technologies and realize business value. He has experience in a wide range of business domains in both the public and private sectors around the world. His passion is helping teams and organizations deliver better value by building products that delight the customer. He does this by engaging with the people, facilitating their understanding, and helping improve their performance. Simon is coauthor of the book, Mastering Professional Scrum (Addison-Wesley Professional, 2019, with Stephanie Ockerman).
How I Learned to Stop Worrying and Start Using Scrum

Konstantin Ribel

Scrum Master and LeSS-Friendly Scrum Trainer

Konstantin Ribel is a Scrum Master and the first fomenter of the LeSS Huge adoption at BMW Group’s Autonomous Driving division. He is convinced that today’s organizations need a radical structural change to shift mindsets and unleash collective intelligence. His vision is to foster organizations where human intelligence and efforts are highly respected. Contact Konstantin at konstantin@ribel.eu and konstantin-ribel.com.
The Vicious Effects of Managing for Utilization

Ryan Ripley

Professional Scrum Trainer

A professional Scrum trainer with Scrum.org, Ryan Ripley has worked as a software developer, manager, director, and Scrum Master at various Fortune 500 companies in the medical device, wholesale, and financial services industries. He is host of Agile for Humans, the top Agile podcast on iTunes. Ryan is coauthor of Fixing Your Scrum: Practical Solutions to Common Scrum Problems (Pragmatic Bookshelf, 2020, with Todd Miller). Ryan lives in Indiana with his wife, Kristin, and three children. He blogs at www.ryanripley.com and is on Twitter @ryanripley.
How I Learned That It’s Not About Me, the Scrum Master

Linda Rising

Computer Software Consultant and Professional

Linda Rising is an independent consultant who lives near Nashville, Tennessee. Linda has a PhD in object-based design metrics from Arizona State University. Her background includes university teaching as well as work in telecommunications, avionics, and tactical weapons systems. She is an internationally known presenter on topics related to Agile development, patterns, retrospectives, the change process, and the connection between the latest neuroscience and software development. Linda is the author of numerous articles and five books.
The Power of Standing Up

Rafael Sabbagh

Certified Scrum Trainer (CST), Accredited Kanban Trainer (AKT)

Rafael Sabbagh is the cofounder of Knowledge21, where he has been working in Agile transformations of companies ranging from startups to multinationals since the mid-2000s. He has over two decades of experience with enterprise IT projects, product development, and software development methods and techniques. As a Certified Scrum Trainer (CST), an Accredited Kanban Trainer (AKT), and a member of the Scrum Alliance Board of Directors from 2015 to 2017, Rafael has done work in more than 20 countries and has spoken at several Agile events worldwide.
Scrum: Giving the Steering Wheel Back to Business
The Purpose of Sprint Review Is to Gather Feedback — Period
The Origins of Scrum Might Not Be What You Think They Are

Sanjay Saini

Professional Scrum Trainer and Founder of AgileWoW

Sanjay has been working for more than 20 years in the IT industry across different domains, including banking, manufacturing, and energy. Sanjay lives Integrity, Think Customer, Ignite Passion, Take Accountability, Promote Innovation, and Achieve Greatness. He is a Professional Scrum Trainer from Scrum.org.
A Demo Is Not Enough — Go and Deploy for Better Feedback

Uwe Schirmer

Agile Coach

Uwe is a coach and trainer for Scrum and for Agile Requirements Engineering. He has more than 20 years’ experience in different roles and domains of IT. He tries to convey a holistic view of the software development life cycle and helps his customers build up and repair teams and invent or rethink their processes and approaches from requirements to production and beyond.
Start with the Why of Your Scrum
Teams Are More Than Collections of Technical Skills

Andreas Schliep

Executive Partner at DasScrumTeam AG

Andreas Schliep started one of the first multi-team Scrum adaptations in Germany back in 2004. Since then, he has helped individuals and organizations as Scrum Master, coach, and trainer. He holds various Certified Scrum certifications from the Scrum Alliance and is cofounder and Scrum Master of DasScrumTeam AG.
Scrum Is “Agile Leadership”

Robbin Schuurman

Product Leader, Professional Scrum Trainer, and Author

Robbin is a product leader, Professional Scrum Trainer, and passionate golfer. Robbin is coauthor of the practical book, 50 Tinten Nee: Effectief stakeholdermanagement voor de Product Owner (Boom Uitgevers, 2019, with Willem Vermaak). Robbin is on a mission to improve the profession of product management.
Mastering the Art of “No” to Maximize Value

Ken Schwaber

Co-creator of Scrum and Founder of Scrum.org

Ken Schwaber is a veteran of the software development industry (from bottle washer to boss). He co-developed the Scrum process with Jeff Sutherland in the early 1990s to help organizations struggling with complex development projects. One of the signatories to the Agile Manifesto in 2001, he subsequently founded the Agile Alliance and Scrum Alliance. He left the Scrum Alliance to found Scrum.org in 2009. Ken has written several books about Scrum. He lives in Lexington, Massachusetts.
Scrum Is Simple. Just Use It As Is.

Anu Smalley

President, Capala Consulting Group

Anu Smalley is a Certified Scrum Trainer and the founder of Capala Consulting Group. Prior to her focus on Agile coaching and training, Anu was a successful Product Owner within large organizations.
Product Backlog Refinement Is an Important Team Activity

Zuzana Šochová

Agile Coach and Certified Scrum Trainer

Zuzana “Zuzi” Šochová is an independent Agile Coach and trainer and a Certified Scrum Trainer with the Scrum Alliance with more than 15 years’ experience. She has implemented Agile transformations and implementations in many companies and teams around the world. By creating and sustaining Agile leadership, she believes the worlds of work and life can be happier and more successful. She is the founder of the Czech Agile Association and the AgilePrague conference, a member of the Scrum Alliance Board of Directors, and author of The Great ScrumMaster: #ScrumMasterWay (Addison-Wesley Professional, 2017). She can be reached at zuzi@sochova.com or on Twitter @zuzuzka.
Guiding Scrum Masters on Their Never-Ending Journey with the #ScrumMasterWay Concept

Michael K. Spayd

Chief Sage, Collective Edge Coaching

Michael is wired for transformation: you, me, us, all of us. Michael started as an Agile coach working on an enterprise transformation way back in 2001. He was involved in a number of large transformations, bringing in models and thinking from his world of organizational development, change, culture, leadership, and professional coaching. In 2010, Michael cofounded the Agile Coaching Institute with Lyssa Adkins to transform the Agile coaching profession. Having made good progress, it was sold in 2017. Michael cofounded Trans4mation with Michele Madore in 2016 to transform Agile transformations. They coauthored the book, Agile Transformation: Using the Integral Agile Transformation Framework to Think and Lead Differently (Addison-Wesley Professional, 2020). Michael has launched a new organizational platform in 2020: The Collective Edge, LLC.
What It Means to Self-Organize

David Starr

Professional Software Craftsman

David Starr is a professional software craftsman committed to improving agility, collaboration, and technical excellence in software development teams. He is currently a Principal Solutions Architect at Microsoft, is the founder of Elegant Code Solutions, has served in numerous leadership roles, and has been an early and consistent advocate for Agile development. He helped in creating some Scrum.org curriculum.
Automating Agility

Gunther Verheyen

independent Scrum Caretaker

Gunther Verheyen is a seasoned Scrum practitioner (since 2003). As a consultant, Gunther had the pleasure of employing Scrum with several teams in diverse circumstances and business domains before becoming the inspiration behind some large-scale Scrum adoptions. After partnering exclusively with Ken Schwaber, Scrum co-creator, and Scrum.org, he is continuing his journey of Scrum as an independent Scrum Caretaker. Gunther is the author of Scrum – A Pocket Guide: A Smart Travel Companion (Van Haren Publishing, 2013, 2019).
What Will You Define as “Done”?
Scrum Is More About Behavior Than It Is About Process

Willem Vermaak

Product Management Consultant

Willem is passionate about handing people a fishing rod. He does not seek quick solutions, but wants to train, guide, coach, and mentor people so that they can go out and win. Willem’s objective is to help product people deliver the most valuable products, both for their users and for the company. Willem is coauthor of the practical book, 50 Tinten Nee: Effectief stakeholdermanagement voor de Product Owner (Boom Uitgevers, 2019, with Robbin Schuurman).
Mastering the Art of “No” to Maximize Value

Stacia Viscardi

CEO, AgileEvolution, Inc.

Stacia Heimgartner Viscardi has been practicing Agile and Lean techniques since 2003. Over the years, she has traveled to 23 different countries to teach and coach a variety of companies to help them think about and practice better ways of working. She has been a CST with the ScrumAlliance since 2006 and recently became part of the leadership team of the Open Leadership Network. Stacia coauthored The Software Project Manager’s Bridge to Agility (Addison-Wesley Professional, 2008) with Michele Sliger and authored The Professional ScrumMaster’s Handbook (Packt Publishing, 2013). Her current work in progress is Failagility: The Business of Imperfection. When she is not teaching or coaching, Stacia can usually be found in a barn, smiling while failing at dressage with her horse, Figo.
Actually, It’s Not Really About Scrum

Bas Vodde

LeSS Co-creator and Product Development Coach

Bas Vodde is a coach, programmer, trainer, and author related to modern Agile and Lean product development. He is the creator of the LeSS (Large-Scale Scrum) framework and is the author of Large-Scale Scrum: More with LeSS, Scaling Agile and Lean Development, and Practices for Scaling Agile and Lean Development (all from Addison-Wesley Professional, all together with his good friend Craig Larman). When he coaches organizations, he likes to have a holistic, system-wide view by working on three levels: 1) organizational, 2) team, and 3) individual/technical practices. In his spare time, he is a maintainer of the CppUTest unit test framework. Bas works for Odd-e, a company that supports organizations in improving their product development.
Digital Tools Considered Harmful: Sprint Backlog
Digital Tools Considered Harmful: Jira
The Scrum Master as a Technical Coach
Actively Doing Nothing (Is Actually Hard Work)

Bob Warfield

CEO of CNCCookbook, Inc.

Bob is a serial entrepreneur with broad industry experience, including CNC manufacturing, social, cloud, big data, SaaS, desktop, and enterprise software in organizations ranging from startups to publicly traded, $500M/year companies. Bob feels comfortable as CEO, Founder, CTO, and VP Engineering. Bob is currently having the best time ever running CNCCookbook, the CNC manufacturing industry’s most popular blog and a haven for professional CNC’ers and DIY makers alike.
The “Standing Meeting”

Geoff Watts

Agile Leadership Coach

Geoff Watts was one of the first Certified Scrum Masters, Certified Scrum Coaches, and Certified Scrum Trainers in the world. He is the author of best-selling books, Scrum Mastery (Inspect & Adapt Ltd, 2013), Product Mastery (Inspect & Adapt Ltd, 2017), and The Coach’s Casebook (Inspect & Adapt Ltd, 2015). His latest available book is Team Mastery (Inspect & Adapt Ltd, 2020). Geoff coaches individuals and teams toward self-mastery for the benefit of themselves and others.
The Scrum Master as Coach

Dave West

CEO, Scrum.org

Dave West is the Product Owner and CEO at Scrum.org. He is a frequent keynote speaker and is a widely published author of articles. He also is the coauthor of two books, The Nexus Framework for Scaling Scrum (Addison-Wesley Professional, 2017) and Head First Object-Oriented Analysis and Design (O’Reilly, 2006). He led the development of the Rational Unified Process (RUP) and then worked with Ivar Jacobson in running the North American business for IJI. He then managed the software delivery practice at Forrester Research, where he was VP and Research Director. Prior to joining Scrum.org, he was Chief Product Officer at Tasktop, where he was responsible for product management, engineering, and architecture.
The Sprint Review Is Not a Phase-Gate

Willy Wijnands

Passionate Science Teacher and Founder of eduScrum

Willy Wijnands is a passionate science teacher at the Ashram College in Alphen aan de Rijn (the Netherlands) and an Aikido teacher. He is the initiator and founder of eduScrum and cofounder of the worldwide initiative, Agile in Education. He has coauthored the eduScrum Guide and Scrum in Actie (Business Contact, 2015). He contributed to the book Agile and Lean Concepts for Teaching and Learning (Springer, 2018). Since 2011, Willy has trained more than 900 teachers in eduScrum worldwide and facilitated over 2,000 students in using eduScrum at the Ashram College. Find more information about eduScrum at https://oreil.ly/MbERJ.
Agile in Education with eduScrum

Scrum Glossary

burn-down chart

A chart showing the decrease of remaining work against time.

burn-up chart

A chart showing the increase of a parameter — e.g., value — against time.

Daily Scrum

A daily event, time-boxed to 15 minutes or less, to re-plan the development work during a Sprint. The event allows the Development Team to share daily progress, plan the work for the next 24 hours, and update Sprint Backlog accordingly.

definition of “Done”

The set of expectations on quality that a product Increment must exhibit to make it releasable — that is, fit for a release to the product’s users.

Development standards

The set of standards and practices that a Development Team identifies as needed to create releasable Increments of product no later than by the end of a Sprint.

Development Team (also: Team)

The group of people accountable for all evolutionary development work needed to create a releasable Increment no later than by the end of a Sprint.

emergence

The process of unforeseen facts or knowledge of a fact coming into existence or prominence of a previously unknown fact; or knowledge of a fact becoming visible unexpectedly.

empiricism

The process control type in which decisions are based on observed results, experience, and experimentation. Empiricism implements regular inspections and adaptations requiring and creating transparency. Also referred to as empirical process control.

forecast

The anticipation of a future trend based on observations of the past, like the selection of Product Backlog deemed deliverable in the current Sprint or in future Sprints for future Product Backlog.

impediment

Any hindrance or obstacle that is blocking or slowing down the Development Team and cannot be solved through the self-organization of the Development Team itself. Raised no later than at the Daily Scrum, the Scrum Master is accountable for its removal.

Increment

A candidate of releasable work that adds to and changes previously created Increments, and — as a whole — forms a product.

product (n)

A tangible or nontangible good or service providing immediate value to its consumers (1); the outcome of an action or process (2). Defines the span of: Product Owner, Product Backlog, and Increment.

Product Backlog

An ordered, evolving list of all work deemed necessary by the Product Owner to create, deliver, maintain, and sustain a product.

Product Backlog refinement

The recurring activity in a Sprint through which the Product Owner and the Development Team add granularity to future Product Backlog.

Product Owner

The person accountable for optimizing the value a product delivers, primarily by managing and expressing all product expectations and ideas in a Product Backlog. The Product Owner is the single representative of all stakeholders.

Scrum (n)

1) A simple framework for complex product delivery; 2) a simple framework for addressing complex challenges.

Scrum Master

The person accountable for fostering an environment of Scrum by guiding, coaching, teaching, and facilitating one or more Scrum Teams and their environment in understanding and employing Scrum.

Scrum Team

The combined accountabilities of Product Owner, Development Team, and Scrum Master.

Scrum Values

A set of five fundamental values and qualities underpinning the Scrum framework: Commitment, Focus, Openness, Respect, and Courage.

Sprint

An event that serves as a container for the other Scrum events, time-boxed to four weeks or less. The event allows teams to get a sufficient amount of work done and ensures timely inspection, reflection, and adaptation at a product, strategic, and process level. The other Scrum events are Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

Sprint Backlog

An evolving plan of all work deemed necessary by the Development Team to realize a Sprint’s goal.

Sprint Goal

A concise statement expressing the overarching purpose of a Sprint.

Sprint Length

The time-box of a Sprint, which is four weeks or less.

Sprint Planning

An event marking the start of a Sprint, time-boxed to eight hours or less. The event allows the Scrum Team to inspect the Product Backlog considered most valuable at that time and design that forecast into an initial Sprint Backlog against the Sprint Goal.

Sprint Retrospective

An event marking the closing of a Sprint, time-boxed to three hours or less. The event allows the Scrum Team to inspect the Sprint that is ending and establish the way of working for the next Sprint.

Sprint Review

An event marking the closing of the development of a Sprint, time-boxed to four hours or less. The event allows the Scrum Team and stakeholders to inspect the Increment, the overall progress, and strategic changes in order to allow the Product Owner to update the Product Backlog.

stakeholder

A person external to the Scrum Team with a specific interest in or knowledge of a product that is required for the further evolution of the product.

time-box

A container in time of a maximum duration, potentially a fixed duration. In Scrum, all events have a maximum duration, except for the Sprint itself, which has a fixed duration.

velocity

Popular indication of the average amount of Product Backlog turned into an Increment of releasable product during a Sprint by a specific (composition of) a team. Velocity helps a team to forecast Sprints.

Index

A

- abuser stories, Judy Neher-Judy Neher

- accountability and responsibilities

- of Development Team, Stacia Viscardi, Mitch Lacey, Rich Hundhausen-Rich Hundhausen, Chris Lukassen, Rich Hundhausen-Not Expressing the Sprint Plan, Mark Levison-Mark Levison, Lisa Crispin-Take It Slow, Rich Hundhausen, Anu Smalley-Anu Smalley, James O. Coplien-James O. Coplien, Ryan Ripley, Michael K. Spayd, Andreas Schliep & Peter Beck, Marcus Raitner

- (see also Development Team)

- of Product Owner, Stacia Viscardi, Ellen Gottesdiener, Ralph Jocham & Don McGreal, Alan O’Callaghan, Markus Gaertner, Willem Vermaak & Robbin Schuurman, James O. Coplien, Product and Sprint Backlog Integration, Luis Gonçalves, Ralph Jocham & Don McGreal, Ryan Ripley, Michael K. Spayd, Andreas Schliep & Peter Beck, Marcus Raitner-What Else?

- (see also Product Owner)

- of Scrum Master, Luis Gonçalves-Luis Gonçalves, Ryan Ripley-Ryan Ripley, Bob Galen, Marcus Raitner-Marcus Raitner, Bas Vodde-Bas Vodde, Derek Davidson-Derek Davidson, Len Lagestee-Anything Keeping a Team from Self-Healing, Stephanie Ockerman-Stephanie Ockerman, Zuzi Šochová-Zuzi Šochová, Andreas Schliep & Peter Beck, Marcus Raitner

- (see also Scrum Master)

- of Scrum Team, Alan O’Callaghan-Alan O’Callaghan, Len Lagestee-Len Lagestee, Luis Gonçalves-Luis Gonçalves, Ralph Jocham & Don McGreal-Ralph Jocham & Don McGreal, Gunther Verheyen

- (see also Scrum Team)

- adaptation

- in Daily Scrum, James O. Coplien-James O. Coplien

- in empiricism, Ken Schwaber, Todd Miller, Ralph Jocham & Don McGreal, Bob Hartman-Bob Hartman

- events as opportunities for, Peter Goetz & Uwe Schirmer

- learning by, Arno Delhij

- of Scrum, premature, Steve Berczuk-Steve Berczuk

- in Sprint Retrospective, Steve Berczuk-Steve Berczuk

- adoption of Scrum

- change, learning discipline for, Chris Lukassen-6. Systematic Ability

- convincing others, Derek Davidson-Derek Davidson

- decision making affected by, Stacia Viscardi

- focusing on current challenges, Peter Goetz & Uwe Schirmer

- impediments revealed by, Stacia Viscardi-Stacia Viscardi

- incremental development skills needed for, James W. Grenning-James W. Grenning

- Jira used for, disadvantages of, Scrum Confusion

- leadership roles, putting into practice, Andreas Schliep & Peter Beck

- MetaScrum pattern for, Alan O’Callaghan-Alan O’Callaghan

- mindset change required for, 2. Scrum Offers No Benefits When You Only Follow the Process, Gil Broza-Gil Broza

- at organization level, 4. Transforming to Scrum Means Transforming Your Organization, Fabio Panzavolta-Fabio Panzavolta

- organizational culture affecting, Ron Eringa-Ron Eringa

- premature adaptations in, Steve Berczuk-Steve Berczuk

- product delivery systems helping with, David Starr-David Starr

- simplicity benefitting, Todd Miller-Todd Miller

- time required for, 3. There Is No “Scrum Switch”

- traditional managerial roles abolished by, What Else?

- Agile Manifesto

- face-to-face conversation, principle for, Daniel James Gullo

- individuals and interactions principle, Ralph Jocham & Don McGreal

- leadership based on, Andreas Schliep & Peter Beck

- simplicity, principle of, Willem Vermaak & Robbin Schuurman

- Agile values, Gil Broza, Andreas Schliep & Peter Beck

- AIR (Actions, Intentions, Results), Si Alhir-Si Alhir

- artifacts, Peter Goetz & Uwe Schirmer

- (see also charts; Sprint Goal)

- Increments (see Increments)

- Product Backlog (see Product Backlog)

- Sprint Backlog (see Sprint Backlog)

- Tao of Scrum regarding, Michael K. Spayd

- authenticity, Hiren Doshi

- automated product delivery systems, David Starr-David Starr

B

- Backlog (see Product Backlog; Sprint Backlog)

- Borland Quattro methodology, James O. Coplien, Bob Warfield

- Bowman, Sharon (author)

- “Training from the Back of the Room”, Evelien Acun-Roos

- brain science (see cognitive processes)

- Brooks, Frederick (author)

- The Mythical Man-Month, Daniel Heinen & Konstantin Ribel

- bugs, Rich Hundhausen-Rich Hundhausen

- burn-down chart, Len Lagestee, Arno Delhij, Scrum Glossary

- burn-up chart, Len Lagestee, Scrum Glossary

- business value (see value)

C

- charts

- burn-down chart, Len Lagestee, Arno Delhij, Scrum Glossary

- burn-up chart, Len Lagestee, Scrum Glossary

- displaying problems, Make Problems Visible

- displaying Sprint Plan, Expressing the Sprint Plan Using a Diagram

- Chouinard, Yvon (author)

- Let My People Go Surfing, Todd Miller

- CI (Continuous Integration) systems, David Starr-David Starr, Jesse Houwing-Jesse Houwing

- coaching, Markus Gaertner, Geoff Watts-Geoff Watts, Bas Vodde-Bas Vodde

- cognitive processes

- insights, creating environment for, Stijn Decneut-Stijn Decneut

- learning and thinking, improving in Scrum events, Evelien Acun-Roos-Evelien Acun-Roos

- collaboration, Gil Broza

- Agile principles for, Daniel James Gullo

- in continuous integration and delivery systems, David Starr, Jesse Houwing

- difficulty of, in distributed development, Pete Deemer

- difficulty of, with vendor teams, Daniel Heinen & Konstantin Ribel

- difficulty of, with “Multiple Scrum Teams”, Multiple Scrum Teams

- methods of, Rich Hundhausen

- personality considerations for, Uwe Schirmer-Uwe Schirmer

- safe environment for, Konstantin Razumovsky

- in Sprint Planning, Luis Gonçalves

- of students, Arno Delhij, Willy Wijnands

- commitment, Len Lagestee, As a Team, Commit to Your Desired Level of Quality, Bob Galen, Gunther Verheyen

- compassion, Hiren Doshi

- complex problems

- compared to complicated problems, Stijn Decneut

- empiricism required for, Stijn Decneut

- negative responses to, overcoming, Bob Galen, Stijn Decneut

- problem solving and scientific method for, Si Alhir-Si Alhir

- Scrum designed to solve, Dave West

- Continuous Delivery systems, David Starr-David Starr

- continuous improvement, Stijn Decneut-Stijn Decneut, Kurt Bittner-Kurt Bittner

- Continuous Integration (CI) systems, David Starr-David Starr, Jesse Houwing-Jesse Houwing

- Conway's Law, Daniel Heinen & Konstantin Ribel

- Coplien, James O. (author)

- A Scrum Book: The Spirit of the Game, Alan O’Callaghan

- “Examining the Software Development Process”, James O. Coplien

- courage, Jesse Houwing, Bob Galen, Gunther Verheyen

- Cross-Functional Team pattern, James O. Coplien-James O. Coplien

- Crunk, John (author)

- Examining Tuckman's Team Theory in Non-collocated Software Development Teams, Daniel James Gullo

- customer-vendor anti-pattern, 2. User Stories Are Specifications, 3. The Product Owner Writes the User Stories

- customers

- giving feedback at Sprint Review, Dave West-Dave West, Rafael Sabbagh-Rafael Sabbagh, Sanjay Saini-Sanjay Saini

- as priority in decision making, Mitch Lacey-Mitch Lacey

- user stories regarding (see user stories)

- value for (see value)

D

- Daily Scrum, James O. Coplien-James O. Coplien, Scrum Glossary

- origins of, Bob Warfield-Bob Warfield

- premature adaptations affecting, Steve Berczuk

- principles benefitting, Gil Broza

- time-box for, James O. Coplien

- traditional principles affecting, Gil Broza

- decision making, Stacia Viscardi, Mitch Lacey-Mitch Lacey, Stephanie Ockerman

- definition of “Done” (see “Done” (and definition of))

- DeGrace, Peter (author)

- Wicked Problems, Righteous Solutions, Rafael Sabbagh

- development standards, Gunther Verheyen, Scrum Glossary

- Development Team, Scrum Glossary

- access to Product Backlog, Markus Gaertner

- accountability of, Mitch Lacey, Rich Hundhausen, Ryan Ripley

- building, personality considerations for, Uwe Schirmer-Uwe Schirmer

- collaboration in, types of, Rich Hundhausen

- communication with stakeholders, Markus Gaertner-Markus Gaertner

- cross-functional, James O. Coplien-James O. Coplien

- distributed (dispersed), Pete Deemer-Pete Deemer, Bas Vodde, Daniel James Gullo-Daniel James Gullo, Eric Naiburg-Eric Naiburg

- dysfunctional types of, Rich Hundhausen-Rich Hundhausen

- learning new skills, Markus Gaertner-Markus Gaertner, James O. Coplien-James O. Coplien, James W. Grenning-James W. Grenning

- market knowledge needed by, Chris Lukassen-Chris Lukassen

- maximizing utilization of, disadvantages of, Daniel Heinen & Konstantin Ribel-Daniel Heinen & Konstantin Ribel

- multiple teams, Markus Gaertner-Multi-Team Scrum, Jesse Houwing-Jesse Houwing

- role in creating Sprint Backlog, Ralph Jocham & Don McGreal

- role in Daily Scrum, James O. Coplien-James O. Coplien

- role in Product Backlog refinement, Anu Smalley-Anu Smalley

- role in setting Sprint Goal, Mark Levison

- role in Sprint Planning, Rich Hundhausen-Not Expressing the Sprint Plan

- role of, Stacia Viscardi

- scaling with vendor teams, Daniel Heinen & Konstantin Ribel-Daniel Heinen & Konstantin Ribel

- Scrum Master having perspective of, Zuzi Šochová

- Scrum Master's authority to remove members of, Derek Davidson-Derek Davidson, Bob Galen-Bob Galen

- shared leadership by, Andreas Schliep & Peter Beck, Marcus Raitner

- shared responsibility by, Markus Gaertner-Markus Gaertner, No Shared Team Responsibility

- Sprint Backlog owned by, Bas Vodde, Mark Levison-Mark Levison

- Tao of Scrum regarding, Michael K. Spayd

- technical coaching for, Bas Vodde-Bas Vodde

- testing as responsibility of, Lisa Crispin-Take It Slow

- transitioning to Agile, James W. Grenning-James W. Grenning

- digital tools

- Jira, Bas Vodde-We’re Stuck with Jira. Now What?, 1. User Stories Are Part of Scrum

- for Sprint Backlog, Bas Vodde-Bas Vodde, Mark Levison-Mark Levison

- DISC, Uwe Schirmer

- distributed development, Pete Deemer-Pete Deemer, Bas Vodde, Daniel James Gullo-Daniel James Gullo, Eric Naiburg-Eric Naiburg

- Distributed Scrum Primer, Pete Deemer

- “Done” (and definition of), Gil Broza, Peter Goetz & Uwe Schirmer, Todd Miller, Gunther Verheyen-Gunther Verheyen, Simon Reindl, Simon Reindl, Mark Levison, Dave West, Evelien Acun-Roos, Michael K. Spayd, Arno Delhij, Scrum Glossary

- Drucker, Peter (author)

- The Practice of Management, Ralph Jocham & Don McGreal

E

- education, using Scrum for, Arno Delhij-Arno Delhij, Willy Wijnands-Willy Wijnands

- eduScrum, Arno Delhij, Willy Wijnands-Willy Wijnands

- “The Elements of Value”, Ralph Jocham & Don McGreal

- emergence, Scrum Glossary

- empathy, Hiren Doshi

- empiricism, Ken Schwaber, Bob Galen, Scrum Glossary

- complex problems requiring, Stijn Decneut

- importance of, Todd Miller

- marketplace validation allowing, Ralph Jocham & Don McGreal

- pillars of, Bob Hartman

- Sprint Retrospective as part of, Steve Berczuk-Steve Berczuk, Bob Hartman-Bob Hartman

- enterprise Scrum, James O. Coplien

- events, Peter Goetz & Uwe Schirmer

- Daily Scrum (see Daily Scrum)

- improving learning and thinking during, Evelien Acun-Roos-Evelien Acun-Roos

- as rituals, Jasper Lamers-Jasper Lamers

- Sprint (see Sprint)

- Sprint Planning (see Sprint Planning)

- Sprint Retrospective (see Sprint Retrospective)

- Sprint Review (see Sprint Review)

- standing during, Linda Rising-Linda Rising

- Tao of Scrum regarding, Michael K. Spayd

- “Examining the Software Development Process”, James O. Coplien

- Examining Tuckman's Team Theory in Non-collocated Software Development Teams, Daniel James Gullo

- example mapping, Keep Talking

- experimentation, Design Small Experiments for Your Biggest Problems, Ryan Ripley, Kurt Bittner, Si Alhir

- Extreme Programming (XP), James W. Grenning, 1. User Stories Are Part of Scrum, Judy Neher, Andreas Schliep & Peter Beck

F

- Flow Framework, Mik Kersten-Mik Kersten

- focus, Gunther Verheyen

- on customer value, Focus on Outcome-Keep Effort and Outcome Visible, Mitch Lacey-Mitch Lacey

- of Scrum Master, Bob Galen

- forecast, Rich Hundhausen, Luis Gonçalves, Scrum Glossary

- forgiveness, Hiren Doshi

- “Fun” (and definition of), Arno Delhij

G

- generalizing, Rich Hundhausen

- goal (see Sprint goal)

- group development stages, Daniel James Gullo

- growth mindset, Mitch Lacey

H

- Heckscher, Charles (author)

- “The Limits of Participatory Management”, James O. Coplien

- Hermann Brain Dominance Index (HBDI), Uwe Schirmer

- hierarchical organizations, Paul Oldfield, James O. Coplien

- hoarding, Rich Hundhausen

- hogging, Rich Hundhausen

- hubs, in scale-free networks, James O. Coplien

- humane leadership, Humane Leadership

- humility, Hiren Doshi, Derek Davidson-Derek Davidson

I

- impediments, Scrum Glossary

- Development Team members as, Derek Davidson-Derek Davidson, Bob Galen-Bob Galen

- openness regarding, Len Lagestee

- revealed by Scrum, Stacia Viscardi-Stacia Viscardi, Fabio Panzavolta-Fabio Panzavolta

- Scrum Master removing, Marcus Raitner-Marcus Raitner

- types of, Len Lagestee-Anything Keeping a Team from Self-Healing

- Increments, Peter Goetz & Uwe Schirmer, Gunther Verheyen, Rafael Sabbagh, Rafael Sabbagh, James O. Coplien, Scrum Glossary

- definition of “Done” for (see “Done” (and definition of))

- not completing, Pete Deemer, Simon Reindl-Simon Reindl

- inside-out thinking, Ralph Jocham & Don McGreal

- insights, environment for, Stijn Decneut-Stijn Decneut

- inspection

- in Daily Scrum, James O. Coplien-James O. Coplien

- in empiricism, Ken Schwaber, Todd Miller, Ralph Jocham & Don McGreal, Bob Hartman-Bob Hartman

- events as opportunities for, Peter Goetz & Uwe Schirmer

- learning by, Arno Delhij

- in Sprint Retrospective, Steve Berczuk-Steve Berczuk

J

- Jira

- acceptable use of, We’re Stuck with Jira. Now What?

- disadvantages of using, Bas Vodde-We’re Stuck with Jira. Now What?

- user stories required in, 1. User Stories Are Part of Scrum

- Jocham, Ralph (author)

- The Professional Product Owner, Ralph Jocham & Don McGreal

L

- leadership

- Agile values for, Andreas Schliep & Peter Beck

- self-organizing teams supported by, Ron Eringa-Ron Eringa

- servant-leadership, Luis Gonçalves, Ryan Ripley-Ryan Ripley, Bob Galen, Geoff Watts, Marcus Raitner

- successful, three characteristics of, Marcus Raitner-What Else?

- triangular framework for, Andreas Schliep & Peter Beck-Andreas Schliep & Peter Beck, Marcus Raitner-What Else?

- Lean principles

- applying across an organization, Mik Kersten

- muri, eliminating, James O. Coplien

- Scrum based on, Ken Schwaber

- self-organization as, Self-Organization

- learning processes (see cognitive processes)

- Let My People Go Surfing, Todd Miller

- LIFO (Life Orientation), Uwe Schirmer

- “The Limits of Participatory Management”, James O. Coplien

M

- Master (see Scrum Master)

- MBTI (Myers-Briggs Type Indicator), Uwe Schirmer

- McGreal, Don (author)

- The Professional Product Owner, Ralph Jocham & Don McGreal

- meetings (see events)

- MetaScrum pattern, Alan O’Callaghan-Alan O’Callaghan

- mindset

- changes required in, 2. Scrum Offers No Benefits When You Only Follow the Process, Gil Broza-Gil Broza

- growth mindset, Mitch Lacey

- inside-out thinking, Ralph Jocham & Don McGreal

- outside-in thinking, Ralph Jocham & Don McGreal, Ellen Gottesdiener

- Scrum as, Ken Schwaber-Ken Schwaber

- mobbing, Rich Hundhausen

- multi-location development (see distributed development)

- “Multi-Team Scrum”, Multi-Team Scrum

- “Multiple Scrum Teams”, Multiple Scrum Teams

- muri, eliminating, James O. Coplien, James O. Coplien

- Myers-Briggs Type Indicator (MBTI), Uwe Schirmer

- #MyScrumMasterWay concept, Zuzi Šochová-Zuzi Šochová

- The Mythical Man-Month, Daniel Heinen & Konstantin Ribel

N

- networks

- self-organizing teams as, Paul Oldfield-Paul Oldfield

- “The New New Product Development Game”, Rafael Sabbagh

- Nonaka, Ikujiro (author)

- “The New New Product Development Game”, Rafael Sabbagh

O

- online resources

- affinity sizing, Anu Smalley

- Conway's Law, Daniel Heinen & Konstantin Ribel

- Distributed Scrum Primer, Pete Deemer

- eduScrum, Willy Wijnands

- “The Elements of Value”, Ralph Jocham & Don McGreal

- example mapping, Keep Talking

- for this book, How to Contact Us

- planning poker, Anu Smalley

- Scrum Master Checklist (James, Michael), Bas Vodde

- story splitting cheat sheet, Anu Smalley

- Three Amigos meetings, Keep Talking

- “Training from the Back of the Room” (Bowman), Evelien Acun-Roos

- openness, Len Lagestee, Bob Galen, Gunther Verheyen, Jorgen Hesselberg-Jorgen Hesselberg

- organization

- continuous improvement of, Kurt Bittner-Kurt Bittner

- culture of, Ron Eringa-Ron Eringa

- MetaScrum pattern aligning, Alan O’Callaghan-Alan O’Callaghan

- scaling Scrum for, Mik Kersten-Mik Kersten, James O. Coplien-James O. Coplien

- Scrum Masters influencing, Zuzi Šochová

- transitioning to Scrum, 4. Transforming to Scrum Means Transforming Your Organization, Fabio Panzavolta-Fabio Panzavolta

- organizational design

- hierarchical, Paul Oldfield, James O. Coplien

- network design, Paul Oldfield-Paul Oldfield

- scale-free networks, James O. Coplien

- orientation around vision, Orientation

- outcomes

- focusing on, instead of output, Ralph Jocham & Don McGreal, Focus on Outcome-Keep Effort and Outcome Visible

- Product Backlog based on, Gil Broza

- outside-in thinking, Ralph Jocham & Don McGreal, Ellen Gottesdiener

- Owner (see Product Owner)

P

- pair programming, Gunther Verheyen, Rich Hundhausen, Take It Slow, Bob Galen, Bas Vodde-Bas Vodde, Linda Rising, Eric Naiburg

- patterns

- Cross-Functional Team, James O. Coplien-James O. Coplien

- customer-vendor (anti-pattern), 2. User Stories Are Specifications, 3. The Product Owner Writes the User Stories

- experimentation not learned (anti-pattern), Ryan Ripley

- MetaScrum, Alan O’Callaghan-Alan O’Callaghan

- Product Owner refining Product Backlog alone (anti-pattern), Anu Smalley

- team co-ownership compromised (anti-pattern), Ryan Ripley

- team disengagement (anti-pattern), Ryan Ripley

- PBI (Product Backlog Item), James O. Coplien, James O. Coplien, James O. Coplien

- acceptance tests created from, Expressing the Sprint Plan Using Tests

- detailing, Markus Gaertner

- estimating (sizing), Anu Smalley

- forecast containing set of, for Sprint, Rich Hundhausen

- multiple, in releasable feature, Keep Effort and Outcome Visible

- resulting from Product Backlog refinement, Anu Smalley-Anu Smalley

- sizing (estimating) based on complexity, Len Lagestee-Len Lagestee

- tasks created from, Expressing the Sprint Plan Using Tasks

- user stories not required for, 1. User Stories Are Part of Scrum

- personalities

- of students, Willy Wijnands-Willy Wijnands

- of team members, Anything Causing Team Tension to Rise Beyond Constructive Conflict, Uwe Schirmer-Uwe Schirmer

- planning (see Sprint Planning)

- play, safe environment for, Jasper Lamers

- police work, using Scrum for, Sjoerd Kranendonk-Sjoerd Kranendonk

- The Practice of Management, Ralph Jocham & Don McGreal

- principles

- Agile (see Agile Manifesto)

- of eduScrum, Willy Wijnands

- Lean, Ken Schwaber, Mik Kersten, James O. Coplien, Self-Organization

- for product definition, Ellen Gottesdiener

- Scrum, Gil Broza, Ken Schwaber, Len Lagestee-Len Lagestee

- traditional (see traditional principles and practices)

- problem-solving techniques, Si Alhir-Si Alhir

- (see also complex problems)

- product, Scrum Glossary

- continuous improvement of, Kurt Bittner

- defining, Ralph Jocham & Don McGreal, Ellen Gottesdiener-Ellen Gottesdiener

- deploying for user feedback, Sanjay Saini-Sanjay Saini

- level of quality for, committing to, As a Team, Commit to Your Desired Level of Quality

- releasing, de-coupling from review, Dave West, Rafael Sabbagh

- success criteria for, Ralph Jocham & Don McGreal-Ralph Jocham & Don McGreal

- time to release, decreasing, 5. Scrum Is Not Faster

- vision for, Ralph Jocham & Don McGreal, Alan O’Callaghan, Ralph Jocham & Don McGreal, Orientation

- Product Backlog, Scrum Glossary

- bug fixes in, Rich Hundhausen

- Development Team's access to, Markus Gaertner

- integrating with Sprint Backlog, disadvantages of, Product and Sprint Backlog Integration

- length of, Willem Vermaak & Robbin Schuurman-Willem Vermaak & Robbin Schuurman, James O. Coplien

- multiple, overlapping, Ellen Gottesdiener

- organization of, James O. Coplien-James O. Coplien

- principles relevant to, Gil Broza

- prioritization of, Markus Gaertner

- purpose of, James O. Coplien-James O. Coplien

- radiating intention from, Len Lagestee

- refinement of, Anu Smalley-Anu Smalley, Scrum Glossary

- single, for multiple teams, Markus Gaertner

- specifications in, James O. Coplien

- Tao of Scrum regarding, Michael K. Spayd

- user stories not belonging in, James O. Coplien, James O. Coplien

- Product Backlog Item (see PBI)

- product delivery systems, David Starr-David Starr

- product development

- bugs as work not Done in, Rich Hundhausen

- distributed, Pete Deemer-Pete Deemer, Bas Vodde, Daniel James Gullo-Daniel James Gullo, Eric Naiburg-Eric Naiburg

- incremental development skills needed for, James W. Grenning-James W. Grenning

- market knowledge needed for, Chris Lukassen-Chris Lukassen

- Scrum approach to, Rafael Sabbagh-Rafael Sabbagh

- standards for, Gunther Verheyen, Scrum Glossary

- technical coaching for, Bas Vodde-Bas Vodde

- traditional approach to, Rafael Sabbagh

- Product Increments (see Increments)

- product management

- Development Team needing knowledge from, Chris Lukassen-Chris Lukassen

- Scrum Master and Product Owner collaboration for, Ralph Jocham & Don McGreal-Ralph Jocham & Don McGreal

- traditional managerial roles not needed for, What Else?

- Product Owner, Stacia Viscardi, Scrum Glossary

- accountability of, Ralph Jocham & Don McGreal, Ryan Ripley

- communication with stakeholders, Willem Vermaak & Robbin Schuurman-Willem Vermaak & Robbin Schuurman

- as leadership role, Andreas Schliep & Peter Beck, Marcus Raitner

- multiple, for “Multiple Scrum Teams”, Multiple Scrum Teams

- role in communication, Markus Gaertner-Markus Gaertner

- role in Daily Scrum, James O. Coplien

- role in defining product, Ellen Gottesdiener

- role in maximizing value, Alan O’Callaghan-Alan O’Callaghan

- role in Product Backlog prioritization, Markus Gaertner, James O. Coplien-James O. Coplien, Product and Sprint Backlog Integration

- role in Product Backlog refinement, Anu Smalley-Anu Smalley

- role in product management, Ralph Jocham & Don McGreal-Ralph Jocham & Don McGreal

- role in setting Sprint Goal, Mark Levison

- role in Sprint Planning, Luis Gonçalves

- simplicity managed by, Willem Vermaak & Robbin Schuurman

- single, for “Multi-Team Scrum”, Multi-Team Scrum

- specifications owned by, James O. Coplien

- Tao of Scrum regarding, Michael K. Spayd

- vision communicated by, Ralph Jocham & Don McGreal

- The Professional Product Owner, Ralph Jocham & Don McGreal

- project management layer, adding to Scrum, Mik Kersten

- project manager, transitioning to Scrum Master, Ryan Ripley

Q

- Quattro methodology, James O. Coplien, Bob Warfield-Bob Warfield

R

- respect, Bob Galen, Bob Galen-Bob Galen, Gunther Verheyen, Hiren Doshi, Paul Oldfield-Paul Oldfield

- retrospective (see Sprint Retrospective)

- review (see Sprint Review)

- rituals, Scrum events as, Jasper Lamers-Jasper Lamers

S

- safe environment for play, Jasper Lamers

- scale-free networks, James O. Coplien

- scaling Scrum, Mik Kersten-Mik Kersten, James O. Coplien-James O. Coplien

- scientific method, Scrum using, Si Alhir-Si Alhir

- Scrum, Scrum Glossary

- adapting prematurely, Steve Berczuk-Steve Berczuk

- adopting (see adoption of Scrum)

- artifacts (see artifacts)

- behavior as focus of, over process, Gunther Verheyen-Gunther Verheyen

- benefits of, 5. Scrum Is Not Faster, Rafael Sabbagh-Rafael Sabbagh, Kurt Bittner-Kurt Bittner

- in education, Arno Delhij-Arno Delhij, Willy Wijnands-Willy Wijnands

- empiricism as most important part of, Bob Hartman-Bob Hartman

- events (see events)

- origins of, Rafael Sabbagh-Rafael Sabbagh

- in police work, Sjoerd Kranendonk-Sjoerd Kranendonk

- principles of, Gil Broza, Ken Schwaber, Len Lagestee-Len Lagestee

- problem solving and scientific method in, Si Alhir-Si Alhir

- products, developing (see Development Team; product development)

- products, managing (see product management; Sprints)

- purpose of, Peter Goetz & Uwe Schirmer-Peter Goetz & Uwe Schirmer

- roles (see Development Team; Product Owner; Scrum Master; Scrum Team)

- scaling, Mik Kersten-Mik Kersten, James O. Coplien-James O. Coplien

- simplicity of, Ken Schwaber-Ken Schwaber

- Tao of, Michael K. Spayd

- team as essence of, Konstantin Razumovsky-Konstantin Razumovsky

- triangular leadership framework of, Andreas Schliep & Peter Beck-Andreas Schliep & Peter Beck, Marcus Raitner-What Else?

- unrealistic expectations of, 1. Scrum Will Not Solve Your Problems, 5. Scrum Is Not Faster, Ken Schwaber

- values of (see Agile Manifesto; Scrum Values)

- “The Scrum At Scale Guide”, James O. Coplien

- A Scrum Book: The Spirit of the Game, Alan O’Callaghan

- Scrum Guide, Ken Schwaber-Ken Schwaber, Peter Goetz & Uwe Schirmer, Steve Berczuk, Markus Gaertner, Jasper Lamers, Konstantin Razumovsky, 1. User Stories Are Part of Scrum, Anu Smalley, Ralph Jocham & Don McGreal, Luis Gonçalves, Bob Galen, Marcus Raitner, Derek Davidson, Len Lagestee, Uwe Schirmer, Michael K. Spayd, Jorgen Hesselberg, Sjoerd Kranendonk

- Scrum Master, Scrum Glossary

- accountability of, Ryan Ripley-Ryan Ripley, Marcus Raitner-Marcus Raitner, Len Lagestee-Anything Keeping a Team from Self-Healing

- actively doing nothing, Bas Vodde-Bas Vodde

- authority to remove Development Team members, Derek Davidson-Derek Davidson, Bob Galen-Bob Galen

- as change agent, Luis Gonçalves

- as coach, Geoff Watts-Geoff Watts

- first actions as, Luis Gonçalves

- as leadership role, Andreas Schliep & Peter Beck, Marcus Raitner

- levels of influence of, Zuzi Šochová-Zuzi Šochová

- as mirror for Scrum Team, Luis Gonçalves

- owning Sprint Backlog, disadvantages of, Bas Vodde

- principles relevant to, Gil Broza

- removing impediments, Marcus Raitner-Marcus Raitner, Len Lagestee-Anything Keeping a Team from Self-Healing

- responding to challenges, Bob Galen-Bob Galen

- responsibilities of, Bas Vodde

- role in Daily Scrum, James O. Coplien

- role in defining product, Ellen Gottesdiener

- role in product management, Ralph Jocham & Don McGreal-Ralph Jocham & Don McGreal

- role in Sprint Planning, Luis Gonçalves

- role of, Stacia Viscardi, Todd Miller-Todd Miller

- as servant-leader, Luis Gonçalves, Ryan Ripley-Ryan Ripley, Bob Galen, Geoff Watts

- serving themselves, importance of, Bob Galen-Bob Galen

- sublime aspects of, Hiren Doshi-Hiren Doshi

- Tao of Scrum regarding, Michael K. Spayd

- as technical coach, Bas Vodde-Bas Vodde

- transitioning from project manager, Ryan Ripley

- transparency provided by, Stephanie Ockerman-Stephanie Ockerman, Bob Galen

- Scrum of Scrums, Mik Kersten, James O. Coplien

- Scrum Team, Scrum Glossary

- accountability of, Gunther Verheyen

- aligning on PBI scope and complexity, Len Lagestee-Len Lagestee

- building, personality considerations for, Uwe Schirmer-Uwe Schirmer

- change, learning discipline for, 1. Individual Motivation-6. Systematic Ability

- co-ownership of, Ryan Ripley

- continuous improvement of, Kurt Bittner

- distributed (dispersed), Pete Deemer-Pete Deemer, Bas Vodde, Daniel James Gullo-Daniel James Gullo, Eric Naiburg-Eric Naiburg

- engagement level of, Ryan Ripley

- as essence of Scrum, Konstantin Razumovsky-Konstantin Razumovsky

- group development stages of, Daniel James Gullo

- insights by, environment for, Stijn Decneut-Stijn Decneut

- multiple teams, Markus Gaertner-Multi-Team Scrum, Jesse Houwing-Jesse Houwing

- play culture for, Jasper Lamers

- priorities of, Mitch Lacey

- radiating information, Len Lagestee-Len Lagestee

- roles in Sprint Planning, Luis Gonçalves-Luis Gonçalves

- self-organizing, Ralph Jocham & Don McGreal, Michael K. Spayd-Michael K. Spayd

- stable teams, Derek Davidson-Derek Davidson

- Tao of Scrum regarding, Michael K. Spayd

- testing as responsibility of, Lisa Crispin

- value as focus of, Alan O’Callaghan-Alan O’Callaghan

- values and commitment of, Jasper Lamers-Jasper Lamers

- Scrum Values, Peter Goetz & Uwe Schirmer, Jorgen Hesselberg-Jorgen Hesselberg, Scrum Glossary

- (see also specific values)

- humility as sixth value, Derek Davidson-Derek Davidson

- importance of, compared to process, Gunther Verheyen-Gunther Verheyen

- sublime aspects related to, Hiren Doshi-Hiren Doshi

- supporting play and experimentation, Jasper Lamers

- teams embodying, Jasper Lamers-Jasper Lamers

- Scrum@Scale framework, James O. Coplien-James O. Coplien

- security, abuser stories for, Judy Neher-Judy Neher

- self-organizing teams, Gil Broza, Ralph Jocham & Don McGreal, Michael K. Spayd-Michael K. Spayd

- leadership style supporting, Ron Eringa-Ron Eringa

- as networks, Paul Oldfield-Paul Oldfield

- personality considerations for, Uwe Schirmer-Uwe Schirmer

- successful leadership requiring, Self-Organization

- servant-leadership, Luis Gonçalves, Ryan Ripley-Ryan Ripley, Bob Galen, Geoff Watts, Marcus Raitner

- simplicity, Ken Schwaber-Ken Schwaber, Todd Miller-Todd Miller, Willem Vermaak & Robbin Schuurman

- sizing Product Backlog Items (PBIs), Len Lagestee-Len Lagestee

- specializing, Rich Hundhausen

- specifications, James O. Coplien, 2. User Stories Are Specifications

- Sprint, Peter Goetz & Uwe Schirmer, Gunther Verheyen, Rafael Sabbagh-Rafael Sabbagh, Scrum Glossary

- goal of (see Sprint Goal)

- measuring afterward, Jutta Eckstein

- organization improvement with, Kurt Bittner-Kurt Bittner

- overarching objectives for, Jutta Eckstein

- time-box (length) of, Scrum Glossary

- Sprint Backlog, James O. Coplien, Scrum Glossary

- bug fixes in, Rich Hundhausen

- created in Sprint Planning, Luis Gonçalves

- digital, disadvantages of, Bas Vodde-Bas Vodde, Mark Levison-Mark Levison

- incompleted work from, returned to Product Backlog, Mark Levison

- integrating with Product Backlog, disadvantages of, Product and Sprint Backlog Integration

- ownership of, Mark Levison-Mark Levison

- premature adaptations affecting, Steve Berczuk

- Scrum Master owning, disadvantages of, Bas Vodde

- Tao of Scrum regarding, Michael K. Spayd

- team as owners of, Bas Vodde

- type of information in, Mark Levison

- Sprint Goal, James O. Coplien, Scrum Glossary

- based on user story, James O. Coplien

- collaboration regarding, Mark Levison

- commitment to, Jasper Lamers

- created in Sprint Planning, Luis Gonçalves

- creating, Rich Hundhausen

- establishing, Mark Levison, Ralph Jocham & Don McGreal

- as focus of Increment, James O. Coplien

- purpose of, Mark Levison, Ralph Jocham & Don McGreal

- Tao of Scrum regarding, Michael K. Spayd

- vision necessary for, Ralph Jocham & Don McGreal

- Sprint Planning, Luis Gonçalves-Luis Gonçalves, James O. Coplien, Scrum Glossary

- acceptance tests created from, Expressing the Sprint Plan Using Tests

- diagram created from, Expressing the Sprint Plan Using a Diagram

- outcomes of, Luis Gonçalves

- planning, Jutta Eckstein

- premature adaptations affecting, Steve Berczuk

- reminder of goals discussed at, Alan O’Callaghan

- representations of, Rich Hundhausen-Not Expressing the Sprint Plan

- tasks created from, Expressing the Sprint Plan Using Tasks

- time-box for, Luis Gonçalves

- Sprint Retrospective, Steve Berczuk, Scrum Glossary

- after not meeting “Done”, Simon Reindl

- discussing non-agreed features in, Markus Gaertner

- effective, structure for, Steve Berczuk-Steve Berczuk

- environment for insights needed for, Stijn Decneut-Stijn Decneut

- items added to next Sprint Backlog from, Mark Levison

- as part of empirical process, Bob Hartman-Bob Hartman

- Sprint Review, Scrum Glossary

- discussions with stakeholders in, Willem Vermaak & Robbin Schuurman

- end users not represented at, Sanjay Saini-Sanjay Saini

- feedback from customers and stakeholders at, Dave West-Dave West, Rafael Sabbagh-Rafael Sabbagh

- not completing Increment for, Simon Reindl-Simon Reindl

- outcomes discussed in, Keep Effort and Outcome Visible

- as phase-gate, disadvantages of, Dave West

- stable teams, Derek Davidson-Derek Davidson

- Stahl, Leslie Hulet (author)

- Wicked Problems, Righteous Solutions, Rafael Sabbagh

- stakeholders, Scrum Glossary

- business value questions for, Alan O’Callaghan

- categories of, Willem Vermaak & Robbin Schuurman-Willem Vermaak & Robbin Schuurman

- communication with Development Team, Markus Gaertner-Markus Gaertner

- giving feedback at Sprint Review, Dave West-Dave West, Rafael Sabbagh-Rafael Sabbagh, Evelien Acun-Roos

- transparency with, Stephanie Ockerman

- standards, Gunther Verheyen, Scrum Glossary

- standing, benefits of, Linda Rising-Linda Rising

- success criteria, Ralph Jocham & Don McGreal-Ralph Jocham & Don McGreal

- Sutherland, Jeff (author)

- A Scrum Book: The Spirit of the Game, Alan O’Callaghan

- “The Scrum At Scale Guide”, James O. Coplien

- swarming, Rich Hundhausen

T

- Takeuchi, Hirotaka (author)

- “The New New Product Development Game”, Rafael Sabbagh

- Tao of Scrum, Michael K. Spayd

- task wall, Len Lagestee

- tasks, created from Sprint planning, Expressing the Sprint Plan Using Tasks

- team (see Development Team; Scrum Team)

- technical coaching, Markus Gaertner, Bas Vodde-Bas Vodde

- testing

- acceptance tests, from Sprint Planning, Expressing the Sprint Plan Using Tests

- level of quality for, As a Team, Commit to Your Desired Level of Quality

- strategies for, Design Small Experiments for Your Biggest Problems-Take It Slow

- team responsibility for, Lisa Crispin

- Three Amigos meetings, Keep Talking

- time to market

- as business decision, Rafael Sabbagh-Rafael Sabbagh

- decreasing, 5. Scrum Is Not Faster

- time-box, Scrum Glossary

- for Daily Scrum, James O. Coplien

- shorter, advantages of, Evelien Acun-Roos

- for Sprint, Scrum Glossary

- for Sprint Planning, Luis Gonçalves

- traditional principles and practices, Gil Broza

- affecting adoption of Scrum, Gil Broza, Steve Berczuk

- disadvantages of, Rafael Sabbagh

- hierarchical organizations, Paul Oldfield, James O. Coplien

- inside-out thinking, Ralph Jocham & Don McGreal

- for leadership, Ron Eringa

- product management vacuum filled by, Ralph Jocham & Don McGreal

- requirements as focus, not solutions, James O. Coplien

- transparency, Gil Broza, Jorgen Hesselberg

- benefits of, Len Lagestee-Len Lagestee

- as pillar of empiricism, Bob Hartman-Bob Hartman

- Scrum Master providing, Stephanie Ockerman-Stephanie Ockerman, Bob Galen

- triangular leadership framework, Andreas Schliep & Peter Beck-Andreas Schliep & Peter Beck, Marcus Raitner-What Else?

- trust, Jesse Houwing

U

- user stories, Marcus Raitner-3. The Product Owner Writes the User Stories

- abuser stories, Judy Neher-Judy Neher

- benefits of, Judy Neher

- format for, Judy Neher

- not being specifications, 2. User Stories Are Specifications

- not belonging in Product Backlog, James O. Coplien, James O. Coplien

- not part of Scrum, 1. User Stories Are Part of Scrum

- purpose of, James O. Coplien

- responsibility for writing, 3. The Product Owner Writes the User Stories

- splitting, Anu Smalley

- utilization, Daniel Heinen & Konstantin Ribel-Daniel Heinen & Konstantin Ribel

V

- validation, by marketplace, Ralph Jocham & Don McGreal

- value

- continuous improvement of, Kurt Bittner

- definition of “Done” based on, Gunther Verheyen-Gunther Verheyen

- as focus of Scrum Team, Alan O’Callaghan-Alan O’Callaghan

- focusing on, Focus on Outcome-Keep Effort and Outcome Visible, Mitch Lacey-Mitch Lacey

- marketplace determining, Ralph Jocham & Don McGreal

- relationship to vision, Alan O’Callaghan

- as success criteria, Ralph Jocham & Don McGreal-Ralph Jocham & Don McGreal

- values (see Agile Values; Scrum Values)

- velocity, Scrum Glossary

- vendor teams, Daniel Heinen & Konstantin Ribel-Daniel Heinen & Konstantin Ribel

- vision, Ralph Jocham & Don McGreal, Alan O’Callaghan, Ralph Jocham & Don McGreal, Orientation

W

- waterfall processes

- carrying over to Scrum, James O. Coplien

- long product timelines for, James O. Coplien

- project management layer as, Mik Kersten

- Scrum as alternative to, Ken Schwaber

- website resources (see online resources)

- Wicked Problems, Righteous Solutions, Rafael Sabbagh

X

- XP (Extreme Programming), James W. Grenning, 1. User Stories Are Part of Scrum, Judy Neher, Andreas Schliep & Peter Beck

About the Editor

Gunther Verheyen

Gunther Verheyen is a longtime Scrum practitioner (since 2003). After a longstanding career as a consultant, he partnered with Ken Schwaber, co-creator of Scrum, and Director of the Professional Scrum series at Scrum.org (2013–2016). Nowadays, Gunther engages with people and organizations as an independent Scrum Caretaker.

Gunther ventured into IT and software development after graduating with a degree in electronic engineering from the University of Antwerp in 1992. His Agile journey started with Extreme Programming and Scrum in 2003. Years of dedication followed, as did years of employing Scrum in diverse circumstances. In 2010, Gunther became the inspiring force behind some large-scale enterprise transformations. In 2011, he became a Professional Scrum Trainer.

Gunther left consulting in 2013 to found Ullizee-Inc and partner exclusively with Ken Schwaber. He represented Ken and his organization, Scrum.org, in Europe, shepherded the “Professional Scrum” series, and guided Scrum.org’s global network of Professional Scrum Trainers. Gunther is co-creator of Agility Path, EBM (Evidence-Based Management), and the Nexus framework for Scaled Professional Scrum.

Since 2016, Gunther has continued his journey to humanize the workplace as an independent Scrum Caretaker — a connector, writer, and speaker. His services build on more than 15 years’ worth of experience, ideas, beliefs, and observations of Scrum.

Gunther is the author of Scrum – A Pocket Guide (Van Haren Publishing, 2013, 2019). Ken Schwaber recommends Gunther’s pocket guide to Scrum as “...the best description of Scrum currently available” and “extraordinarily competent.” Several translations of Gunther’s work are available.

When not travelling for Scrum and humanizing the workplace, Gunther lives and works in Antwerp, Belgium.

1. Preface

1. How This Book Is Organized

2. Acknowledgments

3. O’Reilly Online Learning

4. How to Contact Us

2. I. Start, Adopt, Repeat

3. 1. Five Things Nobody Tells You About Scrum

1. Marc Loeffler

4. 2. Mindset Matters Much More Than Practices

1. Gil Broza

5. 3. Actually, It’s Not Really About Scrum

1. Stacia Viscardi

6. 4. Scrum Is Simple. Just Use It As Is.

1. Ken Schwaber

7. 5. Start with the Why of Your Scrum

1. Peter Goetz & Uwe Schirmer

8. 6. Adopt Before You Adapt

1. Steve Berczuk

9. 7. Regularly Revert to the Simplest Thing That Might Work

1. Todd Miller

10. 8. Will Scrum Work for Multi-Location Development?

1. Pete Deemer

11. 9. Know the Difference Between Multiple Scrum Teams and Multi-Team Scrum

1. Markus Gaertner

12. 10. What Will You Define as “Done”?

1. Gunther Verheyen

13. 11. How I Learned to Stop Worrying and Start Using Scrum

1. Simon Reindl

14. II. Products Deliver Value

15. 12. Successful Projects That...Fail

1. Ralph Jocham & Don McGreal

16. 13. Answer This Question: “What Is Your Product?”

1. Ellen Gottesdiener

17. 14. Scrum: Giving the Steering Wheel Back to Business

1. Rafael Sabbagh

18. 15. Beware the Product Management Vacuum

1. Ralph Jocham & Don McGreal

19. 16. Scaling Scrum to the Entire Organization with the Flow Framework

1. Mik Kersten

20. 17. Put Business Value Front and Center

1. Alan O’Callaghan

21. 18. Product Owner, Not an Information Barrier

1. Markus Gaertner

22. 19. Mastering the Art of “No” to Maximize Value

1. Willem Vermaak & Robbin Schuurman

23. 20. Communicating Prioritized Requirements Through the Product Backlog

1. James O. Coplien

24. 21. Why There Are No User Stories at the Top of Your Product Backlog

1. James O. Coplien

25. 22. Mind Your Outcomes. Pay Attention to Value.

1. Jeff Patton

26. III. Collaboration Is Key

27. 23. Is There Anything to Learn from Football Hooligans?

1. Jasper Lamers

28. 24. And Then a Miracle Occurs

1. Konstantin Razumovsky

29. 25. Put Customer Focus at the Top of Your Decision-Making Stack

1. Mitch Lacey

30. 26. Is Your Team Working as a Team?

1. Rich Hundhausen

31. 27. “That’s Not My Job!”

1. Markus Gaertner

32. 28. Specialization Is for Insects

1. James O. Coplien

33. 29. Digital Tools Considered Harmful: Sprint Backlog

1. Bas Vodde

34. 30. Digital Tools Considered Harmful: Jira

1. Bas Vodde

35. 31. The Vicious Effects of Managing for Utilization

1. Daniel Heinen & Konstantin Ribel

36. 32. Becoming a Radiating Team

1. Len Lagestee

37. IV. Development Is Multifaceted Work

38. 33. Agile Is More Than Sprinting

1. James W. Grenning

39. 34. Patricia’s Product Management Predicament

1. Chris Lukassen

40. 35. The Five Stages of Product Backlog Item Sizing

1. Len Lagestee

41. 36. Three Common Misconceptions About User Stories

1. Marcus Raitner

42. 37. Introducing Abuser Stories

1. Judy Neher

43. 38. What’s in Your Sprint Plan?

1. Rich Hundhausen

44. 39. Sprint Backlogs Deserve a Life Beyond Your Electronic Tool

1. Mark Levison

45. 40. Testing Is a Team Sport

1. Lisa Crispin

46. 41. Rethinking Bugs

1. Rich Hundhausen

47. 42. Product Backlog Refinement Is an Important Team Activity

1. Anu Smalley

48. 43. Automating Agility

1. David Starr

49. 44. The Evergreen Tree

1. Jesse Houwing

50. V. Events, Not Meetings

51. 45. Sprints Are for Progress, Not to Become the New Treadmill

1. Jutta Eckstein

52. 46. How to Have an Effective Sprint Planning

1. Luis Gonçalves

53. 47. Sprint Goals Provide Purpose (Beyond Merely Completing Work Lists)

1. Mark Levison

54. 48. Sprint Goals: The Forgotten Keys of Scrum

1. Ralph Jocham & Don McGreal

55. 49. The Daily Scrum Is the Developers’ Agile Heartbeat

1. James O. Coplien

56. 50. The Sprint Review Is Not a Phase-Gate

1. Dave West

57. 51. The Purpose of Sprint Review Is to Gather Feedback — Period

1. Rafael Sabbagh

58. 52. A Demo Is Not Enough — Go and Deploy for Better Feedback

1. Sanjay Saini

59. 53. Have Sprint Retrospectives and Structure Them

1. Steve Berczuk

60. 54. The Most Important Thing Isn’t What You Think It Is

1. Bob Hartman

61. VI. Mastery Does Matter

62. 55. Understanding the Scrum Master Role

1. Luis Gonçalves

63. 56. How I Learned That It’s Not About Me, the Scrum Master

1. Ryan Ripley

64. 57. Servant-Leadership Starts from Within

1. Bob Galen

65. 58. The Court Jester at the Touchline

1. Marcus Raitner

66. 59. The Scrum Master as Coach

1. Geoff Watts

67. 60. The Scrum Master as a Technical Coach

1. Bas Vodde

68. 61. Scrum Master, Not Impediment Hunter

1. Derek Davidson

69. 62. Anatomy of an Impediment

1. Len Lagestee

70. 63. The Scrum Master’s Most Important Tool

1. Stephanie Ockerman

71. 64. When in Trouble...Break Glass!

1. Bob Galen

72. 65. Actively Doing Nothing (Is Actually Hard Work)

1. Bas Vodde

73. 66. Guiding Scrum Masters on Their Never-Ending Journey with the #ScrumMasterWay Concept

1. Zuzi Šochová

74. VII. People, All Too Human

75. 67. Teams Are More Than Collections of Technical Skills

1. Uwe Schirmer

76. 68. Are People Impediments?

1. Bob Galen

77. 69. How Human Nature Overcomplicates What Is Already Complex

1. Stijn Decneut

78. 70. How to Design Your Scrum for A-ha! Moments

1. Stijn Decneut

79. 71. Use Brain Science to Make Your Scrum Events Stick

1. Evelien Acun-Roos

80. 72. The Power of Standing Up

1. Linda Rising

81. 73. The Effects of Working from Home

1. Daniel James Gullo

82. 74. The Gentle Way of Change

1. Chris Lukassen

83. VIII. Values Drive Behavior

84. 75. Scrum Is More About Behavior Than It Is About Process

1. Gunther Verheyen

85. 76. What It Means to Self-Organize

1. Michael K. Spayd

86. 77. Treating Defects as Treasures (the Value of Openness)

1. Jorgen Hesselberg

87. 78. “That Won’t Work Here!”

1. Derek Davidson

88. 79. Five Sublime Aspects for Being a More Humane Scrum Master

1. Hiren Doshi

89. 80. The Sixth Scrum Value

1. Derek Davidson

90. IX. Organizational Design

91. 81. Agile Leadership and Culture Design

1. Ron Eringa

92. 82. Scrum Is “Agile Leadership”

1. Andreas Schliep & Peter Beck

93. 83. Scrum Is Also About Improving the Organization

1. Kurt Bittner

94. 84. Networks and Respect

1. Paul Oldfield

95. 85. The Power of Play in a Safe (but Not Too Safe) Environment

1. Jasper Lamers

96. 86. The Trinity of Agile Leadership

1. Marcus Raitner

97. 87. The “MetaScrum” Pattern to Drive Agile Transformation

1. Alan O’Callaghan

98. 88. Scrum and Organizational Design in Practice

1. Fabio Panzavolta

99. 89. Thinking Big

1. James O. Coplien

100. X. Scrum Off Script

101. 90. The Origins of Scrum Might Not Be What You Think They Are

1. Rafael Sabbagh

102. 91. The “Standing Meeting”

1. Bob Warfield

103. 92. Scrum: Problem-Solving and the Scientific Method in Practice

1. Si Alhir

104. 93. Scrum Events Are Rituals to Ensure Good Harvest

1. Jasper Lamers

105. 94. How We Used Scrum to Work with an External Agency

1. Eric Naiburg

106. 95. Scrum Applied in Police Work

1. Sjoerd Kranendonk

107. 96. Born to Be Agile: A Case for Scrum in the Classroom

1. Arno Delhij

108. 97. Agile in Education with eduScrum

1. Willy Wijnands

109. Contributors

110. Scrum Glossary

111. Index