Book Notes #24: Enterprise-Scale Agile Software Development by James Schiel

Title: Enterprise-Scale Agile Software Development
Author: James Schiel
Year: 2009
Pages: 382

Most people hear “Agile” and think of sticky notes, stand-ups, and faster delivery. But when it’s time to scale Agile across an entire company—where hundreds of people, systems, and departments are involved—it’s not so simple.

That’s where Enterprise-Scale Agile Software Development by James Schiel becomes a game-changer. This book doesn’t sugarcoat the complexity.

Instead, it offers a grounded, honest, and incredibly detailed blueprint for what it actually takes to make agile work in the real world, especially inside large organizations that can’t just “move fast and break things.”

It’s part manual, part mindset shift—and a must-read for anyone serious about leading change that sticks.

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 Enterprise-Scale Agile Software Development

Book Overview

Most people think going agile means holding daily stand-ups, using sticky notes, and ditching documentation. It sounds simple—maybe even too simple. But once you try to apply that mindset across a large, complex organization, things get messy. Fast. That’s where James Schiel’s Enterprise-Scale Agile Software Development comes in. This isn’t a book about trendy frameworks or surface-level tips. It’s a deep, honest look at what really changes—on the ground, in the boardroom, and everywhere in between—when a company decides to go agile for real.

What makes this book stand out is that it doesn’t pretend agile transformation is just about teams working faster. Schiel starts by asking a bigger question: Why change at all? And from there, he methodically builds a picture of what an enterprise needs to succeed—not just to implement Scrum, but to become truly agile in mindset, structure, and operations.

One of the first big shifts he highlights is the role of management. In traditional models, managers drive the work—they assign tasks, track hours, manage schedules. But in agile, their job changes completely. Suddenly, it’s about enabling teams, clearing roadblocks, and supporting self-organization. That might sound empowering, but it’s also disorienting. Schiel doesn’t shy away from that discomfort—he explains how organizations can reframe what leadership looks like in a system where control is replaced by trust and visibility.

And trust, it turns out, is everywhere in this book. It’s in the decision to let teams build their own schedules based on velocity instead of a top-down Gantt chart. It’s in the choice to prioritize learning over rigid planning, especially in the early stages of a transition. It’s even in how we approach feedback—Schiel argues that retrospectives and real-time collaboration are more than ceremonies; they’re core to how improvement actually happens.

But none of this happens in a vacuum. What really makes or breaks a transformation is how you start. Schiel walks us through creating a transition team, defining goals, building a backlog for the transition itself, and even setting up the budget. These parts are often skipped, but he makes a compelling case that if you want the rest to work, you have to treat the transition like a product—something with outcomes, feedback loops, and room to grow.

Then comes the execution. Schiel doesn’t offer magic frameworks. Instead, he focuses on what needs to be done: launching pilot projects with intention, building team rooms that actually support collaboration, creating training programs that prepare people for new ways of thinking. He explains how to plan sprints with realism, not hope. He shows how to monitor progress without falling back into micromanagement. And maybe most importantly, he keeps reminding us that agile isn’t an excuse to abandon structure—it’s a call to design better, leaner, and more human systems.

The book also gets into areas many agile books avoid, like how to handle ISO 9001 compliance, or how to involve customers who aren’t used to giving feedback every two weeks. These sections don’t just feel like add-ons—they’re critical insights for organizations navigating real-world constraints. Agile can’t afford to be idealistic. It has to work within the limits of finance, regulation, hierarchy, and legacy systems. Schiel shows how it can.

What stays with you after reading is not a list of steps to follow, but a mindset: Agility is not about doing more with less—it’s about doing the right things, at the right time, in the right way, with the people who actually do the work. And that’s hard. It requires cultural rewiring, structural redesign, and a whole lot of patience. But as Schiel proves throughout the book, it’s possible. With clarity, discipline, and a willingness to adapt, even the most traditional organizations can become more responsive, resilient, and aligned with what their customers actually need.

This isn’t a fast read. It’s dense, layered, and honest about how much work is involved. But if you’re serious about leading an agile transformation that sticks—not just on slides, but in behavior—this book is a companion worth having. It won’t promise shortcuts. It’ll help you build something better, one sprint at a time.

How to Actually Apply Enterprise-Scale Agile: A Step-by-Step Guide That Works

Reading a book like Enterprise-Scale Agile Software Development is inspiring—until you close it and wonder, “Okay… where do I start?” James Schiel gives you all the building blocks, but putting them together in a living, breathing organization takes more than good intentions.

The good news? You don’t need to change everything overnight.

In fact, trying to do that is the fastest way to fail. The trick is to treat the transformation like a product—and apply Agile to becoming agile.

Here’s how to do it.

Start with the Why: Before forming a team or running your first stand-up, you need to know why this matters. Is your organization trying to speed up delivery? Improve customer feedback loops? Adapt to fast-changing markets? Get crystal clear on what problem you’re solving with agile. This will guide every decision and keep you grounded when the process inevitably gets messy. Get leadership aligned—not just nodding along, but truly committed.

Build Your Transition Team: You can’t drive change alone. Form a cross-functional transition team made up of people from key departments: tech, HR, finance, operations, product. These folks will drive the transformation—not by issuing mandates, but by collaborating, experimenting, and learning. Think of them as a Scrum team for the transformation itself. Their job is to deliver change in small, iterative chunks, not write a 100-page strategy deck.

Create a Real Transition Backlog: This is where theory becomes practice. Build a living list of everything that needs to happen for the transition to succeed—training, tooling, communications, team setup, workspace changes, pilot project launches. Don’t try to plan the whole thing up front. Just start with what you know. Prioritize based on value and urgency, and update it as you go. If you’re treating this like a product, the backlog is your source of truth.

Define the Rules of Engagement: Now’s the time to define your organizational agreements. What does “done” mean? What’s the role of a Product Owner here? How will sprints work in your context? These shared agreements prevent confusion and misalignment as teams start working differently. Think of this as laying the foundation before you start building floors.

Choose Pilot Projects with Purpose: This isn’t about finding a perfect project. It’s about finding a good-enough one to learn from. Choose a product or initiative that’s small, visible, and relatively low-risk. Make sure the team is stable, the scope is clear, and the stakeholders are open to working in a new way. This pilot isn’t a demo—it’s the beginning of your scaled system. Treat it like the first engine that will pull the rest of the train.

Run a Setup Sprint: Don’t jump straight into coding. Give your pilot team a short sprint—call it Sprint 0—to get their bearings. Set up tools, agree on how to run stand-ups, define what “done” looks like, and prepare the backlog. This sprint is about building rhythm, not delivering features. It helps the team start strong instead of stumbling out of the gate.

Launch, Learn, and Adjust: Let the team start delivering in real sprints. Use velocity, retrospectives, and feedback to learn—not just about the product, but about how the team is working. The goal isn’t perfect delivery, it’s insight. How are roles playing out? What’s confusing people? What’s slowing them down? Capture all of it. Feed that learning back into your transition backlog. Agile thrives on real-time feedback—your transformation should too.

Support Teams Without Smothering Them: This is where many transformations stall. Leaders panic when teams miss a sprint goal or work “slower” than expected. Don’t fall into that trap. Early velocity isn’t a measure of success—learning is. Protect your pilot team, support your Scrum Master, and coach your Product Owner. If you intervene too much, you’ll kill the autonomy you’re trying to build.

Communicate Like It’s Your Job (Because It Is): Agile transformation creates uncertainty—and uncertainty fills the vacuum with fear. Your job is to communicate constantly. Share what’s happening, why it matters, what’s going well, and what’s changing. Not just in slide decks or memos—use stories, visuals, videos, whatever connects. Make the transition feel alive and human, not abstract and corporate.

Train Continuously: This isn’t a one-and-done training session. People need support as their roles evolve. Developers need to understand how to estimate stories. Product Owners need to prioritize. Managers need to learn how to coach instead of direct. Offer training just in time, not just in case. Reinforce it with mentoring, pairing, and practice.

Start Scaling One Team at a Time: Once your pilot team finds its footing, start rolling out to new teams. Don’t onboard everyone at once. Support each team like it’s your only one. Share lessons learned, reuse working agreements, but give each team room to adapt. Transformation isn’t copy-paste—it’s culture building, one team at a time.

Align Leadership with the New System: Leadership can’t stay in waterfall while the teams go agile. Help executives and managers understand how their role changes. Focus on outcomes, not output. Ask about value delivered, not hours worked. Agile at scale fails when leadership is disconnected from how the work actually happens.

Reinforce with Rhythm and Reflection: Use retrospectives across the entire transformation effort. What’s working across teams? What needs rethinking? Schedule regular syncs between the transition team, pilot teams, and leadership. Keep learning visible and make small course corrections along the way. Agile isn’t a switch you flip—it’s a direction you walk in, together.

Chapter by Chapter

Chapter 1 – Introduction

The book begins not with theory, but with a personal story. James Schiel recalls the moment he unknowingly walked into one of the biggest professional challenges of his life: leading a massive agile transformation for a 1,400-person organization. He had no roadmap, no perfect plan—just a conviction that change was needed and a lot of trust in his team and leadership. Over the next four years, what followed was a mix of successes, mistakes, and learning. This book, he says, is the resource he wishes he’d had back then.

A practical toolkit, not a perfect recipe

Right away, Schiel makes something very clear: this isn’t a step-by-step manual. Agile isn’t about strict instructions. It’s about people, context, and adaptation. Some parts of this book might work for you exactly as written, some may need tweaking, and others won’t apply at all. But it will give you something even more valuable—a thoughtful starting point to help you avoid blind spots and make better decisions as you shape your own agile journey.

He even adds a touch of humor, noting that if you try reading it cover to cover, it might double as a cure for insomnia. Instead, use it as a reference, picking the parts you need when you need them.

Scrum, XP, and ISO—yes, all three

Schiel builds his guidance around two core Agile approaches: Scrum as the organizational framework, and Extreme Programming (XP) as the foundation for development practices. He also weaves in quality-focused techniques inspired by ISO 9001—not because everyone needs the formality, but because good discipline tends to produce good software.

Every choice is a balancing act

Throughout the book, you’ll notice Schiel never pushes a single “right way.” Instead, he shows different options, explains their pros and cons, and encourages you to pick what fits your environment. Agile at scale is not about copying another company’s method—it’s about intentional decision-making.

Who this book is for

Although the book speaks to everyone involved in agile—from developers to executives—it’s written through the eyes of someone leading a transformation. It focuses on the real-world concerns of that role: what to prepare for, what can go wrong, and how to steer the ship.

He also makes a legal reminder: transitioning to agile can touch areas like labor laws and compliance. So, if your environment is highly regulated, get experts involved early.

