Book Notes #33: Practices for Scaling Lean and Agile Development by Craig Larman and Bas Vodde

Title: Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum
Author: Craig Larman and Bas Vodde
Year: 2010
Pages: 624

Most teams start small: one product, one team, one backlog. Everything’s smooth… until it isn’t.

Once you introduce multiple teams, departments, and locations, things get complicated fast.

Suddenly, you’re spending more time coordinating than creating, and the agile values you started with start fading into the background.

Practices for Scaling Lean and Agile Development is the book you need before that happens.

It doesn’t just offer techniques—it rewires how you think about scaling, structure, and simplicity. If you’ve ever felt like agility gets lost as organizations grow, this book gives you a way to bring it back—bigger, stronger, and more real.

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

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

3 Reasons to Read Practices for Scaling Lean and Agile Development

Book Overview

What if the way we’ve always handled large-scale software development is the very thing holding us back?

It’s a bold question, and it sits at the heart of Practices for Scaling Lean and Agile Development. This isn’t a book full of silver bullets or polished checklists.

Instead, it’s an invitation to rethink the assumptions we carry into big, complex product development.

Craig Larman and Bas Vodde don’t pretend the reality of distributed teams, offshore development, or legacy systems will disappear.

Instead, they ask: if this is our reality, how can we work better within it—and maybe even reshape it along the way?

At its core, the book doesn’t try to reinvent Scrum or wrap it in some shiny enterprise version. What the authors propose is deceptively simple: keep Scrum as it is, and scale it with thoughtfulness, not gimmicks.

This approach is called LeSS—Large-Scale Scrum—and it stays grounded in the belief that agility is about learning and adapting, not controlling and predicting.

What makes their perspective refreshing is the honesty. They don’t shy away from the messy parts.

Whether it’s the pain of integrating legacy code, the misunderstandings in offshore collaboration, or the discomfort of flattening organizational hierarchies, the authors face these head-on.

In fact, one of the strongest threads throughout the book is the idea that most dysfunctions in scaling aren’t technical—they’re cultural.

Teams get stuck not because they can’t code, but because their structures, incentives, and thinking patterns weren’t designed for collaboration.

Take, for example, how they talk about feature teams. Instead of splitting teams by components (which leads to silos, handovers, and coordination nightmares), Larman and Vodde suggest building long-lived, cross-functional teams that can deliver customer-facing features from start to finish.

This sounds simple, but implementing it in a traditional organization is like turning a cruise ship—it takes time, intention, and often a complete rethink of how work is organized.

And then there’s the test chapter, which is more than a checklist of agile testing practices. It’s a candid look at how testing is often treated like a separate phase, handed off like a baton, when in fact it should be part of the rhythm of development.

The authors don’t just preach automation—they talk about tests as shared understanding, living documentation, and even requirements in executable form. It’s a shift that not only improves quality, but connects people.

One of the most compelling sections explores coordination. In traditional environments, we often throw people at the coordination problem—project managers, program managers, integration leads.

But the book suggests a more radical idea: reduce the need for coordination in the first place. Feature teams, shared code ownership, and continuous integration all serve this goal.

Less coordination doesn’t mean chaos—it means designing systems where teams don’t trip over each other every day.

The real magic of the book is how it threads agile principles with lean thinking.

Concepts like reducing batch size, shortening queues, and improving flow aren’t just thrown in—they’re lived through practical strategies.

You feel the Toyota influence, but applied in a way that makes sense for software.

And unlike many agile books that get lost in rituals, this one keeps returning to the why—why we plan, why we inspect, why we adapt.

Throughout, the authors stay grounded in real-world experience. You can tell they’ve been in the trenches—with large telecoms, banks, software firms, and everything in between. They know what breaks when you scale.

They know which meetings waste time, which roles dilute ownership, and which tools overcomplicate instead of simplify.

This book is their way of sharing what actually works—and warning about what usually doesn’t.

Some key concepts from the book include:

Large-Scale Scrum (LeSS): LeSS is Scrum applied to many teams working on the same product. It’s not a new version of Scrum, but the same framework extended to large-scale environments while keeping the core principles intact. The goal is to scale without losing the simplicity and effectiveness of Scrum, using practices that support transparency, inspection, and adaptation across many teams.

Feature Teams: Feature teams are long-lived, cross-functional, and cross-component teams that can deliver end-to-end customer features independently. They include all the necessary skills within the team to go from idea to working software. Unlike component teams, which focus on narrow technical areas, feature teams reduce the need for cross-team coordination and promote faster delivery of customer value.

Component Teams: Component teams are teams that focus on a specific part of the system, like the database or UI. While they may seem efficient for technical expertise, they often create handoffs, dependencies, and coordination problems. The book recommends moving away from component teams in favor of feature teams for better flow and customer focus.

Requirement Areas: In large products with many feature teams, the Product Backlog can be divided into Requirement Areas—logical groupings of features based on customer needs. Each Requirement Area has a dedicated Area Product Owner, making it easier to manage large backlogs while maintaining alignment and shared responsibility.

Product Owner: The Product Owner (PO) is responsible for the product vision, priorities, and return on investment. In LeSS, there is still one overall Product Owner for the product, even if there are many teams. The PO must be close to the customer, actively available to the teams, and empowered to make decisions.

Area Product Owner (APO): In Framework-2 of LeSS (for more than 8–10 teams), Area Product Owners manage the backlog for a specific Requirement Area. They collaborate with the overall Product Owner but focus on refining and prioritizing items within their area. APOs help scale product ownership while preserving clarity and alignment.

Product Backlog Item (PBI): PBIs represent work that delivers customer value. They should be small enough to be completed in a sprint and focused on delivering features, not technical tasks. PBIs are refined collaboratively by the team and Product Owner, and their clarity is critical for successful planning and execution.

Initial Product Backlog Refinement Workshop: Before starting large-scale Scrum, an initial multi-day workshop helps define the product vision, break down key features into PBIs, estimate effort, and assess risks. This shared start gives all teams a common understanding and sets the foundation for collaborative planning and delivery.

Sprint Review: The Sprint Review is a collaborative event where teams demonstrate the working product increment to stakeholders and gather feedback. It’s not a demo or status report, but a chance for real inspection and adaptation based on what was built during the sprint.

Sprint Retrospective: Retrospectives are used to reflect on how the team is working and to find ways to improve. In LeSS, teams have individual retrospectives, and then there’s a larger Overall Retrospective involving ScrumMasters and Product Owners to address systemic issues across all teams.

Definition of Done (DoD): The Definition of Done is a shared agreement on what it means for work to be considered complete. A robust DoD includes coding, testing, integration, documentation, and more. Expanding the DoD over time helps reduce undone work and leads to higher quality and more frequent releases.

Undone Work: Undone work is any task that needs to be completed after the sprint to make the product shippable. It could include integration, performance tuning, or manual testing. The goal in LeSS is to minimize or eliminate undone work by expanding the Definition of Done and improving team capabilities.

Continuous Integration (CI): CI means developers integrate code into a shared repository multiple times a day. It requires fast, automated builds and tests to detect problems early. In large-scale development, CI becomes even more critical to maintain stability and enable shared code ownership across teams.

Test Automation and Acceptance Test-Driven Development (ATDD): Automated tests are vital for enabling continuous integration and fast feedback. Acceptance Test-Driven Development involves writing tests before coding, based on business requirements. These tests serve as executable specifications, ensuring the system meets customer needs.

Legacy Code: Legacy code is code that is hard to change and lacks automated tests. The book explains how legacy code reduces agility and must be improved incrementally. Rather than rewriting everything, the authors encourage small, continuous improvements and automated testing to increase confidence and maintainability.

Improvement Experiments: Instead of blindly copying practices, teams should run small, safe-to-fail improvement experiments. Try something, inspect the outcome, and adapt. This approach keeps teams learning and evolving rather than relying on one-size-fits-all methods.

Scrum of Scrums: In large-scale Scrum, the Scrum of Scrums is a coordination meeting where representatives from different teams discuss dependencies and integration. It’s not a status update but a working session to surface and solve cross-team issues.

Communities of Practice (CoPs): CoPs are informal groups that cut across teams and focus on specific interests like testing, architecture, or UX. They allow sharing of knowledge and help standardize practices without enforcing top-down control. CoPs are crucial for learning and coherence in large organizations.

Requirement Workshops: These are collaborative sessions where teams and Product Owners clarify and refine backlog items. Workshops help uncover requirements through conversation and shared understanding, reducing the handoff problems of traditional requirements gathering.

Multisite Development: When teams are spread across locations, communication and coordination become more difficult. The book recommends minimizing the number of sites and organizing around co-located feature teams when possible. Synchronous communication (like video calls) is critical to preserving team cohesion.

Offshore Development: Offshore teams introduce added complexity due to time zones, culture, and communication barriers. The book encourages strong integration of offshore teams as real partners—not outsourcing factories—by fostering collaboration, frequent communication, and shared responsibility.

Coaching and Adoption: Agile adoption isn’t a project with an end date—it’s a continuous process. Successful change happens through voluntary experimentation, coaching, and leadership support. Organizations must resist top-down mandates and instead support teams in gradually improving through their own insights.

Impediments Backlog: Teams should maintain a list of systemic problems that block their progress. These impediments are prioritized and addressed with the support of management. Making impediments visible and tackling them is a key part of creating a culture of continuous improvement.

Contracts in Agile: Agile contracts must shift from fixed scope to flexible, trust-based agreements. Contracts should support iterative delivery, early termination, and frequent feedback, enabling both customer and supplier to respond to change. This avoids the pitfalls of rigid, plan-driven engagements.

Visual Management: Tools like boards, cards, and visible workflows help teams track progress, highlight bottlenecks, and stay aligned. In large-scale setups, visual management supports transparency across many teams and locations, making coordination and decision-making more effective.

Requirement Themes and Pruning the Backlog: Themes help organize backlog items by customer value, making it easier to plan releases and track goals. Regularly pruning the backlog—removing low-priority or outdated items—keeps the team focused and the backlog manageable.

System Thinking and Organizational Design: One of the deepest ideas in the book is that most problems in scaling aren’t technical—they’re structural. Agile won’t thrive in a system that’s still built for control and silos. Real change requires rethinking organizational design, incentives, team structures, and how decisions are made.

What makes this especially useful for practitioners is that it never pretends there’s a single “best practice.” Instead, it offers a mindset: experiment, learn, and adapt. Many of the practices are phrased as “Try…” or “Avoid…”—an invitation, not an order.

The idea is to think in principles, not prescriptions. Agile, after all, was never meant to be a fixed system. It was meant to evolve. And this book respects that spirit.

In a world where scaling agile often means adding layers and labels, Practices for Scaling Lean and Agile Development dares to suggest the opposite: simplify, streamline, and above all, stay true to what agility really means.

It’s not always an easy path. But as this book shows, it’s the one that leads to better teams, better systems, and better outcomes—not just at scale, but with soul.

Chapter by Chapter

Chapter 1 – Introduction

The Challenge of Big Development

The chapter opens with a striking story from the early days of large-scale software development—the SAGE system from the 1950s.

When asked what he’d do differently, a director of the project said he’d simply hire the ten best people and let them build everything. It sounds ideal, doesn’t it? Small teams, top talent, all in one place. But the reality for most organizations today is far messier.

They’re working with large, distributed, even offshore teams, not because it’s ideal, but because it’s often assumed to be necessary.

This book doesn’t try to fight that reality. Instead, it offers tools to help those teams get better.

The authors acknowledge that big setups won’t disappear overnight, so the goal is to improve how those teams operate—using agile and lean thinking to eventually realize they might be too big or too spread out.

The Role of Thinking and Structure

Before diving into practices, the authors stress the importance of mindset and organizational design. Practices alone won’t work if the ground they’re planted in isn’t ready.

Without an understanding of systems thinking, queueing theory, feature teams, or how incentives and budgeting affect behavior, teams might just mimic agile rituals without real benefit.

The authors call this “cargo cult” agile—going through the motions without understanding the meaning.

They’ve seen teams abandon agile completely when it doesn’t deliver, simply because it was applied without depth. But with real learning and thoughtful redesign, the results can be powerful. Teams not only work better—they enjoy the work more.

Avoiding False Choices

One key idea from their earlier book is that decisions around agile practices shouldn’t be seen in black-and-white terms. It’s rarely about choosing between right and wrong.

Practices are contextual. What works in one environment might not in another. For instance, feature teams usually work better, but in some contexts, component teams might still make sense.

The real danger is when people use this idea of context as an excuse not to change. The authors caution against organizations that claim to be “unique” as a way to dodge improvement.

They remind us that adopting practices isn’t a binary decision. You can start small and evolve. Teams can blend approaches and shift over time.

Ultimately, both Scrum and lean thinking encourage a mindset of experimentation, not rigid formulas. That’s why this book frames its tools as “Try…” or “Avoid…” experiments—not mandates.

No Best Practices

Another trap the chapter tackles is the seductive idea of “best practices.” In R&D, the very concept is flawed. The context always matters.

When practices get detached from their intent and applied rigidly, they lose effectiveness and even become harmful.

The authors link this to the old thinking from Frederick Taylor’s Scientific Management, which aimed to find the “one best way” to do work.

Lean and agile take the opposite view—there’s always room to improve, and those doing the work are often best positioned to improve it.

The core idea here is that principles may scale across situations, but specific practices don’t. You can’t simply apply the same method across all levels of an organization and expect it to work.

Just because something works for a team doesn’t mean it will work at the enterprise level.

Learning Never Stops

The chapter closes with a humble reminder: the authors are still learning. Every organization they visit teaches them something new.

They invite readers to share stories and insights, especially where the book might be limited.

While many ideas in the book are broadly applicable, the focus is on software-intensive products, often mixed with hardware.

And although the book is about working at scale, they admit—with a touch of humor—that they weren’t able to make big development smaller.

This chapter bridges the companion book and the one you’re reading now. It sets the tone: these aren’t strict instructions, but experiments.

What follows is a deep dive into frameworks, tools, and practices to help large teams work better—not perfectly, but better—using agile and lean thinking.

Chapter 2 – Large-Scale Scrum

The Essence of Large-Scale Scrum

The chapter begins by clarifying that Large-Scale Scrum (LeSS) is not a “new version” of Scrum, but simply regular Scrum applied at scale.

It’s a framework for scaling agile, where Scrum’s core principles—transparency, inspection, and adaptation—remain unchanged.

The idea is to maintain the core of Scrum while introducing practical tips that have worked in large, multi-team, and geographically dispersed teams.

One of the key insights here is the danger of trying to create “better” versions of Scrum, like Scrum 2.0 or Scrum++—these often miss the point of Scrum as an empirical process.

The authors reference Ken Schwaber’s idea that Scrum exposes problems rather than solving them with quick fixes, and these problems must be dealt with over time.

Scaling Scrum: Two Frameworks for Larger Teams

The chapter then shifts into detailing two frameworks for scaling Scrum:

• Framework 1: This framework is suitable for up to ten teams, typically with a single Product Owner (PO) overseeing the product. The tipping point for when this framework no longer works is when the PO can no longer effectively manage the product backlog or balance both internal and external focus. In such cases, the authors suggest delegating more responsibility to the teams or even appointing Product Owner representatives within the teams. This is done to reduce the workload on the PO and help them focus on high-level product management.
• Framework 2: This framework kicks in when there are more than ten teams, potentially scaling to hundreds or even thousands of people. At this point, it’s beneficial to introduce the concept of Area Product Owners (APOs) for different parts of the product. The large product backlog is then split into Area Backlogs, each with its own focus. This framework adds more complexity, requiring careful coordination among all teams and the introduction of new roles.

Roles and Responsibilities in Scaling

The authors emphasize the importance of keeping roles clear even when scaling:

• Product Owner: The PO’s role remains the same as in regular Scrum, focusing on managing the vision, roadmap, and ROI of the product. As the number of teams grows, the PO may need additional support to handle the increased workload.
• Feature Teams: These are the heart of Scrum. They are self-managing, cross-functional teams that are responsible for delivering entire features. These teams work together on customer-centric features and should not require much coordination with other teams, except when integrating code.
• ScrumMasters: In larger setups, ScrumMasters play a dual role—they not only help their teams but also coach the Product Owner and act as change agents to optimize the product development process across the organization.

Artifacts and Events at Scale

• Product Backlog: For scaling, there’s one product backlog for the entire product, not a backlog per team. This is crucial because splitting it would defeat the purpose of Scrum’s unified product vision.
• Sprint Backlogs: Each team maintains its own Sprint backlog, just as in regular Scrum.
• Potentially Shippable Product Increment: This is a huge challenge at scale. While small teams can easily meet this goal, large teams need continuous integration to ensure the output of each team is integrated into a potentially shippable product increment. This is where the chapters on Coordination and Continuous Integration come into play, helping teams align and integrate their work.

Events at Scale

• Sprint Planning: At scale, there might be a need for separate Sprint Planning sessions for each requirement area, especially in Framework 2. But even in Framework 1, planning must be adapted to ensure all teams are aligned.
• Daily Scrum: The daily stand-up remains the same, though scaling introduces the need for additional coordination at times.
• Sprint Review and Retrospectives: These events continue to take place, but for large teams, Joint Retrospectives are recommended to facilitate learning across the entire organization.

Scaling Beyond Framework-1

Once you scale beyond ten teams, Framework-2 introduces the Area Product Owner role, along with the need for separate Area Backlogs.

The key here is to create smaller, more manageable units that focus on specific aspects of the product, making the process more manageable as the number of teams increases.

This framework still holds onto the key idea that no matter how large the organization, the core principles of Scrum should remain intact: it’s about focusing on transparency, inspection, and adaptation at every level of the process.

The challenge is how to scale these principles to larger teams without losing their effectiveness.

The chapter concludes by reiterating that Large-Scale Scrum (LeSS) is simply Scrum applied at scale. The framework isn’t about “new” practices, but about experimenting with ways to scale Scrum in large, multi-team environments.

Whether it’s Framework-1 for smaller groups or Framework-2 for larger teams, the goal remains the same: maintain the integrity of Scrum while scaling it to handle more complexity.

Chapter 3 – Test

Shifting Mindsets in Testing

The chapter begins with a story highlighting the profound shift that happens when moving from traditional to agile development, particularly for testers.

One tester, who had years of experience in conventional testing, found himself questioning everything he knew as he encountered agile practices. This transformation is at the core of the chapter: how agile development changes the purpose and approach to testing.

In agile and lean contexts, testing isn’t just a phase that happens at the end of development. It becomes a continuous part of the process.

The traditional mindset, where testing occurs after coding is complete, is replaced with practices where testing starts before coding, is integrated into design, and is continuously executed throughout the development cycle.

Thinking About Testing

The authors challenge the old assumptions about testing that limit innovation. For example, the idea that testing can only start once coding is done is examined and debunked.

Agile approaches, such as test-driven development (TDD) and acceptance test-driven development (A-TDD), blur the lines between testing and design, making them indistinguishable.

A big takeaway here is that testing cannot remain a separate silo.

In agile teams, everyone—whether developer, tester, or product owner—shares responsibility for testing. The authors argue that this holistic approach fosters collaboration and eliminates bottlenecks.

Simplifying Testing

Instead of adhering to complex, specialized terminology that often leads to department silos and inefficiency, the authors advocate for simplifying how we talk about testing.

They introduce a simplified categorization system to distinguish between developer tests and customer-facing tests. This approach, which focuses on clarity and usability, helps avoid the confusion and inefficiencies caused by overly detailed testing classifications.

Avoiding the Traditional Test Department

A major point made throughout the chapter is avoiding the separation of development and testing roles. In traditional setups, testers are often isolated from developers.

This leads to the “test versus development” conflict, where testers look for defects while developers defend their code. Agile, however, encourages cross-functional teams where developers and testers work together from the start, ensuring that quality is built into the product.

The authors stress the importance of test independence—not in the traditional sense where testing is separate, but in the sense that tests are written independently before code is even developed.

This ensures that tests are not influenced by the developers’ code but are instead based on the desired outcomes.

Automating and Managing Tests

Automated tests are crucial for continuous integration, but the chapter warns against creating separate automation teams. When teams are detached from the actual development work, automation efforts often fail.

Instead, the authors recommend that feature teams temporarily take on automation tasks, as they understand the system the best.

Automating all tests might seem like a daunting task, but the authors argue that it’s worth the effort, particularly when working on large-scale projects with shared code ownership.

Automated tests provide a safety net that prevents regression and speeds up development in the long run.

Acceptance Test-Driven Development (A-TDD)

The heart of customer-facing tests is Acceptance Test-Driven Development (A-TDD), where tests serve as executable specifications for requirements. In A-TDD, the whole team works together in workshops to clarify requirements and write tests.

These tests are not just written by testers but are part of a collaborative effort involving the Product Owner and other stakeholders.

A-TDD is described as a whole-team technique, and it’s not just for testers. It requires everyone to be involved, especially in the requirements discovery phase. The authors emphasize that the goal is to clarify requirements through tests, not simply to test after the fact.

This approach integrates testing into the very definition of the requirement, ensuring that every aspect of the product is tested against real customer needs.

Manual Tests in Agile

While automation is emphasized, manual testing still plays a role in agile environments.

The chapter acknowledges that some tests—particularly those requiring human judgment, such as usability testing or tests involving physical movement—cannot be fully automated.

These tests should be time-boxed and planned to ensure they are done efficiently and effectively.

The chapter concludes by stressing that testing in agile isn’t just about finding bugs; it’s about preventing them early and making testing an integral part of development.

The shift from traditional testing practices to a more integrated, continuous approach is vital for teams that want to scale agile effectively.

Chapter 4 – Product Management

Introduction: Challenging Traditional Product Management

The chapter starts with a story of a clash between agile thinking and traditional product management.

It illustrates the deeply ingrained silo mentality where departments like product management and R&D often function independently, causing friction when agile principles are introduced.

This clash highlights the need to rethink how product management operates within the agile context, especially in large-scale environments.

The authors argue that agile principles can improve product management by fostering closer collaboration, transparency, and faster feedback loops.

Product Management in an Agile World

At its core, product management in an agile environment is all about collaboration and continuous feedback from both customers and teams. The chapter emphasizes that agile product management isn’t about following a strict process but instead about driving innovation and responding to change.

The authors introduce a key concept from lean thinking: eliminating non-value-added activities throughout the product lifecycle to improve efficiency and speed. This approach doesn’t just apply to development but extends to the entire product management process.

Integrating Scrum with Product Management

Scrum is not just a methodology for development teams; it can significantly enhance product management too.

The chapter highlights how product management can benefit from the short, iterative cycles of Scrum, which provide better transparency and control over the product’s direction.

Short iterations allow product managers to continuously re-prioritize the product backlog based on real customer feedback, ensuring that the development teams are always focused on delivering the most valuable features.

The Role of the Product Owner

The authors stress the importance of the Product Owner (PO) role in bridging the gap between the customer, the business, and the development teams.

The PO is responsible for the product’s vision, its features, and ultimately its success. The chapter clarifies that the Product Owner must be someone with business responsibility, not a technical lead from R&D, as they need to steer development according to customer needs and business goals.

A common misconception is that the Product Owner is just an analyst or a middleman. In agile frameworks, the PO must have the authority to make key decisions on priorities and release dates, ensuring that the product evolves in line with customer needs and market trends.

Agile Product Management Practices

The chapter suggests that agile product management requires product managers to become active participants in the development process.

Instead of being distant, managing everything through reports and meetings, they need to work closely with Scrum teams during Sprint Planning and Sprint Review, adjusting priorities and responding to evolving insights.

One of the major shifts with agile product management is how the product roadmap is managed.

Rather than being set in stone with rigid timelines, the roadmap becomes adaptive, with continuous adjustments based on customer feedback and market changes.

This flexible approach increases the likelihood of delivering customer value quickly and consistently.

The Role of Transparency and Collaboration

In large organizations, one of the biggest challenges is overcoming the traditional silos between departments. The authors advocate for cross-functional collaboration, particularly between product managers, R&D teams, and customers.

This collaboration is key to fostering an environment where both the product vision and the customer’s evolving needs can be addressed effectively.

Shifting from Contracts to Collaboration

A central theme in this chapter is moving away from the traditional contract negotiation model, where product managers and R&D teams agree on fixed scopes and dates. Instead, agile product management promotes a collaborative relationship where the Product Owner works with the R&D teams to adapt and refine the product vision iteratively.

This shift fosters trust and ensures that development aligns more closely with customer expectations.

The chapter concludes by reinforcing that agile and lean thinking are not just for R&D teams but should be embraced across the product management function.

By applying these principles, organizations can achieve greater transparency, flexibility, and responsiveness—key ingredients for success in today’s fast-paced, customer-driven markets.

The authors suggest that adopting agile principles in product management requires a cultural shift within organizations.

This shift doesn’t just involve implementing new tools or processes, but a fundamental change in how product managers interact with their teams, customers, and the market.

Chapter 5 – Planning

Introduction: The Need for Agile Planning in Large-Scale Scrum

The chapter begins with a provocative quote: “If everything is going to plan, something somewhere is going massively wrong.” This highlights the essential shift in mindset required for agile planning at scale.

Traditional project management emphasizes detailed, top-down planning, often leading to rigid frameworks that fail to adapt to changing needs.

In contrast, agile planning encourages flexibility, transparency, and iterative learning, especially when scaled across multiple teams.

Early Days: Kicking Off with Initial Product Backlog Refinement

The chapter discusses how to kickstart large-scale Scrum with an initial Product Backlog refinement workshop. This event is more intensive than typical product backlog creation and requires several days.

It serves as the first step in adapting Scrum to large, complex products involving many people. Unlike traditional release planning, which occurs at the start of each cycle, the initial Product Backlog refinement is designed to set the stage for ongoing rolling-wave planning throughout the product’s lifecycle.

This distinction emphasizes that planning in Scrum is continuous and adaptive, unlike the one-off, rigid planning of traditional approaches.

Continuous Product Development Over Projects

The authors argue against the traditional concept of projects as standalone entities.

Instead, they advocate for continuous product development, where work is structured around ongoing iterations, not distinct, isolated projects.

This shift allows teams to focus on constant value delivery through regular increments of potentially shippable product.

In large organizations, moving from project-based to continuous development can feel like a major leap. However, Scrum facilitates this by removing artificial project boundaries, making the process more fluid and responsive to change.

Initial Product Backlog Refinement Workshop Structure

The initial Product Backlog refinement workshop involves several distinct sub-workshops, all focused on different aspects of the product and its development. These include:

• Vision workshops: Define the high-level strategy, constraints, and major features of the product.
• What-to-Analyze Workshops: Identify key features that deserve detailed analysis right from the start.
• Detailed Requirements Workshops: Dive deep into specific features, breaking down requirements into smaller, actionable items.
• Effort and Value Estimation Workshops: Estimate the effort and value of backlog items to ensure proper prioritization.
• Risk Estimation Workshops: Evaluate technical and business risks, which will influence prioritization.
• Form-the-Backlog Workshops: Finally, organize the product backlog, separating items into Release Backlog and future backlog groups.

The goal is to give the entire team a shared understanding of the product, its goals, and the work involved, before kicking off iterative Scrum work.

Scaling Sprint Planning

When scaling Scrum across multiple teams, Sprint Planning can become tricky. The chapter suggests two main parts to Sprint Planning:

1. Sprint Planning Part One (SP1): Focuses on what will be done, ensuring teams understand the product backlog and the priorities.
2. Sprint Planning Part Two (SP2): Focuses on how the work will be executed.

When the number of teams exceeds around ten, the complexity increases. The authors suggest Area Product Owners (APOs) for each product area to help manage backlog priorities at a granular level, ensuring alignment across teams.

In large-scale setups, especially when teams are distributed across multiple sites, these meetings can be difficult to coordinate.

The chapter offers solutions such as asynchronous meetings and using collaborative tools to manage time zone challenges.

Release Sprint: A Special Event to Handle Undone Work

One significant concept discussed in this chapter is the Release Sprint, which is necessary when there’s undone work—tasks that were planned but not completed during regular iterations.

This sprint is dedicated to wrapping up all the unfinished work, allowing the product to be potentially shippable at the end of each iteration.

However, the authors caution against using this as a crutch. Over time, teams should strive to expand their Definition of Done to minimize the need for such sprints.

The Release Sprint also offers a unique learning opportunity: teams experience the challenges of handling incomplete work, which helps them realize how to better address undone work in the future.

Estimation in Large-Scale Scrum

The authors also address estimation in large-scale Scrum, emphasizing the use of story points for estimating effort.

This method is particularly useful when dealing with multiple teams, as it enables quick and flexible updates without getting bogged down in detailed estimates that can become outdated quickly.

They suggest organizing cross-team estimation workshops to ensure all teams have a shared understanding of story points and effort.

However, the authors caution against the temptation to synchronize story points across teams. While this provides a sense of alignment, it can lead to unnecessary comparisons between teams that may not be meaningful.

Instead, they recommend measuring progress using Release Burndown charts and combining estimates from different teams to get a rough picture of overall progress.

In conclusion, the chapter reinforces the idea that agile planning is inherently simpler than traditional project management. By empowering teams to self-organize and collaborate, Scrum facilitates a more adaptive approach to planning.

Large organizations need not resort to rigid, top-down control. Instead, they should embrace agile principles to continuously inspect, adapt, and learn.

Chapter 6 – Coordination

Introduction: The Complexity of Coordination

This chapter opens with a story about two product groups working on the same platform, but their approaches couldn’t be more different.

One group complained about the platform’s bloated design, while the other completely isolated themselves from it to avoid dependencies. This scenario highlights the common challenges of coordination in large-scale development environments.

The key takeaway here is that coordination is hard, but it’s crucial for the success of multi-team and cross-departmental work.

The chapter focuses on two main aspects:

• Thinking about coordination: Understanding the organization, team, and product perspectives.
• Coordination techniques: Practical approaches to ensure smooth coordination between teams and departments.

Thinking About Coordination

The chapter discusses coordination in terms of both product development teams and cross-department collaboration. The more cross-functional the teams become, the more blurred the lines are between departments.

This shift can help expand the product’s Definition of Done, which is critical in scaling agile.

One major takeaway here is the importance of having a cross-department coordinator. This role, often called a project or program manager, facilitates coordination between different teams and departments.

The coordinator works with the Product Owner Team, aligning priorities, but doesn’t make final decisions or get involved in development.

Another interesting concept is evaporating functional departments. Instead of maintaining separate departments, the chapter suggests integrating roles into cross-functional teams.

This approach eliminates silos and enhances collaboration, though it may initially be challenging due to the need for a broader Definition of Done.

A Real Example of Cross-Functional Integration

One example shared is how a company integrated customer documentation into their feature teams. Initially, the documentation department was centralized, outsourced, and offshored.

The shift required a decentralized approach where documentation became part of the feature team.

This required not just a change in structure but also a cultural shift, with team members expanding their skills to take on new responsibilities like testing and writing developer documentation.

Focus on the Overall Product

The chapter emphasizes the importance of focusing on the overall product, rather than just individual teams’ outputs. In the traditional model, local optimization often leads to teams working in silos, which can result in a disjointed final product.

Instead, teams need to coordinate their work to create a cohesive product, and the role of the coordinator is to ensure everyone stays aligned.

One concept that stands out is boundary-spanning activities, as researched by MIT professor Deborah Ancona. These activities are divided into three categories:

1. Ambassador activities: External activities to promote the team and secure resources.
2. Task coordinator activities: Coordination efforts to manage dependencies.
3. Scout activities: Keeping the team updated with new technologies and market trends.

The chapter stresses that teams themselves need to be responsible for managing their boundaries. It’s not just the responsibility of the coordinator; teams must actively manage their dependencies through coordination.

Avoiding External Coordinators

A key recommendation is to avoid external coordinators. Many organizations try to solve coordination problems by creating roles like project managers or coordination managers, but this often leads to the team distancing themselves from the coordination process.

The chapter warns that this can result in a lack of shared responsibility for the overall product, and delays due to handoffs of knowledge.

Instead, the authors suggest that teams themselves should take ownership of coordination, with the ScrumMaster facilitating the process rather than taking charge of it. This ensures that self-organization remains at the core of agile teams.

Decentralized Coordination

The chapter introduces the concept of decentralized coordination, where teams manage their dependencies without a centralized meeting point.

While this approach scales better, it requires each team to be proactive in understanding and addressing their dependencies. Some strategies for decentralized coordination include:

• Sending team representatives (chickens) to other teams’ daily scrums to gather necessary information.
• Travelers, or technical experts who rotate between teams to share knowledge and provide expertise.
• Communities of Practice (CoPs), which allow teams to discuss shared topics and foster coordination through informal channels.

The chapter also discusses tools like environment mapping, where teams map out their dependencies and identify which other teams they need to coordinate with.

This simple technique helps teams visualize their relationships and work more efficiently.

Centralized Coordination Techniques

Although decentralized coordination is emphasized, the chapter also describes centralized techniques for larger, complex teams:

• Scrum of Scrums: A meeting where representatives from different teams share updates and discuss dependencies. The authors stress that this meeting should focus on coordination, not status reporting.
• Open Space: A more flexible, self-organizing format where team members create topics and organize themselves around issues needing attention.
• Town Hall Meetings: These are larger, public meetings where anyone in the product development organization can raise issues or ask questions.

The chapter concludes by emphasizing that coordination is essential but also inherently challenging. The best approach depends on the specific context, team size, and project complexity.

Decentralized coordination is preferred, but teams need to experiment with different techniques and find what works best for them.

In the end, the goal is to create a highly collaborative environment where coordination happens naturally, and everyone is focused on delivering a high-quality product.

Chapter 7 – Requirements & PBIs

Introduction: Understanding Requirements and PBIs in Agile

The chapter starts by addressing a common issue in large-scale agile development: the difficulty in fitting large requirements into short iterations.

This is especially prevalent in fields like embedded systems, where complex features seem too large to break down.

The authors argue that it is entirely possible to divide these large requirements into manageable Product Backlog Items (PBIs), and they walk through methods to organize and manage these items effectively.

Organizing and Managing PBIs

The authors suggest two methods for organizing items in the Product Backlog:

1. Requirement Areas: Group related items based on customer needs rather than technical components. For example, “security” or “color workflow” could be distinct requirement areas, with a dedicated Area Product Owner managing each area.
2. Themes: Group items based on a common theme. Unlike requirement areas, a PBI can belong to multiple themes. For example, “automatic sleep mode” could belong to themes like “energy savings” and “safety.” Themes help define release strategies and can guide testing efforts.

While grouping items is helpful, the chapter advises against feature screening, a technique where features are selected early and excluded from development.

Instead, the authors recommend a prioritized Product Backlog, where new ideas are added at the bottom and only refined if their priority rises.

Splitting PBIs: Cell-like vs. Tree-like Models

When breaking large items into smaller tasks, the authors compare two approaches:

1. Cell-like splitting: When an item is split, the ancestor item is discarded, and each new sub-item is treated as an independent task. This method simplifies the backlog and allows for more flexibility and clearer prioritization.
2. Tree-like splitting: In this model, sub-items retain their links to the original item. This provides context but can lead to over-complication and reduced flexibility, as teams may treat sub-items as a “family” that needs to be completed together.

The authors recommend cell-like splitting for simpler management and clearer prioritization but note that tree-like splitting may be useful in certain contexts where relationships between sub-items provide important guidance.

Pruning the Backlog

A key aspect of managing the Product Backlog is to prune it regularly. Over time, the backlog can accumulate irrelevant or low-priority items, making it harder to manage.

The Product Owner should periodically evaluate and remove unnecessary items, ensuring that only the most relevant tasks are kept in the backlog.

Avoiding Technical Task PBIs

The chapter also warns against including technical tasks as PBIs. A PBI should always reflect a customer need or feature, not an internal task.

For instance, a PBI like “As the UI team, I want the database to include a ‘RECIPIENT’ table” is not customer-centric and should not be on the Product Backlog. Instead, tasks like this should be addressed during Sprint Planning within the team’s internal process.

Dealing with Undone Work

The authors discuss the concept of Undone Work—tasks that are not completed within a sprint but are still necessary for the product’s release. This could include things like performance tuning or documentation.

The recommendation is to keep track of these as PBIs, maintaining visibility and making sure they are part of the release planning process.

Research PBIs and Avoiding Fake Research

Another aspect of the backlog is research work. When conducting research (e.g., evaluating new technology or gathering customer insights), the outcome should always be actionable—identifying new PBIs that can be added to the Product Backlog.

The chapter warns against “fake research”, where teams perform normal exploration work and label it as research without yielding any valuable output.

True research work should focus on solving problems and generating new customer-centric items.

Visual Management of the Product Backlog

The chapter suggests using visual tools to manage the Product Backlog, such as color-coded cards or physical boards, especially in large teams. This not only makes the backlog more tangible but also allows for better tracking of changes and priorities over time.

Additionally, the authors highlight the importance of traceability and propose that requirements be written as executable tests to improve clarity and reduce ambiguity.

Effective Requirements Workshops

The authors advocate for requirements workshops as a key strategy for refining the Product Backlog.

These workshops encourage collaboration between the Product Owner, teams, and subject matter experts to clarify and prioritize backlog items.

Techniques like brain writing, affinity clustering, and mind mapping are suggested to organize and refine ideas.

These workshops help avoid long periods of analysis paralysis and ensure that items are clear and actionable before they enter the backlog.

Splitting PBIs for Delivery

Lastly, the chapter covers strategies for splitting PBIs into smaller, manageable items. This is essential for making items small enough to be worked on within a sprint. The authors present several methods, including:

• Splitting by use case: Breaking items down into specific use cases (e.g., “dhcp.request” or “dhcp.renew” in a networking scenario).
• Splitting by scenario: Dividing a use case into individual scenarios, such as success and failure scenarios.
• Splitting by I/O channel or data part: Focusing on specific components of a feature to simplify development and testing.

The authors emphasize that splitting should always be customer-centric, and each split item should provide value to the customer.

It’s also important to consider risk mitigation when deciding how to split items, ensuring that high-risk components are addressed early.

The chapter concludes by reinforcing the need for simple, flexible, and collaborative approaches to managing requirements and PBIs.

By focusing on customer value, prioritization, and clear communication, teams can ensure that the Product Backlog remains manageable and aligned with the product’s goals.

Chapter 8 – Design & Architecture

Introduction: Rethinking Design and Architecture in Agile

In this chapter, the authors tackle a significant misconception: that architecture and design in software development should be separate from programming.

The chapter introduces the idea that software design is much more dynamic and evolving, much like a garden rather than a building. It argues that the real architecture of a software system is reflected in the source code, not in static design documents.

The key takeaway is that good architecture needs to be grown and maintained continuously as the system evolves.

Thinking About Design

The traditional view of architecture often involves creating a static blueprint before the coding begins.

However, software is inherently fluid and should be treated as such. The chapter uses the analogy of gardening over architecting—the idea being that design evolves through continuous input, much like plants growing in a garden.

One important point is that every act of programming is an architectural decision, whether intended or not. The authors argue that software architecture isn’t a fixed entity but something that changes daily as new lines of code are written or modified.

This contrasts with the traditional view that architecture is something that is designed and fixed at the start of a project.

Challenges with Traditional Software Architecture

In large organizations, the separation between architecting and coding can cause problems. When architects work in isolation from the development team, they risk becoming disconnected from the actual code and losing touch with the evolving needs of the software.

This leads to what the authors call “architecture astronauts”—architects who are too far removed from the real work to have a meaningful impact on the code.

Instead, the authors argue for a more integrated approach, where programmers and architects are not separate but part of the same team.

The architecture evolves as the system does, with architects staying involved in the coding process and making decisions alongside the development team.

Design and Architectural Integrity

Maintaining architectural integrity is essential, but it can be difficult in large teams.

The chapter introduces design workshops as a solution. These workshops are collaborative sessions where feature teams come together to discuss and sketch the design, ensuring alignment and consistency across the system.

The authors also emphasize the importance of having hands-on programmers as part of the architectural decision-making process.

Architects should not be removed from the coding process; they should actively participate in the creation and maintenance of the codebase, guiding the team to ensure that the architecture remains solid as the software evolves.

Agile Modeling

The chapter presents agile modeling as a powerful tool for continuous design. Modeling should not be done to create final, detailed specifications, but rather to facilitate conversation and shared understanding among the team.

The authors argue that simple sketches on whiteboards are often the most effective form of modeling.

They highlight the value of design workshops, which bring together all team members—including programmers, testers, and designers—to work on the architecture together.

These workshops help develop a shared understanding of the system’s design and prevent the issue of design becoming disconnected from reality.

Best Practices for Large-Scale Design

As the chapter shifts to address large-scale design, it offers several best practices:

1. Incremental Design: Design should evolve incrementally as the product grows, with each iteration introducing new architectural insights.
2. Vertical Slices: Focus on delivering customer-centric features that cut across all layers of the system. This approach ensures that architectural decisions are validated early on and that customer needs are prioritized.
3. Prototypes: Use prototypes to test architectural ideas before committing to them. These prototypes allow teams to explore potential solutions without the risk of over-engineering.
4. Joint Design Workshops: Teams working on shared components should hold joint design workshops to ensure alignment and prevent fragmentation of the architecture.

Dealing with Challenges in Large Teams

In large teams, it’s crucial to avoid the handoff of design work from architects to developers. Instead, the architects should remain actively involved throughout the development process.

The authors recommend starting with a “tiger team”, a small, co-located group of skilled programmers and architects who work together on the most architecturally significant features.

Additionally, agile modeling should be used to continuously validate and adjust the architecture as the system evolves. By encouraging collaboration and maintaining hands-on involvement from all team members, the architecture can stay aligned with the needs of the product and the customer.

In conclusion, this chapter argues that software architecture should be flexible and continuously evolving, rather than static and separated from the programming process.

By integrating architects directly into the development process, using design workshops, and focusing on customer-centric features, teams can maintain a high level of architectural integrity while delivering valuable products incrementally.

Chapter 9 – Legacy Code

Introduction: The Reality of Legacy Code

The chapter begins by acknowledging a common scenario in large product groups: many developers feel stuck with legacy code.

While existing, well-structured, reusable code is a valuable asset, it often turns into a burden when it becomes poorly structured, poorly documented, and lacking automated tests.

This type of legacy code limits organizational agility and can eventually lead to a competitive disadvantage.

The authors also acknowledge that legacy code has created jobs, particularly in countries like India and China, where the outsourcing industry thrives on maintaining these old systems. However, they also point out that focusing on legacy code, rather than innovation, stifles progress.

How to Write New Legacy Code

The authors humorously claim that writing legacy code is easy, but preventing it from happening is much harder. The key to avoiding the creation of legacy code lies in preventing certain common practices:

• Unrealistic deadlines with fixed commitments and promises that force developers to take shortcuts.
• Poor development skills, which are often the root cause of badly written, unmaintainable code.

They warn against the “vicious cycle” of unrealistic promises made by sales and management, which force developers to work overtime and take shortcuts. This cycle leads to technical debt—the legacy code that accumulates over time.

The authors argue that this cycle must be broken to avoid creating more legacy code.

Avoiding New Legacy Code

To prevent creating new legacy code, the authors emphasize several important practices:

1. Avoid fixed commitments with unrealistic deadlines. When developers are pressured to meet impossible deadlines, they often resort to hacks, hardcoding, and other shortcuts that ultimately lead to legacy code.
2. Educate developers in modern practices and techniques to help them avoid poor coding habits. The authors acknowledge that many developers lack basic software development skills, which leads to low-quality code. They stress the importance of continuous learning and the need for organizations to invest in developer education.
3. Improve organizational support for learning. Organizations often assume that university graduates are ready to code at a high level, but the reality is that most developers need ongoing training and support to develop sustainable skills.

The authors also caution against trivializing programming in the organization, where developers are pushed into management roles or seen as mere implementers.

This culture undermines the value of programming and creates a disconnect between software development and its impact on the product.

Dealing with Existing Legacy Code

When faced with existing legacy code, the authors caution against simply rewriting it.

Rewriting legacy code often leads to a temporary improvement in quality but can eventually lead to another cycle of poor-quality code. Instead, the focus should be on improving the codebase incrementally, making small improvements with every change.

This is described as “cleaning up your neighborhood”, where each change to the code includes refactoring and adding tests to ensure ongoing improvement.

Strategies for Dealing with Legacy Code

The chapter introduces several strategies for managing legacy code:

• Gradually improve the codebase: Instead of a massive rewrite, focus on small, continuous improvements as part of regular development work. The authors suggest pairing legacy code improvements with new feature development to avoid downtime and keep the codebase healthier over time.
• Write both high-level and unit tests: While unit tests help refactor and improve the code’s structure, high-level tests ensure that the system works as a whole. Both types of tests are crucial when working with legacy code.
• Rewrite lethal legacy code: In cases where parts of the code are impossible to improve incrementally (e.g., code written in an obsolete language), the authors suggest “amputating” those parts and replacing them. However, they emphasize that this should be done carefully, with tests in place to ensure the new code is correct.

The chapter concludes with a reminder that legacy code is inevitable, but the key challenge is not just dealing with it but preventing its creation in the first place.

This requires better developer skills, improved practices, and a culture that values clean, maintainable code.

The authors stress the importance of continuous improvement and investing in the growth of developers, as well as adopting practices like test-driven development to avoid creating new legacy code.

Chapter 10 – Continuous Integration

Introduction: The Essence of Continuous Integration (CI)

Continuous Integration (CI) is one of the core practices for scaling agile and lean development. While the concept may seem simple—automating builds and running tests—the authors emphasize that CI is not just about the tools but a developer practice that requires a cultural shift and consistent discipline.

CI involves frequent integration of code changes by developers into the main codebase, usually on a daily basis, and is verified by an automated build to detect errors early.

The chapter dives deep into the misconceptions surrounding CI, clarifying that the practice is about behavior, not just automation tools.

A CI system alone won’t help if developers do not integrate their changes regularly. The heart of CI lies in small, incremental changes that keep the system working and avoid the bottleneck of large, risky releases.

The CI Practice: Developer’s Discipline

The authors stress that CI is a developer’s practice. It’s about consistently making small changes, integrating them, and ensuring the system remains stable.

CI requires developers to work with small batches and ensure their own local systems are always stable before integrating their changes into the mainline. This eliminates the problems of work-in-progress (WIP) and helps maintain visibility of the entire system’s state.

However, CI does not only rely on automated tools; it also depends heavily on the discipline of the developer.

If developers avoid frequent integration to avoid breaking the build, they create bigger problems later, as integration delays accumulate and increase the chances of errors.

Small Changes for Stability

A fundamental principle in CI is making small changes rather than large ones. Large changes disrupt the system and take more time to stabilize.

By making smaller changes more frequently, developers ensure that the system stays stable, and any defects introduced are quickly identified and addressed.

This principle aligns with lean thinking, which advocates for small batches to improve flow and minimize waste. By continuously integrating small changes, the system evolves in a more controlled, predictable way.

The Role of Automated Tests

Automated tests play a crucial role in ensuring the stability of the system. The CI system checks the integration after each developer commits changes, running a series of tests to validate that nothing has broken. For this to be effective, automated tests must be fast and comprehensive. However, as systems grow, ensuring the tests run quickly becomes challenging. Developers often run a subset of tests locally before committing, while the CI system runs the full suite of tests to catch any errors missed.

Scaling CI in Large Systems

Scaling CI becomes increasingly difficult as the size of the product and the number of developers grows. The build time increases, which can lead to delays in feedback. The chapter suggests several strategies to handle this:

• Speed up the build: Adding hardware or optimizing tools can significantly reduce build times.
• Parallelize the build: Distributing the build process across multiple systems helps reduce the overall build time.
• Incremental builds: Compiling only changed components rather than the entire system can improve speed and efficiency.

As the system grows, multi-stage CI systems become necessary, where different levels of testing are performed at different stages.

This includes fast tests for individual components, followed by slower system-level tests. These stages ensure that errors are detected early without overloading the system with too many tests at once.

The Danger of Branching

The authors highlight one of the most critical challenges in CI: branching. Branching during development can lead to integration hell, where developers work in isolation and only later try to merge their work, leading to conflicts and broken builds.

They stress that branching should be avoided whenever possible, and developers should integrate directly into the mainline.

If branching is necessary, it should be short-lived and continuously merged into the main branch to keep the system integrated.

Visual Management for CI

The authors recommend using visual management tools, such as a red-green screen or an andon system (similar to Toyota’s stop-the-line system), to provide immediate feedback to developers when the build breaks.

These tools give developers a clear visual signal that something is wrong, prompting immediate action. The goal is not to punish those who break the build but to make the process of identifying and fixing issues transparent and immediate.

Scaling CI Systems

To scale a CI system for large teams and products, the build and test process must be fully automated, and performance must be carefully managed. The chapter recommends several strategies for scaling:

• Breaking down the CI process into stages, such as component-level builds, feature-level tests, and system-wide testing, each with different feedback times.
• Optimizing build tools and hardware to speed up the process and manage larger systems.
• Parallelizing tests and deploying in incremental steps to ensure speed and efficiency.

The chapter concludes by emphasizing that CI is more than a tool—it’s a fundamental developer practice. Implementing CI requires a cultural shift, disciplined practices, and careful management of the build and test processes.

As products scale, CI becomes even more essential to ensure that the system remains stable, that feedback cycles are short, and that the development process is as efficient as possible.

The challenge of CI is not about installing tools, but about changing developer behavior to ensure that every change is integrated and tested frequently, making the system progressively more stable and adaptable.

Chapter 11 – Inspect & Adapt

Introduction: The Need for a Shift in Agile Adoption

In this chapter, the authors highlight a common mistake in agile transformation: the misconception that adopting agile practices is a one-time project with a fixed end date.

They explain that agile adoption is a continuous journey of experimentation, learning, and ongoing improvement, not something that can be planned like a traditional project.

The chapter stresses the importance of adaptive thinking—constantly adjusting to new insights rather than sticking rigidly to a predefined plan.

An interesting story is shared about a manager who presented a highly detailed Gantt chart outlining a 27-month plan for transforming to agile.

The authors quickly dismissed this approach, recognizing that it reflected a traditional management mindset that misunderstands the true nature of agile: it’s not about completing tasks within set timelines, but about evolving practices based on continuous learning and adaptation.

Key Concepts in Agile Adoption

The chapter offers several insights into how organizations often mismanage agile adoption:

1. Top-down transformation: While leadership support is essential, top-down mandates can often backfire. Management may push for agile adoption without truly understanding or embracing the principles, resulting in superficial changes like relabeling roles (e.g., turning project managers into ScrumMasters) without any real transformation.
2. Adopting lean/agile principles should happen in an environment of experimentation, self-organization, and adaptation, much like how agile practices themselves are iterative and evolving. This way, teams can reflect on their own processes and improve organically, rather than being forced into rigid frameworks.
3. Coaching and voluntary adoption: The authors stress that coaching should come from a place of support and voluntary engagement. It’s not about forcing people to adopt agile, but encouraging them to experiment with it and see its value for themselves. Teams that want to experiment should be provided the resources and guidance to explore agile methods without being pressured by targets or timelines.

The Role of Management and Leadership

The authors caution that leadership support needs to go beyond merely offering resources or supporting teams from afar. Instead, leaders should engage deeply with the process, continuously learning about agile principles, and leading by example.

This creates a culture of continuous improvement and kaizen (the Japanese term for continuous improvement), which is essential for long-term success.

One key point is that lean and agile adoption should not be seen as a project with an end date but rather a lifetime commitment to experimentation and learning.

Successful adoptions are not about ticking boxes but about building a mindset and culture that embraces ongoing change.

Encouraging Experiments and Learning

One of the best ways to adopt agile practices is to experiment rather than try to force them into existing structures. The chapter introduces the idea of improvement experiments—small, iterative tests that allow teams to learn what works and what doesn’t.

This approach encourages trial and error, with the understanding that mistakes are part of the learning process. The authors emphasize that failure is not a problem as long as it leads to better learning and improvement.

Additionally, leaders should focus on helping teams solve impediments by creating an impediments backlog.

This backlog is a list of obstacles that teams face, which can be prioritized and tackled together by teams and management. The focus should be on removing these impediments as they arise, rather than waiting for them to become bigger issues.

Adopting Agile with Integrity

The chapter also addresses the potential pitfalls of superficial agile adoption, such as organizations implementing agile practices but failing to shift their mindset.

For example, some organizations simply adopt tools without addressing deeper issues like systemic inefficiencies, poor team dynamics, or lack of proper coaching.

The authors warn against this, suggesting that without applying agile principles wholeheartedly, teams will end up with what they call “fake agile”—a practice that looks agile on the surface but lacks the fundamental principles of collaboration, adaptation, and customer-focused value delivery.

Improvement Strategies and Methods

The authors suggest several strategies to help improve the adoption of agile and lean principles:

1. Creating a culture of continuous improvement: This includes regularly reviewing the adoption process, collecting feedback, and adjusting the approach to fit the team’s needs. This process is called inspect and adapt, a core concept in agile that encourages teams to reflect on their work regularly and adjust accordingly.
2. Encouraging self-organizing teams: By focusing on people over processes, agile organizations foster teams that can adapt to change independently. This approach helps build a sense of ownership and accountability within teams.
3. Using visual management techniques: Tools like visual boards can help teams manage their progress and problems more effectively. These tools keep everyone focused on the key priorities and obstacles, which is crucial for long-term success.

The chapter concludes by emphasizing that agile is not a one-time fix or project—it’s an ongoing journey.

Agile adoption should be viewed as a commitment to continuous improvement, with feedback loops built into every aspect of the process.

Leaders must actively engage with teams to ensure they have the tools, knowledge, and support needed to continuously adapt and improve.

In short, the chapter highlights that agile is about building the right culture—one that values experimentation, learning from failure, and constant improvement. This mindset shift is key to achieving long-term success in agile adoption.

Chapter 12 – Multisite

Introduction: The Challenges of Multisite Development

In this chapter, the authors discuss the challenges and strategies of managing multisite development, where product teams are spread across multiple locations.

This scenario introduces complications such as communication breakdowns, coordination issues, and the loss of team cohesion.

The chapter focuses on how to navigate these challenges while maintaining agile practices, particularly Scrum, across geographically dispersed teams.

The Core Challenges in Multisite Development

The authors highlight several problems that arise when working in multisite environments:

• Geographic dispersion: When teams are separated by large distances, it’s harder to maintain rich communication and real-time collaboration.
• Coordination breakdown: Increased complexity in ensuring everyone is on the same page, especially across time zones.
• Loss of communication richness: Face-to-face interactions are crucial for effective communication, and when teams are distributed, this richness is often lost.
• Loss of teamness: Building a strong, cohesive team becomes difficult when members are not co-located.
• Cultural differences: Varied work cultures across locations can create friction and misunderstandings.

Despite these challenges, the authors emphasize that Scrum practices can still be applied successfully in multisite settings, provided proper strategies are put in place.

Thinking About Multisite: Tips for Success

The authors begin by suggesting that the number of sites should be minimized to avoid unnecessary complexity.

One product group they encountered was spread across 13 cities, which they felt was excessive. It’s crucial to challenge assumptions that multiple sites are always needed. Fewer sites can lead to smoother operations and fewer logistical challenges.

They also emphasize that multisite issues can arise even within the same building if teams are on different floors or zones.

The distance factor starts as soon as teams are not in close proximity, and this is where many problems start—something as simple as needing to move between rooms to have a conversation can be a source of friction.

Misconceptions and Realities of Distributed Agile Teams

The authors caution against the misconception that distributed agile development means teams must always be dispersed across multiple locations.

In large-scale Scrum, it’s often better to have co-located feature teams that work together in one location rather than spreading a team across different sites. This setup reduces the need for coordination across different locations and simplifies the development process.

Furthermore, while some might suggest that distributed pair programming is necessary in such environments, the authors note that this is only applicable when teams are dispersed and cannot avoid being so.

However, distributed pair programming is not a requirement of Scrum, and it can often introduce additional complications without sufficient benefits.

Team Structure in Multisite Development

The authors suggest that teams should not be organized by components (e.g., separate teams for testing, architecture, and programming) when spread across multiple sites.

This often leads to communication delays and coordination issues. Instead, teams should be feature-focused, with each team responsible for a complete feature from start to finish.

This eliminates the need for extensive coordination between multiple sites and reduces the “handoff” problems common in multisite environments.

Co-located feature teams—teams that are self-contained and can manage all aspects of a feature—are the key to successful multisite Scrum adoption.

The authors stress that cross-functional teams reduce the need for coordination across sites and lead to faster delivery times.

Coordination and Communication Tools

Effective communication tools are crucial in multisite development. The authors suggest using video conferencing and other synchronous communication tools to maintain real-time interaction between teams.

They note that cheap and simple video technologies like Skype and Google Talk are often more effective than expensive, complex systems.

By incorporating video into daily communications, teams can maintain a rich communication environment despite physical distance.

The use of shared repositories for code and continuous integration (CI) across sites is another key element for ensuring smooth coordination.

The authors discuss how using a single repository that all teams can access and update regularly ensures that integration happens seamlessly, avoiding the delays and issues common in distributed CI systems.

Avoiding Multisite Pitfalls

The chapter also identifies several pitfalls to avoid:

• Treating sites as unequal partners: It’s crucial that all sites are seen as equal partners in the development process, rather than having a central site dominate decision-making. This ensures that all teams are equally invested in the product’s success.
• Not taking into account cultural differences: Multisite teams often operate in different cultural contexts. Understanding these differences and adjusting communication styles can improve collaboration significantly.
• Focusing too much on specialized tools: The authors recommend using simple tools that encourage collaboration rather than fancy commercial tools that may stifle communication and engagement.

To wrap up the chapter, the authors emphasize the importance of simplifying the approach to multisite development.

This includes minimizing the number of sites, focusing on co-located feature teams, and maintaining strong communication practices through video conferencing and shared tools.

The overarching message is that while multisite development introduces challenges, these can be managed effectively with the right strategies and practices.

Chapter 13 – Offshore

Introduction: Understanding the Offshore Challenges

In this chapter, the authors dive into the complexities of managing offshore agile development, particularly when applying Scrum in outsourcing settings.

Offshore development introduces a series of challenges, such as cultural differences, communication barriers, and coordination issues across time zones. The chapter explores how these issues intersect with agile principles and offers strategies to manage them effectively.

The authors emphasize that agile offshore is often misunderstood, with many treating it as just about time-boxed iterations.

However, they stress that real agile offshore development is more about values and principles, not just practices like quick iterations.

Key Challenges in Offshore Agile Development

One significant challenge offshore teams face is the lack of engaged stakeholders, particularly when clients fail to apply agile values themselves.

The authors point out that offshore clients often come with a waterfall mindset, expecting traditional project management behaviors like detailed Gantt charts and fixed specifications.

This can result in a major misalignment when these clients are introduced to agile methods like Scrum, where collaboration and adaptability are key.

Another challenge highlighted is the us-them mentality that can develop between offshore teams and onshore clients. This division can lead to poor communication, lack of trust, and less effective collaboration.

Overcoming these barriers is essential for successful agile offshore practices.

Addressing Misconceptions about Offshore Agile

The authors encourage educating clients about the real meaning of agile. They explain that agile is a mindset shift, involving collaboration, continuous feedback, and flexible, adaptive planning.

Leaders need to communicate this clearly to all stakeholders, especially when introducing agile offshore development to a new client.

They also note that sales teams often oversell the benefits of agile without preparing clients for the necessary cultural shift. For example, many clients are not prepared to be active participants in the Product Owner role, which is a crucial aspect of Scrum.

Building Strong Partnerships Across Teams

One of the most effective ways to foster strong relationships between offshore teams and clients is to remove intermediaries. In traditional offshore models, there’s often a project manager acting as the intermediary between developers and clients.

This can create friction and misunderstandings. Instead, the authors suggest a matchmaker model, where a facilitator helps encourage direct communication between the offshore team and the client. This direct contact helps build trust and improve communication.

The use of video sessions is also emphasized. The authors explain how video conferencing bridges the gap between offshore and onshore teams, improving rapport and understanding.

Face-to-face communication, even remotely, increases the effectiveness of the meetings and helps diminish the us-them divide. Additionally, video communication aids in improving non-verbal interactions, which are often lost in traditional phone calls or emails.

The Role of Customers in Offshore Development

Another critical insight the authors provide is the need for active customer involvement throughout the process. Instead of just handing over requirements and waiting for a completed system, clients should be involved in regular Sprint Reviews and Retrospectives.

This ensures that their feedback is integrated throughout the development process and that they remain engaged with the progress.

Overcoming Knowledge Transfer Challenges

A significant issue in offshore projects is knowledge transfer, particularly in unfamiliar domains.

The authors suggest holding offshore requirements workshops for each iteration.

These workshops allow the offshore team to review and understand detailed requirements directly with the onshore client, reducing the chances of miscommunication and ensuring that everyone is on the same page.

Moreover, to overcome challenges related to language and cultural differences, the authors recommend hiring translators when needed and ensuring that offshore teams have the necessary language skills to communicate effectively with onshore clients.

Creating a Stable, Collaborative Offshore Team

The authors highlight the importance of creating stable, cross-functional teams that stay together across multiple iterations.

In offshore outsourcing, it’s common to see teams restructured frequently, which can lead to a lack of cohesion and team effectiveness.

The authors argue that maintaining stable teams allows for better collaboration, faster learning, and more consistent results.

They also touch on the importance of creating an agile culture within offshore teams, particularly in regions with high attrition rates.

Long-term coaching and continuous exposure to agile principles help reinforce this culture and mitigate the impact of turnover.

Choosing the Right Offshore Partner

Finally, the authors provide insights into choosing the right offshore partner. They caution against selecting outsourcers who focus too heavily on processes and certifications (like CMMI) without understanding the true essence of agile.

A healthy offshore partnership requires deep transparency, continuous improvement, and a shared commitment to lean and agile principles.

In summary, this chapter outlines the best practices for implementing agile in offshore settings.

The key takeaway is that offshore development isn’t just about executing tasks in short iterations; it’s about creating a shared agile mindset, fostering direct communication, and building trust between the offshore teams and clients.

The authors encourage readers to educate all stakeholders, remove barriers between teams, and focus on building long-term, stable partnerships to achieve success in offshore agile development.

Chapter 14 – Contracts

Introduction: The Importance of Contracts in Agile Projects

In this chapter, the authors explore how to structure contracts that support agile practices, especially in outsourced or agile project scenarios.

The chapter addresses how traditional contracts fail to align with agile methodologies and offers guidance on drafting contracts that foster collaboration, transparency, and trust while mitigating the risks inherent in software development.

Agile Contracts: Moving Beyond Traditional Approaches

The authors highlight that while traditional contracts focus on rigid structures with fixed deliverables, agile contracts emphasize flexibility, collaboration, and iterative progress.

Agile contracts need to support incremental delivery and continuous customer feedback, allowing both parties to adapt to change rather than sticking to a predefined plan.

One critical insight is that contracts should not be about controlling risks, but about enabling a collaborative relationship that aligns both customer and supplier around delivering a successful project.

As agile emphasizes collaboration over contract negotiation, contracts need to reflect this shift in focus.

Challenges with Traditional Contracts

The chapter explains how traditional contracts often assume a predictable project scope, which is unrealistic in software development.

Fixed-price, fixed-scope contracts are common but tend to lead to problems, such as suppliers cutting corners to meet the fixed terms, resulting in low-quality software and increased maintenance costs.

The authors argue that these contracts lead to waste and inefficiencies, which agile methods are designed to avoid.

Legal professionals involved in these projects often fear that agile contracts are too flexible, which challenges their instinct to protect clients from all potential risks. The authors emphasize that agile contracts reduce risks by focusing on regular, incremental delivery that allows clients to see progress at each iteration, minimizing the uncertainty and risk associated with traditional models.

Core Principles of Agile Contracts

• Flexibility: Agile contracts need to allow changes in requirements, reflecting the iterative and evolving nature of agile development. A rigid change-management process is incompatible with agile principles.
• Collaboration: Successful contracts foster collaboration between the customer and the supplier. This is reflected in a contract’s design by including mechanisms that encourage transparency and joint decision-making.
• Acceptance and Payment: Agile contracts should define clear, but flexible, criteria for deliverables and acceptance testing. Acceptance should be done incrementally after each iteration, with clear and achievable goals for each cycle.
• Termination Clauses: In agile contracts, termination clauses should allow customers to stop the project at the end of any iteration without penalty, acknowledging that a project might be deemed complete once a working system is delivered.

Overcoming Misunderstandings in Agile Contracts

The authors address several common misconceptions when transitioning from traditional to agile contracts:

• False Dichotomies: Some legal professionals might misinterpret the agile value of collaboration over contract negotiation as undermining the contract itself. However, the authors clarify that this value highlights the importance of collaboration rather than negating the necessity of contracts.
• Non-legal Contracts: Agile contracts extend beyond the legal realm and should encompass all agreements, including requirements and specifications, encouraging a more flexible, collaborative approach to product development.

Progressive Contract Models

The chapter highlights progressive contracts as a better alternative to fixed-price contracts. These models allow for flexibility in scope and encourage ongoing collaboration between the customer and supplier.

The contracts evolve with the project, and payments are tied to the completion of iterations, rather than fixed milestones, which allows both parties to adapt based on the evolving needs of the project.

The key takeaway is that contracts should align with agile principles to ensure project success. This includes being flexible, focusing on iterative progress, and fostering collaboration between customers and suppliers.

Agile contracts are not just about legal protections but about building a collaborative, trust-based relationship that increases the likelihood of delivering a successful product.

Chapter 15 – Feature Team Primer

Introduction to Feature Teams

The chapter begins by introducing feature teams, which are the cornerstone of scaling agile practices. These teams are long-lived, cross-functional, and cross-component, responsible for delivering customer-centric features across the entire product.

The essential concept behind feature teams is that they work together on end-to-end customer features, from requirements gathering to implementation and testing. This makes them highly focused on delivering value continuously.

The authors stress that a feature team isn’t just a collection of developers, but a self-organizing group with the necessary skills to handle all aspects of the feature, including analysis, design, development, and testing.

The team stays together for a long time, ideally across many releases, which helps them become highly effective and proficient at delivering complete features.

Characteristics of Feature Teams

Feature teams are stable and cross-functional, meaning they have all the skills necessary to implement a feature from start to finish.

Importantly, the authors emphasize that it’s not necessary for every individual team member to have full knowledge of the entire system, but the team as a whole must possess all the required skills to implement a complete feature.

Some key characteristics of feature teams include:

• Cross-functional: Each feature team includes members from different disciplines (e.g., developers, testers, analysts, and designers).
• Cross-component: Feature teams don’t specialize in a specific component of the system, allowing them to work across all areas of the product.
• Customer-centric: The teams are organized around delivering features that directly benefit the customer.
• Stable: These teams stay together for long periods to build expertise and improve efficiency over time.
• Co-located: While not always necessary, co-location is ideal for reducing communication overhead and increasing collaboration.

Feature Teams vs. Component Teams

The chapter contrasts feature teams with traditional component teams, which are often organized around technical expertise and components (e.g., a testing team, a backend team, etc.). Feature teams differ significantly:

• Customer focus: Feature teams focus on delivering value to the customer, whereas component teams often focus on technical aspects like writing code or optimizing systems.
• Collaboration and coordination: Feature teams avoid the extensive coordination required between component teams. Component teams often need to pass work across team boundaries, leading to dependencies and delays.
• Shared ownership: Feature teams take collective ownership of the work they do, whereas component teams have individual ownership of specific parts of the system.

The Importance of Modern Engineering Practices

The chapter highlights that continuous integration (CI) is essential when adopting feature teams. CI ensures that code changes from multiple teams can be integrated regularly, reducing the risk of conflicts and promoting shared ownership of the product.

By adopting CI, teams can maintain a shared codebase, which allows them to work more collaboratively and efficiently, even as they tackle different parts of the same feature.

Specialization Within Feature Teams

Another point the authors make is that while team members in feature teams are generalizing specialists—meaning they have a broad understanding of multiple disciplines—they are still allowed to specialize in particular areas.

This balance between specialization and flexibility is crucial. The team as a whole must have all the skills required to complete a feature, but each member may have their own areas of deeper expertise.

Feature Teams in Large-Scale Agile

As organizations scale, the chapter introduces the concept of Requirement Areas to support feature teams.

Requirement Areas help to structure the Product Backlog in a way that aligns with customer needs and makes it easier to manage the work for multiple teams.

These areas provide clear ownership of parts of the product, ensuring that teams have a focused area of responsibility.

Transitioning to Feature Teams

The chapter outlines strategies for organizations transitioning from component teams to feature teams.

A gradual, phased approach is recommended, where an organization begins by establishing a single feature team within the existing component team structure. This allows teams to adapt and understand the feature team dynamics before scaling up.

The chapter acknowledges that such transitions are difficult but ultimately provide greater value and flexibility once feature teams are fully adopted.

In conclusion, the authors assert that feature teams are the most effective structure for delivering customer value in a scalable and sustainable way. They help eliminate the inefficiencies associated with component teams and allow for faster, more responsive product development.

The requirement areas provide the necessary structure for scaling feature teams while maintaining a customer-focused approach.

The chapter ends by recommending that readers explore the Feature Teams chapter in the companion book for further insights.

4 Key Ideas from Practices for Scaling Lean and Agile Development

6 Main Lessons from Practices for Scaling Lean and Agile Development

My Book Highlights & Quotes

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

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

Conclusion

This book is a reminder that big doesn’t have to mean bureaucratic.

With the right mindset and practices, even the largest organizations can stay nimble, human, and focused on delivering value.

If you’re leading, coaching, or just trying to stay sane in a growing agile environment, Practices for Scaling Lean and Agile Development offers a path forward—one that’s grounded, practical, and refreshingly honest.

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: