What’s in this Book
In each chapter (starting with Chapter 3), we run through several common anti-patterns related to the topic of that chapter, and suggest ways to prevent or fix that anti-pattern on your team. At the end of each chapter is a section titled “Coach’s Corner,” where we provide an exercise you can try with your team that applies to all the anti-patterns in that chapter, and which can help you narrow down the issues you’re dealing with.
In Chapter 1, A Brief Introduction to Scrum, we provide some sage advice on how to learn and explore the Scrum framework. This will give you a great refresher on Scrum and will prepare you for the upcoming chapters.
When Scrum goes bad, it isn’t just the product that suffers. In Chapter 2, Why Scrum Goes Bad, you’ll see what happens when trust is lacking in an organization and empiricism isn’t safe. Spoiler: Scrum doesn’t thrive in this kind of environment.
But take heart! In Chapter 3, Breaking Bad Scrum with a Value-Driven Approach we’ll explore the Scrum values. These values can promote the characteristics and behaviors that a Scrum team needs to overcome organizational dysfunction and achieve high performance. These values are really, really important. You may want to read this chapter twice.
As the “mini-CEO” of the product, the product owner plays a fundamental role in defining the vision, assessing the value, and validating the success (or failure) of the product in the marketplace. In Chapter 4, The Product Owner, we’ll look at what happens when the product owner role is misinterpreted and/or poorly performed.
Do you have a future vision of your product? If not, we’ll show you how to build one in Chapter 5, The Product Backlog. The product backlog is where Scrum teams store anything and everything that they may need for their products in the future. It’s the single source of truth for the Scrum team, who uses it to plan, forecast, roadmap, and guide the direction of the product.
Chapter 6, The Development Team is dedicated to the folks who develop the product. The development team is a cross-functional, self-organizing team of people who can turn product backlog items into working software. Closely examine the anti-patterns we discuss in this chapter. A dysfunctional development team doesn’t often deliver product.
A Scrum master must ensure that Scrum is well-understood and enacted by the Scrum team. Chapter 7, Embracing the Scrum Master Role explores what happens when the Scrum master doesn’t act as a servant leader. Honestly, many of the anti-patterns in this book can be tied directly to a weak Scrum master. Solve these anti-patterns quickly.
Management is not the enemy. In Chapter 8, Management, we discuss how important it is for a Scrum master to have empathy for leadership and suggest meaningful and effective ways to work with middle managers. Get this right and many of your organizational impediments can be resolved much faster than previously possible.
The sprint is often the overlooked and underappreciated Scrum event. By the end of Chapter 9, Thinking in Sprints you’ll have a deeper understanding of the rules of the sprint and what can happen when Scrum teams violate these rules.
Sprint Planning is a complex event that can go wrong in many different ways. Chapter 10, Sprint Planning examines common missteps during sprint planning, including skipping product backlog refinement during the sprint. This chapter could save you hours of wasted time if you’re able to adapt the way you approach this important planning event.
The development team owns the sprint backlog. If that doesn’t ring true with you, Chapter 11, The Sprint Backlog will help change your mind. Commitment is also a big topic we’ll discuss as we explore scope issues, progress, and being transparent about work during a sprint.
Did you know that you don’t have to stand up during the daily scrum? This and many more earth-shattering revelations come to light in Chapter 12, Reclaiming the Daily Scrum.
Chapter 13, Deconstructing the Done Product Increment covers a lot of ground. We examine the pitfalls of not having a definition of “done,” why “visible” doesn’t mean “transparent,” and what to do when Scrum teams and the organization don’t adopt the concept of done.
Did you know that the sprint review isn’t a demo? Chapter 14, The Sprint Review covers the anti-patterns that come out when the sprint review isn’t properly implemented or is facilitated poorly. Learn how to engage your stakeholders, collaborate with your customers, and get the info you need to update your product backlog and start the next sprint with the best information possible.
If you’re using the “What Went Well,” “What Didn’t Go Well,” and “What Do We Need to Change” format—STOP. Read Chapter 15, The Sprint Retrospective and update your retrospective practices. Continuous improvement is essential to good Scrum. A well-executed sprint retrospective generates the insights a Scrum team needs to continuously improve their process, practices, and interactions.