The 8 success factors you need before you begin

This is perhaps the most useful part of the introduction. Schiel outlines the key ingredients he believes must be present for a successful agile transition. If you don’t have them yet, they should be your first priority.

1. Executive support – You need leadership buy-in, not just for funding and space, but for cultural change.
2. Early wins – Choose pilot projects carefully. Avoid big risky bets. Small, early wins build momentum.
3. Automated testing – Continuous integration and frequent delivery only work if you can test fast and reliably.
4. Management engagement – Mid-level managers must enable agile practices daily, or the change will quietly stall.
5. Developer commitment – Agile only works when developers care about doing the right thing for the product.
6. Discipline – Agile isn’t chaos. It’s structured flexibility, walking the line between freedom and order—like walking near the edge of the Grand Canyon with caution and clarity.
7. Patience – Cultural change takes time. Morale might improve quickly, but product quality and maturity? That takes longer.
8. Willingness to fail – Embrace mistakes. Learn from them fast. Agile is built on the cycle of trying, learning, and improving.

Some suggested reads

He closes the chapter by recommending several books by well-known Agile authors like Ken Schwaber, Mike Cohn, Kent Beck, and others. These are for anyone who wants to go deeper into specific practices like Scrum, user stories, test-driven development, or retrospectives.

Chapter 2 – Why Agile?

Before diving into the how of agile development, Schiel starts with a more fundamental question: Why do this at all? His answer is refreshingly blunt—businesses want to make more money. That’s the core motivation. Even though agile brings better collaboration, faster feedback, and improved quality, none of that matters if it doesn’t ultimately help the organization’s bottom line. Unless you’re a government agency or a deeply funded exception, profitability still rules the game.

Clearing up common myths

Schiel takes time to address the myths that often scare organizations away from agile or cause them to misunderstand its purpose.

First, there’s the idea that agile does little planning or analysis. Not true. Agile simply spreads these activities across the project instead of front-loading them all at the beginning. It’s like just-in-time inventory—only doing what’s needed when it’s needed, to avoid waste.

Then there’s the belief that agile avoids documentation. Again, false. Agile teams do document things—but only if there’s a clear need or someone who will actually read it. Writing just for the sake of compliance or tradition isn’t the point.

Another myth is that agile erases roles or forces everyone to do everything. While it’s true that agile encourages cross-functionality and collaboration, it doesn’t eliminate roles—it just prioritizes team success over strict job definitions.

And finally, the myth that agile can’t provide reliable schedules. Agile doesn’t pretend to offer fixed-date, fixed-scope certainty. Instead, it gives you flexibility—delivering high-priority work first and making it easier to adapt plans along the way. That’s not a weakness; it’s honest project management.

Why agile is still hard to adopt

Despite the benefits, Schiel acknowledges that many organizations avoid agile for one simple reason: it’s hard. It challenges old habits, forces you to face your organizational dysfunctions, and demands change across the board. If you’re not ready to accept disruption or rethink the way your company operates, you probably shouldn’t jump into agile just yet.

There’s also the intimidation factor. Agile terminology—Scrum, sprint, planning game, Extreme Programming—can sound alien to executives, and the cultural shift required can be overwhelming. But often, the real issue is deeper: many organizations have built layers of process to hide or soften the impact of internal dysfunction. Agile peels that back. If you’re not ready to deal with what you find, the transition won’t stick.

So… why go agile anyway?

Because the benefits, when done right, are worth it.

Improved software quality is one of the most consistent outcomes. Practices like continuous integration, test-driven development, and clearly defined “done” criteria all help ensure better, more stable software throughout the development process—not just at the end.

Greater team and organizational commitment also show up. Agile teams get regular feedback, visibility into how their work impacts users, and a rhythm that keeps them focused. It fosters ownership and engagement.

Reduced waste is another key win. Agile doesn’t do unnecessary work—it plans and analyzes just enough to move forward. It defers decisions until the last responsible moment and avoids deep dives into features that might never see the light of day. The goal is to minimize rework and focus on what truly matters.

Better customer relationships come from close, ongoing collaboration. Agile invites the customer in—asking them to review, prioritize, and help shape the product as it evolves. This involvement makes customers feel heard, valued, and invested, often turning them into partners instead of passive recipients.

In the end…

Going agile isn’t about chasing a trend. It’s about committing to a better way of working, even when that means facing tough truths and changing deeply ingrained habits. If your organization is willing to embrace that challenge—and if you’re clear on why you’re doing it—agile can absolutely pay off.

Chapter 3 – Transitional Concepts

Before diving headfirst into agile, Schiel encourages us to pause and consider where we’re heading. This chapter is about laying the foundation for a successful agile transition. It’s like prepping the runway before takeoff—if the surface is bumpy or unclear, you’re not going to get very far.

What is agile development, really?

At its core, agile isn’t about rituals or buzzwords. It’s about four big ideas: valuing people over processes, focusing on working software over documentation, collaborating with customers, and embracing change rather than resisting it. The chapter assumes you’re going with a Scrum and XP combo, but it makes room for other agile flavors too.

How workflow works in agile

Schiel breaks down the agile workflow starting with the Product Backlog, a dynamic list of features, bugs, tech improvements, and more. These items, called PBIs (Product Backlog Items), are shaped and prioritized by the Product Owner, with input from business needs, customers, and technical realities.

Then comes grooming—a continuous process of slicing big PBIs into smaller, actionable chunks. Teams document insights, refine items, and make sure they’re ready for a sprint. The goal is to have clear, understandable items that can be completed in less than a week by a small group.

Defects and technical debt get treated seriously too. If something’s broken or outdated, it goes into the backlog, gets researched, and rewritten into something actionable. A vague complaint becomes a clearly defined fix.

Sprint execution is where the real magic happens. Teams take PBIs from the top of the backlog, build and test them during the sprint, and demo them at the end. If something’s not done right, it goes back into the backlog—not as a failure, but as part of the process.

Beta testing and defect handling are baked into the cycle. Feedback loops never stop.

The evolving product backlog

Agile backlogs are never “done.” They’re always changing as priorities shift, requirements evolve, and new ideas emerge. The top items are the most refined and smallest—ready for action. The bottom? Often big, vague, or maybe not even necessary.

This backlog should reflect the product owner’s vision. It must be visible to the whole organization and constantly reprioritized.

Writing stories that make sense

Here’s where Schiel gets practical. He explains how to turn old-school requirements into useful user stories. Instead of “The system shall…” language, agile asks: Who wants what and why?

For example, a requirement like “The last name must be 30 characters or less” is meaningless in isolation. But if you reframe it as part of a user story—“As a customer, I want to register my name and address so I can get more product info”—it suddenly has context and value. The character limits then become acceptance criteria, not standalone demands.

Schiel even tackles nonfunctional requirements—performance, standards, tech stacks. These don’t fit neatly into user stories, so he suggests keeping a separate checklist that applies across stories, ensuring that quality and compliance are never forgotten.

Slicing stories into smaller ones

When stories get too big, slice them up. Instead of “register name and address,” split it into two stories: “register name” and “register address.” Each becomes more manageable and easier to estimate.

In short, this chapter sets the stage for your transition. Agile isn’t just about doing things differently—it’s about thinking differently. And that starts with how we structure work, talk about requirements, and build collaboration into every step of the process.

Chapter 4 – Transition Barriers

This chapter is where things get real. Schiel doesn’t sugarcoat it: transitioning to agile is hard, and many organizations fail—not because agile doesn’t work, but because the organization isn’t ready to change. This chapter explores what gets in the way and what to watch out for before and during the shift.

Why agile transformations fail

Schiel begins by outlining a hard truth: even well-meaning agile transitions can crash and burn. He lists several common reasons:

• Lack of commitment from leadership
• Resistance from middle management
• Confusion about what agile really is
• Underestimating how much discipline agile requires
• Trying to “do” agile without changing the culture

These aren’t small obstacles—they’re fundamental. If you ignore them, your agile adoption will likely become superficial or collapse entirely.

The problem with “agile by name only”

Many companies want the benefits of agile—speed, innovation, happier teams—but without giving up their old habits. So, they slap agile labels on their processes without changing how decisions are made, how people work, or how success is measured. Schiel calls this out as one of the biggest traps: using agile terms while keeping a waterfall mindset underneath.

When leadership gets nervous

One of the biggest challenges comes when management doesn’t truly support agile. Maybe they like the idea, but once things get uncomfortable—like missing delivery dates or seeing fewer traditional documents—they panic. This fear leads to micromanagement or reverting to old processes “just to be safe.” And that kills the transformation.

The culture shock of agile

Agile brings a completely different way of thinking. Instead of top-down control, it encourages self-organization. Instead of full specs up front, it thrives on constant learning. This shift can feel chaotic and uncomfortable, especially for organizations built around strict roles, rigid schedules, and a blame-heavy culture.

That’s why cultural inertia is such a strong barrier. If people aren’t ready to work differently—to share responsibility, accept uncertainty, and focus on outcomes—agile simply won’t stick.

Trust issues and fear of failure

Schiel emphasizes how fear holds people back. In traditional environments, failure is punished, so teams play it safe. But agile expects failure—it builds learning and adjustment into the process. If people don’t feel safe to try, experiment, or be honest about problems, agile can’t work. Trust, psychological safety, and open communication are essential.

Middle management: stuck in the middle

Middle managers are often caught in the toughest spot. They’re told to support agile, but also expected to hit delivery dates, manage teams, and follow old performance metrics. Many feel lost—unsure of their new role or afraid of losing relevance. If they don’t get clarity, training, and a new purpose, they can become blockers instead of enablers.

So, what can we do?

Schiel doesn’t offer quick fixes, but he makes one thing clear: success starts with awareness. Before launching into sprints and standups, organizations need to ask hard questions:

• Are we ready to give up control?
• Are we willing to trust teams and learn from failure?
• Do we have executive support and a culture that values collaboration?
• Can we be patient, knowing that real change takes time?

Chapter 5 – Management in an Agile Environment

This is one of the richest chapters in the early part of the book, and it hits right at the heart of agile transformation: what happens to management when teams become self-organizing? If agile empowers teams, what do managers do? This chapter offers a thoughtful and surprisingly honest look at the evolving role of management—and why it’s still crucial.

The myth of “no managers”

Let’s clear this up: agile doesn’t eliminate managers. That’s a common myth. Instead, it redefines their purpose. Traditional management is often about control—assigning tasks, checking progress, making decisions. But in agile, the power to make many of those decisions shifts to the teams. So, managers need to evolve from taskmasters to enablers.

Schiel compares this transition to parenting a teenager. When your child is young, you give direct instructions. But as they grow, you shift toward support, guidance, and trust. That’s what agile expects from management: less control, more coaching.

Management still matters—a lot

Schiel is very clear about this: agile does not work without strong management. But “strong” doesn’t mean domineering. It means present, engaged, and focused on creating the right environment.

Agile managers need to:

• Set clear goals aligned with strategy
• Remove obstacles that block team progress
• Encourage growth and learning
• Foster collaboration across teams
• Create psychological safety

They may not decide how the code is written or who works on which feature, but they have an even more powerful job: shaping the system in which the work happens.

The shift in mindset

This chapter is all about mindset change. Schiel argues that managers must move away from directing individual performance and instead focus on team-level outcomes. That’s hard. Many managers were promoted because they were good at solving problems themselves. Now, they’re being asked to step back and let teams figure things out. That can feel like losing control.

But Schiel insists this shift is necessary. Managers who cling to old habits—approving every decision, assigning tasks, demanding updates—create bottlenecks. They slow things down and kill team autonomy.

Leadership as service

One of the most powerful themes here is that agile management is servant leadership. That’s not a buzzword—it’s a total reframe. In traditional organizations, teams exist to serve management. In agile, it’s flipped: management exists to serve teams.

This means helping teams succeed by giving them what they need—not just tools and training, but also time, clarity, and protection from unnecessary interruptions. It also means trusting them to own their work, even when they stumble.

Schiel offers a simple but strong image: agile teams walk near the edge of a cliff. Managers don’t hold their hands—but they make sure the edge is clearly marked, safe, and free of traps.

Dealing with fear and loss of identity

Schiel doesn’t ignore the emotional side of this change. Managers often feel anxious during agile transitions. They worry about losing status, relevance, or even their jobs. Some resist by micromanaging; others check out entirely. That’s why organizations must support managers too.

They need training, new metrics, and a clear understanding of how their role evolves. Without that, even the most well-intentioned manager can become a barrier to agile.

What great agile managers do

By the end of the chapter, Schiel outlines what good agile management looks like in practice:

• They trust teams to solve problems, but stay close enough to coach and guide.
• They facilitate rather than dictate.
• They create an environment of experimentation—where failure is okay if we learn from it.
• They promote alignment across teams, helping everyone stay connected to a shared purpose.
• They know when to step in, and when to stay out of the way.

Chapter 6 – Create the Transition Team

In this chapter, Schiel moves from concepts to action. Now that the foundations are clear—why agile, what the barriers are, and what management’s role looks like—it’s time to assemble the group that will lead the transition. And this isn’t just any task force. This is the team that will design, guide, and push through the deep organizational change that agile requires.

Why a transition team matters

Schiel starts by explaining that no transformation can succeed without a dedicated team to lead it. Agile touches every corner of the organization, from how teams work to how customers are involved, so you need a group that reflects that diversity. The transition team isn’t there to implement agile directly, but to create the environment that allows it to thrive.

It’s not just about managing change—it’s about building trust, removing friction, and helping people let go of old habits. That kind of change doesn’t happen from a PowerPoint presentation. It needs people who are living and breathing the transformation from day one.

Who should be on the team

The key message here is inclusion. The transition team should represent the whole organization, not just the leadership layer. That means you bring in developers, testers, tech writers, architects, and business analysts—people who are actually impacted by the change. This mix brings different perspectives and prevents the transition from being top-down or disconnected from reality.

Schiel also makes a strong case for choosing people who are open-minded, influential, and respected. Not necessarily the most senior folks, but those who others will follow. He recommends working with department heads to nominate the right people—those who care deeply about making the organization better, not just those with free time on their calendars.

Structuring the team for scale

In smaller companies, one transition team might be enough. But in larger organizations, you’ll likely need a core team supported by sub-teams. The sub-teams focus on specific workstreams like tools, training, customer communication, and infrastructure. Meanwhile, the core team keeps the whole effort aligned, prioritizes work, and keeps leadership informed.

Each sub-team has a lead, and together, they form a kind of agile transition “network.” This setup ensures you can move fast without losing cohesion.

The role of the transition owner

Every transition team needs a transition owner—someone who plays the same kind of role as a product owner in Scrum. This person doesn’t make all the decisions alone, but they are accountable for the transition backlog, prioritizing work, and guiding the team toward the vision. It’s a critical role, and Schiel warns against assigning it to someone who’s only “kind of” available. This needs real focus.

The executive sponsor’s influence

The other key role is the executive sponsor. This is the leader who gives the transition credibility and clears the path when things get difficult. Their job is to support the team, defend the time and resources needed, and show—through words and actions—that the organization is serious about this shift.

One of the most insightful points here is that the executive sponsor must be visible and active. If they’re absent, the message is clear: this change isn’t a priority. So they need to be engaged in reviews, decisions, and even setbacks. Their presence gives the team the authority and protection it needs to succeed.

Start small, grow wisely

Schiel encourages starting with a small, committed team, then expanding as needed. The early focus should be on learning, building credibility, and gaining early wins—not boiling the ocean. As the team builds confidence and influence, they can take on more.

Chapter 7 – Define the Organizational Agreements

After building the transition team, the next big step is getting everyone on the same page about how agile will actually function in your organization. That’s what this chapter is about—defining the organizational agreements that set expectations, reduce misunderstandings, and create alignment across leadership.

Why agreements matter

Schiel opens with a warning: many agile transitions fail not because the teams don’t want to change, but because leadership doesn’t agree on what change looks like. Without clear agreements, you’ll constantly run into mixed messages—one manager wants strict velocity targets, another expects full documentation, and someone else thinks developers should estimate work without participating in planning.

These conflicting assumptions confuse teams and undermine the transformation. So, before launching pilot teams or holding your first standup, you need to hold a workshop to define the agreements that will shape your version of agile.

The workshop: getting leadership aligned

Schiel recommends pulling in key players from across the organization: executives, directors, managers, architects, and maybe even representatives from operations or compliance. This isn’t just about process—it’s about changing how work happens at a systemic level.

During the workshop, the group answers core questions that define how agile will operate. These aren’t abstract—Schiel gives specific examples of what to decide on:

• Will Scrum Masters be full-time or part-time roles?
• How will teams be formed—and will they stay stable?
• Who’s responsible for defining what’s built?
• Will teams estimate their own work or will it be imposed?
• Can we limit multitasking or will people work across multiple projects?
• Will the team be protected during a sprint or can leadership insert new work?

Each answer reflects a decision about trust, control, and accountability. Schiel’s point is that these choices shape the culture. If leadership says teams are empowered, but still assigns tasks top-down, you’re not doing agile—you’re pretending.

Documenting the agreements

The output of the workshop isn’t just alignment—it’s a written set of working agreements. These should be published, shared, and visible to the whole company. They’re not just rules—they’re a signal that leadership is serious about supporting the new way of working.

Schiel makes it clear: these agreements aren’t permanent. They’ll evolve. But starting with a shared understanding sets the tone. And if you don’t write them down, expect drift, confusion, and resistance later.

Planning for the tough conversations

One of the most honest sections in the chapter addresses the reality that not everyone will thrive in an agile environment. Some developers won’t want the increased collaboration or accountability. Some managers will struggle to let go of control. And some customers will need help adjusting to more frequent delivery and involvement.

The transition team—and especially the leadership—needs to be ready to handle this. That doesn’t mean being harsh. It means creating support, training, and open conversations. But it also means being clear: the way we work is changing, and opting out isn’t a long-term option.

Chapter 8 – Determine Transition Goals

After building the team and aligning leadership, Schiel shifts focus to something critical—but often overlooked: why are we doing this at all? In this chapter, he explains that before launching any major change, especially one as disruptive as agile, you need to define your goals. Without goals, the transition becomes a collection of activities with no clear purpose. And without a clear purpose, it’s hard to know if you’re succeeding—or just spinning in circles.

The problem with vague intentions

Many agile transformations begin with good intentions: “We want to be more responsive,” or “We want to deliver faster.” But Schiel points out that these goals, while inspiring, are too vague to guide decisions. They don’t tell you what to prioritize, how to measure progress, or when to adjust course.

So he makes the case for setting concrete, measurable goals—ones that make it clear what success looks like.

Business value as the foundation

The author reminds us that any agile transition, no matter how idealistic it sounds, needs to deliver business value. Agile isn’t about being trendy or holding better meetings—it’s about producing better results for the organization. That might mean delivering software faster, reducing costs, improving quality, increasing employee engagement, or all of the above.

Whatever the goals are, they must be relevant to the organization’s real needs. Schiel emphasizes that teams should work with leadership to define these goals clearly, in a language that makes sense to everyone involved.

GQM: Goal – Question – Metric

To bring structure to this, Schiel introduces the GQM method—a practical way to turn high-level goals into actionable measurements.

Here’s how it works:

• Start with a goal: For example, “Reduce customer-reported defects by 50%.”
• Ask questions: What kind of defects are being reported? Where do they come from? Are they concentrated in a specific feature?
• Define metrics: How will you track progress? Number of open defects? Time to resolution?

What’s useful about GQM is that it helps teams avoid measuring things just because they’re easy to track. Instead, it keeps measurement tied directly to purpose.

The danger of misuse

This part of the chapter is especially thoughtful. Schiel warns that metrics, even well-intentioned ones, can be misused. If teams feel like metrics are being used to punish them—or if those metrics are tied to personal performance reviews—they’ll start gaming the system.

That’s when people inflate estimates, hide problems, or “check the box” without improving anything. It turns the transition into a numbers game rather than a culture shift.

So, he offers simple advice: only measure what matters, and make the purpose of those metrics transparent and safe. Let teams be part of the conversation. Create a culture where metrics are used for learning and improvement—not control.

Control limits and variability

One of the more advanced ideas in this chapter is using control limits—an approach borrowed from quality management. Schiel explains that any team’s performance will naturally fluctuate. A spike in defects or a dip in velocity doesn’t always mean something’s wrong.

Instead of reacting to every variation, teams and managers should define acceptable upper and lower bounds. If a metric stays within those limits, it’s probably just natural variation. If it goes outside, then it’s time to explore the cause.

This avoids micromanagement and builds trust. It also reinforces a key agile mindset: systems improve through observation and adaptation, not fear and overreaction.

Use metrics to support, not scare

The final message in the chapter is simple but powerful: use metrics to guide and encourage, not to coerce. Metrics should help teams understand themselves better and help leadership make smarter decisions. When done well, they provide focus, alignment, and momentum. When done poorly, they create stress, manipulation, and resistance.

Chapter 9 – Create the Transition Backlog

Now that the team is in place, agreements are set, and goals are defined, Schiel turns his attention to execution. This chapter is about organizing the actual work of the transition—and the tool for that is the transition backlog. If the transition were a product, this backlog would be its roadmap.

Why a backlog? Because change is complex

Just like building software, transforming an organization is a complex, evolving effort. You don’t know everything upfront. Priorities shift, new insights emerge, and obstacles appear. That’s why a living, prioritized list—instead of a rigid plan—is the best way to manage the transition work.

The transition backlog keeps things visible, trackable, and actionable. It prevents chaos and allows the team to focus on what matters most at each stage of the journey.

What goes into the backlog?

Schiel is very clear that the backlog should include everything the transition team might need to do—from early planning to later-stage rollout. This includes:

• Communicating the change
• Developing training programs
• Creating metrics and dashboards
• Engaging customers and stakeholders
• Selecting pilot teams
• Managing tools and infrastructure
• Supporting role transitions

Nothing is too small or too big. If it supports the success of the transition, it belongs in the backlog.

Some items will be vague at first—just placeholders. Others will be detailed and ready to act on. That’s normal. Like a product backlog, the transition backlog evolves over time as more is learned.

Kickoff meeting: setting the tone

Once the transition team is formed, Schiel recommends holding a kickoff meeting. This isn’t just to hand out assignments—it’s about creating shared understanding and energy.

During the kickoff, the team discusses the goals of the transition, reviews the backlog, and agrees on how they’ll work together. Will they use sprints? Who’s responsible for what? How often will they meet? How will they track progress?

This is also where sub-teams are officially launched. If the organization is large, you might have sub-teams for things like tooling, customer communication, or training. Each sub-team gets its own mini-backlog, drawn from the larger transition backlog, and focuses on delivering its part of the transformation.

The role of the transition owner (again)

The transition owner, introduced in Chapter 6, takes on a product owner-like role here. They prioritize the backlog, ensure clarity, and help the team stay focused on delivering value. That might mean choosing which training to build first or deciding when to roll out a pilot team.

Just like in Scrum, this person doesn’t dictate how the team works—but they own the “what” and the “why” of the transition effort.

Open contribution, focused execution

Anyone can suggest new backlog items—from developers to executives. But the transition team decides what makes it into the backlog and how it should be prioritized. This openness keeps the backlog responsive and connected to reality, while the structure prevents it from becoming chaotic.

Start small, deliver fast

The final lesson in this chapter is one of agile’s core principles: start small. Don’t try to change the whole organization at once. Pick a few high-priority items, deliver them well, and use what you learn to improve the next steps. This builds momentum and confidence.

Schiel isn’t promising a flawless rollout. He’s offering a realistic, adaptive way to move forward—one backlog item at a time.

Chapter 10 – Beginning Transition Sprint 1

This chapter marks the turning point where planning shifts into real execution. Schiel refers to it as Transition Sprint 1—the first iteration where the transition team starts delivering change instead of just preparing for it. But this sprint is not just symbolic. It sets the tone for how the entire agile transformation will unfold.

Start small, learn fast

One of Schiel’s key messages is that this first sprint should focus more on learning and organizing than trying to deliver massive change. Yes, there are tasks to complete—but the goal is to figure out how the transition team works together, how they manage their backlog, and how to build momentum.

In many ways, Sprint 1 is like a warm-up. The team is forming. People are learning their roles. The backlog is still being refined. And that’s okay. What matters is that the team starts practicing what they preach—working iteratively, inspecting and adapting, and being transparent about progress.

What to expect in Sprint 1

Schiel lays out the kinds of tasks that might show up in the first sprint’s backlog. Some are foundational, like:

• Finalizing the communication plan
• Finishing training materials
• Preparing facilities for pilot teams
• Defining tool needs
• Drafting customer engagement strategies

Other tasks might involve outreach—like meeting with executives or introducing the transition plan to key departments.

But here’s the important part: nothing big rolls out yet. Sprint 1 is not when you launch your first agile team or hold your first daily stand-up across the company. It’s when the transition team gets its own agile engine running.

Using Scrum to manage the transition

The transition team uses Scrum to manage its own work—just like the delivery teams eventually will. That includes:

• A prioritized transition backlog
• Sprint planning
• Daily stand-ups
• Sprint reviews
• Retrospectives

This not only brings structure, but it also builds empathy. When the transition team lives through the agile experience themselves, they better understand what delivery teams will face. They’ll be more prepared to coach, support, and remove blockers because they’ve felt the friction firsthand.

Deliver something visible

Even though Sprint 1 is focused on getting organized, Schiel recommends delivering something visible. Maybe it’s the first version of the communication plan. Maybe it’s a training draft or a walkthrough of proposed tool changes. Whatever it is, it should be something that can be reviewed with stakeholders at the end of the sprint.

This creates a sense of progress, builds trust, and starts the feedback loop early.

Get feedback early and often

Sprint reviews are essential from the start. Schiel suggests inviting the executive sponsor, department heads, or other leaders to these sessions. This keeps leadership engaged and gives them a front-row seat to the transition as it evolves. It also signals that the transition is real—and that it’s happening in the open.

Retrospect and adapt

Just like any Scrum team, the transition team runs a retrospective at the end of Sprint 1. What worked? What didn’t? What will we change in Sprint 2? These early retrospectives are gold. They help the team learn how to collaborate, uncover misalignments, and course-correct before bigger issues arise.

Chapter 11 – Create the Transition Budget

In this chapter, Schiel turns to something that makes many transformation efforts feel very real, very fast: money. Agile isn’t just about values and post-its on the wall—it needs a budget. And if you’re serious about making the transition work, you need to treat that budget as part of your strategic investment, not an afterthought.

Budgeting with intention

Schiel emphasizes early on that budgeting for an agile transition is a business decision, not just an administrative one. The transition costs money—sometimes a lot of it. But that cost is tied to real, measurable goals like increased product quality, faster delivery, and better alignment with customer needs. If done well, the return on investment is substantial.

Still, someone has to justify the spend. That’s why the transition team and executive sponsor need to work together to build a clear, credible, and defensible budget.

What to include in the budget

This is one of the most practical chapters in the book because Schiel lays out exactly what you should expect to spend money on. It’s not just about buying sticky notes or paying for a few workshops. A serious transformation has serious components, including:

• Training – Internal or external, for all roles (Scrum Masters, Product Owners, developers, testers, and even executives). This can be one of the biggest costs, but also one of the most important.
• Consultants or coaches – Many organizations bring in experienced agile coaches to guide the transition, especially in the early stages. These experts help avoid common mistakes and tailor the transition to the organization’s context.
• Tooling and infrastructure – Agile requires good tools for backlog management, CI/CD pipelines, test automation, and collaboration—especially if teams are distributed.
• Communication and marketing – Schiel points out that communication during a transition is so critical that it deserves its own line item. Whether it’s creating internal videos, posters, or events, spreading the message costs money.
• Team logistics and facilities – From reconfiguring workspaces to supporting new collaboration models, the physical side of the change often requires resources.
• Ongoing support – The transition doesn’t stop after Sprint 1. Sustaining the momentum through future sprints, scaling efforts, and supporting late adopters will continue to draw resources.

Schiel even includes things like time from full-time employees—because dedicating staff to the transition means they’re not working on other initiatives. That lost opportunity has a cost, too.

Be realistic—and transparent

One of the most grounded messages in this chapter is that your first budget will be wrong. You can’t predict everything. But that doesn’t mean you don’t need a budget. It means you need to be open about assumptions and flexible as the transition unfolds.

He suggests presenting the budget to leadership in a way that shows tiers or phases: the minimum needed to start, the ideal plan for full transformation, and a stretch version if things go better than expected. This helps manage expectations while also showing that the transition team is being thoughtful and strategic.

Making the business case

Schiel emphasizes that agile transitions are often competing for funding with other initiatives—product launches, marketing campaigns, hardware upgrades. So your transition budget has to come with a business case. What’s the expected benefit? What pain points are you addressing? What improvements are likely, and what will they mean in terms of speed, quality, and customer satisfaction?

In some cases, the benefits might be indirect—like higher team morale or reduced attrition. In others, they’ll be tangible: fewer defects, faster release cycles, or improved customer retention. The key is to tell the story of why this investment makes sense.

Monitor and revisit

Finally, budgeting doesn’t end once it’s approved. The transition team should treat the budget like a living document—reviewing it regularly, comparing forecasted costs to actuals, and adjusting as needed. Agile is about adaptation, and budgeting is no exception.

Chapter 12 – Develop the Transition Communication Plan

Schiel opens this chapter with a clear truth: agile transitions live or die on communication. No matter how solid your plans or how well you define your goals, if you don’t communicate effectively, confusion will take over—and with it, resistance, rumors, and wasted energy.

This chapter is about designing a communication plan that not only shares information but builds trust, reduces fear, and creates engagement. Because in times of change, silence breeds anxiety, and anxiety kills momentum.

Why communication must be intentional

One of the strongest messages here is that communication in a transition isn’t just about sending status updates. It’s about guiding people through uncertainty. Schiel compares it to any significant life event—people don’t resist change itself; they resist the unknown.

That’s why the communication plan isn’t just a checklist of emails or meetings. It’s a strategic framework for how the organization will talk about the transformation—why it’s happening, what’s coming next, and how people are involved.

Four communication channels to cover

Schiel identifies four major channels that your plan needs to address:

1. To the teams and departments: This is about informing the people who will experience the most immediate change—developers, testers, analysts, and managers. What will change for them? What support will they have? How do they participate?
2. To the rest of the organization: Even teams not going through the transition right away need to understand what’s happening. They need to know that agile is coming, what it means, and why it matters.
3. To customers: This is often overlooked. Customers will notice changes—in delivery cadence, in how feedback is handled, maybe even in who they interact with. You can’t assume they’ll adapt on their own. The communication plan needs to include a strategy for bringing them along, too.
4. To executives and stakeholders: These are the sponsors and decision-makers. They need frequent, focused updates—usually in a different language than what the teams hear. Not technical details, but progress against goals, return on investment, and risk management.

Each of these audiences has different needs. Schiel’s advice is to tailor the message—don’t blast the same memo to everyone and expect it to land.

Transparency beats perfection

This part of the chapter is especially human. Schiel argues that trying to spin the transition as smooth and flawless will backfire. People can sense when they’re being sold a story. Instead, he suggests embracing honest, transparent communication—even when things are messy.

Share what’s working, but also what’s not. Acknowledge that not all questions have answers yet. Let people see the real process. When the transition team models vulnerability, it gives permission for others to be open too. That creates a culture of trust.

Two-way communication is non-negotiable

Schiel emphasizes that communication has to be bi-directional. This isn’t a broadcast—it’s a conversation. People need places to ask questions, raise concerns, and give feedback. That might be through town halls, Q&A sessions, Slack channels, anonymous forms—whatever fits your culture. But if communication only flows top-down, the plan has already failed.

He even suggests assigning a communication team or champion within the transition team—someone responsible for ensuring that this isn’t just “extra work” but a dedicated, ongoing effort.

Celebrate and humanize

Lastly, Schiel reminds us that communication can be a tool for motivation. Celebrate small wins, highlight team stories, share successes in ways that make people feel proud. Don’t just talk about metrics—talk about progress in human terms.

When people feel included and informed, resistance drops. Curiosity goes up. And even those who were skeptical at first might lean in instead of pulling away.

Chapter 13 – Create the Training Plan

In this chapter, Schiel tackles one of the most crucial and underestimated elements of any agile transition: training. If communication is about telling people what’s happening and why, then training is about equipping them to live it.

You can’t just say “we’re agile now” and expect people to instinctively know what that means. Agile introduces new roles, new ways of thinking, and entirely new behaviors. Without intentional training, even your most talented teams will flounder.

Training is not optional

Schiel is clear: training is a non-negotiable investment. Agile challenges people’s assumptions about work—how to plan, how to collaborate, how to lead, and how to deliver. So whether you’re coaching executives or onboarding developers, you need to prepare them for this new world.

He’s also honest: even with great training, people will struggle at first. But without training, the transition can become chaotic and demoralizing. This is where many agile transformations lose momentum—because people are expected to change, but they’re not taught how.

One size doesn’t fit all

One of the key insights in this chapter is that different audiences need different kinds of training. Schiel breaks this down clearly:

• Executives and senior managers need to understand agile principles, the business case, how success will be measured, and what their new role is in supporting agile teams. This is not about teaching Scrum mechanics—it’s about shifting mindsets at the top.
• Middle managers and functional leads are often the most confused and concerned during a transition. They need training on their evolving responsibilities, how to support self-organizing teams, and how to align goals without micromanaging. Schiel recommends starting their training early—they’re key influencers.
• Team members (developers, testers, analysts, etc.) need practical, hands-on training. This includes not just the theory behind agile, but also tools, ceremonies, estimation, test automation, continuous integration, and real-life simulations of how agile teams operate.
• Product Owners and Scrum Masters need deep, role-specific training. These roles are critical to success, and Schiel strongly advises providing more than just a short overview. They need mentoring, coaching, and opportunities to practice their role in safe environments.
• Customers and stakeholders also need training, especially if they’re going to be actively involved. Agile assumes a partnership between teams and customers—so those customers need to know what’s expected, how feedback loops work, and how to collaborate in the process.

Internal vs. external training

Schiel weighs the pros and cons of using external trainers versus building an internal training program. External experts bring credibility, experience, and structure, especially in the early stages. But over time, the goal should be to internalize knowledge—to build your own agile coaches, mentors, and facilitators.

In fact, he encourages identifying people early who can evolve into internal trainers. These are the people who will carry the transformation forward long after the initial workshops are over.

Training as a long-term investment

Another powerful reminder in this chapter: training isn’t a one-time event. Agile capability develops over time. People need refreshers, role-specific deep dives, and space to ask new questions as challenges arise.

He recommends maintaining a training backlog—just like the product and transition backlogs—with evolving needs, feedback, and improvement opportunities.

Prepare for discomfort

This part of the chapter is especially honest. Training will surface anxiety, resistance, and even fear. Agile often makes people feel exposed—especially those who have relied on command-and-control structures for years. That’s normal. And it’s why training needs to be done with empathy and a clear understanding of the emotional side of change.

Good training doesn’t just teach practices—it helps people feel safe enough to try something new.

Chapter 14 – Facilities Planning

This chapter explores something most agile guides gloss over, but Schiel gives it the attention it deserves: the physical environment. Agile isn’t just a mindset—it’s a way of working that’s deeply affected by how teams are set up in space. The layout of desks, meeting areas, whiteboards, and even how far people sit from each other can either support or sabotage collaboration.

Schiel begins with a simple point: agile teams need constant communication, and that’s easier when people can see, hear, and interact with each other naturally. Traditional office layouts—with cubicles, closed doors, or teams scattered across floors—don’t support this well.

Co-location: more than a buzzword

The ideal setup, according to Schiel, is co-location. That means a team works in the same physical space where everyone—developers, testers, product owners—can interact quickly and informally. Agile thrives on real-time discussions, spontaneous problem-solving, and visual tracking of work. When you put people together, these things happen organically.

He’s realistic, though. Not every organization can rearrange offices overnight. Some teams are spread out, some are remote, and some office cultures are resistant to open space. But Schiel pushes leaders to think seriously about how much of their agile ambition depends on improving proximity.

And if you can’t move walls, then find creative alternatives: shared collaboration rooms, dedicated video conferencing setups for distributed teams, or even hybrid solutions that replicate a sense of togetherness.

The team room setup

One of the most useful parts of the chapter is when Schiel describes the components of a well-designed team room:

• Whiteboards or wall space for task boards, diagrams, and roadmaps.
• Team workstations in clusters, not rows—so people can easily swivel and talk.
• Meeting zones for quick standups, planning, or retrospectives.
• Accessible product owner space, either in the room or nearby—so they’re present but not disruptive.
• Breakout corners for focused work or pair programming.

What’s striking here is how intentional the layout is. Agile doesn’t just happen anywhere—it’s supported by a space that encourages flow, collaboration, and visibility.

Dealing with distributed teams

Of course, not all teams are in the same building—or even the same country. Schiel doesn’t ignore this. He acknowledges that distributed teams are a reality, especially in large enterprises. But he challenges organizations to make these setups feel less distant.

This means investing in good tooling (video conferencing, shared digital boards, real-time chat), setting norms for availability, and—when possible—bringing people together periodically to build trust and connection.

One of the best practices he mentions is giving distributed teams overlap hours—windows of time where both ends of a time zone divide are working and can sync up. Without this, collaboration suffers.

Respecting noise, privacy, and focus

While openness helps collaboration, Schiel reminds us not to go too far. People still need to concentrate. So agile spaces should also include quiet zones, phone booths, or ways to temporarily block out distractions. Agile isn’t noisy chaos—it’s purposeful flexibility.

And as team sizes grow or change, space needs might shift too. That’s why Schiel encourages regular feedback from teams about the setup. Is it working? What’s missing? What could be improved?

Chapter 15 – Selecting the Pilot Projects for the Agile Transition

In this chapter, Schiel dives into one of the most strategic and sensitive decisions of the entire transition: choosing the pilot projects. This is where theory meets reality. The pilot teams are the first to go through the full agile experience—they set the tone, model success, and often determine whether the rest of the organization gets on board or pulls back in fear.

Pilots are not just “tests”

Right off the bat, Schiel makes a strong point: don’t treat pilot projects like experiments you can discard if things go wrong. A pilot is the first step in a larger rollout, not a proof-of-concept that ends in a report. It’s part of the transition, and it should be treated with the same seriousness and structure as the rest of the transformation.

That means planning, support, training, and follow-through. It also means being prepared to scale lessons learned, not just watch from the sidelines.

Criteria for selecting pilot teams

This is where the chapter gets very practical. Schiel outlines what to look for when picking the teams and projects that will lead the way. He suggests avoiding both extremes—don’t pick the easiest, safest project just to get quick wins, and don’t throw agile into your most complex, high-stakes product and hope for a miracle.

Instead, look for projects that meet several criteria:

• Low external dependencies – Teams should be as self-contained as possible, without relying heavily on other departments or systems that aren’t yet agile.
• Collaborative potential – Choose teams open to working together, learning, and experimenting. Avoid highly siloed or politically charged groups.
• Right-size scope – Projects should be meaningful, but not so massive that they overwhelm the team. A three- to six-month timeline is often ideal.
• Stable staffing – You need team members who can stay on the project for the duration, without constant churn or role changes.
• Customer involvement – Pilots should include access to real users or stakeholders who can provide feedback, even if on a small scale.
• Tolerant stakeholders – Choose customers or business partners who are curious and flexible—not ones who will panic at the first delay or defect.

These factors don’t guarantee success, but they create the conditions for success—which is what you really need at this early stage.

Start with one, then scale

Schiel recommends starting with one pilot project, not several. Why? Because every organization will learn a lot from that first experience—what worked, what didn’t, where the culture resisted, what tools or training were missing. If you launch multiple pilots at once, you multiply the risk and spread your support too thin.

Once the first pilot is stable and showing signs of success, then you can onboard more teams, adjusting the rollout strategy based on what you’ve learned.

Don’t forget the human side

Even if the project is a great fit, it won’t succeed if the people on the team aren’t ready—or if leadership isn’t committed. Schiel stresses the importance of personality and leadership dynamics. Choose team members who want to be part of the transition. Choose leaders who are open to letting go of control and letting the team grow.

The transition team should be closely involved with the pilot—coaching, observing, and adjusting. This isn’t a “set it and forget it” moment. It’s hands-on.

Be clear about the goal

Finally, Schiel cautions against a common trap: turning the pilot into an endless phase. The pilot should have a clear goal, a defined duration, and a path forward. Everyone involved should know that this is the start of a new way of working—not a temporary detour.

Chapter 16 – Tools in the Agile Enterprise

In this chapter, Schiel explores a topic that many organizations either overcomplicate or underestimate: tools. While agile is fundamentally about people and interactions, tools still play an important role—especially when you’re scaling agile across an enterprise. But here’s the catch: tools must support agility, not define it.

Tools are enablers, not solutions

Right from the start, Schiel warns against falling into the “tools-first” trap. Too many companies think buying a fancy agile tool will make them agile. It won’t. Tools are just that—tools. They can improve visibility, help track work, and support collaboration, but they cannot replace discipline, communication, or shared values.

The bigger risk? A tool can actually undermine agility if it forces teams to conform to rigid workflows or discourages direct conversation.

That’s why Schiel encourages teams to start by focusing on practices and principles—and only then choose tools that support the way they want to work.

Start simple—then scale

For many organizations, the first tools are the simplest: whiteboards, sticky notes, spreadsheets, wikis. Schiel actually recommends starting this way, especially for the first pilot teams. Physical boards make work visible, encourage conversation, and keep things grounded in reality.

But he knows this won’t scale forever—especially in distributed teams or regulated environments. So at some point, teams will need electronic tools. That’s where the real decisions begin.

Key capabilities to look for

Schiel doesn’t push any specific vendor. Instead, he outlines the kinds of features your agile tools should offer:

• Support for Scrum or Kanban boards, including customizable workflows
• Backlog management, including story hierarchies, prioritization, and acceptance criteria
• Sprint planning tools, with visibility into team capacity and commitments
• Burndown or flow metrics, so teams and stakeholders can track progress
• Role-specific views, so developers, testers, product owners, and managers can each see what matters to them
• Integration with source control, CI/CD, and test tools, especially in more technical environments

He stresses flexibility. Tools should adapt to your process, not the other way around.

Centralization vs. team autonomy

Here’s where things get interesting. In large enterprises, it’s tempting to standardize one tool across all teams. That makes reporting easier and simplifies procurement. But Schiel cautions against being too heavy-handed.

Agile teams thrive on autonomy, and sometimes forcing a one-size-fits-all tool can choke creativity and slow teams down. His advice? Set core requirements that support organizational needs—like visibility and traceability—but allow teams to choose tools that fit their style, as long as they integrate with the larger ecosystem.

It’s a balancing act: support consistency where it matters, but don’t crush flexibility.

Tool fatigue and the myth of automation

Schiel also addresses another common issue: tool fatigue. With so many tools in play—task boards, chat, documentation, deployment pipelines—it’s easy for teams to feel overwhelmed or scattered.

He recommends being intentional about what tools are used for what purpose, and reducing overlap whenever possible. For example, don’t use three different tools to manage requirements. Pick one, define its role, and help teams learn it well.

He also warns against over-automating. Just because you can track every metric, enforce every workflow, and log every click doesn’t mean you should. Tools should support human judgment, not replace it.

Security, compliance, and visibility

For larger organizations, Schiel includes a practical note about compliance. Agile doesn’t exempt you from audits, legal constraints, or security policies. So tool selection should include stakeholders from IT security, legal, and compliance—especially in industries like finance, healthcare, or government.

But these needs shouldn’t be used as an excuse to lock things down completely. The goal is to find a setup that allows both agility and control—a system that gives teams freedom while also ensuring traceability and audit readiness.

Chapter 17 – Managing Customer Involvement

In this chapter, Schiel tackles a critical (and often tricky) aspect of agile at scale: how to involve customers effectively. Agile champions customer collaboration as a core value—but what does that look like when your customers are busy, spread across time zones, or not used to participating in the development process?

This chapter explores that question in a direct and realistic way. Because while customer involvement is vital to success, it rarely happens by accident.

Agile depends on real feedback

Schiel begins by reminding us that agile relies on fast, frequent feedback. Teams don’t build big batches and deliver months later. They build small pieces, get input, and adapt. But that only works if someone is on the other end—giving that feedback in a timely and meaningful way.

Without customer input, agile teams end up guessing. That leads to wasted effort, rework, and frustration.

Not all customers are created equal

A big insight in this chapter is that “the customer” isn’t always a single person—or even a single group. In large organizations, “the customer” could mean:

• An internal business stakeholder
• A department head or product manager
• External clients or end users
• A legal or compliance group
• Even the executive sponsor for the transition

Each of these groups may have different needs, expectations, and levels of availability. That’s why Schiel stresses the need to clarify who your customer is for each product or team—and to define how they will be involved.

The challenges of customer participation

This part of the chapter is refreshingly honest. In many cases, customers are too busy. They don’t understand agile. They don’t want to attend every review. Or they want control without responsibility.

Schiel doesn’t sugarcoat it: this is one of the biggest hurdles in scaling agile. But the solution isn’t to give up. It’s to create structures that make participation easier and more valuable.

He suggests:

• Setting clear expectations about customer roles—especially what “active involvement” means.
• Scheduling regular, fixed meetings (like sprint reviews) so customers can plan for them.
• Providing training or coaching to help them understand the process and their impact.
• Assigning a proxy—someone like a business analyst or internal product owner—to gather input if direct involvement isn’t feasible.

The role of the Product Owner

In agile, the Product Owner is the bridge between the team and the customer. But in complex organizations, this role often becomes diluted. Schiel emphasizes that the Product Owner must be empowered—not just to collect requirements, but to make decisions and represent the customer’s voice effectively.

If the Product Owner isn’t close to the customer—or if they’re overruled constantly—then feedback slows down and trust breaks down.

Schiel also reminds us that being a Product Owner is hard. They balance business priorities, tech constraints, customer feedback, and team capacity—all while trying to keep delivery flowing. That’s why training, coaching, and clear organizational support are essential.

Involving customers without overwhelming them

Some teams worry about involving customers too much—will they demand changes constantly? Will they micromanage the backlog?

Schiel suggests creating boundaries and rhythms. For example, customers can give feedback during reviews, help prioritize upcoming work, and clarify requirements—but not interrupt mid-sprint or derail ongoing work. This balance keeps collaboration healthy and productive.

He also highlights that involving customers often builds trust. When they see progress regularly and feel heard, they become more engaged—not less.

Chapter 18 – Agile Project Management—Getting Started

This chapter is all about the real-world shift from traditional project management to Agile, especially as organizations begin launching their first Agile projects. James Schiel walks us through what it truly means to manage an Agile project—and why it requires a completely different mindset than what many project managers are used to.

The role of the project manager changes

One of the first things Schiel makes clear is that project managers don’t disappear in Agile. But their role evolves significantly. In traditional settings, project managers are the central command—they build and maintain schedules, assign tasks, track every dependency, and try to predict everything upfront.

Agile, especially with Scrum, flips that idea. The Scrum Master now handles many of the PM’s former responsibilities, and schedules become far more fluid. Instead of a master project schedule, we have product backlogs and sprint backlogs, which shift based on ongoing feedback and team velocity.

Project managers must shift from controlling to enabling—facilitating collaboration, clearing roadblocks, and helping teams self-organize.

Agile scheduling isn’t about predicting everything

Schiel explains that Agile scheduling is closer to an assembly line than a waterfall Gantt chart. Teams operate in sprints, and their work is defined by velocity—how much they can realistically deliver within each timebox.

Instead of building one giant schedule at the beginning, Agile teams do high-level planning early, mid-level planning around each sprint, and daily planning through stand-ups and task tracking. This means the schedule is flexible and continuously adapted.

Still, organizations often need cost and time estimates upfront. Schiel shows a practical way to approach this using T-shirt sizing (small, medium, large) and sprint planning techniques to approximate effort and translate that into hours. He reminds us that estimates are guesses, especially at the beginning—but good enough guesses can be powerful if you keep improving them along the way.

Planning must reflect reality—not fantasy

A standout idea in this chapter is what Schiel calls “developer load.” It’s a way to calculate how much work each team (or each coder) has, based on hours estimated and team capacity. The problem many organizations face is unbalanced backlogs—some teams have too much to do, others too little.

Instead of forcing balance, Schiel encourages practical solutions:

• Move team members (with training).
• Adjust expectations (based on capacity).
• Accept that some teams will finish earlier and use their time for testing or other value-adding tasks.

This approach is refreshing because it’s not rigid. It acknowledges that real organizations are messy, with specialized skills, legacy code, and people learning as they go.

Getting the architecture and backlog ready

Before teams start sprinting, Schiel emphasizes the importance of having a clear product architecture. Without it, teams will get blocked on foundational questions (like how authentication works) or reinvent parts of the system in inconsistent ways.

Similarly, the product backlog needs to be “right-sized”—not just a wish list, but broken down into items small enough for sprint planning. This is why backlog grooming becomes a critical early activity.

The first sprint is foundational

Schiel proposes starting your project with a setup sprint. This isn’t about delivering features yet—it’s about getting the engine running. During this sprint, the team:

• Defines release goals
• Finalizes the definition of DONE
• Updates organizational policies and processes
• Sets the sprint schedule
• Prepares the backlog for grooming
• Staffs the teams based on priority and skill

The goal is to get aligned on expectations, tools, roles, and direction—before building anything.

Release goals and team formation matter

Schiel spends time showing how important clear release goals are. They help everyone understand what really matters—whether it’s entering a new market, fixing a set of defects, or supporting a strategic product launch.

As for team staffing, he offers three methods: manager’s choice, a “draft” model where leaders select team members, and a sign-up model where people choose their team. Each has pros and cons, and the choice depends on your organizational culture.

Sprint scheduling needs intentional design

Not all teams need to sprint on the same calendar—but if they do, product owners need space to attend all the planning meetings. Schiel even suggests staggered sprint starts to make this more manageable.

He also gives solid advice on choosing sprint lengths. New teams often benefit from longer sprints (3–4 weeks), while experienced ones might succeed with shorter sprints.

Avoiding the trap of the “stabilization sprint”

One of the most eye-opening parts of this chapter is the discussion on stabilization sprints—those final cleanup phases that teams often use to fix technical debt they’ve accumulated.

Schiel warns that relying on these sprints can be dangerous. It makes it easy for teams to cut corners during regular sprints, deferring testing or quality work until later. That creates hidden risks and pressure at the end. Instead, he suggests testing throughout and only using stabilization sprints as a last resort.

He also shares other creative ways to manage quality when automated testing is weak, like having a dedicated QA team sprinting one cycle behind development.

Chapter 19 – Agile Project Management: Monitoring, Reporting, and Controlling

In this chapter, Schiel goes deep into what Agile project management really looks like once the project is in motion. It’s not just about starting strong—it’s about staying on track, keeping stakeholders informed, and responding effectively to inevitable changes.

And no, Agile doesn’t mean giving up on oversight or visibility. Quite the opposite—it means adopting a new kind of discipline.

Tracking progress the Agile way

Traditional project management often relies on huge Gantt charts, percent-complete tracking, and complex status reports. Agile replaces that with lightweight, focused monitoring tools that give better insight, faster.

Schiel outlines the key tools Agile teams use to track work:

• Task boards (physical or digital) to visualize current sprint work
• Burndown charts to show how much work is left in a sprint or release
• Velocity charts to reflect how much the team is delivering sprint after sprint
• Cumulative flow diagrams (in Kanban-style teams) to monitor bottlenecks and progress over time

The beauty of these tools isn’t just that they’re visual—it’s that they encourage real-time conversations. You don’t need a weekly meeting to know how the team is doing. You can see it at a glance.

Who reports what—and to whom

Even though Agile teams are self-managing, stakeholders still need to know what’s going on. Schiel highlights that transparency is a core Agile value, and good reporting builds trust.

He shows how Scrum Masters, Product Owners, and teams each have their roles:

• Scrum Masters ensure that impediments, sprint health, and team dynamics are shared and escalated if needed.
• Product Owners provide clarity on progress toward business goals and keep stakeholders engaged with sprint reviews.
• The team is responsible for task-level visibility and honest estimates.

He also reminds us that reporting should be aligned with stakeholder expectations. Not everyone wants a sprint-level burndown—some executives want a one-page update that shows ROI or milestone risk. Agile doesn’t eliminate reporting; it makes it meaningful and adapts the format to the audience.

Controlling scope and schedule—without control issues

One of the most interesting parts of the chapter is Schiel’s take on control. Agile doesn’t mean giving up control—it means shifting it.

Instead of managing tasks, Agile PMs manage risk, scope changes, and external influences. Schiel explains that Agile gives you more levers to control delivery than traditional models because you’re reviewing outcomes and adjusting direction every sprint.

Scope is managed through prioritization and backlog grooming. Schedule is managed through velocity and sprint planning. The trick is not to panic when things shift—adjust the plan, not the people.

And if velocity changes (due to illness, tech challenges, etc.), the team recalibrates and updates the forecast. That kind of adaptive control is much more powerful than pretending a fixed schedule is still accurate after six months of surprises.

Managing defects and quality

Schiel emphasizes that quality must be built in, not added later. Agile teams should be tracking defects like backlog items, estimating them, and fixing them as part of their normal sprint work. If your defect count is rising, it’s not just a bug—it’s a signal that something deeper is wrong (architecture, testing, or discipline).

He’s also honest about the need for technical metrics—test coverage, failed builds, code complexity, etc.—especially when working at scale. These help technical leaders see what’s coming and act early.

Change requests don’t go away—they get handled differently

In traditional projects, a change request goes through a formal process. In Agile, it becomes a backlog item, prioritized alongside everything else. If it’s important enough, it rises to the top. If not, it waits. This simplifies change control while still keeping it visible and accountable.

Don’t forget retrospectives—they are control tools too

One of the most powerful (and underrated) Agile control tools is the sprint retrospective. It’s not just about feelings—it’s a structured opportunity for the team to inspect and adapt their process, tools, and behaviors.

Over time, this leads to improvements in velocity, quality, morale, and predictability. Schiel encourages teams to treat retrospectives seriously—not as a complaint session, but as a learning engine.

Chapter 20 – Agile Analysis

In this chapter, Schiel zooms in on analysis within Agile teams—a topic that’s often misunderstood. Agile doesn’t eliminate analysis; it reimagines it. Instead of doing all the analysis up front in long requirements documents, Agile spreads the work throughout the development process, evolving it just in time to match the flow of delivery.

This chapter is about how to do that well—especially in large, complex projects where skipping analysis isn’t an option.

Good analysis doesn’t go away—it becomes continuous

Schiel is quick to dispel a myth: Agile isn’t “build first, ask questions later.” In fact, he argues that Agile teams do more analysis—just differently. Instead of trying to solve everything in a giant design phase, Agile breaks analysis down into manageable chunks that happen before, during, and even after development.

This continuous flow of analysis helps teams stay focused on delivering real customer value, not just checking boxes on requirements.

Agile analysts wear many hats

Agile analysis isn’t confined to a single person. Everyone on the team shares responsibility for understanding the work—but some people still specialize in it. These are often business analysts, architects, or senior team members with deep domain knowledge.

Their job shifts from gathering and documenting everything up front to:

• Collaborating with stakeholders and Product Owners to define just enough detail.
• Helping slice large features into smaller user stories.
• Guiding conversations about business rules, edge cases, and workflows.
• Supporting backlog grooming and refining upcoming work.

The best analysts in Agile don’t disappear—they become facilitators of clarity, constantly turning vague ideas into well-understood deliverables.

From requirements documents to conversations

One of the biggest mindset shifts is moving from static documentation to active dialogue. Schiel emphasizes that the most powerful tool for analysis is still the same: a conversation.

He references the Agile Manifesto: “Working software over comprehensive documentation” and “Customer collaboration over contract negotiation.” This means Agile teams rely more on real-time discussions, prototypes, and feedback loops than on massive requirement specs.

That doesn’t mean “no documentation.” It means just enough documentation—focused on what the team truly needs to build and test the next slice of value.

User stories and acceptance criteria are analysis tools

In Agile, user stories become the primary container for analysis. A good story includes:

• A clear user goal (“As a user, I want…”)
• Context for the business need
• Well-defined acceptance criteria

These acceptance criteria are the Agile version of traditional requirements—they define when the work is “done,” but also capture the important behaviors, boundaries, and rules.

Analysts often help Product Owners write these stories and refine them during grooming sessions. It’s not about perfection. It’s about clarity.

When and how analysis happens

Schiel outlines where analysis fits across the Agile lifecycle:

• During release planning, teams and Product Owners collaborate on high-level story mapping and defining the minimum viable product.
• Before each sprint, the team refines stories in grooming sessions, identifying what still needs analysis.
• During the sprint, the team does detail-level work—clarifying business rules, exploring edge cases, and testing assumptions.

Sometimes, analysis has to go a bit ahead of development—what Schiel calls “just-in-time but slightly early.” But it should never become a big, upfront activity again.

How to handle complex domains

Agile works best when stories are small and self-contained—but real-life systems aren’t always that tidy. In complex domains (finance, healthcare, legacy systems), some features require deep, careful analysis.

In these cases, Schiel suggests creating a parallel analysis track, where analysts research and prepare large features a sprint or two ahead. This helps reduce surprises and makes planning more reliable—without dragging teams back into waterfall habits.

He also recommends building a shared knowledge base (like a wiki), where definitions, diagrams, and key decisions are stored for the whole team—not buried in documents or someone’s email.

Chapter 21 – Launching Scrum Teams

This chapter is all about how to successfully start Scrum teams in an organization that’s moving into agile ways of working. Schiel treats this as both a technical and cultural launch—not just assigning people to teams, but setting up the environment, expectations, and rhythms that will help those teams thrive from day one.

If you’ve ever heard the phrase “Scrum is simple, but not easy,” this chapter brings that to life.

Starting right means starting intentionally

Schiel emphasizes that launching a Scrum team isn’t just about saying “you’re a team now” and sending them into a sprint. It requires intentional setup, much like launching a new product. Teams need clarity, structure, and space to grow into their new roles.

Without this, early sprints are chaotic, team morale drops, and the organization may prematurely judge agile as “not working.”

The team composition matters

A big part of the launch is deciding who will be on the team. Schiel outlines several ways to approach this:

• Manager-driven assignment, where leadership places individuals based on skill needs and availability.
• A draft model, where team leads “pick” members from a talent pool.
• A volunteer-based model, where people choose which team or product they want to work on.

Each approach has pros and cons. What matters most is that teams are cross-functional, meaning they have all the roles needed to deliver a working product increment: developers, testers, designers, maybe even data analysts.

Teams should also be stable—you can’t constantly move people around and expect Scrum to work. Trust, velocity, and collaboration take time to build.

Team training and role clarity

Once teams are staffed, they need to be trained—together. This helps establish a shared language and understanding of Scrum principles, roles, and ceremonies.

Schiel suggests team-level training that covers:

• The Scrum framework (roles, artifacts, events)
• How to run a sprint planning meeting
• How to conduct a daily stand-up
• How to define DONE
• What to expect in sprint reviews and retrospectives
• How to use task boards or agile tools

This helps set early expectations and prevents confusion. It also reinforces that Scrum is a team sport, not a set of individual tasks.

Launching the first sprint

Schiel recommends starting the new Scrum team with a “sprint zero” or setup sprint—not to deliver features, but to prepare the ground:

• Clarify the team’s product goal
• Establish the initial definition of DONE
• Set up tools and workspaces
• Build the initial product backlog
• Plan out the team’s calendar of events (sprint length, review meetings, etc.)

This gives the team space to learn how they’ll work together without the pressure of delivering features immediately.

Once the real first sprint begins, the team runs a standard Scrum cycle: sprint planning, daily stand-ups, sprint review, and retrospective. But during these early sprints, the focus is often less on delivery speed and more on building team rhythm and trust.

Support is essential early on

New Scrum teams are going to hit bumps. That’s normal. Schiel emphasizes that this is the time for active support from Scrum Masters, agile coaches, and even the transition team. Leaders should protect the team from external interference, resist the urge to judge performance too quickly, and let the team figure things out in their own rhythm.

This chapter makes a strong point: early sprints are about learning, not perfection. Mistakes will happen. Stand-ups will feel awkward. Estimates will be off. The goal is to inspect, adapt, and grow.

Scrum is simple—but hard to master

The final message is both reassuring and challenging. Scrum’s rules are few, but the real work is cultural—shifting how people communicate, collaborate, and take ownership. That transformation doesn’t happen in a workshop. It happens over time, through support, consistency, and commitment.

Chapter 22 – Managing Scrum Teams

Now that teams are up and running, Schiel turns his attention to how to manage Scrum teams effectively—and this is where many organizations struggle. The traditional management style doesn’t quite fit anymore, but that doesn’t mean management disappears. Instead, it transforms. And that’s the heart of this chapter.

Schiel guides us through what it really means to support, develop, and guide Scrum teams without micromanaging or interfering with their self-organization.

Let the team own the “how”

One of the core ideas in this chapter is that Scrum teams must own their process. Managers don’t assign tasks, break down stories, or monitor daily activities. That’s the team’s job now. Schiel makes it clear: if management keeps control over these things, Scrum collapses into theater—it might look Agile on the surface, but it won’t deliver the results.

Instead, managers focus on creating the right environment: removing obstacles, resolving escalations, aligning teams to business goals, and coaching individuals as needed.

Coaching over commanding

The manager’s new role is much more about coaching. This means helping team members grow, building trust, and guiding teams through tough situations without taking over. Managers who succeed in this role become servant leaders—they ask more than they tell, and they step in only when the team truly needs help.

It’s a huge mindset shift, especially for those used to being the go-to problem solver. But as Schiel explains, empowered teams solve more problems on their own, which scales better and creates stronger ownership.

Measuring performance—differently

Schiel dives into one of the most sensitive areas: how do you evaluate Scrum teams? You can’t just use velocity or number of completed tasks—that leads to gaming the system. Instead, he suggests looking at a mix of quantitative and qualitative feedback, such as:

• Is the team delivering working software consistently?
• Are stakeholders engaged and satisfied with outcomes?
• Are team members collaborating well and continuously improving?
• Is technical quality improving or declining?

The focus should be on value and behavior, not just activity. And performance reviews should emphasize team contribution over individual heroics.

Let teams make mistakes (within limits)

An important theme in this chapter is psychological safety. If you want teams to be self-organizing, they need room to try, fail, learn, and adapt. Managers must resist the instinct to rescue them at the first sign of trouble.

That doesn’t mean being absent. It means showing confidence in the team while staying available to help them reflect and improve. If a sprint goal is missed or a delivery flops, the right response is, “What did we learn?” not “Who messed up?”

Schiel encourages a mentoring model, where managers give feedback, offer insights, and act as sounding boards—especially for newer Scrum Masters and Product Owners.

Supporting Scrum Masters and Product Owners

Scrum Masters often feel like they’re caught in the middle—expected to guide the team but not always supported by leadership. Schiel reminds us that managers should actively support Scrum Masters, helping them grow into their servant-leadership roles and backing them up when they face resistance.

Likewise, Product Owners often juggle too much—managing stakeholders, prioritizing work, attending meetings, and sometimes trying to be the team’s full-time analyst. Managers can help by making sure Product Owners are trained, available, and not overloaded.

Team health is the foundation

Schiel wraps the chapter by reminding us that team health is the leading indicator of agile success. High-functioning teams communicate well, trust each other, and focus on customer value. If a team is toxic, overworked, or ignored, no process will fix it.

So managers need to watch for signs of burnout, tension, or disengagement. They need to hold space for one-on-ones, retrospectives, and team reflection—not as formal processes, but as living practices that support continuous growth.

Chapter 23 – Agile Product Management

In this chapter, Schiel dives into the role of product management in an Agile environment—one of the most misunderstood and underdeveloped areas in many agile adoptions. While Scrum gives us the Product Owner, Agile product management goes beyond one person. It involves a strategy for delivering the right product—not just delivering quickly.

Schiel sets out to clarify what product management really means in an Agile enterprise, how it’s different from traditional approaches, and why it’s essential to align product vision, customer value, and team execution.

From project focus to product focus

One of the first big ideas in the chapter is the shift from managing projects to managing products. Traditional IT teams are often structured around delivering a project—start, finish, and move on. Agile product management focuses on continuous delivery and evolution of a product over time.

This shift changes how we think about scope, schedules, and success. It’s no longer “Did we finish everything we promised?” but rather, “Did we deliver the most valuable thing, and are we continuously improving it?”

The Product Owner is essential—but not alone

Schiel acknowledges the importance of the Product Owner, but he also makes it clear: one person alone can’t carry all the weight of product strategy, stakeholder alignment, backlog management, customer feedback, and business outcomes.

In larger organizations, Agile product management becomes a team activity. There might be:

• A Chief Product Owner for larger product areas
• Multiple Product Owners aligned to different teams or features
• Product Managers handling strategic roadmaps and long-term vision

The key is coordination. Everyone involved in product direction needs to be aligned on goals, outcomes, and what “value” actually means to the customer.

Product vision guides everything

At the heart of Agile product management is a clear product vision—a concise statement that defines what the product is, who it serves, and why it matters. Without a shared vision, teams can easily fall into building what’s easy or familiar instead of what the customer actually needs.

Schiel recommends keeping the vision visible and regularly revisited. It should guide backlog prioritization, sprint goals, and trade-off decisions. And it should be inspiring, not just functional—it gives the team a purpose beyond completing tasks.

Managing the product backlog strategically

The product backlog isn’t just a to-do list. It’s a living representation of strategy. Schiel points out that backlog items should be prioritized based on:

• Customer value
• Business risk or opportunity
• Technical feasibility and cost
• Dependencies and timing

A good Product Owner (or product management team) doesn’t just accept requests—they curate the backlog, negotiate trade-offs, and work closely with stakeholders to decide what matters most now.

One insightful tip Schiel offers: start at the top of the backlog and get really good at refining just the top items. You don’t need to flesh out 300 stories—just make sure the next 2–3 sprints are clear and ready. This avoids waste and allows faster adaptation.

Balancing short-term delivery and long-term thinking

Agile emphasizes fast feedback and frequent delivery, but Schiel warns that without strategic product management, teams can get stuck in short-term loops—delivering features that feel productive but aren’t part of a coherent product evolution.

That’s why product managers need to zoom in and out—working with teams on sprint-level planning while also maintaining a long-term roadmap. It’s a balancing act: respond to today’s learning while still guiding the product toward a future vision.

Customer involvement must be ongoing

As with earlier chapters, Schiel reinforces that customer feedback isn’t optional. Agile product managers and Product Owners should seek it constantly—through sprint reviews, user testing, metrics, or direct conversations.

He also notes that customers sometimes need coaching, too. They’re not always sure how to give useful feedback, how to prioritize their needs, or how to collaborate with development teams. Part of Agile product management is teaching customers how to be part of the process.

Metrics for product success

Finally, Schiel urges product leaders to define what success looks like beyond velocity or delivery dates. That means tracking:

• Customer satisfaction and retention
• Business KPIs (like revenue, cost savings, or conversions)
• Product quality and stability
• Team engagement and sustainable pace

These metrics help shift the conversation from “how busy are we?” to “how much value are we delivering?”

Chapter 24 – Incorporating ISO 9001 into the Agile Transition

In this final chapter, Schiel addresses a challenge that many large organizations face during an agile transformation: how to remain compliant with quality standards like ISO 9001 while adopting Agile methods. At first glance, Agile and ISO 9001 might seem like opposites—one is lightweight and flexible, the other structured and document-driven. But Schiel shows that they can absolutely work together, and even complement each other.

This chapter is about bridging that gap and helping quality-driven organizations stay compliant without losing agility.

Understanding ISO 9001 in context

Schiel starts by laying out what ISO 9001 really is: a standard for building a quality management system (QMS). It’s about defining processes that help an organization consistently meet customer and regulatory requirements.

The key word here is “system.” ISO doesn’t demand how you do things—but it does require that you define how you do things, follow your defined process, and demonstrate that it works. That means Agile teams can still be Agile—as long as their ways of working are intentional, documented, and consistently applied.

Agile and ISO 9001: Not mutually exclusive

One of the strongest points Schiel makes is that Agile and ISO 9001 share a common goal: delivering quality to customers. Agile does this through working software and fast feedback loops; ISO does it through process control and continuous improvement. They’re both about learning and improving—just from different angles.

The misunderstanding happens when people assume Agile means “no process” or that ISO means “lots of documentation.” In truth, ISO wants you to define and follow what works for you, as long as you can prove it leads to quality outcomes.

Aligning ISO principles with Agile practices

Schiel walks through how the core principles of ISO 9001 align well with Agile:

• Customer focus: Agile teams talk to customers frequently and adapt based on their feedback—exactly what ISO expects.
• Leadership and engagement: Agile empowers teams, but also requires leadership support and accountability—aligned with ISO’s focus on responsibility.
• Process approach: Agile isn’t chaotic. It’s built on repeatable cycles (like sprints) and defined roles (Scrum Master, Product Owner, etc.).
• Improvement: Agile has retrospectives, velocity tracking, and continuous integration—all tools that support ISO’s demand for ongoing improvement.
• Evidence-based decision making: Agile teams measure progress with working software, metrics, and feedback—providing exactly the kind of evidence ISO auditors want to see.
• Relationship management: Agile puts strong emphasis on collaboration between teams, customers, and stakeholders.

Documenting the Agile process for ISO

The tricky part, of course, is documentation. Agile teams tend to favor light artifacts—user stories, sprint boards, and code over detailed specs. But ISO requires process documentation, traceability, and record keeping.

Schiel recommends a practical approach:

• Document the team’s Agile process as part of the QMS—this could be a flow diagram of how work enters and moves through the team.
• Keep records of planning meetings, sprint goals, reviews, and retrospectives—these are valid audit artifacts.
• Track defects, changes, and releases—not in huge logs, but in ways that match how the team works (e.g., Jira, Confluence, Git).
• Define what “done” means, including testing, documentation, and quality checks.

This level of documentation doesn’t burden the team—it simply captures what’s already happening and makes it visible for compliance and audit purposes.

Common pitfalls to avoid

Schiel warns against two extremes:

1. Throwing out ISO controls entirely in the name of agility. This leads to risk, audit failures, and quality gaps.
2. Re-implementing old waterfall processes under the Agile label just to meet ISO. This kills agility and innovation.

The middle ground is where agility and compliance co-exist—by thoughtfully integrating ISO requirements into the Agile framework, without adding waste or bureaucracy.

Include quality teams in the transition

A final, practical note: don’t forget to include QA and compliance stakeholders in your Agile transition. If they’re left out, they may try to reassert control later in ways that clash with Agile values. Instead, engage them early. Show how Agile can meet (and even improve) ISO compliance. Let them help define how documentation, audits, and traceability will work.

4 Key Ideas from Enterprise-Scale Agile Software Development

6 Main Lessons from Enterprise-Scale Agile Software Development

My Book Highlights & Quotes

“… Agile development is about people, not a prescription. The intent of this book is to offer guidance and a tool kit…”

“… In the end, whether you decide to transition to agile development or not depends on your commitment to doing it right and your tolerance for being exposed to, dealing with, and solving organizational dysfunctions. You’ll need both commitment and tolerance in good supply to successfully complete a transition to agile development…”

“… I have seen agile development benefit organizations in a number of different ways. First and foremost, software quality is always improved by the concepts ingrained in agile development. The continuous testing of an application, rather than waiting for the testing phase of a project to see if it all works together, is one of the most effective practices that agile development provides to an organization. I have witnessed integration efforts that took months, only to be followed by projects that included continuous integration and testing that eliminated any special time during the project when the only thing happening was integration. This is also reflected in the practice of test-driven development, where the code and its associated tests are not only kept current and working but the tests are written before the code and are driven by the design, rather than being driven by the completed code…”

“… Whether the project went well or didn’t, any potential positive feedback was so far in the future that it was easy to abandon one project to go work on another that either was using the latest technology or was the beginning of the “next great product.” On the other hand, agile development, with its short iterations and sprint reviews, gave the developers that worked for me (and, truth be told, me as well) something to look forward to at the end of the sprint. Of the three possible answers we could get for any completed backlog item (“fantastic,” “great but would be better with changes,” and “not what I wanted”), two of them were at least positive and the third (“not what I wanted”) was fairly easy to protect against by simply improving the product owner’s contact with the team. Constructive feedback on a frequent basis keeps the development teams charged and engaged with the project…”

“… Similarly, customers are considered to be the subject matter experts in how a feature will be used in the finished product. Therefore, while customers don’t drive what a Scrum team works on (what a team builds is defined by the prioritization of the product backlog and how much the team is able to commit to), they can have a significant impact on how the feature actually works. In addition, those same customers can make suggestions for improvement that can be passed to the product owner and be added and prioritized on the product backlog immediately. In this way, a customer can actually suggest new possibilities and potentially see those possibilities become reality in a short space of time. Customers that feel more connected to your prioritization decisions and feel more a part of how your product is built become satisfied and committed customers…”

Conclusion

If you’ve ever tried to lead change inside a complex organization, you know how hard it can be. Enterprise-Scale Agile Software Development doesn’t pretend it’s easy—but it proves it’s possible.

With patience, structure, and the right mindset, even the most traditional enterprise can become faster, more adaptive, and more human in how it builds and delivers value.

Whether you’re a leader, coach, or curious team member, this book gives you the map and the tools—you just have to take the first step.

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: