Book Notes #27: Succeeding With Agile by Mike Cohn

Title: Succeeding with Agile: Software Development Using Scrum
Author: Mike Cohn
Year: 2010
Pages: 475

We’ve all heard about companies “going agile,” but too often, it ends in frustration. People sit through trainings, adopt Scrum ceremonies, and still… nothing really changes.

Projects miss deadlines. Teams burn out. Leadership loses patience. What gives? That’s exactly the kind of question Succeeding with Agile by Mike Cohn sets out to answer.

This isn’t a how-to guide for Scrum mechanics—it’s a human, honest, and incredibly useful book about what really makes agile work in the real world.

If you’ve ever tried to lead or support change in a team or company, this book will feel like a wise friend handing you a flashlight and saying, “Here’s how to navigate this mess.”

As a result, I gave this book a rating of 8.0/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 Succeeding with Agile

Book Overview

You can tell a lot about a team by the way they handle a change in plans. Some fall apart. Others freeze, waiting for direction. But then there are those rare teams that adapt quickly, adjust course, and keep moving with confidence.

What makes them different? That’s the heart of Mike Cohn’s Succeeding with Agile—a book that doesn’t just teach Scrum, but shows what it really takes to make agility stick when real people, messy organizations, and everyday pressures are involved.

Cohn doesn’t write like someone selling a framework. He writes like someone who’s seen it all—teams that thrive, teams that fake it, and teams that quietly slide back into old habits despite good intentions. From the very first chapters, it’s clear that this isn’t about ceremonies or roles.

It’s about mindset. Scrum is simple on paper, but deeply disruptive in practice. And Cohn isn’t afraid to tackle the hard stuff: resistance, old-school HR systems, distributed teams, cultural friction, and PMOs still clinging to Gantt charts like a safety blanket.

What makes this book stand out is how grounded it feels. Cohn doesn’t hide behind theory—he shares real stories, missteps, and the kind of challenges that don’t show up in certification training. Like the developer who refused to pair program because he feared it would tank his individual performance review.

Or the team that needed to hang visual boards on the hallway walls because the cubicles didn’t support collaboration. These moments are small but powerful—they show what transformation actually looks like in the wild.

And then there’s the way the book approaches leadership. Instead of telling managers to step back and disappear, Cohn challenges them to shift from control to influence.

His idea of “agitating” the system to keep it learning—not just managing it into comfort—is one of the most refreshing takes on agile leadership I’ve read.

You get the sense that this book isn’t just for ScrumMasters or coaches—it’s for anyone who wants to lead change without falling into command-and-control habits.

The chapters on scaling and coexistence are particularly eye-opening. Cohn doesn’t pretend every organization is a blank slate. He knows many teams live in hybrid worlds, where Scrum needs to bump elbows with waterfall processes, stage gates, or regulatory audits. But instead of treating those realities as barriers, he shows how teams can work within them—gently bending rules, adjusting expectations, and proving value without confrontation. It’s agile with empathy.

And just when you think it might get too tactical, the book zooms out. The later chapters dive into how HR, office layouts, compliance requirements, and even governance models influence agility.

You start to see Scrum not as a team tool, but as something that reshapes how an entire organization thinks about work. It’s not about doing faster standups. It’s about creating workplaces where people are trusted, where progress is visible, and where learning is built into the rhythm of every sprint.

But perhaps the biggest insight comes near the end, where Cohn talks about measuring success. Not with rigid maturity models or vanity metrics, but with simple, honest indicators of whether Scrum is actually making life better—for the team, the business, and the customer.

He reminds us that the goal of agility isn’t to “do Scrum right.” It’s to deliver value more reliably, to make better decisions faster, and to enjoy the process along the way.

If you’re looking for a book that gives you checklists, templates, and easy answers, this isn’t it. Succeeding with Agile is something better—it’s a deeply practical, often humble, and always thoughtful guide for people trying to change how they work without losing sight of why they work in the first place.

In the end, what this book offers is clarity. Not in the form of step-by-step instructions, but in the way it helps you see the real path to agility—one grounded in people, trust, and continuous learning. It’s the kind of book you finish with a quiet nod, thinking, “Yes. This is what we’ve been missing.”

Chapter by Chapter

Chapter 1 – Why Becoming Agile Is Hard (But Worth It)

Becoming Agile Sounds Great—But It’s Tougher Than It Looks

The first chapter sets the stage for the whole book by tackling a hard truth: transitioning to Agile, especially through Scrum, is much harder than most companies expect. Sure, Agile sounds great—faster releases, happier customers, better teamwork. But when teams try to put it into practice, many hit walls they didn’t anticipate.

Mike Cohn opens by highlighting the impressive results companies like Salesforce.com saw after embracing Scrum—more features delivered, more value created, and even a significant jump in revenue. But then he points out something important: many companies don’t get those results, even if they try hard. Why? Because they underestimate the depth of change Agile demands.

The Trouble with Change

The chapter tells the story of several failed or semi-successful Agile transitions. In each one, a different problem got in the way. One company spent over a million dollars trying to go Agile, but it failed because executives assumed only the development teams needed to change. Another leader, Josef, launched Scrum successfully with one team, but his second attempt was blocked by middle managers who felt threatened. Caroline, a VP, rolled out Scrum across her division and saw good early progress—but nothing beyond that because her teams forgot one core principle: continuous improvement.

All of these stories highlight the same core issue—transformation is hard, especially when it affects not just what people do, but how they think and collaborate.

Why Transitioning Is Especially Hard

The chapter then digs into six specific reasons why moving to Scrum is so difficult:

Successful change isn’t just top-down or bottom-up: You need leadership support and team-level engagement. If one is missing, resistance creeps in. Middle managers, especially, can be blockers if they don’t feel part of the process.

The end state is unpredictable: Unlike traditional change efforts where you define a clear “future state,” Scrum is about continuous improvement. There’s no final destination. That means traditional change plans—gap analyses, step-by-step transitions—often fail. Instead, Cohn suggests a “provoke and observe” approach: try something small, watch how the system reacts, then adapt.

Scrum touches everything: It’s not just a new process—it’s a new way of working. Developers must shift from long planning phases to quick iterations, maybe even adopt test-driven development or pair programming. But the impact goes beyond IT. Finance, sales, and HR may all need to adjust. That broad reach creates more friction.

Scrum is radically different: People have to unlearn habits they were praised for. For example, developers trained to do detailed up-front design now need to embrace emergent design. That’s not easy. The story of Terry, who tried to bring test-driven development into his team and faced long resistance, shows just how deep these changes go.

We’re already overwhelmed by change: Organizations have been in constant flux—new technologies, restructurings, outsourcing. For many, Agile is just one more change in a long list. This “future shock,” as Alvin Toffler called it, can make people resist even the best ideas.

Best practices can backfire: In most change efforts, “best practices” are shared and standardized. But in Agile, locking in one way of doing things too early can kill the spirit of continuous improvement. Mike Cohn gives the example of a company that made 10:00 a.m. the mandatory time for all daily scrums—an unnecessary rule that felt like micromanagement and missed the point of agility.

But It’s All Worth It

After laying out all the challenges, the chapter shifts gears to explain why pushing through is absolutely worth it.

Companies that adopt Agile well tend to:

• Deliver more with less (higher productivity and lower costs)
• Improve job satisfaction (employees feel more engaged and less burned out)
• Move faster (time-to-market shrinks significantly)
• Produce better quality software (fewer bugs, more usable features)
• Make stakeholders happier (because priorities can change and visibility is better)

Data backs this up. Studies from QSMA, VersionOne, DDJ, and academic researchers like David Rico show that Agile projects consistently outperform traditional ones across all these metrics. Even morale improves—at Salesforce.com, employee satisfaction doubled after the shift to Scrum.

A Final Word: Because What We Were Doing No Longer Works

Many companies don’t adopt Scrum because it’s trendy. They do it because their current way of working just isn’t cutting it anymore. Yahoo! and High Moon Studios are cited as examples—both tried to “do waterfall better” but just made things worse. For them, Agile was not just a nice option; it was a survival move.

Looking Ahead

The chapter ends on a motivational note. Yes, becoming Agile is hard—maybe harder than expected. But the payoff is real. And in the next chapter, the book dives into how to start making real, meaningful progress.

Chapter 2 – ADAPTing to Scrum

The Journey of Scrum Adoption

In this chapter, the author introduces the ADAPT model, a framework that outlines the essential activities for successfully adopting Scrum. This model is based on five key activities—Awareness, Desire, Ability, Promotion, and Transfer—which, together, help guide teams and organizations through the process of Scrum adoption. Each of these stages is crucial in making Scrum not just a temporary change but a lasting and effective shift in how teams work.

Lori Schubring’s Story

The chapter begins with the story of Lori Schubring, an application development manager who recognized that her company’s formalized process was hindering progress. Lori’s journey to adopting Scrum involved several key steps: realizing the existing process wasn’t working, learning about Scrum, promoting it within her team, and ultimately spreading its benefits throughout the organization. Her experience is a perfect example of how ADAPT works in practice.

The ADAPT Cycle

ADAPT stands for:

• Awareness: Recognizing that the current processes aren’t delivering results.
• Desire: Developing the desire to change and adopt Scrum.
• Ability: Gaining the necessary skills to effectively use Scrum.
• Promotion: Sharing successes to encourage wider adoption.
• Transfer: Ensuring the Scrum mindset spreads beyond the development team to other parts of the organization.

The model emphasizes that these activities should be ongoing, especially in larger organizations where the process can take time to fully take hold.

The Key Activities Explained

1. Awareness: The first step in the process is acknowledging that the current methods aren’t producing the desired outcomes. This can be difficult, as many organizations are often entrenched in their ways. Tools for developing awareness include communicating problems clearly, using metrics to highlight inefficiencies, and exposing team members to new ideas through conferences or pilot projects. The goal is to create a shared understanding of why change is necessary.
2. Desire: Moving from awareness to desire is often the hardest step. It’s not enough for people to understand that change is necessary—they must also want to make that change. Building desire can be done through communication that showcases how Scrum can solve the problems identified during the awareness phase. Creating a sense of urgency, building momentum through early successes, and aligning incentives with team goals can all help turn awareness into a strong desire to adopt Scrum.
3. Ability: Even if a team is aware of the need to change and has the desire to adopt Scrum, it won’t work unless they acquire the skills to succeed. This phase involves learning new technical skills, collaborating more effectively as a team, and working within the constraints of short, focused sprints. Training, coaching, and hands-on experience are crucial here. Teams need continuous support to develop and refine their ability to work within Scrum’s framework.
4. Promotion: Promoting the successes of Scrum teams is key to sustaining momentum and encouraging wider adoption. This phase isn’t about selling Scrum but about celebrating and sharing successes within the team and the wider organization. Communication of these successes, whether through presentations, word of mouth, or internal reports, helps to spread enthusiasm and attract others to try Scrum.
5. Transfer: The final phase is about ensuring that the Scrum mindset and practices are transferred to other parts of the organization. Development teams can’t work in a vacuum; other departments—such as HR, marketing, and finance—must understand and support Scrum’s principles to prevent the forces of “organizational gravity” from pulling the development team back into old ways. Communication, education, and collaboration across departments are essential for long-term success.

Tools for Promoting and Transferring Scrum

As teams progress through the ADAPT cycle, it’s crucial to promote Scrum effectively and transfer its implications to other departments. This chapter emphasizes that change isn’t just about the development team—it’s about creating an environment where Scrum can thrive across the organization. Promoting Scrum doesn’t require flashy marketing campaigns but should focus on spreading real successes and practical examples of how Scrum improves outcomes. Transferring Scrum’s implications to other departments, like HR or marketing, is also necessary to maintain momentum.

The Organizational Impact

The ADAPT model is iterative, and the process of adopting Scrum doesn’t end with one successful project or team. The changes must spread throughout the organization, with constant promotion and reinforcement. This ongoing cycle of awareness, desire, ability, promotion, and transfer helps ensure that Scrum adoption is not just a phase but a sustainable change that delivers lasting results.

Key Takeaways

• Scrum adoption is a multi-step process that requires awareness, desire, ability, promotion, and transfer.
• Creating awareness of the need for change is the first step, followed by building the desire to adopt Scrum.
• Developing the ability to succeed with Scrum requires training, coaching, and hands-on practice.
• Promoting early successes and transferring Scrum’s principles to other departments are crucial for long-term success.
• The ADAPT model is iterative, meaning Scrum adoption is a continual process of improvement and reinforcement across the organization.

This chapter lays the foundation for the practical steps of implementing Scrum within a team or organization. It highlights that successful Scrum adoption requires more than just learning new practices—it involves changing mindsets, fostering collaboration, and ensuring that the whole organization is aligned with Scrum’s principles.

Chapter 3 – Patterns for Adopting Scrum

Choosing the Right Approach for Scrum Adoption

This chapter explores various strategies for adopting Scrum in organizations, offering insight into which approach works best depending on the situation. The author highlights four distinct patterns for Scrum adoption that organizations can choose from based on factors like size, readiness, and risk tolerance.

Key Questions to Consider

Before jumping into Scrum, organizations must address two important questions:

1. Should we start with just a few teams, or should we convert all teams at once?
2. Should we announce our intent to adopt Scrum publicly or keep it quiet for now?

The chapter also introduces different methods for spreading Scrum within an organization, and the considerations for when to introduce technical practices like automated testing and pair programming.

Start Small or Go All In

Historically, many agile experts recommend starting small with Scrum by implementing it with just one or two teams. This cautious, phased approach helps organizations minimize risk, learn from early mistakes, and gradually build the internal expertise needed for wider adoption.

However, the chapter presents the opposite approach through the story of Salesforce.com, which went “all in” by converting 35 teams to Scrum overnight. Salesforce.com’s culture—fast-paced and achievement-oriented—was a good fit for this bold strategy. Despite the chaos and resistance during the transition, it ultimately proved successful because the company was committed to Scrum on a large scale.

Interestingly, combining both strategies is also common: some organizations start with a small pilot project and then quickly scale Scrum across the entire company once the first few teams succeed. This hybrid method allows for initial learning while also demonstrating the organization’s commitment.

Advantages of Starting Small

The start-small approach comes with several benefits:

• Lower cost: Smaller teams mean less external support, fewer outside consultants, and a more controlled learning environment.
• High likelihood of success: By selecting projects that are likely to succeed, organizations can generate early wins, which helps build momentum.
• Less stress: A smaller scale reduces the pressure on employees and leaders and allows for gradual change. Early adopters can also become ambassadors, sharing successes and easing the transition.
• Avoiding major mistakes: If things go wrong, they’re contained within a smaller team or project, making it easier to learn and adapt without significant consequences.

Advantages of Going All In

While riskier, an all-in transition offers some compelling benefits:

• Reduces resistance: If the whole organization transitions at once, it avoids the problem of “us vs. them” that can arise when some teams are using Scrum while others are not.
• Faster transition: An all-in approach allows the organization to reach full adoption more quickly.
• Clear commitment: A public declaration of going all-in sends a strong message to the organization that Scrum is here to stay, which can inspire employees and leaders alike.

Choosing Between the Two Approaches

The decision largely depends on the urgency of the need and the level of risk an organization is willing to take. Start small when:

• There’s reluctance or uncertainty among leadership.
• The potential cost of failure is high.
• You need to build confidence slowly.

Go all in when:

• Time is critical, and the benefits of Scrum are needed quickly.
• You want to demonstrate a strong, visible commitment to change.
• You have enough experienced ScrumMasters to support the transition.

Public Display of Agility or Stealth

The chapter then delves into another choice organizations face: whether to publicly announce their transition to Scrum or keep it quiet (a “stealth” transition). Both approaches have their merits:

• Public Display: Announcing the transition can help generate support, encourage accountability, and make the organization commit to Scrum. It also sets a clear vision and allows for wider engagement.
• Stealth Transition: A stealth approach allows teams to work without external pressure or resistance, and can help avoid unrealistic expectations. However, it might also delay support from key stakeholders and create confusion later on.

The author suggests a public display is more likely to lead to a successful transition, as it demonstrates commitment. However, a stealth approach might be better for organizations that want to experiment with Scrum without external scrutiny.

Patterns for Spreading Scrum

Once Scrum is successfully adopted by a few teams, the next challenge is spreading it to others. The chapter outlines three patterns for this:

1. Split and Seed: This approach involves splitting a successful Scrum team into smaller teams, each seeded with experienced members to help new teams learn the ropes. It’s a quick way to spread Scrum but can cause disruption within teams that are still forming.
2. Grow and Split: This variation involves growing a team to a sufficient size before splitting it. This approach maintains more continuity and reduces disruption, as teams aren’t split prematurely.
3. Internal Coaching: In this pattern, experienced Scrum team members are selected to act as internal coaches for other teams. Coaches are embedded within teams to provide guidance and spread Scrum practices.

Choosing the Right Spread Pattern

• Split and Seed is ideal for rapid spread, especially in large organizations, but it can cause disruption as teams are constantly restructured.
• Grow and Split is less disruptive and works well when teams are naturally expanding.
• Internal Coaching is beneficial when teams are already doing well, but the organization lacks enough experienced Scrum practitioners to coach new teams.

Introducing New Technical Practices

The chapter also discusses when to introduce technical practices such as test-driven development or pair programming. Some believe that early adoption of these practices leads to quicker improvements, while others argue that teams should first focus on learning the basics of Scrum before adding complex technical practices.

The author suggests that introducing technical practices too soon can add unnecessary pressure, but waiting too long might result in missed opportunities for improvement.

This chapter underscores that there’s no one-size-fits-all approach to adopting Scrum. The right path depends on factors like the organization’s size, readiness for change, and the speed at which it needs to transition. Ultimately, whether you start small or go all in, the key to success is ongoing commitment to the Scrum principles and a willingness to adapt as you go.

Chapter 4 – Iterating Toward Agility

A New Approach to Organizational Change

In Chapter 4, Mike Cohn challenges the traditional, top-down approach to organizational change. Instead of adopting a rigid change program, he suggests using Scrum itself to guide the change process—applying iterative cycles to manage the adoption of Scrum. This approach mirrors Scrum’s core philosophy: small, continuous changes lead to long-term success.

Historically, change efforts in organizations were driven by large, formal “change programs,” where a well-defined process with a beginning and an end was followed. However, as the pace of change has accelerated in today’s competitive landscape, this model has proven less effective. Cohn argues that we need to adopt smaller, iterative changes that allow organizations to adapt more quickly and effectively, just like the Scrum methodology.

The Shamrock Foods Example

A compelling example of this approach comes from Shamrock Foods, which faced rapid changes in its industry. The company had used a traditional strategic planning process for years, but it was quickly becoming outdated. CEO Kent McClelland shifted the company toward using Scrum for quarterly strategic planning sprints. These “strategic scrums” involved teams evaluating the previous quarter’s performance and adjusting action plans accordingly. They also held annual meetings to reassess the company’s strategic assumptions. This iterative approach allowed Shamrock to remain agile and responsive to fast-changing market conditions.

The Improvement Backlog

Just as Scrum teams use a product backlog to manage their work, organizations adopting Scrum should use an “improvement backlog.” This backlog tracks what needs to be improved in the organization’s Scrum adoption efforts. At IBM, for example, their improvement backlog included items like increasing the number of teams using Scrum, adopting test automation, and implementing continuous integration. The improvement backlog should evolve over time, reflecting the ongoing improvements needed as the organization becomes more proficient with Scrum.

In large organizations, multiple improvement backlogs might exist—each one maintained by a community of employees dedicated to improving specific areas of Scrum adoption, such as test automation or team development. A master improvement backlog can also be maintained to guide the overall transition across the organization.

The Enterprise Transition Community (ETC)

The chapter introduces the concept of the Enterprise Transition Community (ETC)—a small group of senior leaders responsible for guiding an organization’s Scrum adoption. The ETC is not a traditional steering committee; rather, it’s a working group focused on removing impediments, providing support, and generating excitement about the transition to Scrum. The members of the ETC typically come from various functional areas of the organization, such as engineering, marketing, and HR, to ensure that Scrum adoption is embraced company-wide.

The ETC operates using Scrum principles, with each sprint focused on moving the transition effort forward. The sprint length for an ETC can vary, but two-week sprints are recommended to maintain momentum and demonstrate visible progress. Like Scrum teams, the ETC holds sprint planning, review, and retrospective meetings to assess progress and refine their approach.

The Role of the Sponsor and Product Owner

A critical element of successful Scrum adoption is a committed sponsor—typically a senior executive—who champions the transition and ensures its success. At Salesforce.com, for example, cofounder Parker Harris served as the sponsor for the company’s large-scale Scrum adoption. The sponsor acts as the product owner for the ETC, guiding the team’s work and ensuring alignment with the organization’s goals.

A strong sponsor’s involvement is vital for maintaining momentum and overcoming resistance. As the chapter notes, a sponsor’s passive support—such as providing resources but not actively engaging—can hinder the transition. Active engagement and visible commitment are essential for keeping the organization on track.

Improvement Communities (ICs)

The chapter also introduces the idea of improvement communities (ICs), which are grassroots groups of employees focused on specific areas of improvement within Scrum. These communities form naturally when individuals identify areas that need attention, such as improving automated testing or refining the role of the product owner. ICs allow employees to take ownership of improvements and drive change within their areas of expertise.

ICs operate in sprints just like Scrum teams, and they are responsible for determining their own goals, prioritizing work, and achieving measurable outcomes. By focusing on practical and relevant goals, ICs contribute directly to the organization’s broader Scrum adoption effort.

Google’s “grouplets” (improvement communities) are a great example of how these communities can drive change. For instance, Google’s Testing Grouplet focused on improving developer testing, and over time, it became an influential group that helped drive significant improvements across the company.

Creating the Right Environment for Improvement Communities

For improvement communities to thrive, the ETC must foster an environment where they can form and evolve organically. The key is creating a culture where employees feel empowered to contribute to Scrum adoption and improvement efforts. This is where the concept of “communityship” comes in—a form of leadership that encourages self-organization and initiative among team members.

The ETC’s role is not to dictate the work of the improvement communities, but to provide support, resources, and guidance. They also help resolve obstacles and ensure alignment with the organization’s broader goals.

Disbanding Communities

Eventually, improvement communities may disband once their goals have been achieved. For example, a community focused on improving automated testing may dissolve once the organization becomes proficient in that area. However, the knowledge and improvements made by these communities remain valuable, and they can continue to influence the organization’s Scrum practices.

Conclusion: Iteration and Continuous Improvement

The chapter concludes by emphasizing that Scrum adoption is a continuous, iterative process. There is no “end state” to achieving agility; instead, it’s about ongoing improvement. The ETC and improvement communities play crucial roles in fostering a culture of continuous change, helping the organization become more agile over time.

Chapter 5 – Your First Projects

The Importance of Choosing the Right First Project

Starting with your first Scrum project can feel like stepping into a high-stakes situation, with all eyes on it. The choice of the pilot project is crucial because it sets the tone for how Scrum will be perceived and adopted within the organization. The first project must be significant enough to show Scrum’s potential but manageable enough not to become overwhelming.

Mike Cohn emphasizes that this project must not be so large or complex that it overwhelms the team, but it should also be substantial enough to demonstrate that Scrum can lead to real benefits. This balance is key because selecting the wrong type of project can either make Scrum seem ineffective or make it impossible to manage the transition successfully.

The Two Meanings of “Pilot Project”

The chapter explains two definitions of “pilot project.” The first is a test, conducted to see if Scrum works in a specific context. However, because Scrum’s effectiveness is well-established by now, the author is more focused on the second meaning: a pilot project that guides the organization in how to make Scrum work for them. The aim is to learn how to implement Scrum effectively rather than testing whether Scrum works at all.

Selecting the Ideal Pilot Project

Choosing the right pilot project requires balancing four critical attributes:

1. Size: The project should be large enough to be meaningful but small enough to be manageable. Starting with one Scrum team is often ideal.
2. Duration: A project that lasts around three to four months is optimal. This gives the team enough time to adjust to Scrum and see results, but it’s not so long that the project feels like a major gamble.
3. Importance: It’s tempting to choose a low-risk, low-importance project to minimize potential failure. However, Cohn advises against this. Choosing a project that’s too small won’t garner the attention and support needed for Scrum’s success. It’s better to pick an important project that can drive meaningful change.
4. Business Sponsorship: A strong, engaged business sponsor is essential for the success of the project. This sponsor helps guide the team and ensures that the business side is aligned with Scrum’s goals.

Choosing the Right Time to Start

The chapter also discusses the timing of when to begin the Scrum pilot project. While it might seem logical to start a new project with Scrum, Cohn warns against waiting for the “perfect” project to come along. A better approach is to start as soon as you identify a suitable opportunity, even if it means adopting Scrum in the middle of a current project.

Another interesting suggestion is resurrecting a failing project. Cohn highlights that sometimes Scrum can save projects that are already heading toward failure. By introducing Scrum, teams can regain focus and deliver results that were otherwise unlikely.

Selecting the Pilot Team

The team is perhaps the most crucial aspect of a successful Scrum pilot. While selecting the right project is important, the team’s makeup is what will ultimately determine the project’s success. Cohn advises selecting individuals based on several key traits:

• Willingness to Try Something New: This is the most important factor. Team members must be open to learning and adapting to Scrum’s new ways of working.
• Compatibility: The team members should have complementary skills, a good balance of personalities, and the ability to work collaboratively.
• Skeptics and Optimists: Including a mix of optimistic team members, Scrum advocates, and even fair skeptics can create a healthy balance of enthusiasm and critical thinking.

What If the Pilot Fails?

Even with the best planning and execution, the pilot project may not meet all expectations. In this case, Cohn recommends not to panic. The goal of the pilot is to learn how Scrum works within the organization, and even a failed project can provide valuable insights. The key is to manage expectations from the outset, acknowledging that the pilot is an experiment and that failure can be part of the learning process.

If the pilot falls short of expectations, it’s important to assess whether those expectations were realistic in the first place. Often, the failure lies in the unrealistic optimism placed on the project. Clear, honest communication with stakeholders about the lessons learned is essential to keep momentum going.

Setting and Managing Expectations

Setting realistic expectations is one of the most important things you can do when adopting Scrum. Cohn shares his experience from a project where expectations were set too high, leading to frustration when the team couldn’t meet them. He emphasizes four key areas to manage expectations:

1. Progress: Be realistic about how quickly teams will become productive. Most teams will initially slow down as they learn Scrum.
2. Predictability: Early on, Scrum teams will be less predictable than teams using traditional methods. Velocity, a key Scrum metric, is often volatile in the beginning.
3. Attitudes Toward Scrum: Expect initial resistance. Many developers will complain about the daily scrums, the focus on testing, or the lack of individual assessments. Be prepared to handle these objections and ensure teams remain committed to the process.
4. Involvement: Scrum requires constant involvement from all stakeholders, particularly the product owner. Make sure everyone understands their role and commitment to the process.

It’s Just a Pilot

Lastly, Cohn reminds readers that a pilot is not a definitive test of Scrum—it’s a learning experience. Just like a scientific experiment, a pilot project helps organizations figure out what works and what doesn’t. Even if things don’t go perfectly, the insights gained from the first project will pave the way for future success.

Chapter 6 – Overcoming Resistance

Understanding Resistance to Scrum

In this chapter, Mike Cohn dives into the challenge of overcoming resistance to Scrum adoption. Resistance to change is inevitable in most organizations, especially when transitioning to something as significant as Scrum. The chapter outlines the main reasons people resist change, how to anticipate and address it, and how to manage different types of resistors within the organization.

Cohn starts by referencing a 1969 article by Paul Lawrence that explains the dual nature of resistance: the technical aspect (the actual change in processes and routines) and the social aspect (how the change affects relationships within the organization). He argues that the social aspect—the fear of how change will impact individual roles and relationships—is often what leads to resistance. This chapter focuses on how to address individual resistance to Scrum, which is where the challenge lies.

Anticipating Resistance

It’s important to anticipate resistance rather than be surprised by it. People resist change for various reasons—fear of the unknown, loss of control, and job insecurity, among others. Cohn points out that some individuals, like managers, resist change out of fear of losing authority, while others, such as employees, resist because they feel it threatens their job security or disrupts their comfort zone.

The key to overcoming resistance is understanding where it will come from. Cohn suggests considering:

• Who stands to lose something if Scrum succeeds?
• What coalitions are likely to form in opposition to Scrum?

This analysis helps identify where initial efforts to reduce resistance should be focused. He also introduces the concept of three types of individuals with respect to change:

• Conservers: They resist because they prefer predictability and stability.
• Pragmatists: More flexible, but need concrete results before they fully embrace the change.
• Originators: Enthusiastic about challenging the status quo and embracing new ways.

Conservers are the most likely to resist Scrum, as it requires changes that go against their preference for routine and structure. Pragmatists are more likely to join if they see success, while originators will usually embrace the change readily.

Waterfallacies and Agile Phobias

The chapter identifies two common sources of resistance—waterfallacies and agile phobias:

• Waterfallacies are misconceptions formed from previous experiences with waterfall methods. For example, the belief that Scrum doesn’t involve planning or that it requires everyone to be a generalist.
• Agile phobias are emotional fears about agile methods, such as concerns about job security, conflict, or not having a clear set of instructions.

While waterfallacies can be countered with rational arguments, agile phobias often require a more empathetic approach, acknowledging the emotional nature of these fears and addressing them accordingly.

Communicating About the Change

Cohn emphasizes that effective communication is crucial to overcoming resistance. Employees need to understand why the change is happening, how it will affect them, and what benefits it will bring. He explains that different messages should be delivered by different messengers:

• Leaders are best for explaining the reasons for the change.
• Managers are key for explaining the personal impact on individuals.
• Peers are often the most effective messengers, as people tend to trust and relate more to their colleagues than to higher-ups.

The chapter stresses the importance of listening. A successful change agent not only communicates the reasons for Scrum but also listens carefully to the concerns of resistant individuals. This active listening can uncover deeper reasons for resistance, allowing you to address them effectively.

Types of Resistors

Cohn classifies resistors into four types based on their reasons for resistance and the ways in which they resist:

1. Skeptics: They question the value of Scrum but resist passively. They often need more exposure to Scrum’s benefits and success stories.
2. Saboteurs: These individuals actively work against Scrum, undermining the change effort. They can be combated through visible success, reinforcement of commitment, or even being moved to a different team.
3. Diehards: They resist Scrum because they are deeply tied to the current status quo. Addressing their resistance requires aligning incentives and creating dissatisfaction with the current state.
4. Followers: These individuals are passive resisters who hope that the change will go away. They can often be persuaded by involving them in the process and modeling the right behaviors.

Resistance as a Useful Red Flag

Cohn closes by reframing resistance as a useful signal—rather than something to be overcome. Resistance can be seen as a red flag, indicating that something is not working as expected. The goal is not to ignore or suppress resistance but to understand it, learn from it, and use it to improve the adoption process.

By identifying and addressing the root causes of resistance, organizations can move beyond the obstacles and gain full buy-in for Scrum. The chapter emphasizes that overcoming resistance requires time, patience, and empathy.

Chapter 7 – New Roles

Understanding the New Roles in Scrum

Chapter 7 dives into the key roles in Scrum—ScrumMaster and Product Owner—which are crucial for any team transitioning to Scrum. These roles might seem unfamiliar to those coming from traditional project management, and organizations often face confusion about who should fill them. The chapter breaks down these roles, outlining their responsibilities, necessary attributes, and common challenges.

The Role of the ScrumMaster

The ScrumMaster serves as a servant-leader to the Scrum team, focused on ensuring the team is able to use Scrum effectively. Unlike traditional managers, ScrumMasters do not have authority over team members but possess authority over the process. They ensure that the team adheres to Scrum practices and removes any impediments that hinder progress.

The ScrumMaster’s role can be likened to a personal trainer, offering guidance and helping the team perform at its best. The authority of the ScrumMaster lies in maintaining the Scrum process, not in controlling team behavior. They help the team stay focused on delivering high-quality work without making decisions on behalf of the team.

Attributes of a Good ScrumMaster

Cohn identifies six key attributes for an effective ScrumMaster:

• Responsible: A ScrumMaster is responsible for ensuring the team uses Scrum effectively but not for the project’s success.
• Humble: They should put the team’s needs ahead of their own ego.
• Collaborative: Ensuring collaboration is at the heart of the team’s work, resolving conflicts, and fostering an open environment.
• Committed: A ScrumMaster must be fully committed to helping the team, consistently addressing obstacles.
• Influential: They need the ability to influence others and drive change without formal authority.
• Knowledgeable: A good ScrumMaster should understand Scrum and have a sufficient grasp of the technical aspects of the project to provide effective guidance.

Tech Leads as ScrumMasters

While tech leads may have strong technical knowledge, they are not automatically suited to be ScrumMasters. ScrumMasters need to be facilitators and not decision-makers. In fact, tech leads with a history of making decisions can struggle with the ScrumMaster’s role, which requires a more hands-off, servant-leader approach.

Internal vs. External ScrumMasters

The chapter discusses whether it’s better to have internal or external ScrumMasters. While external consultants can provide valuable expertise during the initial transition, it’s essential for ScrumMasters to be part of the organization long-term. Organizations should work toward developing their own internal ScrumMasters to sustain Scrum practices.

Rotating the ScrumMaster Role

Some teams consider rotating the ScrumMaster role among team members, but Cohn advises against this for long-term success. While rotating may help team members understand the role, it often leads to inconsistent leadership. A dedicated ScrumMaster is needed to ensure effective Scrum implementation.

The Product Owner

The Product Owner is responsible for defining and prioritizing the product backlog, ensuring the team works on the most valuable tasks. They provide the team with a clear vision and set boundaries that define the product’s goals and limitations. This role is critical in maintaining focus and ensuring the product meets business objectives.

The Product Owner is like a guide who steers the team toward the right goal, while the ScrumMaster helps them reach that goal effectively. Cohn emphasizes that the Product Owner’s role involves a balance between vision and constraints—ensuring the team is inspired but also has clear limitations to guide their work.

Responsibilities of the Product Owner

The Product Owner’s primary responsibilities are to:

• Provide Vision: They create and communicate a compelling vision for the product, ensuring the team remains focused on the end goal.
• Set Boundaries: While the vision is broad, the Product Owner must set practical limits, such as deadlines, performance criteria, and resource constraints.

Attributes of a Good Product Owner

Cohn identifies five key attributes for a successful Product Owner:

1. Available: The Product Owner must be accessible and responsive to the team’s needs.
2. Business-savvy: They must have a deep understanding of the market and the business to make informed decisions.
3. Communicative: Strong communication skills are essential for conveying the product vision and updates to various stakeholders.
4. Decisive: A good Product Owner makes quick, clear decisions to avoid delays.
5. Empowered: The Product Owner must have the authority to make decisions and be held accountable for them.

Combining the Roles of ScrumMaster and Product Owner

Although there are benefits to combining the ScrumMaster and Product Owner roles in some cases, the chapter stresses that this is generally not a good idea. The tension between the roles—where the ScrumMaster protects the team and the Product Owner pushes for more features—helps maintain balance. Combining the roles can lead to confusion and loss of focus, making it hard to protect the team while also driving product decisions.

Overcoming Common Problems in Role Assignment

One of the challenges organizations face is selecting the right people for the ScrumMaster and Product Owner roles. It’s important to address issues like inappropriate candidates or role confusion early on. If a Product Owner is unavailable or too focused on short-term goals, it can disrupt the team’s progress. The ScrumMaster should step in to help manage these situations, ensuring the roles are properly defined and respected.

The chapter concludes by emphasizing that these roles, although new to many organizations, are crucial for a high-performing Scrum team. The responsibilities of the ScrumMaster and Product Owner are not new—they’ve just been formalized within the Scrum framework.

Chapter 8 – Changed Roles

Adapting to New Responsibilities in Scrum

In Chapter 8, Mike Cohn explores how the traditional roles within teams need to evolve when transitioning to Scrum. The Scrum framework encourages self-organizing teams, which means that many of the established roles and responsibilities will need to be redefined or even eliminated entirely. This chapter outlines how various roles within a traditional software development team, such as analysts, project managers, architects, and testers, are impacted by the shift to Scrum.

The Shift for Analysts

In traditional projects, analysts were responsible for creating detailed specifications for the team to follow. However, in Scrum, the role of an analyst changes significantly. Instead of working far ahead of the team, analysts now work in a more just-in-time manner, staying slightly ahead of the team while providing useful information about features that are coming up in the current and near-term sprints.

One significant shift is that analysts are encouraged to move away from writing extensive documentation and instead focus on discussing requirements with the team. This change promotes better communication and collaboration, as analysts are more involved in team discussions rather than acting as intermediaries. Analysts are also expected to engage in testing and to help answer questions about features being developed.

Cohn highlights that analysts must become more comfortable with informal, verbal communication rather than relying on heavy documentation, which can lead to delays and misunderstandings.

Project Managers: A Role Reimagined

The chapter also discusses the fate of the project manager role in Scrum. Traditionally, project managers were responsible for overseeing everything from scope and cost to communication and risk management. In Scrum, many of these responsibilities are decentralized and distributed across the team.

The role of the project manager is typically eliminated, but the work that was once handled by the project manager still needs to be done. In Scrum, responsibility for task selection, scope management, and resource allocation shifts to the self-organizing team, with the ScrumMaster and product owner taking on some of the responsibilities.

Former project managers often transition into roles such as ScrumMaster or product owner, depending on their skills and interests. ScrumMasters, for example, take on the responsibility of removing impediments and ensuring the team’s focus. Meanwhile, project managers with strong customer or business knowledge may transition into the product owner role, where they can influence the product’s direction.

Architects in the Scrum World

Architects also undergo a significant shift when transitioning to Scrum. In traditional projects, architects often held significant decision-making power and were responsible for setting the technical direction. However, in Scrum, the focus is on collaboration and shared responsibility. Architects must adapt to a more advisory role, guiding the team without dictating technical solutions.

Cohn explains that architects who are still technically active and involved in coding will fit well into Scrum teams. However, non-coding architects who have moved away from hands-on work might struggle with the new role, as Scrum requires a more active involvement in the development process.

Functional Managers

Functional managers, such as those overseeing development or quality assurance, experience a shift in their role as well. While they retain responsibility for tasks like assigning team members and overseeing career development, they no longer control the day-to-day work of the Scrum team. Scrum emphasizes the self-organization of teams, and functional managers must adapt to supporting the teams rather than directing their work.

One important change for functional managers is that they are now expected to work in a more collaborative and bottom-up manner, offering guidance and coaching rather than giving orders. Their role involves ensuring that team members are continually developing and that standards across projects are met.

Programmers and Their Evolving Role

Programmers face significant changes in how they work within Scrum. On a Scrum team, programmers are expected to be generalists who can contribute to all aspects of the work, from programming to testing and even design. This change challenges programmers who are used to specializing in a single area, such as coding or testing.

Scrum encourages programmers to work closely with team members from other disciplines, such as testers and designers, and participate in more direct discussions with customers and users. This increased collaboration can be uncomfortable for programmers who are used to working in isolation, but it helps build a stronger, more unified team.

Database Administrators and the Agile Shift

Database administrators (DBAs) also face challenges when transitioning to Scrum. Traditional database design often involved significant up-front planning, which can be at odds with the incremental, iterative approach of Scrum. However, Scrum encourages DBAs to shift to an iterative, incremental approach to database design, where they collaborate closely with the product owner and development team to prioritize work and address architectural concerns.

This new approach requires DBAs to adapt their mindset from focusing on large, up-front analysis to working incrementally and iteratively with the development team.

Testers: Embracing Iteration

Testers also experience significant shifts in their roles within Scrum. In traditional projects, testers often waited for a completed product before starting their work. In Scrum, testing is an integral part of each sprint, with testers expected to collaborate closely with programmers and participate in discussions about user stories and features.

The shift to Scrum also encourages more emphasis on test automation, as the fast pace of Scrum makes it difficult to rely on manual testing alone. Testers need to embrace new tools and practices to support the team’s iterative work.

User Experience Designers in Scrum

User Experience Designers (UEDs) face challenges in Scrum, particularly when they are used to working ahead of the development team. In Scrum, UEDs must work in parallel with the development team, ensuring that designs are ready for upcoming sprints but not too far ahead of the team’s work.

The key change is that UEDs must focus on delivering user experience designs incrementally, collaborating closely with the team throughout the sprint rather than working ahead in isolation. Cohn emphasizes that UEDs must view themselves as part of the team, with the same goals and responsibilities as other team members.

Three Common Themes

The chapter concludes by reinforcing three common themes that apply to all roles in Scrum:

1. Work Incrementally: Strive to produce a potentially shippable product increment within each sprint.
2. Work Iteratively: Functionality can be revisited and refined in subsequent sprints.
3. Work Beyond Your Specialty: Team members must be willing to step outside their traditional roles to ensure the success of the team.

These themes highlight the collaborative, flexible, and iterative nature of Scrum, where everyone is expected to contribute to the team’s overall success, regardless of their specialty.

Chapter 9 – Technical Practices

The Need for Technical Excellence in Scrum

In Chapter 9, Mike Cohn focuses on the importance of technical practices in Scrum. He explains that while Scrum provides the structure and framework for team collaboration, high-performing Scrum teams also need to adopt specific technical practices to truly excel. Without these, even a well-organized Scrum team can only go so far. Teams that follow Scrum rituals, like sprint planning, daily scrums, and retrospectives, but lack solid technical practices, may still see improvements, but not the full potential of Scrum. For a team to achieve significant improvements, Cohn argues, technical excellence must also be a priority.

Scrum itself doesn’t prescribe specific technical practices, leaving the team to decide what works best for them. However, Cohn suggests that Scrum teams look into practices such as test-driven development (TDD), refactoring, collective ownership, continuous integration, and pair programming. These practices are popular in Extreme Programming (XP) and are considered crucial for teams that want to maximize their performance and product quality.

Test-Driven Development (TDD)

Test-Driven Development is a practice where programmers write tests before writing the code to pass them. This contrasts with traditional development where code is written first, followed by testing. The benefit of TDD is that it ensures no untested code ever makes it into the system. Additionally, it encourages a design-first mindset, where the structure of the code is driven by what needs to be tested.

Cohn emphasizes that TDD can initially feel slow because it requires writing tests before code. However, studies show that while it may take slightly longer, it ultimately leads to fewer bugs and better code quality. The key takeaway is that TDD forces developers to think carefully about their design upfront and helps catch issues early. Refactoring also ties into TDD, as it allows developers to clean up the code after it passes the tests, improving its structure over time.

Refactoring

Refactoring is the practice of improving the structure of existing code without changing its behavior. Cohn stresses the importance of refactoring to prevent “code rot,” which is the decline of the code’s quality over time as more and more changes are made. Without refactoring, systems often require a complete rewrite. Refactoring helps avoid this by regularly cleaning up and improving the codebase.

A central concept Cohn mentions is the “Boy Scout Rule,” which is to “leave the campground cleaner than you found it.” In software terms, this means making small improvements to the code each time you touch it. This is a sustainable practice that avoids the need for large, disruptive refactoring efforts later on.

Collective Ownership

In a Scrum team, collective ownership refers to the idea that every team member feels responsible for all parts of the codebase. No one should claim ownership of a particular module, and every programmer should be able to work on any part of the system. This approach ensures that the team is cross-functional and that knowledge about the system is spread across multiple team members, preventing bottlenecks and over-reliance on specific individuals.

Cohn points out that collective ownership improves code quality because team members take more care in writing clean code. When everyone can see everyone else’s code, there’s an incentive to write high-quality code that won’t cause problems for others. He also encourages developers to work across different parts of the codebase to prevent “siloed” expertise, where one person becomes the only one who understands a specific module.

Continuous Integration

Continuous integration (CI) refers to the practice of integrating new code into the main codebase multiple times per day and running automated tests to ensure nothing breaks. Instead of waiting days or weeks to merge changes, Scrum teams using CI integrate frequently, reducing the risk of large, hard-to-find integration problems.

Cohn emphasizes the importance of automation in CI. He recommends using tools to automate the build and testing process, so developers are always aware of whether their changes work with the rest of the code. CI tools like Cruise Control can run tests automatically when code is checked in, providing immediate feedback to the team.

Pair Programming

Pair programming involves two developers working together at one computer to write code. One writes the code (the “driver”), while the other reviews the work and suggests improvements (the “navigator”). Pair programming offers benefits like improved code quality, better knowledge sharing, and faster problem-solving.

Cohn acknowledges that while pair programming can feel awkward at first and may seem inefficient, studies show it can actually lead to shorter project durations, higher quality, and fewer bugs. Pairing also facilitates knowledge transfer, which is particularly useful when onboarding new team members. Cohn encourages teams to use pair programming selectively, especially for complex tasks, while recognizing that it’s not always necessary for every piece of work.

Intentional Yet Emergent Design

In Scrum, design is both intentional and emergent. Scrum teams do not do big, up-front design but rather develop the system incrementally, responding to feedback and adapting as they go. This emergent design allows teams to adapt to changing requirements and refine their work over time.

Cohn discusses how product owners and technical teams should collaborate to prioritize product backlog items that address technical risks and uncertainties early on. By doing so, teams ensure that they can address potential problems before they become bigger issues.

Improving Technical Practices Is Not Optional

The chapter closes by reinforcing that these technical practices are not just nice-to-haves; they are essential for high-performing Scrum teams. While some practices may take time to adopt, the return on investment is significant, both in terms of quality and efficiency. By continuously improving their technical practices, Scrum teams can deliver high-quality products more efficiently and with fewer defects.

The chapter serves as a reminder that Scrum is not just about the framework; it’s also about adopting the technical practices that will enable teams to excel in their work.

Chapter 10 – Team Structure

Why Team Structure Matters

In this chapter, Mike Cohn emphasizes how a Scrum team’s structure plays a crucial role in its success. He refers to the well-known “Conway’s Law,” which suggests that the design of a system will reflect the structure of the team that produces it. Thus, organizing teams effectively is key to ensuring that the team produces quality, well-structured products. The decision on how to structure teams involves considering several factors, such as team size, communication channels, technical design, and the complexity of the product.

Cohn discusses how two critical factors impact team structure decisions: the importance of keeping teams small and ensuring that each team is oriented around delivering end-to-end functionality.

Small Teams Are More Effective

Cohn advocates for small teams, typically ranging from five to nine members. This size is optimal because small teams are more productive, face fewer coordination challenges, and foster better communication and cohesion. He mentions Amazon’s concept of “two-pizza teams,” which are teams small enough to be fed by two pizzas. This lighthearted yet practical approach shows that if a team requires more than two pizzas, it may be too large.

Large teams, although they may have more diverse skills, often face higher communication overhead, making them less efficient. Research shows that smaller teams experience less social loafing, are better at building trust, and spend less time coordinating efforts, leading to more productive work environments.

Why Small Teams Perform Better

Several advantages come with small teams:

1. Less Social Loafing: Team members feel more accountable and are less likely to slack off when the team is small.
2. Better Interaction: Small teams encourage more meaningful and constructive interactions, which is essential for collaboration and trust-building.
3. Efficiency: Coordination is quicker and more effective in smaller groups, making it easier to complete tasks.
4. Satisfaction: Small teams tend to be more satisfying for their members because contributions are more visible and valued.
5. Avoiding Over-Specialization: In larger teams, people tend to become overly specialized, leading to inefficiencies and wasted handoffs.

A study of teams of different sizes revealed that smaller teams (4–9 people) were not only more productive but also had higher engagement and rapport among team members.

Feature Teams vs. Component Teams

Cohn stresses the importance of organizing teams around features rather than components. Feature teams are responsible for delivering fully functional user-visible features, meaning they work across the different layers of the system (e.g., front-end, back-end, database). This approach minimizes waste from hand-offs, enhances communication, and ensures that teams focus on delivering real, usable functionality rather than abstract components.

On the other hand, component teams specialize in one area (e.g., UI, database, or services). While this structure may seem practical, it often leads to problems such as lack of end-to-end ownership, integration difficulties, and delayed delivery of features. Cohn recommends that feature teams be the default choice, with component teams used sparingly and only when necessary.

When to Use Component Teams

Despite the benefits of feature teams, Cohn acknowledges that there are situations where component teams may be appropriate. Component teams may be needed when a specialized technology is required that will be used by multiple feature teams. However, even then, it is crucial that the component teams deliver usable, shippable code at the end of each sprint. The key is to keep component teams small, focused, and closely aligned with the needs of the feature teams.

Choosing the Right People for the Team

The success of a Scrum team depends on having the right mix of people. Cohn explains that team members should be selected carefully, considering technical skills, domain knowledge, and personal dynamics. He emphasizes the importance of balancing experience levels within the team. While it may be tempting to fill a team with senior experts, a balance of skill levels ensures that less experienced members can learn from their peers while also contributing to the team’s success.

The chapter also touches on the idea of team persistence—keeping teams together for longer periods. This continuity allows team members to build stronger working relationships, better understand each other’s strengths, and improve overall team performance.

Multitasking Is a Productivity Killer

Cohn highlights how multitasking across multiple projects can severely reduce productivity. He references studies showing that individuals working on multiple projects perform worse than those focused on a single project. In Scrum, it’s critical that people are dedicated to one project at a time, which ensures that they can focus and complete tasks efficiently.

When individuals are stretched across multiple projects, their performance suffers, and communication becomes fragmented. Cohn suggests that the solution to this is to limit multitasking and to prioritize projects so that individuals can focus on one thing at a time.

Self-Organizing Teams Don’t Mean Randomness

Cohn ends the chapter by discussing the concept of self-organizing teams. Scrum encourages teams to organize themselves, but this doesn’t mean randomly assigning people to a project. It’s still important to carefully select team members based on the project’s needs and the skills required. Teams should be empowered to make decisions on how to organize themselves, but they need to have the right mix of expertise and experience to do so effectively.

Self-organization doesn’t mean chaos—it means allowing teams to own their processes and make decisions about how to achieve their goals while maintaining accountability.

1. Small teams (five to nine people) are more efficient and have better communication than large teams.
2. Feature teams that focus on end-to-end delivery of functionality are more effective than component teams.
3. Keep team members dedicated to one project at a time to avoid the productivity pitfalls of multitasking.
4. Select the right people with the necessary skills and balance experience levels for better collaboration.
5. A team structure should be iteratively refined, with input from the team and key decision-makers, to support Scrum’s principles.

Chapter 11 – Teamwork

The Power of Teamwork in Scrum

In Chapter 11, Mike Cohn emphasizes that teamwork is the foundation of Scrum. The Agile Manifesto highlights the importance of “individuals and interactions over processes and tools,” which is a principle Scrum heavily relies on. Scrum teams are expected to work together as a unit, much like a rugby team, where every individual contributes to moving the ball forward. This concept is crucial because Scrum teams are designed to succeed and fail together. There is no “my work” versus “your work”—everything belongs to the team.

Cohn explains that while many teams in traditional settings work in silos and focus only on their specific tasks, Scrum requires a shift to whole-team responsibility. For a Scrum team to truly perform at a high level, they must embrace collective ownership, collaboration, and continuous improvement.

Whole-Team Responsibility

One of the first steps toward building a high-functioning Scrum team is embracing whole-team responsibility. The entire team shares the responsibility for the success of the product, not just individual tasks. For example, while the Product Owner may be responsible for maintaining the product backlog, the whole team should feel responsible for making sure the backlog is well-formed and prioritized.

Cohn gives an example involving testers noticing recurring bugs in the application. Even though fixing the bugs may primarily be the programmer’s responsibility, the tester should feel empowered to share their observations with the team, not just passively wait for someone else to fix the issue. This sense of responsibility should extend to quality, clean code, and overall product development.

Cohn also discusses the misconception that “if everyone is responsible, then no one is responsible.” He counters this by using a sports analogy—on a team, no single individual can be blamed when things go wrong, but everyone feels accountable for the result, win or lose. Similarly, in Scrum, everyone on the team shares the blame or credit, reinforcing the idea that true teamwork requires mutual responsibility.

Whole-Team Commitment

Along with responsibility comes commitment. Cohn stresses that the team must commit to the sprint goals, not just to completing their individual tasks. The commitment is collective. If one person finishes their work early, they should help the rest of the team, especially if others are falling behind. This collective commitment is vital for completing the sprint’s product backlog items, and without it, the team might end up with many incomplete tasks at the end of the sprint.

Cohn gives an example of a programmer who completes their tasks but doesn’t contribute to the team’s overall sprint goals. This individual-focused approach fails because the team is meant to succeed or fail together. Achieving the sprint goals requires the entire team to work toward a shared objective, not just their assigned parts.

Rely on Specialists but Sparingly

A common myth is that Scrum teams should consist entirely of generalists, with everyone doing everything. Cohn challenges this idea, suggesting that while generalists play an essential role, specialists also bring valuable skills to the team. For instance, a Scrum team will need specialists for tasks like database management or complex algorithm design. However, it’s crucial that these specialists work alongside generalists who can help fill in the gaps.

The key takeaway is to balance specialists with generalists. Too many specialists can lead to bottlenecks when waiting for one person to finish their task before others can start. Cohn compares this to a sandwich shop where specialists (order takers and sandwich makers) work efficiently, but generalists (floaters) help keep the process smooth during busy times.

Do a Little Bit of Everything All the Time

Scrum requires teams to work collaboratively, where tasks are not handed off in large chunks like in traditional waterfall development. Instead, Scrum teams should work on a product backlog item across multiple disciplines simultaneously. This means that programmers, testers, analysts, and others collaborate early in the process, discussing, designing, and testing as they go along.

Cohn illustrates this with the example of a team working on a feature for an eCommerce application. Instead of passing a large feature from one group to the next (e.g., analysts to developers, then to testers), the team works together, tackling different parts of the task concurrently. This approach reduces delays and allows for quicker feedback and iteration, leading to smoother workflow through the sprint.

Don’t Wait Until the End of the Sprint to Finish Everything

Teams that still work in traditional hand-off models often find themselves scrambling to finish work at the end of the sprint. This happens when testers wait until programmers are done with coding before they begin their work. To combat this, Cohn suggests that teams should aim to have smaller chunks of work ready to test and review earlier in the sprint. The goal is to avoid the bottleneck that occurs when large portions of work are left to the end.

By charting the progress of product backlog items across the sprint, teams can visualize when tasks are getting delayed and identify the causes. This transparency helps the team to improve their workflow over time, ensuring that they finish tasks more consistently throughout the sprint rather than at the last minute.

Foster Team Learning

For Scrum teams to become truly high-performing, they need to foster a culture of continuous learning. Cohn argues that most teams plateau after they start functioning well together, but true agility comes from constantly improving processes, knowledge sharing, and personal growth. Effective teams are proactive in seeking learning opportunities and finding new ways to work better.

Cohn outlines five conditions necessary for team learning:

1. Teams must be designed for learning.
2. There must be concrete ways to share knowledge.
3. Leaders must actively reinforce learning.
4. Teams should face motivating challenges.
5. A supportive learning environment must be in place.

A key point is that learning should not be left to chance. High-performing teams create opportunities for learning, whether it’s through daily scrums, retrospectives, or informal knowledge-sharing sessions. Leaders also play an important role by encouraging the team to ask questions, reflect on their experiences, and model the behavior they want to see.

Eliminate Knowledge Waste

Cohn highlights the concept of “knowledge waste,” which occurs when opportunities to learn are lost, or when the knowledge gained is not captured or used effectively. Knowledge waste can occur due to poor communication, ineffective tools, or failure to document lessons learned.

By minimizing hand-offs and encouraging collaboration, teams can reduce knowledge waste. Cohn also mentions that companies should strive to capture valuable insights from the team’s experiences, such as bug fixes or best practices, to prevent recurring problems.

Encourage Collaboration Through Commitment

To keep teams energized and aligned with their shared goals, Cohn stresses the importance of renewing the team’s commitment regularly. This involves making sure everyone is motivated and understands the relevance of their work. Scrum teams should focus on building a sense of unity and shared purpose, rather than working in isolation.

Cohn suggests that teams should work together on all aspects of the product, share knowledge, and support each other in maintaining a high level of commitment throughout the project. Additionally, finding personal motivations and aligning them with the team’s goals can boost engagement and ensure everyone feels valued and relevant.

Key Takeaways

1. Whole-team responsibility means that everyone is accountable for the product and its quality.
2. Commit to whole-team commitment—it’s not about individual tasks but about collective sprint goals.
3. Specialists are valuable, but they should be balanced with generalists to avoid bottlenecks.
4. Scrum teams should engage in collaborative, concurrent work rather than waiting for hand-offs.
5. Learning must be a continuous, proactive pursuit within the team.
6. Reducing knowledge waste is key to improving team performance and preventing recurring issues.
7. To keep the team motivated, regularly reaffirm the team’s shared goals and individual contributions.

Chapter 12 – Leading a Self-Organizing Team

The Role of Leaders in Self-Organizing Teams

In this chapter, Mike Cohn explores how leaders, managers, and change agents can influence self-organizing teams in Scrum. One of the key misconceptions that Cohn addresses is the idea that because Scrum teams are self-organizing, they don’t need leadership. He argues that while Scrum teams are expected to self-organize, leaders still play a crucial role in guiding the evolution of teams and ensuring that they remain agile.

Cohn begins by discussing the importance of self-organization in Scrum. He clarifies that self-organization does not mean chaos or freedom without boundaries; it means that teams should organize themselves around challenges and within the constraints set by management. This requires leaders to provide the right environment where self-organization can thrive.

The Importance of Agitation in Leadership

Cohn introduces the concept of agitation, which refers to a leader’s responsibility to stir up the status quo in order to keep the organization agile and adaptable. This concept is inspired by Kurt Lewin’s model of change, which describes the process of “unfreezing” an organization, transitioning it to a new state, and “refreezing” it. However, Cohn argues that in today’s fast-paced world, organizations should not return to equilibrium. Instead, leaders must continuously agitate the system to keep it in a state of “far-from-equilibrium,” where it is more responsive to change.

By keeping the organization in this state, leaders ensure that the team is always ready for change and able to adjust quickly. Agitation can come in many forms: introducing new challenges, rearranging teams, or encouraging new ideas. The key is that leaders need to create an environment that supports continuous change rather than one that resists it.

The Role of Leadership and Change Agents

The chapter emphasizes that leadership is not just about having authority over team members. Instead, it is about influencing and guiding the team without direct control. Leaders, including ScrumMasters, Product Owners, and managers, must understand how to subtly shape the self-organizing behavior of teams through influence, rather than command.

One of the critical points Cohn makes is that leadership must be subtle. Self-organization doesn’t mean complete freedom or a lack of guidance. It means that leaders should set the stage and allow the team to organize itself, but they must do so within the right constraints. Overly strict control will stifle self-organization, but too little guidance can lead to chaos.

Three Key Conditions for Self-Organization

Cohn highlights three key factors that influence how a team self-organizes, drawing from the work of Glenda Eoyang: containers, differences, and exchanges. These factors help leaders understand how subtle changes in the environment can influence the team’s self-organizing behavior.

• Containers: These are boundaries within which the team organizes itself. Containers can be physical, such as the workspace, or conceptual, such as organizational departments or skill sets. Leaders can influence the structure of these containers to guide the team’s behavior.
• Differences: Teams need to have differences among their members in skills, experience, and perspectives. Cohn explains that without differences, teams might end up working in isolation and fail to collaborate effectively. Leaders can amplify or dampen these differences to improve team dynamics.
• Exchanges: These are interactions between team members that influence how they collaborate. Exchanges can include the sharing of information, energy, or resources. Leaders can influence how exchanges happen by changing the frequency or form of communication among team members.

Applying the CDE Model

The CDE model (Containers, Differences, and Exchanges) provides leaders with a framework to understand and influence how their teams self-organize. By adjusting these conditions, leaders can help teams move toward more effective self-organization. For example, if a team is overly dominated by one person, like Jeff in the example, a leader might change the team’s composition (container) or encourage more exchanges between team members to create a more balanced environment.

Cohn also discusses how leaders can influence these factors subtly. For example, by changing the team’s responsibilities, adjusting who is on the team, or introducing new communication patterns, leaders can nudge the team toward more effective self-organization.

Leading Organizational Evolution

The chapter concludes by discussing how leaders can guide the overall evolution of the organization. Cohn draws on the concept of evolution as it applies to organizations. Just as species evolve through variation, selection, and retention, organizations also evolve by adapting to environmental changes. Leaders influence this process by selecting the right people, defining performance, managing meaning, and energizing the system.

The goal of leadership is to keep the organization agile by fostering continuous evolution. Leaders must be proactive in guiding this process by creating an environment where the organization can evolve rapidly in response to external and internal changes.

Key Takeaways

1. Self-organization requires leadership: Leaders don’t need to control everything but must create the conditions that allow teams to self-organize effectively.
2. Agitate the system: Leaders should continuously stir up the status quo to keep the organization agile and responsive to change.
3. Use subtle control: Instead of rigid management, leaders should influence teams by adjusting containers, differences, and exchanges.
4. Evolution is key: Just like living organisms, organizations must evolve in response to their environment, and leaders play a crucial role in guiding this process.

This chapter reinforces the idea that leadership in Scrum is about influence, not control. By understanding the factors that affect self-organization, leaders can guide their teams toward greater agility and performance.

Chapter 13 – The Product Backlog

The Product Backlog in Scrum

In this chapter, Mike Cohn explains the concept of the Product Backlog, a central component in Scrum that evolves as the project progresses. Unlike traditional approaches, where everything is planned upfront, the Product Backlog is dynamic and continuously refined. It’s a prioritized list of features, functions, and improvements that the team will work on, with each item evolving as new information comes in.

The biggest question at the start of any project is, “What are we building?” While the initial product vision may be clear (like building a word processor), the specific details and features often emerge as the team progresses. Scrum bypasses the need for extensive upfront planning by focusing on a just-in-time approach to requirements gathering. This means that while high-level features are outlined early, the details are refined over time in the Product Backlog.

The Importance of Conversations Over Documentation

One of the central ideas in Scrum is to move away from detailed written requirements documents. Cohn emphasizes the need for conversations over documents, arguing that written specifications can be misleading. Written words, though they may seem precise, often lead to misunderstandings. For instance, Cohn shares a personal anecdote about a miscommunication when booking a hotel. The written words “the hotel is booked” led to confusion, as one person meant the room was secured, and the other thought the hotel itself was booked.

This miscommunication illustrates why relying on written documentation alone can be problematic. In contrast, conversations allow for more nuanced understanding and help ensure both parties are on the same page. Scrum encourages this kind of dialogue between team members, especially between the product owner and the development team, to ensure a clear, shared understanding of product features.

User Stories: Moving from Documentation to Discussion

Cohn advocates for using user stories to describe the product backlog items. A user story is a brief, simple description of a feature from the perspective of the user or customer, often following the format: “As a <type of user>, I want <some goal> so that <some reason>.”

User stories focus the conversation around the user’s needs, helping the team understand the goal of a feature rather than getting bogged down by detailed documentation. A user story isn’t meant to provide a comprehensive specification but to spark conversation. The key promise is that the development team will discuss the story with the product owner before starting work. This ensures that the feature is well-understood before being implemented.

Progressively Refining Requirements

Scrum embraces the idea of progressively refining requirements as the project evolves. Cohn argues that no matter how carefully you plan at the start, some requirements will inevitably emerge during the project. These emergent requirements can’t be fully anticipated, so it’s better to refine them gradually as the team builds the product.

The Product Backlog reflects this approach, starting with high-level features at the top (which are detailed enough for immediate work) and moving to broader, less-defined features further down. This is where the metaphor of the Product Backlog Iceberg comes in: the items at the top are small and well-understood, while those further down are larger and less detailed, representing features that are yet to be fully defined.

Grooming the Product Backlog

As the project progresses, the Product Backlog needs to be groomed regularly. This means the team revisits the backlog to ensure that it remains relevant and up-to-date. Grooming includes breaking down large user stories (epics) into smaller, more manageable stories, and making sure the top items in the backlog are well-understood and ready to be worked on in the upcoming sprints.

Cohn suggests that about 10% of each sprint’s effort should be spent on grooming the backlog. This is important because as features are developed and moved out of the backlog, the remaining items become more visible, and some may need additional refinement before they are worked on.

Key Attributes of a Good Product Backlog

Cohn introduces the DEEP acronym to summarize the key attributes of a well-managed Product Backlog:

• Detailed Appropriately: Items that will be worked on soon are understood in sufficient detail. Items further down the backlog are more general and refined as their time approaches.
• Estimated: The backlog isn’t just a list of features; it also includes estimates to help with planning.
• Emergent: The backlog is dynamic. As new information is gained, the backlog changes—items may be added, reprioritized, or removed.
• Prioritized: The backlog is ordered so that the most valuable features are worked on first, maximizing the product’s value.

Specification by Example

One powerful technique that Cohn emphasizes is specifying by example. Instead of writing long, detailed requirements documents, teams can use real-world examples to describe the desired behavior of the system. For example, in a system designed for automatic approval of time-off requests, the product owner could provide a set of test cases illustrating the expected behavior.

This approach allows developers, testers, and business stakeholders to collaborate on understanding the requirements. By working with examples, the team can spot inconsistencies and ensure they’re building the right thing. Furthermore, these examples can be turned into automated tests that verify the system’s behavior, ensuring that the application meets the requirements and remains consistent as it evolves.

Challenges with Documentation

While Cohn acknowledges that some documentation is necessary, especially for regulatory or compliance reasons, he stresses that over-documentation can be detrimental. Scrum doesn’t eliminate documentation entirely; instead, it shifts the focus to creating documentation only when it adds value. The goal is to avoid excessive upfront documentation and instead allow documentation to evolve alongside the product.

Cross-Functional Teams and Reduced Documentation Needs

Scrum teams are cross-functional, meaning that all team members, including developers and testers, work together from the start. This reduces the need for detailed specification documents because work isn’t handed off from one team to another. Instead, team members collaborate on defining and refining features together, with everyone contributing their expertise.

This collaborative approach leads to better communication and reduces the need for extensive documentation that traditionally served to pass information between isolated teams.

The Product Backlog is a central tool in Scrum, enabling teams to build products in an agile, flexible manner. By shifting from documents to discussions, progressively refining requirements, and using user stories, teams can ensure that they stay aligned with user needs and respond quickly to changes. Cohn’s emphasis on collaboration and iterative refinement fosters an environment where teams can build better products faster.

Chapter 14 – Sprints

This chapter focuses on how Scrum’s sprints integrate both iterative and incremental development to deliver working software and valuable outcomes consistently. Scrum’s approach is a mix of building features incrementally and improving them iteratively. The author dives into why it’s essential for teams to finish each sprint with working software, how they can prepare for the next sprint, and why the entire team needs to work together throughout the sprint.

Incremental and Iterative Development

At the core of Scrum, we have incremental and iterative development. Incremental development means that the system is built piece by piece, while iterative development acknowledges that things won’t be perfect the first time, so features will be revisited and refined. The beauty of Scrum lies in combining both—each sprint builds incrementally on the product while simultaneously improving previous work through iterations.

Deliver Working Software Each Sprint

One of the key Scrum principles is to deliver working software at the end of every sprint. The importance of this is emphasized by the Agile Manifesto’s value of “working software over comprehensive documentation.” Working software helps in multiple ways: it enables real feedback from users, helps gauge team progress, and allows the product to be shipped early if needed. The challenge here is ensuring that each piece of software delivered is complete and potentially shippable—meaning it could be released at any time.

Defining Potentially Shippable

“Potentially shippable” means that by the end of each sprint, the software must meet certain quality standards, which include being fully tested and integrated. This doesn’t mean that the software is perfect, but it’s in a state that could be released to users. The author shares an example where a team worked on an online auction site, ensuring that each feature was fully functional and tested, even if it wasn’t entirely complete in terms of the entire product.

Deliver Something Valuable Each Sprint

In Scrum, it’s not just about working software; it’s about delivering value. Each sprint should result in something of real use to users or customers. Teams should focus on features that can provide immediate value, rather than doing things just for the sake of progress. For example, if a team is developing a search feature, they might prioritize a basic working version that can be improved over time. This ensures that even partial features have a tangible impact and users can provide feedback.

Prepare in This Sprint for the Next

Sprints need to be carefully planned, and teams should always allocate time to prepare for the next sprint. The author compares poorly planned sprints to “billiard ball sprints,” where one sprint pushes the next into the future. A better approach is to use about 10% of the sprint time for preparation—this prevents delays and ensures that teams are ready for the next sprint’s challenges.

Work Together Throughout the Sprint

A key point in Scrum is that all team members, regardless of their roles, need to work together. There should be no silos where only developers code, designers design, and testers test. Instead, Scrum promotes collaboration across functions. The author emphasizes that having teams work together in parallel, overlapping their tasks, results in faster development and fewer errors.

Keep Timeboxes Regular and Strict

Timeboxes are crucial in Scrum. Sprints need to have a fixed length to ensure teams maintain a regular cadence and can measure their progress consistently. Allowing sprints to vary in length can create uncertainty and make planning difficult. The author warns against extending sprints, as this breaks the rhythm and discipline that Scrum thrives on.

Don’t Change the Goal

The sprint goal is sacred in Scrum. Once a team commits to a goal at the beginning of a sprint, it should not change. This focus ensures that the team doesn’t get sidetracked by new, often unrelated, tasks during the sprint. The author shares that changing the sprint goal mid-sprint should only happen in exceptional circumstances, and it should be done transparently.

In summary, Chapter 14 emphasizes that Scrum’s strength lies in its iterative and incremental nature. By delivering working software every sprint, collaborating deeply, and maintaining strict timeboxes, Scrum teams create a process where feedback and progress flow seamlessly.

The key takeaway is that teams should maintain their focus on delivering something valuable in each sprint, while also preparing for the next sprint so that they can continue building effectively and efficiently.

Chapter 15 – Planning

In this chapter, Mike Cohn explores the often misunderstood role of planning in Agile and Scrum processes. Early in Agile’s evolution, the notion of avoiding planning was common. Teams would say things like “We’re agile, we don’t plan,” but the author argues that this was a reaction to the rigid planning methods of the past.

The truth is, planning is still an essential part of Scrum, but it should be handled differently than in traditional project management.

Planning Must Evolve Over Time

The key insight Cohn shares is that plans should evolve over time. Just like how the Product Backlog is progressively refined, planning must also be done incrementally. This way, the team can make the best decisions as they gather more knowledge. Initially, plans should focus on the overall goals and rough details, leaving specifics to be filled in as the team progresses. This allows the Scrum team to remain flexible while still having a roadmap to follow.

A great example Cohn gives is a team working on a genealogy product. Initially, they can specify that users will draw family trees and upload photos, but the exact technical details, like which file formats to support, can be refined later. This allows the team to keep moving forward while still accommodating the inevitable changes and refinements that occur during development.

The Danger of Overcommitting

Cohn explains that it’s easy to confuse estimates with commitments. Teams often make a detailed estimate of how long something will take, only for that estimate to become a binding commitment. The problem with this is that estimates are inherently uncertain, and when they are turned into firm commitments, the team is at risk of failing to meet them. Instead, estimates should be separated from commitments, allowing the team to remain flexible and adapt as new information arises.

The Myth of Overtime

One of the most compelling points in this chapter is Cohn’s argument against using overtime to fix schedule problems. Early in his career, he was convinced that working extra hours would help meet deadlines. But over time, he realized that overtime wasn’t sustainable. Instead of helping the team meet goals, it often led to burnout and decreased productivity. The idea of a “sustainable pace” is central here. Just as marathon runners pace themselves, Scrum teams should maintain a steady rhythm to stay productive over the long term. Excessive overtime may provide short-term gains, but it will eventually hinder the team’s performance.

Cohn shares an interesting story from the video game industry, where overtime initially boosted productivity but eventually led to diminishing returns. This serves as a warning about the long-term effects of pushing teams too hard.

The Iron Triangle: Scope, Schedule, and Resources

The author revisits the well-known concept of the “Iron Triangle” (scope, schedule, and resources), emphasizing that Scrum teams should focus on adjusting scope rather than the schedule or resources. Reducing scope allows the team to meet deadlines while maintaining quality. The challenge, however, is managing the business’s expectations when features need to be dropped. Cohn argues that if the team has been working in priority order, dropping lower-priority features is a viable solution.

Estimating and Committing

Finally, Cohn discusses the difference between estimating and committing. Estimates are based on available information, and while they are useful for understanding the likely scope and schedule, they should not be presented as commitments. Commitments should be based on realistic expectations, considering the team’s velocity and historical data. Using a range of estimated work, rather than committing to a single point, provides a more accurate and manageable commitment.

In summary, this chapter highlights that planning in Scrum is not only possible but essential. However, it should be done incrementally, allowing for flexibility and adaptation. Cohn emphasizes the importance of sustainable pace, managing scope changes, and separating estimates from commitments. These practices help ensure that Scrum teams remain effective, focused, and capable of delivering value even when the unexpected happens.

Chapter 16 – Quality

In this chapter, Mike Cohn discusses the crucial role of quality in Scrum and how it needs to be embedded into every step of the development process. Drawing from his own experience, Cohn emphasizes the importance of building quality into the product rather than treating testing as a step that happens at the end.

This chapter covers a range of practices from test automation to paying off technical debt and explains how quality becomes a shared responsibility for the entire Scrum team.

Integrate Testing into the Process

Cohn starts with an anecdote from his early career when he had to take responsibility for testing due to the lack of a dedicated tester. This experience highlighted the value of making quality everyone’s responsibility. The chapter stresses that testing should not be an afterthought but a continual process that starts early and happens throughout development, even during the sprint. This is in stark contrast to older methods where testing was left until the end. By building quality into the process, teams can spot issues early, saving time and resources in the long run.

He uses the example of car manufacturers introducing a tire pressure sensor to show how continuous testing can help catch problems early. Similarly, software development needs continuous testing throughout the cycle to ensure quality isn’t overlooked.

Why Testing at the End Doesn’t Work

Cohn explains several reasons why traditional testing—done at the end of development—fails to ensure quality:

• It’s difficult to improve quality of an existing product. Once a product is finished, it’s hard to go back and make quality improvements.
• Mistakes continue unnoticed. Problems are not identified until testing, meaning developers may be repeating the same mistakes without realizing it.
• The state of the project is hard to gauge. Without continuous testing, it’s difficult to know how far along a project really is or how much work remains.
• Feedback opportunities are lost. Waiting until the end to test means missing chances for feedback during the sprint.
• Testing is likely to be cut. With time pressure, the testing phase at the end is often reduced or dropped altogether.

The key takeaway here is that delaying testing until the end introduces risks and inefficiencies. By integrating testing into the process, Scrum teams can avoid these issues and maintain high quality throughout development.

What Building In Quality Looks Like

A Scrum team that integrates quality into every step of the process will look and behave differently than one that leaves testing until the end. Some characteristics of such a team include:

• Good engineering practices like pair programming, code inspections, and test-driven development (TDD).
• Automated unit testing and continuous integration, where the code is tested and integrated frequently.
• Minimal hand-offs between developers and testers, allowing both to work seamlessly and share responsibility for quality.
• Testing from day one of the sprint, not just at the end.

Cohn emphasizes that this approach makes the whole team more aware of quality and less likely to produce faulty code in the first place.

Automate at Different Levels

Cohn introduces the Test Automation Pyramid, which lays out a strategy for automating tests at three levels:

1. Unit tests: At the base of the pyramid, unit tests are the most frequent and crucial type of test. They test individual parts of the application and provide quick feedback for developers.
2. Service-level tests: The middle of the pyramid involves testing the services of the application separately from the user interface. This helps identify issues earlier without testing everything through the UI.
3. User interface tests: At the top of the pyramid, UI tests are the least frequent and most expensive to run. Cohn recommends minimizing UI tests due to their brittleness and slow execution.

By focusing on automating unit and service-level tests first, teams can create a more efficient and scalable test suite. User interface tests should be kept to a minimum, as they are often slow and fragile.

The Role of Manual Testing

While automation is crucial, manual testing still plays a role. Cohn argues that manual testing is best used for exploratory testing, where testers go through a product without predefined test cases to uncover new issues or gaps in functionality. Manual testing also helps identify missing test cases that can later be automated.

Automate Within the Sprint

Scrum teams should automate tests within the sprint, not afterward. Automating tests as soon as possible during development provides immediate feedback, helping the team catch bugs early and avoid accumulating technical debt. Cohn discusses how automating tests early has significant benefits, including reduced costs and more stable software. Teams should focus on automating tests as they develop features, rather than putting it off until later sprints.

Do Acceptance Test–Driven Development

Cohn introduces Acceptance Test–Driven Development (ATDD) as a way to ensure that the team stays aligned with the product owner’s expectations. In ATDD, the team writes acceptance tests throughout the sprint based on the product owner’s high-level conditions of satisfaction. These tests guide the development process and ensure that the features meet the product owner’s needs.

Pay Off Technical Debt

Finally, Cohn discusses technical debt, which refers to the cost of working with poorly written or unfinished code. He warns that accumulating too much technical debt—especially due to things like outdated tools or lack of automated tests—can slow down development and make the code harder to work with. Paying down this debt is crucial for maintaining long-term agility, and teams should make it a priority to gradually eliminate technical debt throughout the product’s life cycle.

In summary, quality is a team responsibility in Scrum, and it needs to be built into the process from the start, not tacked on at the end. Teams should automate tests at multiple levels, pay down technical debt, and use acceptance test–driven development to ensure they’re meeting product owner expectations. By integrating quality into every phase of development, Scrum teams can improve their productivity and deliver high-quality products consistently.

Chapter 17 – Scaling Scrum

Scaling adds complexity

The chapter begins with a simple metaphor: preparing Christmas dinner. For the author’s wife, cooking a big holiday meal brings more complexity than a regular weeknight dinner. That example sets the tone. Scaling Scrum isn’t just about doing more—it’s about managing added coordination, timing, and effort. When multiple teams are involved in a single product, things get harder. The big question this chapter tackles is: How can we scale Scrum effectively without losing its core benefits?

What it means to scale Scrum

The author explains that “scaling” can mean two things. First, there’s scaling up, where multiple teams work on the same product. Then there’s scaling out, where multiple Scrum teams work on different products. This chapter focuses on scaling up—because when teams need to collaborate on one shared product, the challenges grow fast. Coordination, alignment, and integration become crucial. And you can’t just copy what worked with one team and expect it to work with ten.

One Product, One Product Backlog

A key rule when scaling Scrum is that even with many teams, there must still be a single Product Backlog. This keeps everyone aligned to one product vision and shared priorities. If every team starts using their own backlog, the product direction becomes fragmented. It’s also important that there’s one Product Owner—not a committee or group—who owns the prioritization and vision. That person may get help from others, but ultimate responsibility stays with them.

Many teams, one Definition of Done

When teams work together on the same product, they must share a common Definition of Done. This ensures consistency across deliverables and avoids the mess of mismatched quality. If one team considers work done after coding and another only after full testing, integration will become a nightmare. The author points out that agreeing on this shared definition early is essential—it prevents confusion and rework later.

Scaling means more planning. Teams can’t work in isolation. So, multi-team planning meetings become necessary. These help align goals, clarify dependencies, and decide who works on what. Each team still holds their own Sprint Planning sessions, but those are informed by broader coordination meetings. Scrum of Scrums (a recurring theme throughout the book) plays a key role here—it’s the glue that keeps teams talking and collaborating regularly.

Coordinating work and integration

When you scale, you get more integration challenges. The chapter emphasizes frequent integration and testing. Teams should integrate their work often, ideally daily, so they spot problems early. Waiting until the end of the Sprint (or worse, longer) risks painful surprises. The book also encourages having cross-team retrospectives from time to time—not just individual team ones—so shared challenges can be discussed and solved together.

Challenges and practical advice

The author doesn’t pretend scaling is easy. It takes effort, discipline, and willingness to adapt. He suggests starting small—even if the product needs many teams, begin with one or two Scrum teams working well before scaling up. Also, avoid falling into the trap of creating artificial coordination roles (like “Scrum PMOs”) that go against Scrum’s principles. Instead, focus on strengthening team collaboration and clear communication.

The heart of Scrum must stay intact

This part is crucial. The author argues that when scaling, it’s easy to lose sight of what makes Scrum work: self-organization, iterative delivery, close feedback loops, and transparency. Just because you scale doesn’t mean you abandon these. If anything, they become more important. You can introduce new practices to help coordination, but the core values and structure of Scrum should remain.

Scaling Scrum is less about adding layers of control and more about reinforcing collaboration. It’s about aligning many teams under one vision, one Product Backlog, one Product Owner, and a shared Definition of Done.

The chapter makes it clear: successful scaling starts by deeply understanding Scrum and expanding it carefully, rather than layering on complexity. The bigger the effort, the more discipline is needed to stay true to the framework.

Chapter 18 – Distributed Teams

Why Distributed Teams Seem Tricky with Scrum

The author opens by challenging a common belief: that Scrum doesn’t work well with distributed teams. People argue that Scrum’s emphasis on face-to-face communication makes it unsuitable when teams are spread out across cities or continents. But that’s not true. While co-located teams often perform better, distributed teams can still succeed with Scrum—if they’re intentional about how they work together. Scrum can bring structure, visibility, and rhythm to help remote teams collaborate more effectively.

Two Models: Collaborating Collocated vs. Deliberately Distributed

When teams are split across locations, there are two ways to organize them. One is to create fully capable teams in each location (collaborating collocated). The other is to deliberately spread team members across locations (deliberately distributed). While the first option simplifies daily work and avoids global calls, the second one—though more challenging—helps prevent miscommunication, misunderstandings, and “us vs. them” dynamics. Deliberately mixing team members across sites builds better understanding and connection.

The Role of Connectors

To make distributed teams work, it helps to have “connectors”—people who naturally bridge groups. These folks, who often have friends in both locations or past experience working across teams, act as informal glue holding the team together. They help build trust, navigate miscommunications, and keep relationships smooth.

Creating a Coherent Team

The heart of the chapter is about coherence—how to make distributed teams feel like one. That means “sticking together” across distances, cultures, and time zones.

• Cultural Awareness: Using research from Hofstede, the author highlights how teams vary in power distance, individualism, achievement orientation, uncertainty avoidance, and long-term thinking. For example, a U.S.–China team might need to work through differences in hierarchy, communication style, and expectations.
• Little Things Matter Too: Small cultural differences—like workweek schedules, dinner times, or holiday traditions—also affect collaboration. Teams that acknowledge and share these differences build empathy and connection. A short chat about a local holiday can go a long way.

Building a Shared Identity

Effective teams don’t just think of themselves as “the Bangalore group” or “the U.S. developers.” Instead, they identify as part of a unified team. Encouraging communities of practice and shared goals helps build this mindset.

• Shared Vision: A clear, well-communicated vision is essential. Without it, misunderstandings happen, and teams feel disconnected. Product owners play a key role in bringing everyone together around a common purpose.
• Team Agreements: Distributed teams benefit from explicit norms: when to reply to emails, what tools to use, expectations around availability, and so on. Clear, shared agreements reduce friction.
• Adapt Scrum, Don’t Just Copy It: Distributed teams shouldn’t blindly follow Scrum “by the book.” Instead, they should adapt the framework to fit their realities—time zones, communication barriers, etc.—and agree on how they’ll apply Scrum across locations.

Trust Comes from Progress

A powerful insight from this chapter is that trust isn’t built by icebreakers—it’s built by delivering value. When teams focus on making real progress from the start, trust grows naturally. People see each other’s capabilities and commitment through shared work. Social bonding can come later, once the foundation is built.

Face-to-Face Still Matters

Even in distributed settings, occasional in-person meetings can dramatically boost team cohesion. Whether it’s a full sprint together (seeding visit), quarterly planning, or ambassador visits, physical presence helps build empathy and trust. These meetings don’t just align the work—they also help team members understand each other as people.

Changing How We Communicate

Distributed teams must lean more on written communication: documentation, shared understanding, and clarity become even more important. A casual hallway chat now requires a thoughtful email or shared wiki. That said, communication doesn’t need to lose its human side. Casual check-ins, sharing local news, and even low-fidelity video calls (like holding up someone’s photo during a call) can keep things personal.

Adapting Meetings for Distribution

Meetings need to change too. The chapter gives detailed advice on how to handle sprint planning (long calls vs. two-part meetings), daily scrums (regional vs. written updates), and how to handle the challenges of time zones. The key is to be intentional, inclusive, and fair—sharing the pain of odd meeting hours and rotating schedules so no one team bears the burden alone.

Distributed teams aren’t just about managing work across locations—they’re about creating strong, trusting relationships across boundaries. The author’s message is clear: with the right structure, empathy, and focus on progress, distributed Scrum teams can work just as effectively—and sometimes even more creatively—than collocated ones.

Chapter 19 – Coexisting with Other Approaches

Scrum in the Real World

The chapter opens with a reality check. It’s one thing to talk about agile in theory, in a clean environment with no external constraints. But real-world organizations have to deal with things like certifications, governance requirements, and legacy processes. The truth is, most teams can’t just “go agile” overnight. There are existing rules, expectations, and processes—like CMMI certifications or stage-gate approvals—that Scrum teams must find ways to navigate.

Scrum Meets Waterfall

Mike Cohn explores three common ways Scrum and sequential development (like waterfall) intersect in organizations that are still transitioning.

• Waterfall-up-front happens when a Scrum project needs to produce upfront documentation or pass an architecture review before it can start. Teams might write a “barely sufficient” spec just to meet the approval requirements. Interestingly, this exercise can help align the team around a shared product vision—even if they never look at the document again.
• Waterfall-at-end shows up when testing or final verification is still done by a separate team or department, usually after the main development work is complete. In these cases, Scrum teams dedicate one or more sprints at the end to fulfill these requirements while still using Scrum practices like daily standups and sprint reviews.
• Waterfall-in-tandem is the trickiest. It happens when Scrum teams must collaborate with other teams still using sequential processes. This creates tension: Scrum teams prefer evolving designs and informal communication, while traditional teams want fixed plans and formal documents. Cohn shares a real example where skeptical managers were invited to Scrum planning meetings—and eventually became fans of the shared visibility and coordination.

Types of Conflict

Barry Boehm and Richard Turner identify three types of conflict that arise when Scrum and traditional approaches coexist:

• Development process conflicts: Different expectations about documentation, planning, and interface definition.
• Business process conflicts: Differences in how teams engage with stakeholders and how they handle approvals and plans.
• People conflicts: Changes in roles and power dynamics, especially around self-organization and team decision-making.

Ways to Make It Work

To survive this mix of agile and traditional, Cohn shares several practical strategies:

• Do more upfront analysis than Scrum usually requires to ease coordination with waterfall teams.
• Start with nothing and build just enough process—rather than stripping down a heavyweight one.
• Partition the system architecture so that stable, well-known areas go to traditional teams, while Scrum handles the uncertain or fast-changing parts.
• Apply agile practices that work everywhere, like continuous integration, automated testing, and refactoring.
• Educate stakeholders who interact with both types of teams, so they understand the different approaches and expectations.

Can Scrum and Traditional Approaches Coexist Forever?

Opinions differ. Some say yes, others (like Michele Sliger) believe that eventually, companies must choose a path. She describes a concept called “high-centering”—when an organization is stuck halfway up the agile mountain, unable to move forward or back. Cohn agrees that coexistence is often a transitional phase. The deeper a company goes into Scrum, the more the pain of dual approaches increases—until a decision becomes unavoidable.

Dealing with Governance

Many companies adopt sequential processes because they align easily with governance models like the stage-gate process. These models impose checkpoints to prevent projects from going off-track. But Scrum works iteratively and doesn’t fit neatly into predefined gates.

Cohn argues that governance isn’t the enemy, but it should be separated from day-to-day project management. The goal is to provide visibility and oversight without dictating how teams do their work.

To make it work:

• Negotiate expectations early. Let governance committees know what to expect from Scrum teams, and propose experimental adaptations.
• Fit reporting to what’s expected. If they want Gantt charts, give them—but also start including burn-down charts or automated test metrics.
• Invite governance folks into the process. Having them attend sprint reviews or daily scrums can build trust and reduce friction.
• Highlight successes. Use early wins to show that agile projects can meet governance needs without losing their agility.

Handling Compliance (e.g., ISO, CMMI)

Compliance is a big concern for many companies—especially in regulated industries or large enterprises. Cohn walks through how Scrum can coexist with common standards like ISO 9001 and CMMI.

• With ISO 9001, the focus is on having and following a defined process—not necessarily what that process is. Teams have successfully passed audits by documenting their practices (even photocopying index cards!), taking whiteboard photos for design docs, and creating lightweight quality systems.
• With CMMI, the trick is realizing that it tells you what to do, not how. That means agile methods like XP or Scrum can fulfill CMMI goals—just in a different way. Several real-world cases show Scrum teams operating at CMMI Level 3 or even Level 5.

Tips for Scrum Teams with Compliance Requirements

Cohn wraps up with a list of practical advice for handling compliance:

• Put effort into a clear, evolving product backlog.
• Include compliance-related tasks in the backlog.
• Use checklists based on your Definition of Done.
• Automate everything possible, especially builds and tests.
• Use agile project management tools when traceability is needed.
• Change compliance systems gradually—one improvement at a time.
• Meet your auditor early to clarify expectations.
• Bring in outside help if needed, especially for your first certification.

Scrum rarely exists in a vacuum. Teams will almost always have to interact with traditional processes, governance systems, or compliance standards. But rather than fighting them, this chapter shows that Scrum can adapt—without compromising its core principles. With creativity, openness, and some smart compromises, Scrum teams can coexist with other approaches and still thrive.

Chapter 20 – Human Resources, Facilities, and the PMO

The Need for Broader Change

Scrum often starts in development teams, but if the rest of the organization doesn’t evolve along with it, those old structures and habits—what the author calls “organizational gravity”—can pull the transformation back down. This chapter dives into how key departments like Human Resources (HR), Facilities, and the Project Management Office (PMO) must adapt to support long-term agility. Ignoring these groups can stall or even reverse progress.

Human Resources: Rewarding Teams, Not Just Individuals

One major clash comes from how HR typically evaluates performance. Most traditional systems reward individual achievement—exactly the opposite of what Scrum encourages. Scrum thrives on teamwork and shared accountability, but when bonuses and promotions are based on individual heroics, the system breaks down. A vivid example is shared about Chuck, a developer who resisted pair programming because he feared it would blur individual contributions and lower his performance review score. His story shows how deeply ingrained individual-focused evaluations can disrupt agile progress.

Cohn recommends several practical changes: reduce individual metrics in reviews, include real teamwork indicators, and collect feedback from a broader group—ScrumMasters, peers, and even customers. Also, don’t just review performance once a year. Frequent feedback matters more in fast-moving Scrum environments.

Reporting Structures and Who Reports to Whom

There’s debate about whether team members should report to their ScrumMaster. While many say it can limit openness, especially during daily stand-ups, Cohn argues it’s not inherently bad if the right kind of leader is in place. However, he strongly advises against having the team report to the product owner, as this undermines the necessary tension between building fast and maintaining quality.

Career Paths Without the Ladder

With Scrum’s flatter hierarchy, traditional career ladders—where status grows with the number of direct reports—no longer make sense. People wonder, “How do I grow now?” Cohn proposes a shift: career growth comes through increased responsibility and influence, not just job titles. For example, a ScrumMaster might begin with one small team and, through proven results, eventually coach multiple teams or lead a community of practice. This mindset applies to developers, testers, and designers too.

Facilities: Your Office Setup Can Make or Break Agility

Workspace matters more than people often realize. Traditional cubicles can hinder collaboration, while open areas with flexible “caves and commons” setups foster spontaneous conversation and teamwork. The book highlights how some companies completely reconfigure their office layout to support Scrum, often removing cubicles and encouraging mobility. Even furniture plays a role—large desks for pair programming, big whiteboards, and physical task boards can all boost agility.

There are stories of teams taking matters into their own hands—rearranging furniture or “borrowing” wall space to hang up burndown charts. But long-term success usually depends on facilities teams and executives being on board. Without their support, even basic things like phone placement or desk arrangements can become frustrating obstacles.

Making the Work Visible

An agile workspace should visually communicate progress. This includes sprint burndown charts, task boards, big whiteboards, and visual indicators like lava lamps or traffic lights tied to the build status. The more feedback and transparency a workspace offers, the better the team performs. Even things like having access to a window or a quiet corner matter, showing that small details can support—or undermine—the team’s effectiveness.

The PMO: From Enforcer to Enabler

The PMO can either be a powerful ally or a stubborn blocker. Traditional PMOs often feel threatened by Scrum because it redistributes responsibilities among Scrum roles. But rather than becoming obsolete, PMOs can reinvent themselves by taking on new responsibilities in three key areas:

• People: Train and coach Scrum teams, support individual growth, and develop internal coaches.
• Projects: Help with reporting, compliance, and managing project inflow to avoid overwhelming teams.
• Process: Maintain tools, collect meaningful metrics, eliminate waste, and support consistency across teams.

Importantly, the PMO should stop enforcing rigid procedures and instead focus on enabling learning and agility. Cohn even suggests renaming the PMO (e.g., Scrum Office, Development Support) but warns that a name change without real change won’t help.

Scrum isn’t just a development thing. If HR continues to push individual rewards, if facilities block collaboration, and if the PMO sticks to old control patterns, agility stalls. But when these groups evolve alongside development, they become crucial partners. The lesson is simple but powerful: agility is a team sport across the whole company. If you want to succeed with Scrum in the long run, you can’t do it alone—you need everyone onboard.

Chapter 21 – Seeing How Far You’ve Come

Why Measurement Matters

At some point in every Scrum journey, someone inevitably asks, “How are we doing?” And while it may sound like a simple question, the answer is anything but. The author makes it clear: there’s no such thing as being “Scrum level three.” Measuring progress in agile isn’t about chasing certifications or ticking boxes—it’s about reducing uncertainty and knowing whether the effort to adopt Scrum is paying off.

The real reason we measure is not to find a perfect number, but to get just enough clarity to make decisions. Even an estimate, like the waitress showing soup sizes with her hands instead of ounces, can help you make the right choice. In agile, it’s the same. The goal isn’t perfection—it’s insight.

What Are We Trying to Learn?

Before collecting metrics, teams need to ask the right questions. Are we delivering better products? Are we faster than before? Are there fewer defects? Is Scrum helping us or not? These kinds of questions guide which metrics we should care about—and not all of them need exact answers.

General Agility Assessments

There are several ways teams have tried to measure “how agile” they are, using proxy metrics. These help teams spot trends and improvements before more concrete business results (like revenue) show up. The chapter explores three widely used methods.

Shodan Adherence Survey

Created by Bill Krebs, the Shodan Adherence Survey includes 15 questions covering core agile practices. Each question includes multiple behaviors and is scored from 0 to 10. While the score gives a general view of how closely the team is following agile practices, it’s not directly actionable. For instance, if a team scores low on a question about customer acceptance tests, you won’t immediately know which specific behavior is missing. Still, the survey is valuable for spotting long-term trends and encouraging reflection. Cohn recommends doing it no more than once every three months to avoid survey fatigue.

Agile Evaluation Framework (Agile:EF)

Also developed by Krebs (with Per Kroll), Agile:EF is a lighter, more flexible alternative to Shodan. It encourages brief surveys at the end of each sprint using short, focused questions about agile practices, each rated from 1 to 10. Although Agile:EF doesn’t come with a fixed set of questions, teams can repurpose Shodan items or make their own. Cohn suggests rotating question sets to avoid repetitive answers and to give teams time to act on feedback before reassessing.

Comparative Agility

This one was co-created by Mike Cohn and Kenny Rubin in response to clients asking, “How do we compare to others?” Unlike Shodan or Agile:EF, Comparative Agility (CA) benchmarks your team against others in a shared database, allowing comparisons by industry, company size, or time since Scrum adoption. It evaluates seven dimensions: teamwork, requirements, planning, technical practices, quality, culture, and knowledge creation.

What makes CA stand out is its actionable insight. For example, if your team scores low on quality, you can drill down to see whether the issue is with testing, acceptance criteria, or timing. While the CA survey is extensive (around 125 questions), teams can take it once or twice a year or focus on just one dimension at a time.

Creating Your Own Assessment

Some companies go a step further and build custom surveys tailored to their goals. The benefit is full control over what you measure—but it takes more effort. Organizations like Yahoo! and Salesforce.com asked their teams how Scrum affected productivity, morale, quality, collaboration, and ownership. They kept it simple but meaningful, often asking team members to rate statements like “Scrum has improved our product quality” on a 5-point scale.

A Balanced Scorecard for Scrum Teams

The most powerful part of this chapter is the introduction of a balanced scorecard for Scrum teams. Inspired by Robert Kaplan and David Norton’s original business concept, Cohn adapts it for agile teams using four perspectives from Liz Barnett at Forrester:

• Operational Excellence – Are we productive, predictable, and high quality?
• User Orientation – Are we delivering features users really want?
• Business Value – Are we providing tangible value like revenue or savings?
• Future Orientation – Are we investing in learning and long-term capability?

Each perspective should have strategic goals, with leading indicators (things that signal future improvement) and lagging indicators (things that prove the goal was achieved). For example, more passing tests (a leading indicator) may lead to fewer defects (a lagging indicator).

Simple Metrics Matter

You don’t need fancy metrics to see real progress. Salesforce.com used basic ones—like features delivered per developer—and saw a 38% increase in a year. They also tracked “cumulative value delivered” over time, showing that Scrum helped them release more features more often. Even if the numbers weren’t perfect, they told a clear story: things were getting better.

Cohn closes the chapter with a reminder: metrics matter, but not because of the numbers. They help fight the “organizational gravity” pulling teams back to old habits. Metrics also promote success stories and help identify where to improve. The caution is to avoid misusing them as weapons. Metrics should be a flashlight, not a hammer.

4 Key Ideas from Succeeding with Agile

6 Main Lessons from Succeeding with Agile

My Book Highlights & Quotes

“… Scrum teams are encouraged not to think in terms of my tasks and your tasks but of our tasks. This forces collaboration among team members to new highs. Working in this way also creates a mindset of shared responsibility that will be new to many team members…”

“… Quality is improved because working at a sustainable pace prevents sloppiness. Quality is also improved through many of the engineering practices such as pair programming, refactoring, and a strong emphasis on early and automated testing…”

“… Like sirens singing to us from the rocks, best practices tempt us to relax and stop the effort of continuous improvement that is essential to Scrum…”

“… The “if it ain’t broke, don’t fix it” mentality is about as far as can be from an agile “if it ain’t perfect (and it never will be), keep improving” mindset…”

“… Having a chance to change or personalize a process to fit themselves seems to be a critical success factor for a team to adopt a process. It’s the act of creation that seems to bind teams to ‘their own’ process…”

“… Think about your current transition to Scrum. Are you just getting started, in the middle, or feeling like you’re nearing the end of the transition push? No matter where you are, identify the primary obstacle you think may be holding you back from the next level of success…”

“… Getting coworkers to commit to a Scrum transition effort rather than merely comply with it (perhaps waiting for it to blow over) is what we would like to achieve with a successful promotion…”

“… Most successful changes, and especially a change to an agile process like Scrum, must include elements of both top-down and bottom-up change…”

Conclusion

If agile has ever felt like more ceremony than substance, this book is the missing piece. It cuts through the noise and shows what real agility looks like—messy, human, but absolutely possible.

Whether you’re new to Scrum or knee-deep in transformation, Succeeding with Agile will leave you feeling wiser, clearer, and a little more hopeful.

Because it’s not just about frameworks. It’s about people learning to work better—together.

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 Agile Coaching Agile Transformation 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 #127: The Laws of Simplicity by John Maeda2025-04-04
• 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

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: