Book Notes #37: The Enterprise and Scrum by Ken Schwaber

Title: The Enterprise and Scrum
Author: Ken Schwaber
Year: 2007
Pages: 152

If you think Scrum is just a tool for developers to build better products, this book will surprise you. The Enterprise and Scrum isn’t about daily standups or sticky notes on a board—it’s about what happens when a whole organization stops pretending everything is fine and decides to face its problems head-on.

Ken Schwaber doesn’t sugarcoat the truth.

He shows, with clarity and real-life stories, what it really takes to bring agility to an enterprise. It’s uncomfortable, sometimes painful, but incredibly honest—and that’s what makes it powerful.

As a result, I gave this book a rating of 7.5/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read The Enterprise and Scrum

Book Overview

There’s something brutally honest about the way Ken Schwaber approaches Scrum. He doesn’t try to sell it as a magic formula or a feel-good framework that’ll instantly fix your organization. Quite the opposite. He starts with a warning: Scrum won’t solve your problems. It will expose them—and that’s the point.

Reading The Enterprise and Scrum feels less like diving into a technical manual and more like sitting down with a seasoned guide who’s seen the inner workings of dozens of companies and is ready to tell you the truth most consultants won’t. If you’ve ever worked in a place that relied on overly detailed Gantt charts or endless layers of approvals, you’ll quickly understand why Schwaber insists that those structures don’t hold up in a world defined by complexity.

At the heart of the book is a simple, powerful idea: in complex environments—like software development or large-scale product innovation—you can’t plan everything in advance. Things change too fast.

The market shifts. Requirements evolve. Teams learn. And when you try to force predictability into that chaos, you end up pretending. You build false certainty. You miss what really needs your attention.

Scrum, Schwaber argues, is built on a different kind of logic. Instead of pretending we know everything, we start from the assumption that we don’t.

That’s why the framework is centered around three core ideas: transparency, inspection, and adaptation. In practice, this means working in short cycles (Sprints), constantly reviewing progress, and adjusting course based on what we learn. It’s not flashy, but it’s real.

One of the most striking things in the book is how Schwaber treats enterprise transformation. He doesn’t romanticize it. He says plainly: it’s going to be painful. You’re going to lose people—about 20%, if history is any guide.

Teams will push back. Managers will feel threatened. Old habits will rear their heads like muscle memory. But if you stick with it, if you respect the process and resist the urge to water it down, change will come. Not overnight, but through thousands of small, deliberate steps.

He shares stories of companies that tried to “do Scrum” without changing their mindset—and failed. One story that stands out is about a team in a gaming company that, after adopting Scrum, started delivering high-quality work during regular 8-hour days. But their parent company in Japan couldn’t make peace with the idea that work wasn’t painful enough.

So, they shut it down—just before that very product became a huge success. That story lingers. It’s a reminder that even when results improve, culture can be a powerful force of resistance.

What makes the book practical is how Schwaber breaks down what needs to happen in the first year. He maps out what to expect—chaos in the first month, breakthroughs and frustrations in the second, and a long, gritty path ahead.

He talks about how roles need to shift, especially for managers who must move from controlling to coaching. He explains the importance of real cross-functional teams and why trust and openness are non-negotiable.

The book also dives into the structure of Scrum itself—not in a mechanical way, but as a reflection of the environment it’s meant to thrive in. The roles, events, and artifacts aren’t just checklists.

They’re designed to create clarity and rhythm in the middle of complexity. And once you understand that, you see why skipping parts of the process or reshaping them to avoid discomfort usually leads right back to the dysfunctions Scrum is meant to surface.

What makes The Enterprise and Scrum different from other Agile books is its unflinching honesty. It doesn’t promise shortcuts or happy endings. But it does offer a real path forward. One that’s grounded in humility, transparency, and continuous learning.

And maybe that’s the real message here: if your organization is struggling, don’t cover it up with more processes or tighter controls. Shine a light on it. Let the problems surface. Then face them, together, one Sprint at a time. Scrum isn’t easy. But it might be the most honest way to build something that actually works.

Ken Schwaber and Jeff Sutherland

Ken Schwaber sees Scrum not as a solution, but as a mirror. In his view, Scrum exists to expose the dysfunctions that organizations would rather not face—unclear priorities, siloed teams, command-and-control leadership, and the illusion of predictability in complex work.

In The Enterprise and Scrum, Schwaber is clear: Scrum is intentionally disruptive. It’s designed to force uncomfortable conversations and shine a spotlight on what’s broken.

For him, the value of Scrum lies in its ability to create transparency, encourage inspection, and drive real, often painful, change—not in wrapping organizations in agile labels or surface-level rituals.

Jeff Sutherland, on the other hand, tends to present Scrum with more emphasis on speed, performance, and success.

In his book Scrum: The Art of Doing Twice the Work in Half the Time, the tone is more upbeat and results-focused. Sutherland highlights how Scrum can lead to high-velocity teams, fast learning cycles, and breakthrough outcomes.

While he also acknowledges the need for discipline and accountability, his approach leans more on the benefits of Scrum when it’s working well, rather than the turmoil of getting there. It’s a more optimistic take, often aimed at energizing teams and executives to adopt Scrum for competitive advantage.

The core difference lies in tone and focus. Schwaber is the realist—he sees Scrum as a mechanism to challenge an organization to grow up. Sutherland is the idealist—he shows what’s possible when Scrum is embraced deeply and used to unlock a team’s full potential. Both perspectives are true, and both are valuable.

But if you’re looking for a tough love, no-nonsense guide that holds up a mirror to your company’s behavior, Schwaber’s lens offers a raw, unfiltered look at what Scrum really demands.

Chapter by Chapter

Scrum: Artifacts

Understanding Scrum Artifacts

In this final appendix, Schwaber explores the artifacts that are key to Scrum’s success. Artifacts in Scrum are tools that provide transparency and serve as the primary means of managing work and progress. These artifacts are central to Scrum’s ability to manage complexity, and they allow teams to keep track of work, prioritize tasks, and monitor progress. The main Scrum artifacts are the Product Backlog, the Sprint Backlog, and the Increment.

The Product Backlog

The Product Backlog is a dynamic list of everything that could be needed for the product. It is continuously refined and prioritized by the Product Owner to ensure that the team is always working on the most valuable tasks.

Key characteristics of the Product Backlog include:

• Prioritized Work: The Product Backlog items (PBIs) are prioritized by the Product Owner based on their business value, customer impact, and urgency.
• Emergent and Evolving: The Product Backlog is not static; it evolves as more is learned about the product and customer needs. New items can be added, and existing items can be re-prioritized as necessary.
• Detailed Appropriately: Backlog items should be detailed enough to allow the team to understand what needs to be done, but not so detailed that the entire project is mapped out in advance. The level of detail increases as work approaches a particular Sprint.

The Product Backlog serves as the single source of truth for the product, guiding the team’s work. The Product Owner is responsible for managing the backlog, ensuring it reflects the product’s needs and goals.

The Sprint Backlog

The Sprint Backlog is the set of Product Backlog items that the team has committed to completing in the upcoming Sprint. The Sprint Backlog is owned by the Development Team, and it serves as their plan for achieving the Sprint Goal.

Key characteristics of the Sprint Backlog include:

• Sprint Goal: The Sprint Backlog is aligned with a specific Sprint Goal, which gives the team a clear focus for the Sprint. The goal ensures that the team remains aligned with the overall product vision while making steady progress toward completing the product increment.
• Live Document: The Sprint Backlog is a live document, meaning that it evolves throughout the Sprint. As the team gains more insight into the work required to complete the tasks, they can refine their understanding of how to accomplish the goal. New tasks can be added, and existing tasks can be adjusted.
• Task Breakdown: The team breaks down the selected Product Backlog items into smaller, more manageable tasks. These tasks are tracked by the team to ensure steady progress throughout the Sprint.

The Sprint Backlog is owned and managed by the team, giving them the autonomy to determine how to accomplish the work. The ScrumMaster helps to remove obstacles that might impede progress, but the team is responsible for executing the work.

The Increment

The Increment is the result of the work completed during the Sprint. At the end of each Sprint, the team delivers a potentially shippable product increment, meaning that the work is in a state where it could be released to customers (if desired).

Key characteristics of the Increment include:

• Working Software: The Increment must be in a working state, meaning that it is complete, tested, and meets the required quality standards. It must be potentially shippable, meaning that it could be released to customers or stakeholders without additional work.
• Cumulative: The Increment is cumulative; each Sprint adds new functionality to the product, building on previous increments. Over time, the product evolves, with each increment adding more value to the customer.
• Transparency: The Increment is visible to all stakeholders. This transparency ensures that the team’s progress is clear, and it helps to build trust with customers and other stakeholders.

The Importance of Artifacts in Scrum

Schwaber emphasizes that Scrum artifacts provide transparency and clarity. They make the work visible, enabling the team and stakeholders to track progress, make informed decisions, and adjust as necessary. The Product Backlog, Sprint Backlog, and Increment provide a structure for managing complex work, and they help ensure that the team is focused on delivering valuable outcomes.

Scrum artifacts are crucial for Scrum’s empirical process control. They allow teams to inspect progress regularly and adapt their work based on new information. The transparency of these artifacts helps teams and stakeholders understand the current state of the product, making it easier to make decisions and adjust priorities.

Appendix E explains the artifacts in Scrum—Product Backlog, Sprint Backlog, and Increment—and how they provide the transparency and structure needed for Scrum to succeed. Each artifact serves a specific purpose: the Product Backlog outlines what needs to be done, the Sprint Backlog details how the team will accomplish the work, and the Increment represents the completed work at the end of each Sprint. These artifacts help manage complexity, ensure alignment, and enable continuous improvement.

Scrum: Flow

The Flow of Work in Scrum

In this appendix, Schwaber discusses the concept of flow in Scrum and how it relates to the overall efficiency of the team. Scrum is designed to optimize the flow of work, allowing teams to deliver valuable increments in a predictable and sustainable way. Schwaber highlights how Scrum’s structure and events create an environment where work flows smoothly and obstacles can be identified and addressed early.

The Importance of Flow

In a traditional waterfall model, work is often blocked at various stages of the process, and teams wait for approvals, testing, or other departments to finish their work before they can move forward. This can lead to bottlenecks, delays, and inefficiencies. Scrum, on the other hand, is designed to minimize these delays by making work visible and ensuring that teams focus on delivering value continuously.

Schwaber explains that flow is about continuous delivery—ensuring that the team is consistently delivering valuable product increments at the end of each Sprint. The goal is to create an environment where work moves efficiently through the system without unnecessary delays or interruptions.

Flow in Scrum Events

The Scrum events are designed to support the flow of work. Each event serves a specific purpose that contributes to ensuring the team stays on track:

• Sprint Planning: This is where the team defines the work for the upcoming Sprint. The goal is to establish a clear, actionable plan that ensures the team’s work flows smoothly throughout the Sprint.
• Daily Scrum: The Daily Scrum is an opportunity for the team to check in and make sure that work is progressing smoothly. Team members discuss any blockers or obstacles and quickly identify solutions, ensuring that the flow of work continues.
• Sprint Review: At the end of each Sprint, the team demonstrates the product increment to stakeholders, ensuring that the product is on track and that feedback is incorporated into future work.
• Sprint Retrospective: After each Sprint, the team reflects on their performance and identifies areas for improvement. This helps to continuously optimize the flow of work and the processes involved.

Minimizing Waste

A key principle of Scrum is minimizing waste. Waste can come in many forms, such as unnecessary meetings, delays in approvals, or work that doesn’t add value to the customer. Schwaber stresses that Scrum teams need to identify and eliminate waste wherever possible. This is where continuous improvement comes into play—teams should constantly be looking for ways to improve their flow and reduce inefficiencies.

By focusing on eliminating waste, Scrum enables teams to work more effectively and deliver more value with fewer resources. Schwaber mentions that teams can achieve this by reducing cycle times (the time it takes to complete a task), improving quality, and optimizing processes.

The Role of the ScrumMaster in Maintaining Flow

The ScrumMaster plays a key role in ensuring that the flow of work is maintained. They help the team identify and remove any impediments that may be blocking progress. This could include technical issues, organizational barriers, or even interpersonal conflicts within the team. The ScrumMaster’s job is to remove these obstacles quickly so that the team can stay focused on delivering value.

The ScrumMaster also helps the team maintain the right balance between speed and quality. It’s important that the team doesn’t rush through work just to get it done. Instead, they should aim for steady progress, with each increment meeting the required quality standards.

Flow and Cross-Functionality

Another important aspect of flow in Scrum is the concept of cross-functional teams. Scrum teams are composed of individuals with diverse skills who collaborate to deliver a complete product increment. This cross-functional nature of the team ensures that work flows smoothly because team members don’t need to wait for other departments or specialists to complete their tasks. Everyone has the skills to contribute to every part of the product, which minimizes delays and enhances collaboration.

Appendix D discusses the importance of flow in Scrum and how the framework is designed to ensure that work moves efficiently through the system. By focusing on continuous delivery, minimizing waste, and optimizing processes, Scrum teams can deliver valuable product increments consistently. The Scrum events are structured to maintain this flow, and the ScrumMaster plays a critical role in removing impediments and supporting the team’s work. With a focus on flow, Scrum helps teams stay focused, agile, and efficient.

Scrum: Roles

The Three Key Roles in Scrum

In Chapter C, Schwaber delves deeper into the three essential roles within Scrum: Product Owner, ScrumMaster, and Development Team. Each of these roles is critical to the success of the Scrum framework, and their responsibilities are distinct but interdependent. Schwaber stresses that clarity and understanding of these roles are necessary for Scrum to function effectively.

The Product Owner

The Product Owner is responsible for ensuring that the Scrum team delivers the highest possible value to the business and customers. This person must have a deep understanding of customer needs and business objectives and use this knowledge to guide the team’s work.

The Product Owner’s main responsibilities include:

• Managing the Product Backlog: The Product Owner is responsible for creating and maintaining the Product Backlog, which contains all the work items for the product. They must prioritize these items based on customer needs and business goals.
• Defining the Product Vision: The Product Owner must create and communicate a clear product vision that aligns with the company’s strategy. This vision provides direction for the team and keeps everyone focused on the overall goal.
• Stakeholder Management: The Product Owner serves as the main point of contact for stakeholders and customers, ensuring their needs are accurately represented in the backlog.

The ScrumMaster

The ScrumMaster plays the role of a facilitator and coach, ensuring that the Scrum process is understood and followed by the team. Unlike a traditional manager, the ScrumMaster doesn’t give direct orders. Instead, they help the team remove obstacles, improve their processes, and work more effectively.

The ScrumMaster’s main responsibilities include:

• Facilitating Scrum Events: The ScrumMaster ensures that Scrum ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) take place and are effective. They help keep these meetings focused and productive.
• Coaching the Team: The ScrumMaster helps team members understand and adopt Scrum practices. They coach the team to become self-managing and continuously improve.
• Removing Impediments: The ScrumMaster helps identify and remove obstacles that may be hindering the team’s progress. This could be anything from a technical issue to a broader organizational barrier.
• Shielding the Team: The ScrumMaster protects the team from outside interference, ensuring that they can focus on the work in the Sprint.

The Development Team

The Development Team is made up of professionals who do the actual work of delivering the product increment. In Scrum, the development team is self-organizing, meaning that they are responsible for organizing their work, deciding how to approach tasks, and how to achieve the Sprint goals.

The Development Team’s main responsibilities include:

• Delivering the Increment: The Development Team works to deliver a potentially shippable product increment at the end of each Sprint. They are responsible for the quality and completeness of the work.
• Collaboration and Cross-Functionality: The team is expected to collaborate and draw from a wide range of skills to ensure they can tackle all aspects of the product, from coding to testing to design.
• Continuous Improvement: The Development Team continuously looks for ways to improve their processes and work more effectively. This is reflected in their Retrospectives and their commitment to Scrum values.

Role Interdependence

Schwaber emphasizes that these three roles must work closely together for Scrum to be successful. While each role has distinct responsibilities, the Product Owner, ScrumMaster, and Development Team must collaborate and communicate effectively. The Product Owner provides the direction, the ScrumMaster ensures the team follows the process, and the Development Team delivers the work.

Appendix C breaks down the essential roles within Scrum and explains how each one contributes to the success of the framework. The Product Owner drives the product vision and ensures the team is building the right thing. The ScrumMaster helps the team follow Scrum practices and removes obstacles. The Development Team is responsible for delivering the product increment and continuously improving. When these roles work in harmony, Scrum can deliver value to customers quickly and efficiently.

The Science

Why Software Development Is Complex

Ken Schwaber opens this section by reminding us that software development is inherently complex. Unlike building physical objects, software deals with ephemeral results, unpredictable user needs, and constantly evolving technologies. Everything is intellectual, based on thoughts translated into code, and often created by teams of individuals with different skills, moods, and perspectives. All this makes software development unpredictable, volatile, and full of uncertainty.

Defined vs. Empirical Process Control

To manage this level of uncertainty, Schwaber explains the difference between two types of process control: defined and empirical. Defined processes work well when everything is known upfront—like building cabinets, where measurements and procedures are predictable. But when things are messy and complex, defined processes fall apart. That’s where empirical process control comes in.

Empirical control works by constantly inspecting, adapting, and making everything transparent. You don’t pretend to know all the answers in advance. Instead, you watch how things go, make frequent adjustments, and share what’s happening so the whole team can stay on track.

Three Pillars of Empirical Control

1. Transparency – Everyone must understand what’s going on. For example, if someone says a task is “done,” it has to mean the same thing to everyone—unit tested, reviewed, working, documented.
2. Inspection – You must inspect progress regularly to catch issues early. In software, this could be code reviews or sprint reviews.
3. Adaptation – If something’s off, you change the process or the product quickly to stay aligned with the goal. This agility is what makes Scrum effective in complex environments.

Scrum as a Response to Complexity

Schwaber stresses that Scrum was created to deal with this kind of complexity. It doesn’t offer simple answers but provides a framework for making the best decisions as you go. The goal isn’t to create perfect predictions but to guide the work toward the most valuable outcomes, sprint by sprint.

This mindset is a big shift for organizations used to heavy planning and upfront certainty. But for modern software development, it’s necessary. Scrum doesn’t eliminate the chaos—it helps us manage it.

Scrum: Skeleton and Heart

The Core Structure of Scrum

In this appendix, Schwaber explains that Scrum’s simplicity is its strength. It’s often described as having two key parts: the skeleton and the heart. The skeleton is the formal structure of Scrum—the roles, events, and artifacts. It provides the framework within which Scrum teams operate. The heart represents the values and principles that give Scrum its life and purpose. Without the heart, the skeleton would be hollow, just a set of processes to follow.

The Skeleton

The skeleton of Scrum includes the following core elements:

• Roles: Scrum defines three roles—Product Owner, ScrumMaster, and Development Team—each with specific responsibilities.
• Events: These are the time-boxed activities in Scrum, such as the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
• Artifacts: These are the key items Scrum teams work with: the Product Backlog, the Sprint Backlog, and the Increment. These artifacts help guide the team in delivering value.

The Heart

While the skeleton provides structure, the heart of Scrum lies in the values and principles that guide the team’s behavior. These values are:

1. Commitment: Each team member commits to achieving the goals of the team.
2. Courage: Team members need the courage to do the right thing, even when it’s difficult.
3. Focus: The team focuses on the work of the Sprint and the goals of the Product Owner.
4. Openness: The team and stakeholders need to be open about progress, challenges, and issues.
5. Respect: Team members respect each other’s abilities, ideas, and contributions.

Why Both Matter

Schwaber highlights that Scrum’s true effectiveness comes from balancing both the skeleton and the heart. The skeleton provides a disciplined approach, and the heart ensures that teams are motivated to deliver high-value products in a collaborative and transparent manner. When teams focus only on the skeleton (following the process) without the heart (embracing the values), Scrum can become a mechanical process that doesn’t deliver real results.

Chapter 1 – What Do We Have to Do to Adopt Scrum?

Scrum doesn’t fix problems—it exposes them. That’s the bold message Ken Schwaber starts with. If your organization struggles with product development, Scrum won’t sweep in as a hero with ready-made solutions. Instead, it’s more like a brutal mirror. You’ll see every weakness, every inefficiency, and every cultural dysfunction—clearly and unavoidably. And that’s exactly why it works.

The Game Metaphor

Schwaber invites us to see Scrum as a game with rules and a field to play on. The enterprise provides the players. If they work well together, it shows. If not, the gaps are immediately obvious. When Scrum is adopted across the enterprise, this transparency scales up. The larger the game, the more critical the coordination becomes—and the more dysfunctions are revealed.

Two Sides of Adoption

There are two phases: first, rolling out Scrum by teaching everyone how to play. This takes 6 to 12 months. Second, improving the game—honing skills, collaboration, and excellence—which takes 3 to 5 years. This second phase never really ends. Every Sprint is an opportunity to improve, and each one puts the organization under a microscope.

The Need for Cultural Change

Scrum only thrives in a culture that accepts change, embraces complexity, and values inspection and adaptation over prediction. Schwaber shares the story of Adventure Works, a game company that implemented Scrum successfully, delivering high-quality increments at a sustainable pace. But when their Japanese parent company couldn’t accept the new work culture (specifically, 8-hour workdays), they sold the company—ironically just before its product sold for double the acquisition price. It’s a striking example of how culture can resist—even destroy—progress.

Prove It to Yourself First

Schwaber advises not to commit to enterprise-wide Scrum just because it sounds good. First, try it. Run a few projects. See if it works for your toughest problems. Only after seeing real improvement—faster delivery, better quality, more transparency—should you consider scaling it. Scrum is simple to learn, but its power only becomes obvious when used under pressure, not just in theory.

Understanding the Change Ahead

If you do move forward, be ready. The changes will go far beyond process. Job roles shift. Managers become coaches. Product managers become Product Owners—fully accountable for delivery and value. Teams must become self-managing. Compensation systems should reward team performance, not individual heroics. Around 20% turnover is normal, both among staff and managers. Not everyone wants to work in a transparent, high-accountability environment.

Don’t Try to Modify Scrum

A key warning: don’t change Scrum to avoid pain. The temptation is strong. When the process reveals a problem, some teams tweak Scrum to avoid the discomfort. But in doing so, they lose what makes it powerful. It’s like ignoring a fire alarm because you don’t like the noise. Schwaber is blunt here—Scrum is your canary in the coal mine. When it hurts, it’s working.

Don’t Wait—Start Now

Another warning: don’t delay. Many organizations try to “get ready” before starting. Scrum turns that idea upside down. Start now. The first steps will reveal what’s really holding you back. Those insights are far more valuable than any amount of upfront planning.

This chapter lays the emotional and strategic groundwork for Scrum at scale. It’s not a gentle entry. Schwaber is clear that adopting Scrum across an enterprise is hard, disruptive, and deeply cultural. But if you’re ready to look in the mirror and face the real reasons your teams aren’t performing, then Scrum is the right tool for the job.

Chapter 2 – Scrum qua Scrum

Scrum in Action

In this chapter, Schwaber takes us beyond theory and explains how to kick off Scrum in an enterprise. He emphasizes that Scrum isn’t just a set of rules to follow; it’s a process for transforming the way your teams work and how your organization operates. The chapter focuses on how to get started with Scrum, from forming the right teams to managing the adoption process.

The Three Scrum Teams

Schwaber introduces three key teams needed for the enterprise Scrum adoption:

1. The Enterprise Transition Team (ETC) – This is a senior leadership team responsible for managing the transformation. They decide to adopt Scrum and guide the entire enterprise through the process. The team includes senior executives, key functional leaders (like HR and finance), and the heads of development and product management.
2. Scrum Rollout Teams – These teams are responsible for implementing Scrum at various levels of the organization. They handle the day-to-day work of rolling out Scrum, removing impediments, and driving change.
3. Scrum Development Teams – These are the teams that will be using Scrum to build products. They are composed of cross-functional members who work together to deliver incremental product improvements every Sprint.

The Role of the ETC

The ETC is crucial to the success of the transition. Schwaber stresses that senior management must be involved, and they need to understand the role they play. The most senior person in the enterprise acts as the Product Owner for this transition, ensuring the Scrum process aligns with the organization’s goals. The ScrumMaster for the ETC ensures the team follows Scrum processes and keeps everything on track.

The ETC team works like any other Scrum team. They start with a goal for each Sprint, working together to achieve it. Their success depends on collaboration and trust—just like any Scrum team. This is a huge cultural shift for many organizations where top-down management has been the norm.

The Transition Product Backlog (TPB)

The success of Scrum adoption depends on the Transition Product Backlog (TPB), which Schwaber compares to a regular Product Backlog. The difference? The TPB is a list of all the things that need to change to adopt Scrum across the enterprise. This can include training sessions, developing Scrum roles, removing organizational roadblocks, and selecting initial Scrum projects.

The highest priority in the TPB is to start actual Scrum projects—real work that will help the organization see value immediately. The process isn’t about theorizing but about jumping into Scrum and identifying roadblocks as they arise.

The Scrum Kickoff Meeting

To formally begin the adoption, the Scrum Kickoff Meeting is essential. This three-hour meeting brings together the ETC team, the ScrumMasters, and other key members. The agenda is straightforward:

• Review Scrum to ensure everyone understands how it works.
• Describe the adoption process and how the ETC team will manage it.
• Make the decision to proceed with Scrum adoption.
• Establish the ETC Scrum team, defining roles and responsibilities.
• Kick off initial Scrum projects, selecting ones that will put the enterprise to the test.
• Identify initial TPB items, like defining the Product Backlog and selecting ScrumMasters.
• Schedule the first Sprint Planning Meeting to start building momentum.

Team Structure and Roles

Once the Scrum Kickoff Meeting is complete, the next step is to form Scrum rollout teams. These teams will manage the tasks laid out in the TPB and implement Scrum within the enterprise. Each team should have a ScrumMaster and a Product Owner from the ETC team to ensure that the transition is on track and aligned with the overall vision.

These rollout teams work in Sprints, typically two weeks long, to tackle the most urgent tasks identified in the TPB. Each Sprint starts with a Sprint Planning Meeting where teams select the highest priority tasks and commit to completing them. By the end of each Sprint, there’s a Sprint Review to evaluate progress and adjust as needed.

Building the Transition

Schwaber emphasizes that Scrum adoption is a journey of continuous improvement. The process is iterative, with each Sprint revealing new challenges and opportunities. The TPB is a living document that evolves as teams identify new impediments, track progress, and adapt strategies. It’s about making change incrementally, one Sprint at a time.

Chapter 2 outlines the practical steps for adopting Scrum within an enterprise. Schwaber focuses on the importance of strong leadership, clear roles, and structured teams to guide the transformation. The key message is that Scrum isn’t just about introducing a new process; it’s about creating a new culture that encourages collaboration, accountability, and continuous improvement.

Chapter 3 – The First Year

Getting Started with Scrum

The first year of adopting Scrum in an enterprise is a rollercoaster. Schwaber describes the journey in stages, starting with the most hectic first month and progressing to a phase where Scrum starts to take root. In this chapter, he shares a roadmap for how the first year might unfold, focusing on the key milestones and challenges.

The First Month

The first month is all about launching Scrum and setting the foundation. During this month, things will be chaotic. It’s natural to feel like you’re moving too fast and not everything is in place yet, but Schwaber urges not to wait for perfection. The problems that were hurting your productivity won’t wait for you to get everything sorted out. They’ll continue to drag down the enterprise, so it’s better to start implementing Scrum and work through the mess as you go.

In the first month, several key activities will take place:

• Communicating the adoption: It’s crucial to clearly explain why Scrum is being introduced and what it will mean for everyone in the enterprise. Everyone needs to understand the benefits, what is expected of them, and how the adoption will unfold.
• Training: Everyone in the enterprise should receive Scrum training to ensure they’re familiar with the framework, roles, and practices.
• Setting preconditions for Scrum projects: Not all projects are ready to use Scrum right away. The first month involves establishing the minimum requirements for projects to use Scrum and defining the criteria for getting started.
• Establishing Scrum roles: For the first projects, identify the Product Owners, ScrumMasters, and teams. You don’t need everything to be perfectly staffed, but having these roles clearly defined is key.

The goal in this first month is to start real Scrum projects. These initial projects should push the boundaries of the enterprise and start delivering product increments immediately, even if some parts of the process are not fully in place yet. It’s about learning through doing.

The Second Month

By the second month, you’ll have several Scrum teams running, and some of the initial issues will be becoming clear. The key here is not to wait for everything to be perfect before starting. Once the first projects begin, you’ll start seeing impediments and challenges that were previously hidden.

The second month will likely involve:

• Identifying and addressing impediments: As Scrum exposes the problems in your enterprise, you’ll need to tackle them head-on. Every project will reveal areas where things aren’t working smoothly. These should be logged and prioritized for improvement.
• Focusing on improvement: The focus here should be on improving productivity and removing obstacles that prevent teams from working effectively. Scrum will expose every inefficiency, but it’s a process of gradual improvement.
• Shifting management practices: Managers must adjust from a top-down, command-and-control mindset to a more servant-leadership role. They will focus on removing impediments, coaching teams, and supporting the Scrum process rather than directing every step.

The Third Month and Beyond

As the months go by, things won’t magically fall into place. It’s normal for the third month and beyond to be tough. This is when the real challenges of adopting Scrum will emerge.

Key points in this phase include:

• Cultural change: Scrum will highlight and make visible every dysfunctional habit in the organization. Some teams will be hesitant to embrace the new way of working, and old habits will die hard. Be prepared for resistance, but don’t let it derail progress.
• Continual adaptation: The enterprise needs to continue adapting. As Scrum reveals problems, the organization must work to solve them, one Sprint at a time. The Transition Product Backlog (TPB) will evolve and grow as new issues arise, and priorities shift.
• Building momentum: Over time, Scrum will start to build momentum. Teams will become more accustomed to working within the framework, and the benefits of Scrum will begin to show. But there will still be setbacks and difficult moments. Expect constant iteration and refinement.

The First Year: A Process of Change

The first year of Scrum adoption isn’t about immediate perfection. It’s a process of learning by doing. Scrum will expose every flaw, but it will also provide a framework for improvement. During the first year, the enterprise will make significant progress, but the true mastery of Scrum will take several years of practice.

Chapter 3 lays out the timeline for the first year of adopting Scrum. The first few months will be chaotic and messy, but the key is to start implementing Scrum and work through the challenges as they arise. The first year is a time of learning and adaptation, and although there will be resistance and setbacks, Scrum will gradually expose areas of improvement and guide the enterprise toward becoming more efficient and agile.

Chapter 4 – Against Muscle Memory—The Friction of Change

The Resistance to Change

In this chapter, Schwaber dives into one of the biggest challenges when adopting Scrum across an enterprise: resistance to change. He describes how deep-seated organizational habits and traditional management practices can create friction when trying to implement a new way of working. The problem is that these old habits are like “muscle memory” for the organization—they’re ingrained and automatic. When Scrum challenges them, the result is often pushback.

Why People Resist Scrum

The first reason for resistance is simple: comfort with the status quo. People are used to doing things a certain way, and even if that way isn’t efficient or effective, it feels familiar and safe. Scrum, on the other hand, requires people to step outside their comfort zones and embrace change. It exposes problems, calls for more collaboration, and demands transparency. This can be uncomfortable, especially for those who are used to working in silos or with top-down command structures.

Another source of resistance comes from the fear of accountability. Scrum emphasizes personal responsibility, with each team member expected to take ownership of their work. In organizations where performance is often hidden or not directly tied to outcomes, this can be a huge shift. People who are used to working in a way that minimizes their exposure to failure may resist a system that requires them to be fully accountable for their part of the work.

The Role of Leadership in Overcoming Resistance

The role of leadership is critical in overcoming this resistance. Schwaber stresses that leaders must actively support the change and be visible in their commitment to Scrum. If leaders aren’t fully onboard, teams will see it as just another management initiative that can be ignored or tweaked to fit their needs.

Leaders need to understand that their role is no longer to control and direct every decision. Instead, they must focus on removing impediments, empowering teams, and fostering an environment of trust and transparency. This shift from controlling to coaching can be difficult for managers who are used to a command-and-control style, but it’s essential for Scrum to work.

The Change is Not Instant

One of the key takeaways from this chapter is that change doesn’t happen overnight. Scrum adoption is not a quick fix—it’s a long-term process that requires consistent effort. Schwaber argues that it takes at least three to five years for Scrum to fully take root in an enterprise. This time frame is necessary to unlearn old habits and build new ones. It’s also essential for leadership to set realistic expectations and understand that there will be setbacks along the way.

During this time, teams will experience friction as they adapt to Scrum. They’ll encounter growing pains as they shift from traditional work styles to more collaborative and self-organizing teams. But these growing pains are not signs of failure. They are part of the process. The key is to stay committed to the transformation, learn from the mistakes, and continuously refine the process.

Scrum as a Cultural Change

Schwaber emphasizes that Scrum isn’t just about implementing a set of rules. It’s about creating a cultural shift. Scrum requires teams to be more transparent, to communicate more openly, and to be accountable for their work. It changes the relationship between managers and teams, and it changes how teams collaborate. All of this goes against the grain of traditional organizational structures, which are often hierarchical, secretive, and siloed.

As Scrum is rolled out, it will expose cultural dysfunctions within the organization. These dysfunctions may have been hidden under layers of bureaucracy, but once they’re exposed, they must be addressed. The process of exposing these issues can feel uncomfortable, but it’s also necessary for improvement.

Small Wins Along the Way

While the road to full adoption may be long and difficult, small wins can help keep the momentum going. These early successes—such as completing a Sprint on time or improving the quality of a product—demonstrate that Scrum works. These small wins provide proof that the new approach is viable and worth the effort. They help build trust in the process and encourage the organization to continue down the path of transformation.

Schwaber also points out that it’s important to celebrate these wins, no matter how small. Recognition and positive reinforcement can go a long way in building enthusiasm for Scrum.

Chapter 4 addresses the natural resistance to change that arises when implementing Scrum in an enterprise. Schwaber explains that old habits, muscle memory, and traditional management practices create friction as Scrum challenges the status quo. Leadership plays a critical role in overcoming this resistance by actively supporting the change, shifting from control to coaching, and setting realistic expectations for the transformation. Scrum isn’t a quick fix—it’s a cultural change that takes time. But with small wins along the way, organizations can stay motivated and continue to refine their practices.

Chapter 5 – Enterprises in Transition

Understanding Enterprise Transformation

In this chapter, Schwaber explores what happens when an entire enterprise attempts to transform using Scrum. He emphasizes that adopting Scrum isn’t just about changing how teams work; it’s about transforming the entire organization. The goal is not just to improve the development process but to reshape how the company operates at every level.

The challenges here are significant. Unlike small teams, enterprises have complex hierarchies, entrenched processes, and cultural norms that can make the shift to Scrum seem impossible. Schwaber highlights that change on this scale requires sustained effort and deep commitment from leadership. It’s not just a quick fix, but a long-term strategic decision to overhaul how work gets done.

The Resistance and Its Roots

As with the previous chapters, resistance remains a major theme in this chapter. Schwaber discusses how large enterprises often resist transformation due to a deeply ingrained culture that prioritizes control, predictability, and stability over flexibility and empowerment. The more hierarchical an organization, the harder it is for teams to embrace the self-organization that Scrum demands. This resistance stems from fear of loss of control—many leaders worry that giving teams more power will lead to chaos or reduced performance.

However, Schwaber argues that true empowerment doesn’t mean abandoning control—it means shifting from top-down management to a model where leaders empower teams to make decisions, solve problems, and continuously improve. It’s a shift in mindset, and it’s one of the hardest aspects of the transition.

Overcoming Barriers to Change

The chapter dives into specific barriers to Scrum adoption that enterprises typically face, such as:

• Managerial Control: Traditional management structures are built on command and control, making it difficult for managers to let go and allow teams to self-manage.
• Lack of Trust: Scrum demands transparency, and transparency often requires a level of trust that many enterprises haven’t cultivated. Leaders must trust that teams can make decisions without constant oversight.
• Failure to Understand Scrum’s Full Impact: Many enterprises try to adopt Scrum without fully understanding its implications. It’s not just a framework for software development; it’s a framework for changing the entire way an organization operates. Without this understanding, Scrum can be misapplied, leading to poor results.

Schwaber suggests that to overcome these barriers, enterprises need to take gradual steps and build trust in Scrum’s ability to deliver value. Overcoming the resistance involves showing, through real projects, that Scrum can actually increase efficiency, product quality, and overall business performance.

The Role of Leadership in Transformation

The chapter emphasizes the critical role that leadership plays in the transformation process. Leaders are not just responsible for supporting Scrum—they are the driving force behind the organizational change. They must model Scrum principles, embrace transparency, and prioritize long-term goals over short-term profits.

One of the major shifts required from leadership is moving from being problem-solvers to being problem-identifiers. In Scrum, leadership is about identifying obstacles and removing them, not about fixing every issue directly. This shift is a major cultural change for leaders, who have been trained to “fix” everything that goes wrong.

Building Scrum Across the Enterprise

To help enterprises scale Scrum, Schwaber stresses the importance of starting small and expanding gradually. Enterprises should begin with a few teams and use them as a learning experience. Once Scrum is successfully implemented in those teams, the approach can be scaled to other teams and departments. But it’s important to remember that scaling Scrum across an enterprise is a slow and gradual process. Every team, department, and project needs to adopt Scrum at its own pace. Some areas may take longer to adapt, and that’s okay.

The Power of Small Wins

A key takeaway from the chapter is the idea of small wins. While the transformation process can take years, enterprises can begin to see tangible results fairly quickly. Early successes—such as teams meeting their Sprint goals or delivering high-quality products—can provide the proof needed to keep everyone engaged in the change process.

These small wins, Schwaber argues, build momentum and show that Scrum isn’t just a theoretical concept. It’s a proven way to increase efficiency, improve collaboration, and deliver real value.

The Long-Term Journey

Schwaber concludes by emphasizing that the transition to Scrum in an enterprise is a long-term journey. It’s not about expecting immediate perfection but about gradual improvement over time. There will be setbacks, resistance, and difficult moments, but by staying committed to Scrum’s principles, enterprises can achieve sustained success.

The process of transformation takes patience, effort, and trust—but it’s ultimately worth it. Schwaber encourages enterprises to embrace the learning process, adapt along the way, and keep the focus on delivering value to customers.

Chapter 5 highlights the scale of the challenge enterprises face when adopting Scrum. It’s not just about tweaking a few processes—it’s about changing the entire organizational culture. Schwaber outlines the common barriers to transformation, including resistance to change, managerial control, and a lack of trust. Leadership must play a central role in driving the change, modeling Scrum principles, and focusing on long-term transformation. The journey to full adoption is long and gradual, but small wins along the way provide the necessary momentum to keep moving forward.

Chapter 6 – Organizational Practices

Transforming Organizational Practices with Scrum

In Chapter 6, Schwaber focuses on the transformation of organizational practices. Scrum doesn’t just change how teams work; it requires enterprises to rethink their entire structure, policies, and practices. The goal is to align these practices with Scrum’s values of collaboration, transparency, and continuous improvement.

Breaking Down the Traditional Structure

Schwaber explains that traditional organizational structures, particularly hierarchical ones, are not compatible with Scrum. In a typical enterprise, there are layers of management and rigid lines of communication, but Scrum demands transparency, open communication, and the removal of barriers between teams. A Scrum organization is built around cross-functional teams, each fully capable of delivering product increments without waiting for instructions from a higher authority.

One of the biggest obstacles to adopting Scrum is the existing power structure. Managers are used to having control over their teams, but Scrum encourages a shift toward self-managing teams. Managers in a Scrum environment should act as coaches, guiding teams rather than directing them. The challenge here is that many leaders will need to unlearn old habits of top-down control and embrace a more servant-leadership approach.

Creating Cross-Functional Teams

To effectively implement Scrum, enterprises must create cross-functional teams that can handle all aspects of the product development process—from design to testing to delivery. Traditional departments like marketing, development, and sales often work in silos, but Scrum teams are intended to be holistic, meaning that everyone in the team has the skills and knowledge to contribute to the entire project.

Schwaber emphasizes that these cross-functional teams aren’t just about technical roles. Teams should include people with diverse skills, such as marketing and business analysis, so that they can make decisions on their own without needing approval from other departments. This autonomy accelerates decision-making and helps ensure the team stays focused on delivering value to the customer.

Rethinking the Role of Managers

In Scrum, the role of managers shifts significantly. Rather than managing tasks and micromanaging employees, managers should focus on creating an environment where teams can thrive. Their new job is to remove impediments, provide support, and ensure that teams have the resources they need to succeed.

One of the key differences between traditional management and Scrum management is the level of empowerment given to teams. Scrum calls for teams to be self-organizing, meaning they should be able to make decisions about how to approach their work. Managers must trust teams to make the right choices and intervene only when absolutely necessary to remove obstacles.

Measuring Success in a Scrum Organization

A traditional organization measures success through key performance indicators (KPIs) that track individual performance or efficiency. In a Scrum organization, the focus shifts to team performance and delivering value to the customer. Schwaber suggests that enterprises should measure success based on team collaboration, product quality, and customer satisfaction rather than the old metrics that focus on individual productivity.

Encouraging Continuous Improvement

One of the most important changes in organizational practices is the focus on continuous improvement. Scrum promotes a culture of reflection and adaptation, and this applies not only to the work being done by Scrum teams but to the enterprise as a whole. Schwaber argues that organizations need to establish regular opportunities for reflection, such as Sprint Reviews and Retrospectives, where teams can discuss what went well, what didn’t, and how they can improve in the next Sprint.

Beyond the team level, the enterprise needs to continuously evaluate its practices and processes to ensure that Scrum is being implemented effectively. This means regularly reviewing organizational structures, policies, and practices to see if they align with Scrum’s values. As the enterprise matures, the focus should shift from simply implementing Scrum to continuously optimizing organizational practices to support Scrum’s principles.

Chapter 6 underscores the importance of transforming organizational practices to align with Scrum’s core principles. It’s not just about adopting Scrum at the team level; it’s about rethinking how the entire enterprise operates. Traditional hierarchies and departmental silos are incompatible with Scrum, which requires cross-functional, self-managing teams and a culture of continuous improvement. Managers need to shift from directing work to removing obstacles and empowering teams. By focusing on collaboration, customer value, and ongoing optimization, enterprises can create a strong foundation for Scrum to thrive.

Chapter 7 – Engineering Practices

Aligning Engineering with Scrum

In Chapter 7, Schwaber focuses on how engineering practices need to change to align with Scrum. Engineering, particularly in software development, has traditionally been a siloed process where work is handed off between different teams. Scrum changes that by encouraging cross-functional teams that collaborate and deliver product increments every Sprint. The chapter discusses how Scrum drives engineering practices toward more adaptive, iterative, and collaborative approaches, all designed to deliver value to the customer faster and more effectively.

The Shift from Predictive to Adaptive Engineering

One of the most significant shifts in engineering when adopting Scrum is moving away from predictive engineering to adaptive engineering. In traditional, waterfall-based approaches, engineering teams would often attempt to predict the entire product development cycle upfront. This would involve creating extensive plans and schedules based on assumptions about requirements, timelines, and resources.

Scrum, however, demands an adaptive approach, where teams work in short iterations (Sprints) and continuously adjust their plans based on feedback from the product owner and stakeholders. This ensures that the team is always building the most valuable features, based on the most current information.

Schwaber notes that adaptive engineering is more flexible and realistic in an environment where customer needs and market conditions can change rapidly. It allows teams to adjust course quickly, rather than following a rigid, pre-determined plan.

Cross-Functional Teams and Continuous Delivery

In Scrum, the cross-functional team is a fundamental concept. This means that everyone needed to deliver the product—in software engineering, testing, design, and even marketing—works together as a single unit. Each team member brings their skills to the table and collaborates throughout the Sprint, rather than waiting for their turn in a sequential process.

One of the results of this collaborative approach is continuous delivery. In Scrum, the team works on delivering small, incremental improvements to the product regularly. This ensures that the product is always in a potentially shippable state, and that value is being delivered to the customer continuously, rather than in one large chunk at the end of a long development cycle.

For engineers, this shift to continuous delivery requires the adoption of certain technical practices to ensure the product can be released frequently and reliably. These include:

• Automated Testing: To ensure the quality of the product and prevent regressions, automated tests are essential. Scrum teams need to incorporate automated testing into their development process, enabling them to check the integrity of the product after every change.
• Continuous Integration: Engineers must commit code frequently and integrate it into the main codebase. This avoids the common pitfall of having large, complicated merges later in the process, and ensures that the product is always ready for release.
• Pair Programming: Pair programming is another key practice in Scrum, where two engineers work together at one workstation. This practice not only improves code quality but also helps transfer knowledge between team members.

Technical Debt and Refactoring

As Scrum teams iterate on their products, they might sometimes take shortcuts or make trade-offs in order to meet deadlines. This results in technical debt—the extra work that will be needed to clean up or improve the code later.

Schwaber stresses the importance of refactoring—the practice of improving the structure of existing code without changing its functionality. Scrum teams should dedicate time during each Sprint to refactor their codebase and reduce technical debt, ensuring that the product is sustainable over time.

Refactoring allows teams to maintain a clean codebase, which is critical for future iterations and ensures that the product remains maintainable and adaptable as it evolves.

Engineering Practices in a Scrum Organization

As Scrum moves from individual teams to the enterprise level, engineering practices must be consistent across all teams. Schwaber encourages enterprises to:

• Standardize engineering practices across teams to ensure that all Scrum teams are following similar procedures. This includes defining common tools and techniques for continuous integration, testing, and deployment.
• Promote technical excellence and ensure that engineers are constantly improving their skills. Scrum organizations should foster a culture of technical innovation where engineers have the time and space to experiment with new technologies and techniques.
• Encourage collaboration between engineers and other stakeholders, such as product owners and business analysts. In Scrum, everyone involved in product development must work together to create the best possible product.

Chapter 7 emphasizes that engineering practices need to evolve in order to support Scrum’s principles of adaptability, collaboration, and continuous improvement. Scrum requires a shift from traditional, predictive engineering practices to more adaptive, iterative, and collaborative ones. Key practices such as automated testing, continuous integration, pair programming, and refactoring are essential for delivering high-quality products quickly. As Scrum spreads across an enterprise, it’s important to standardize these practices and promote technical excellence to ensure consistent success across teams.

Chapter 8 – People Practices

Adapting People Practices for Scrum

In Chapter 8, Schwaber turns his attention to the people practices that are essential for successfully adopting Scrum across an organization. This chapter highlights that for Scrum to thrive, individuals and teams must operate in ways that align with Scrum’s values of transparency, collaboration, and self-organization. It’s not just about new processes and tools—it’s about changing the way people think, work, and collaborate.

The Shift in People’s Roles

One of the most striking changes when adopting Scrum is the shift in roles within teams. Traditional organizations often have rigid role definitions, with departments like development, testing, and marketing working in separate silos. Scrum, however, calls for cross-functional teams, where everyone works together to deliver a product increment. This means people need to adapt by wearing multiple hats and working outside their traditional roles.

For instance, the role of ScrumMaster is essential in helping teams implement Scrum successfully. The ScrumMaster is not a project manager who assigns tasks but instead is a servant leader who removes impediments, facilitates Scrum ceremonies, and ensures the team stays focused on delivering value. The ScrumMaster’s job is to help the team grow and improve, not to direct their actions.

The Product Owner also plays a pivotal role. They are responsible for defining the product vision and managing the product backlog. Unlike traditional managers who may delegate tasks to teams, the Product Owner works closely with the team to make sure they’re building the right product.

Additionally, team members in Scrum are expected to be self-managing. They are responsible for organizing their work and solving problems without waiting for instructions from above. This means they need to be empowered to make decisions, and they must be held accountable for the work they commit to during each Sprint.

Cultural Shifts in People Practices

The cultural shift required for Scrum to work isn’t just about roles—it’s about attitudes, mindsets, and behaviors. In traditional organizations, there’s often a fear of failure and a need to avoid mistakes at all costs. In a Scrum environment, however, failure is viewed as a learning opportunity. Teams are encouraged to experiment and iterate quickly, failing fast to learn faster. This mindset requires psychological safety, where team members feel comfortable taking risks, making mistakes, and speaking up without fear of judgment.

Schwaber points out that creating this safe environment is crucial for success. Teams must feel empowered to make decisions and act on them, and leaders must trust their teams to do so. Managers need to stop being micromanagers and instead adopt a coaching mindset—guiding teams while giving them the autonomy to manage their work.

Building Trust and Accountability

The principle of trust is at the core of Scrum’s people practices. For Scrum to succeed, everyone involved must trust each other, from the Product Owner to the ScrumMaster to the development team members. Trust is built through transparency—everyone can see what’s happening within the team, and team members are open about their progress, challenges, and needs.

However, trust must also be coupled with accountability. Scrum doesn’t just allow team members to make decisions—it holds them accountable for the results. This combination of trust and accountability is powerful because it leads to high-performing teams that are motivated to deliver the best possible product.

Training and Development in Scrum Teams

A key aspect of people practices in Scrum is the ongoing training and development of team members. Scrum encourages continuous improvement, and that doesn’t just apply to processes and products—it applies to people as well. Schwaber argues that investing in training is crucial for enabling teams to continuously enhance their skills and grow their capabilities.

In Scrum, training should focus on both technical skills (like software development and testing) and soft skills (such as communication, collaboration, and problem-solving). Teams should regularly reflect on their performance and identify areas for improvement. This reflection can take place during Retrospectives, where teams discuss what worked well, what didn’t, and how they can improve going forward.

Managing Change in People Practices

The adoption of Scrum is a change management process, and this applies to people practices as much as to processes and structures. As Scrum changes the way work is done, people in the organization will also need to change the way they think about their work. For example, roles that were once hierarchical are now more collaborative. Managers become coaches, and team members take ownership of their work.

This cultural shift can be challenging, especially for those who are used to a more traditional, command-and-control environment. Schwaber stresses the importance of gradual change—making incremental adjustments rather than trying to change everything at once. Successful Scrum adoption requires patience, and organizations must be ready for ongoing learning and adaptation.

Chapter 8 focuses on the people practices required for Scrum to succeed. It emphasizes that Scrum is not just about new processes and roles, but about shifting the organizational culture to foster collaboration, trust, and accountability. Scrum teams must be cross-functional, self-managing, and empowered to make decisions. Managers must act as coaches rather than controllers, and the organization must prioritize continuous learning and development. The chapter underscores that trust, empowerment, and a growth mindset are key to creating high-performing teams and a thriving Scrum environment.

Chapter 9 – The Relationship Between Product Management/Customer and the Development Team

Aligning Product Management and Development Teams

In Chapter 9, Schwaber discusses the crucial relationship between Product Management, the customer, and the development team in a Scrum environment. One of the most significant changes in Scrum is the collaborative, transparent, and iterative relationship that develops between these groups. Traditional organizations often have siloed departments where product managers and developers work separately, with limited communication. Scrum, on the other hand, demands close collaboration between the Product Owner (representing the customer and product management) and the development team.

Schwaber emphasizes that the Product Owner plays a pivotal role in bridging the gap between the development team and the customer. The Product Owner is responsible for ensuring that the team is building the right product by keeping a well-prioritized Product Backlog and actively engaging with stakeholders throughout the development process. The role is vital because it provides the development team with the clarity they need to make decisions and stay aligned with customer needs.

The Role of the Product Owner

The Product Owner’s primary responsibility is to represent the voice of the customer within the development team. They work closely with stakeholders, gather requirements, and set priorities based on customer needs and business goals. However, this is not just a communication role. The Product Owner must also actively manage the Product Backlog, which includes creating and refining user stories, prioritizing them based on value, and ensuring that the team’s work aligns with the organization’s strategic goals.

One of the challenges faced by Product Owners is managing conflicting priorities. In many organizations, Product Owners may be overwhelmed with requests from different departments or stakeholders, each with their own interests and needs. To succeed in Scrum, the Product Owner must balance these competing demands, ensuring that the most valuable features are delivered first.

The Product Owner’s role is also critical during the Sprint Review meetings. Here, the Product Owner helps the team understand what was accomplished, gathers feedback from stakeholders, and adjusts the Product Backlog as necessary. This regular feedback loop ensures that the team is always working on the highest-priority tasks and can adapt to changing needs.

Collaborating with the Customer

In traditional product development processes, there is often a significant gap between the customer and the development team. Customers may provide requirements at the beginning of the project, but their input is rarely sought until the end of the process when the product is ready for delivery. Scrum, however, encourages constant feedback and collaboration with the customer.

This regular engagement ensures that the development team is building the right product and that customer needs are met. Schwaber notes that early and continuous customer feedback is one of the key advantages of Scrum, as it allows the team to make adjustments throughout the development process, rather than at the very end. The Product Owner plays an essential role in facilitating this ongoing dialogue with the customer.

Transparency in Product Development

Transparency is a core value in Scrum, and it is essential for building trust between product management, the development team, and the customer. Scrum encourages open communication about progress, challenges, and changes in scope. The development team must be transparent about the work they are doing, the obstacles they face, and the timeline for completion. Similarly, the Product Owner must ensure that stakeholders are kept informed about the product’s status and any changes to the scope or priorities.

One way that transparency is achieved is through the Sprint Review meetings, where the team demonstrates the product increment to stakeholders. This creates an open space for discussion and feedback, and it ensures that everyone is on the same page regarding the direction of the product.

Managing Expectations

Managing expectations is a crucial skill for both the Product Owner and the development team. Customers and stakeholders often have high expectations for what a product will deliver, and it is the Product Owner’s responsibility to set realistic expectations while keeping them aligned with the team’s progress.

Schwaber explains that communication is key when managing expectations. The Product Owner must communicate what is possible within the constraints of time, resources, and scope. At the same time, the development team must communicate any challenges or delays they are facing so that stakeholders can adjust their expectations as needed.

One of the benefits of Scrum’s iterative approach is that expectations can be adjusted quickly. After each Sprint, there is a chance to reassess what has been delivered and what remains to be done, ensuring that the product is always aligned with customer needs and business goals.

Chapter 9 focuses on the relationship between product management, the customer, and the development team in Scrum. Schwaber stresses that this relationship must be collaborative, transparent, and iterative. The Product Owner plays a central role in representing the customer and aligning the development team’s work with customer needs.

This requires balancing conflicting priorities, managing expectations, and maintaining open lines of communication between all parties. Regular customer feedback and continuous engagement ensure that the product evolves in the right direction, and Scrum’s focus on transparency helps to build trust and keep everyone aligned.

4 Key Ideas from The Enterprise and Scrum

6 Main Lessons from The Enterprise and Scrum

My Book Highlights & Quotes

People subconsciously retard their own intellectual growth. They come to rely on cliches and habits. Once they reach the age of their own personal comfort with the world, they stop learning and their mind runs idle for the rest of their days. They may progress organizationally, they may be ambitious and eager, and they may even work night and day. But they learn no more.

One of the Scrum rules is that work cannot be pushed onto a team; the Product Owner offers items for the iteration, and the team pulls as many as they decide they can do at a sustainable pace with good quality.

Conclusion

In a world where companies often chase agile by renaming departments or rearranging chairs, The Enterprise and Scrum is a breath of fresh air. It strips away the buzzwords and gets to the heart of what agility really takes: courage, commitment, and a willingness to look in the mirror.

If you want your team—or your whole organization—to stop spinning in circles and start delivering real value, this book isn’t just helpful. It’s essential.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09
• Book Notes #122: The First 20 Hours by Josh Kaufman2024-05-02

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: