Book Notes #50: Doing Agile Right by Darrell Rigby, Sarah Elk, and Steve Berez

Title: Doing Agile Right: Transformation Without Chaos
Author: Darrell Rigby, Sarah Elk, Steve Berez
Year: 2020
Pages: 256

According to Forbes, Agile continues to “eat the world”, with the five largest firms on the planet steadily increasing their market capitalizations, including three with trillion-dollar market capitalizations, it’s not surprising that there’s a torrent of books and articles about what’s involved in becoming agile.

But Agile has also become one of those buzzwords that shows up everywhere—from tech teams to executive boardrooms.

But ask ten people what it actually means, and you’ll get ten different answers. Some think it’s about moving fast. Others think it’s about cutting red tape.

And for many leaders, it just feels like a confusing jumble of sprints, stand-ups, and sticky notes. That’s where Doing Agile Right comes in.

Instead of promising a silver bullet, this book takes a step back and asks the bigger question: how do we make agile work—not just in theory, but in the messy, complicated world of real organizations?

The answer isn’t more speed or more teams—it’s doing agile with purpose, balance, and leadership that actually walks the talk.

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

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

3 Reasons to Read Doing Agile Right

Book Overview

What if we’ve been doing “agile” all wrong? Not wrong in theory, but in practice.

It’s a question that haunts many leaders today as they watch agile teams sprout across their organizations—only to find that deadlines still slip, employees feel more confused than empowered, and nothing truly seems… well, agile.

That’s the starting point for Doing Agile Right by Darrell Rigby, Sarah Elk, and Steve Berez. It’s a book that doesn’t just tell you how to “do” agile—it challenges you to rethink the entire way organizations lead, structure, and adapt. And it does this not by preaching, but by storytelling.

Thoughtful, practical, and refreshingly honest storytelling.

The book opens with a familiar scene: executives hyped about agile, hiring consultants, launching dozens of teams, renaming departments to “tribes” or “squads,” and expecting overnight transformation.

But instead of speed and innovation, they end up with chaos and frustration. The authors argue that the problem isn’t with agile itself—it’s with how we try to scale it without really understanding it.

What makes this book so engaging is how it explains agility not as a methodology, but as a mindset shift. One of the standout stories is about a product owner named Brian working at a large snack company.

He leads a cross-functional team tasked with creating new healthy snacks, but keeps bumping into old habits: approvals, silos, people reporting to multiple bosses, and executives who love the idea of agility but hate giving up control.

Through a mix of persistence, trust-building, and actual working prototypes, Brian’s team starts to change minds—not by slogans, but by results. That story stays with you, because it’s not an abstract framework. It’s real, messy, and inspiring.

And that’s what this book does so well. It doesn’t throw acronyms and frameworks at you. It walks you through how agile actually works, how it gets tangled up inside traditional organizations, and what it takes to untangle it. It makes the case that agility isn’t about replacing bureaucracy—it’s about balancing it.

Bureaucracy brings structure and reliability. Agile brings flexibility and innovation. You need both, and figuring out where and how to apply each is the art.

One of the most powerful chapters breaks down why scaling agile across an entire company often backfires. It’s not because scaling is bad—it’s because it’s rushed. Leaders get inspired by companies like Spotify or Amazon and try to copy-paste structures without understanding the culture, context, or the pacing required.

The book offers a different approach: use agile to become agile. In other words, don’t try to design the perfect transformation upfront. Treat the transformation itself like an agile product—run experiments, learn fast, and adapt.

The authors are also clear that leadership behavior is the make-or-break factor.

They tell the story of Bosch Power Tools and how their CEO had to go through his own journey—letting go of command-and-control habits, showing up in team stand-ups, cutting out corporate red tape, and modeling the agile values he wanted others to follow.

That change in behavior cascaded through the company, not because it was mandated, but because it was demonstrated.

And then there’s the budgeting chapter—which, let’s be honest, sounds like it should be the dullest part. But here, it’s surprisingly energizing.

It shows how companies like Dell and Target restructured their funding models to behave more like venture capitalists—investing in small bets, doubling down on what works, and stopping what doesn’t. Agile, in this context, becomes not just a team thing, but a financial strategy.

Toward the end of the book, the authors introduce a clever metaphor: a chainsaw. Agile is like a chainsaw—it’s powerful, fast, and effective when used in the right context.

But it’s not the right tool for everything, and it certainly shouldn’t be handed to people who haven’t learned how to use it.

You wouldn’t perform surgery with a chainsaw. Likewise, don’t try to solve every business problem with agile if it’s not the right fit.

One of the book’s most refreshing insights is its rejection of perfection. Agile teams, agile leaders, and agile organizations don’t wait until they’re ready. They try, learn, and improve. Progress over polish. Direction over certainty.

In the final pages, there’s a subtle but profound message: if agile doesn’t feel energizing, you’re probably not doing it right.

Done well, it should bring joy, clarity, and meaning to the work. It should bring leaders closer to their people, teams closer to their customers, and organizations closer to their purpose.

So if you’re a leader who’s tired of watching agile get twisted into bureaucracy 2.0, or someone wondering why your “transformation” feels more like a rebrand, Doing Agile Right is a book worth reading.

Not because it gives you a checklist, but because it gives you something better—a shift in how you see your role, your teams, and the path to real, lasting agility.

Doing Agile Right covers several key concepts, including:

The importance of creating a culture that supports Agile practices, including building trust and fostering collaboration among teams.

The need for clear and measurable goals, as well as regular check-ins and reviews to ensure progress is being made.

The use of data and metrics to track progress and make informed decisions.

The importance of effective leadership in implementing and maintaining Agile practices.

The role of experimentation and learning in the Agile process, and the need to be willing to adapt and change course as needed.

The need for a strong sense of ownership and accountability among team members.

The importance of creating a transparent and inclusive environment where all team members feel valued and heard.

The need to focus on delivering value to customers, and continuously seeking ways to improve the customer experience.

They illustrate that agile teams can indeed be powerful, making people’s jobs more rewarding and turbocharging innovation, but such results are possible only if the method is fully understood and implemented the right way.

The key, they argue in Doing Agile Right, is balance.

Every organization must optimize and tightly control some of its operations, and at the same time innovate, which is basically doing agile right. 

Agile, done well, enables vigorous innovation without sacrificing the efficiency and reliability essential to traditional operations.

Chapter by Chapter

A Leadership Team’s Agile Manifesto

Why a Manifesto for Leaders?

Just like the original Agile Manifesto created in 2001 by software pioneers, leadership teams going through an agile transformation often need their own version—one that reflects their role and responsibility in shaping the culture.

The authors describe how, in their consulting work, they guide executive teams to build and commit to a customized Agile Leadership Manifesto. It’s not just a symbolic gesture; it’s a behavioral contract.

This manifesto helps leaders define their values, change their habits, and hold each other accountable as role models. The idea is simple but powerful: agile starts at the top. And if leaders don’t live it, the rest of the organization won’t either.

The appendix walks through what a representative leadership manifesto looks like. It mirrors the original Agile Manifesto but expands on it with practical, specific behaviors that make agile values real.

Individuals and Interactions Over Processes and Tools

Leaders set clear ambitions—the “what” and “why”—but let teams figure out the “how.” They align on strategy and purpose, keep metrics focused, and check in personally through team demos rather than relying on milestone trackers.

They also recognize that teams have the best answers. So instead of commanding, they listen, ask thoughtful questions, and push decisions to the people closest to the work. They embrace humility, invite diverse opinions, and show up in Scrum ceremonies—not to supervise, but to learn.

Working Solutions Over Excessive Documentation

Agile leaders want progress, not perfection. They encourage early prototypes, protect teams from distractions, and unblock issues quickly. They kill unnecessary meetings and reports, attend team reviews, and prioritize removing friction.

The focus is on delivering working solutions sprint by sprint, not polishing slide decks or waiting for final approvals. Leaders don’t ask for status updates—they go see the work and offer feedback that teams can use immediately.

Customer Engagement Over Rigid Contracts

Customer feedback is treated as the most valuable input. Leaders push teams to define who their customers are, test assumptions, and involve real users early. Surrogates and internal guesswork aren’t good enough.

They emphasize spending time with customers, not just reading reports. Metrics prioritize customer outcomes, and teams are equipped to gather feedback directly. Agile leadership teams also promote a culture where things can always get better—no “finished” state, just continuous improvement.

Responding to Change Over Following a Plan

Agile leaders foster a safe space for experimentation. They encourage teams to test bold ideas, reduce red tape, and learn from both successes and failures. They reward those who challenge assumptions and bring new thinking—even when it’s uncomfortable.

Importantly, leaders also ruthlessly prioritize. They stop initiatives that aren’t delivering value and make work and prioritization transparent across the company. They run company-wide backlogs and actively reprioritize based on real results, not plans set months ago.

Agile Behavior Starts at the Top

The manifesto finishes with a bold call for leaders to model agile themselves:

• They cut their own meeting time in half.
• They walk the room instead of reviewing slides.
• They work from shared spaces, give up perks, and open direct channels of communication.
• They openly share personal growth goals.
• They seek coaching and feedback.

It’s a reminder that agile transformation is not a side project. It’s how the business will run.

And that means leaders must become agile themselves—working as a team, serving customers, and constantly learning.

Chapter 1 – How Agile Really Works

A Real Story That Feels Familiar

The chapter opens with Brian, a product owner who’s leading a new agile team inside Irresistible Snacks. He’s preparing for a big moment—the team’s third sprint review, where real customers will test early prototypes of a new product line. This review is being watched closely, not just because of the product, but because it’s a test of agile itself. Some executives are skeptical, and this sprint might be make or break.

Brian’s background is in smaller, fast-moving companies. He joined Irresistible after they acquired his previous company, AlwaysAuthentic. At first, he felt stuck in the big-company bureaucracy—too many layers, too many approvals. But things shifted when Lori, Irresistible’s CEO, asked him to lead an innovative new effort. She was tired of the slow, risk-averse culture and wanted results fast.

Building an Agile Team From Scratch

Brian accepted Lori’s challenge, but only if he could do it his way. That meant forming a cross-functional, full-time team with people from every part of the business. No part-timers, no dotted-line responsibilities. They needed their own space, freedom to work face-to-face, and direct access to customers. Lori agreed.

Getting the team wasn’t easy. Leaders resisted giving up key people. They worried about how their departments would cope. But Brian held firm, and Lori backed him up. This tension highlighted an important truth: for agile to work, teams need real commitment—not just lip service.

Sprints, Prototypes, and a Lot of Hurdles

Once the team was assembled, they jumped into action. In just a few days, they set up their vision, prioritized a backlog, and planned their first two-week sprint to produce prototypes. But as they moved forward, they hit roadblocks—IT delays, rigid food safety rules, unavailable chefs, and a budgeting system that wasn’t built for speed.

Brian kept a notebook to track every structural and cultural issue that slowed them down. Whether it was a lack of support for agile career paths, outdated safety policies, or budgeting cycles that killed momentum, he wrote it down. These notes weren’t just for this project—they were a map of everything that would have to change for agile to scale.

Leadership and Culture Clashes

As the team gained momentum, they faced a different kind of challenge: executive interference. Some leaders missed early reviews and then demanded special sessions. Others tried to give direct orders to team members, forgetting that agile teams are supposed to be self-managing. This created tension—team members didn’t want to defy their bosses, especially since they might return to those departments later.

Brian stepped in again. He addressed the executive committee directly, with Lori’s support, to clarify their role. Leaders weren’t there to control the team—they were there to remove barriers and trust the process. It was a hard message to deliver, but a necessary one.

The Turning Point: Seeing Real Results

In the third sprint, the team went bold. They presented seven prototypes to real consumers, gathered detailed feedback, and watched executives see the results firsthand. Four prototypes resonated strongly, and the room shifted. Even Colin, the skeptical CFO, gave his reluctant support.

That moment changed everything. The executives saw progress they didn’t think was possible. They began offering help instead of resistance. And just like that, agile went from experiment to inspiration.

Why This Chapter Matters

The story of Brian and his team isn’t just a feel-good tale—it’s a window into how agile really works in the real world. It shows the pain of trying to move fast in a slow system, the importance of trust and team autonomy, and how leadership behavior makes or breaks transformation. Agile isn’t just about speed. It’s about changing how people think, work, and lead.

Where Agile Came From

The chapter then shifts gears and explores the roots of agile. While you can trace its spirit back centuries, most credit modern agile to innovations in the 20th century. Walter Shewhart and W. Edwards Deming introduced early ideas of continuous improvement. In the 1980s, Takeuchi and Nonaka observed that the best product development looked more like a rugby match than a relay race—teams moving together, passing work back and forth.

In the 1990s, Jeff Sutherland built on those ideas to create Scrum, a lightweight method for software development that favored short iterations, direct customer feedback, and team autonomy. By 2001, a group of developers came together in Snowbird, Utah, and created the Agile Manifesto. It laid out core values like responding to change over following a plan, and working software over comprehensive documentation.

Agile in Practice Today

Agile is now used far beyond software. From tractors to wine to fighter jets, companies apply agile principles across industries. But no matter the field, the basics remain the same.

Agile teams are small, cross-functional, and empowered. They run short cycles—called sprints—to deliver real value and get customer feedback fast. They prioritize based on what customers need, not internal politics. They don’t rely on rigid plans but adapt as they learn. And they’re measured by outcomes, not outputs.

The product owner plays a central role—balancing the needs of customers and the business, keeping the backlog focused, and making sure the team builds what matters. A process facilitator (like a Scrum Master) helps the team stay on track and protected from distractions. Everyone stays aligned through daily check-ins, transparent progress tracking, and constant testing with real users.

Why It Works

Agile isn’t just a feel-good idea—it works. Studies show it boosts productivity, employee satisfaction, and customer engagement. It reduces waste, improves speed, and lowers risk. It also frees up senior leaders to focus on big-picture priorities, not micromanaging every project.

But perhaps the most important insight is this: agile recognizes that trying to plan every detail in advance just doesn’t work when things are uncertain. It’s like trying to program a car to drive from Minnesota to Florida by scripting every possible road condition. Instead, agile equips the car to sense, adapt, and navigate as conditions change. It’s a mindset shift—from prediction to learning, from control to collaboration.

Chapter 2 – Scaling Agile

Scaling Agile Isn’t Just About Adding Teams

The chapter opens with a powerful example from Saab’s aeronautics division, where more than 100 agile teams work together on the incredibly complex Gripen fighter jet. What makes this interesting is how they coordinate: every morning, teams escalate issues up through layers of leadership, and by 8:45 a.m., the executive team has a clear list of top issues to resolve. It’s fast, structured, and aligned—showing how a well-run scaled agile system can work across a high-stakes business.

Other Companies Are Scaling Too

We also hear about SAP, USAA, and many other organizations that have scaled agile across large parts of their business. SAP started with software, then expanded to sales, marketing, and even internal IT. USAA connects agile teams directly to P&L owners, ensuring clear accountability. These companies aren’t just experimenting—they’re integrating agile into their core operations.

Agile at Scale vs. the Agile Enterprise

The authors make a key distinction here. Most companies practice agile at scale—which means launching dozens or hundreds of agile teams, often while keeping the rest of the organization running in the old way. It improves individual team performance but often leaves overall business performance stuck. Why? Because bureaucracy still slows things down.

On the other hand, an agile enterprise goes deeper. It rethinks the entire business system so that innovation and bureaucracy are not at odds but work together. This chapter introduces that bigger vision and why it matters.

The Hidden Problem: Flow Efficiency

A fascinating insight in this chapter is the concept of flow efficiency—the proportion of time spent actually working versus waiting. Even with agile teams, the waiting (for approvals, funding, IT integration, etc.) still dominates. Most companies operate at just 15–20% flow efficiency. So even if agile speeds up the “work” part, the overall innovation speed barely improves. Without changing the surrounding processes, agile’s impact is limited.

The Agile Enterprise Mindset

An agile enterprise doesn’t try to put everyone into an agile team. Instead, it balances reliable operations with agile innovation—and integrates the two. Leaders manage the transition as an agile initiative itself, using continuous improvement, backlogs, and team-based problem-solving. They treat employees as customers of the change process, not passive subjects.

Bosch provides a great example. Initially, its scaling effort led to silos—agile teams in “cool” areas and traditional ones left behind. So they reset. The board acted as a steering team, personally involved in testing agile ways of working and solving real problems. They moved from a status-report mindset to active participation—and the results were tangible: more collaboration, faster adaptation, and better results.

It’s About Balance, Not Elimination

The authors emphasize that agile doesn’t mean killing off bureaucracy. Like yin and yang, innovation and operations need to coexist. Agile enterprises know how to run the business efficiently while also changing it boldly. The right balance depends on the industry, company, and even department.

Creating a Strategic Vision (Like an Agile Team Would)

Leaders should think like agile teams when shaping a vision. That means starting from the customer’s perspective—what are their goals? What experiences matter most? Then, build user stories and hypotheses about what changes will help. But stay humble. These hypotheses may need to adapt over time. So leaders create an enterprise backlog—a sequenced list of changes to test and refine over time.

Build a Taxonomy of Teams

To scale effectively, companies need a taxonomy—a clear structure of all potential agile teams mapped to customer experiences and business processes. This helps avoid redundancy, clarify ownership, and reveal talent gaps. USAA’s taxonomy is fully visible across the company. If someone asks, “Who owns the change-of-address experience?” the answer is clear.

A good taxonomy allows leaders to think big but take action in small steps. It brings clarity to an otherwise overwhelming transition.

Sequence the Transformation—Don’t Rush It

Not every company can (or should) go all in at once. ING tried a “big bang” transformation—putting everyone on mobility, making them reapply for jobs, and shifting 40% into new roles. While some praised the results, the trauma was real. This kind of move can undermine agile values before they even take root. Most companies are better off rolling out agile in thoughtful waves, learning and adapting along the way.

Managing Interdependencies Without a Central Hub

More agile teams mean more interdependencies. But agile enterprises don’t solve this with heavy central control. Instead, they use transparency, face-to-face communication, and lightweight coordination offices. These help, but they shouldn’t turn into command centers. Real coordination still happens within and between teams.

The authors warn against giving early agile teams special treatment. Real learning happens when teams face real obstacles. Test teams in diverse, challenging environments so you understand what needs to change at a system level.

Agile Teams Must Be Ready Before They Launch

A good agile team doesn’t need to have every answer, but it should be focused, autonomous, cross-functional, and supported. It must own a business outcome, be trusted to act, and be connected to customers. Without this setup, the team won’t succeed—and neither will the broader transformation.

Early Wins Matter—but So Does Learning

Quick wins build momentum. 3M launched 90 agile teams over two years and saw faster deliveries and early beta releases. But the goal isn’t just to ship faster—it’s to learn how to adapt, continuously improve, and scale without losing agility.

Harmonizing Bureaucracy and Innovation

Agile enterprises bring bureaucrats and innovators together. That means having operating folks inside agile teams, and letting agile values influence traditional functions like HR, finance, and compliance. Sprints are key tools here—they create feedback loops, shorten delays, and let big changes unfold in manageable cycles.

What Questions Should Leaders Ask?

The chapter closes with ten thoughtful questions for leaders, like:

• Where can we give people more autonomy?
• How do we reduce work in process?
• How can we use experiments and fast feedback to improve?

These are the kinds of questions that turn agile from a buzzword into a behavior.

Choosing the Right Scaling Framework

There’s no one-size-fits-all method for scaling agile. The chapter reviews a few popular options:

• SAFe is highly structured and popular with tech-heavy companies that need coordination and control. It adds roles, events, and artifacts but can be too rigid.
• Scrum@Scale aims for minimal bureaucracy and spreads agile values across the entire organization. It works best where teams already know Scrum and want to customize.
• Spotify Model is famous but misunderstood. It works for Spotify because of their unique culture—but copying their structure without their mindset often leads to chaos.

In the End, It’s About Fit

No framework is perfect. What matters is picking what works for your business, culture, and goals.

Leaders need to be flexible, thoughtful, and deeply involved—not just picking a framework off the shelf.

Chapter 3 – How Agile Do You Want to Be?

A Surprising Question With a Deeper Message

The chapter starts with a twist: the question “How agile do you want to be?” is actually a trick. The authors use the story of Mark Allen, a triathlete who went from burnout to world champion, to show how transformations—whether athletic or organizational—need to happen at the right pace, not the fastest pace. It’s a great metaphor. Just like Allen had to learn the importance of training at a sustainable pace (not always pushing to the max), companies need to find their own “maximum aerobic rate” when transforming into agile enterprises.

The Sweet Spot of Change

There’s a concept at the heart of this chapter: every business has an optimal level of agility. Too little, and it risks becoming slow and irrelevant. Too much, and it risks chaos. The authors call this the “agile golden mean”—a balance between change deficiency and change excess. In large companies, change deficiency is often the bigger threat, with bureaucracy slowing down innovation. But small startups often face the opposite problem: moving too fast without the systems to support scale.

The key is to aim for the point where the benefits of agility outweigh the costs. Those benefits include faster innovation, higher customer retention, and lower turnover. But the costs—like training, coordination, or increased risk—are real too. The chapter encourages leaders to estimate both sides, even roughly, to make smarter, more grounded decisions.

Why Big-Bang Agile Fails

This part is a wake-up call. The authors explain why many sweeping agile overhauls fall short. Companies dive in with mass restructurings, slash headcounts, and force everyone into new roles—hoping agility alone will drive results. But research shows these efforts often don’t improve real business agility. Why? Because they guess at the right level of change without testing or learning.

The authors point to the planning fallacy—our human tendency to overestimate our ability to forecast the future. In vague, complex systems (like a company undergoing change), this leads to bad decisions. So instead of copying others or launching big, risky initiatives, the book argues for something smarter: use agile to become agile.

Start With Purpose, Not Process

Mark Allen had a clear goal: win the Ironman. Companies need the same kind of clarity. Agile should never be the goal—it’s a means to an end. When the purpose is clear and aligned, teams can act with more autonomy. The authors give the example of Warby Parker’s short, punchy mission. Compare that to Barnes & Noble’s confusing and wordy statement—one inspires action, the other confuses.

Also, don’t fall into the trap of adopting agile just to follow trends, reduce headcount, or look modern. That’s a recipe for frustration. Real agility is about creating value, not checking boxes.

Learn to Measure Agility the Right Way

Many leaders say they want agility, but few know how to track it. Some count agile teams. Others report how many people went through training. But very few measure agility’s impact on outcomes like cash flow or market share.

The authors introduce a useful model for thinking about this, adapted from the W.K. Kellogg Foundation. It breaks the agile system into five parts:

• Purposes – the big, long-term mission (e.g., lead the way for socially conscious businesses)
• Outcomes – results you can see in 1–3 years (like revenue growth or customer loyalty)
• Outputs – immediate results (such as faster product cycles or better morale)
• Activities – what teams and leaders actually do
• Inputs – the resources and conditions that support the work

The book emphasizes that every company’s system is different, so the metrics must be customized. Still, by understanding how these elements connect, leaders can make better decisions and avoid focusing on the wrong things.

A Real-World Example

One retail client thought things were going great—more agile teams and rising revenue. But digging deeper showed the company was actually losing market share. They were failing to connect with next-gen customers who wanted better online options and in-store experiences.

Agile teams were optimizing outdated systems instead of rethinking the customer journey. Worse, no one on the teams even represented the newer customer segments. Once they saw the gaps in their inputs, activities, and outputs, they could start fixing them.

Use Agile Methods to Guide the Transition

Here’s the chapter’s big insight: use agile methods to become agile. That means leaders need to stop pretending they have all the answers. Don’t design transformation in a vacuum or roll it out through press releases. Instead, think like an agile team. Be transparent. Collaborate. Gather feedback. Adapt.

Too often, leaders do the opposite. They build rigid plans. They treat employee input as resistance. They focus on org charts instead of real constraints. But the authors argue that reorganizations rarely solve core problems—they’re often just used to justify layoffs. A better approach is to focus on what’s really slowing things down: poor leadership behaviors, clunky processes, outdated planning cycles, or lack of clarity.

These are the levers of change, and like items in a backlog, they can be sequenced and prioritized by the leadership team. You don’t need to change everything at once. Instead, adjust the system like a sound engineer fine-tuning a mix—making small, smart changes where it matters most.

A Metaphor That Sticks

The chapter circles back to Mark Allen’s journey. When he stopped trying to copy others and started training at his own sustainable pace, he improved dramatically—and eventually surpassed the pioneers of his sport. That’s the message for companies too.

Agility isn’t about going all-in right away. It’s about finding your pace, adjusting over time, and committing to the long game.

Chapter 4 – Agile Leadership

Leadership in Action: Bosch Power Tools

The chapter opens with a compelling case from Bosch Power Tools. Under CEO Henk Becker, the company launched an agile transformation that reshaped not only how teams worked but how leaders operated. Becker formed a six-person team to guide the process, introduced Kanban structures, redefined meeting habits, and prioritized alignment through stand-ups.

At every level—from product owners to the executive suite—teams shared updates quickly, made decisions transparently, and focused on eliminating wasted time. Stand-up meetings became short, sharp, and regular. Visual boards helped everyone see priorities and status. And at the executive level, Becker created an agile leadership team that set strategic direction using agile practices.

This real-world example sets the tone for the chapter’s deeper point: agile leadership isn’t about techniques—it’s about mindset, behavior, and changing how value is added.

The Shift From Old-School Command to Agile Trust

Traditional leadership followed the Frederick Taylor model: define the job, tell people how to do it, and make sure they comply. Later came Theory Y, introduced by Douglas McGregor, which encouraged listening and trust—but many organizations gave it lip service while sticking to the old, control-based model. Leaders felt responsible for delivering results, so they rolled up their sleeves and solved problems themselves.

But that doesn’t work anymore. The pace of change is too fast, and employees want more autonomy, flexibility, and impact. Leaders are starting to feel that the old ways aren’t working—and they’re right.

Becker’s Turning Point

Becker, despite decades of experience and a strong track record, realized his leadership style wasn’t helping his teams succeed. A few brave colleagues gave him feedback, and it hit him deeply. He didn’t brush it off—he listened, reflected, and started changing how he led. He gave up his office, stopped requesting PowerPoint decks, and began visiting teams where they worked. He shifted from telling to asking. From control to collaboration. Slowly, trust grew, and his transformation became the foundation for the broader agile shift at Bosch.

Rethinking the “Noble Mission” of Leadership

Many leaders see themselves on a mission to help the company succeed by guiding others, protecting them from mistakes, and making sure work is done well. But the book argues that this mission must evolve. Agile leaders don’t just ensure the work gets done—they create environments where others can thrive. That requires rethinking what leadership actually means.

Employees Learn by Doing

A great comparison is made to “helicopter parenting.” Just as overprotective parents prevent kids from learning, leaders who micromanage stifle employee growth. Agile teams thrive when they’re trusted to experiment, fail, and learn. Leaders in agile environments give teams direction on what to achieve but leave the how up to the team. That’s where innovation and ownership grow.

Trust is Built Over Time

Trust doesn’t appear overnight. It’s earned through small, consistent interactions—especially in agile teams. Working in short cycles with transparent backlogs helps both teams and leaders see real progress and correct course quickly. It builds confidence and credibility. Even skeptical leaders can start to see that letting go of control doesn’t mean chaos—it often means faster learning and better results.

Focus on What Only You Can Do

There’s a powerful insight here, borrowed from economics: comparative advantage. Even if a leader can do everything better than their team, they shouldn’t. Their real value lies in doing what only they can do—like setting strategy, allocating resources, and building systems. If they get stuck doing everyone else’s job, no one benefits.

Let the Customer Be the Judge

Agile teams rely on customer feedback—not leadership assumptions. That’s why they develop minimum viable products, test ideas early, and involve users in the process. This applies inside the organization too. Teams that improve internal processes work directly with those affected to make sure the solutions actually help. Leaders don’t guess what customers want—they empower teams to find out for themselves.

A New Kind of Noble Mission

When leaders embrace these principles, their role transforms. Instead of running the business directly, they enable agile teams to run and improve it. The best leaders focus on priorities, remove obstacles, and create alignment. Their time shifts from micromanaging to shaping the system as a whole.

This shift also changes how executive teams work. Instead of a group of siloed department heads defending their turf, an agile leadership team acts as a united, cross-functional group aligned around customer needs. They stop managing by reporting and start managing by learning and acting. They break large changes into small tests. They make decision-making faster by removing red tape. And they set the tone for agility across the organization.

Guiding the Agile Transformation

Agile transformations aren’t delivered through grand plans and top-down rollouts. They’re built iteratively, in collaboration with the people doing the work. Leaders co-create a vision with teams, test strategies, and measure progress based on outcomes—not just outputs. It’s not about announcing a new culture; it’s about living it, step by step.

The book offers a strong reminder: crises don’t justify command-and-control leadership. In fact, those moments demand even more agility, not less. Adaptive teams with real-time insight and decision-making autonomy outperform rigid structures when the environment is unpredictable. That’s true in combat, disaster response, and business alike.

Five Practices of Agile Leaders in a Crisis

To lead through uncertainty, agile leadership teams take five key actions:

1. Overcommunicate the strategy so that decision-makers know the “why” even if the “how” changes.
2. Coach more decision-makers instead of bottlenecking decisions at the top.
3. Make work visible to improve coordination and avoid confusion.
4. Embrace learning loops, choosing progress over perfection.
5. Align rewards to teamwork, not individual silos, to expand trust and collaboration.

Pace and Progress

Finally, the chapter reinforces that transformation doesn’t happen all at once. Agile leaders launch a few teams, learn what works, and expand based on results. They weigh value against cost and adjust accordingly. That’s real agility—moving with purpose, not pressure.

Bosch Power Tools is proof. In three years, innovation cycles shrank from three years to six months. Stand-ups replaced long meetings. Feedback loops shortened. And the leadership mindset shifted from telling people what to do to creating the space for them to thrive.

Chapter 5 – Agile Planning, Budgeting, and Reviewing

The Planning Myth That Won’t Die

One of the most damaging misconceptions about agile is the idea that agile companies don’t plan. Some executives avoid agile for this reason, while some agile enthusiasts use it as an excuse for sloppy planning. But the truth is the opposite.

Agile companies do plan—they just do it differently. They treat plans as adaptable hypotheses, not rigid instructions. Planning, budgeting, and reviewing are all part of a continuous learning loop: plan, do, study, adjust. When done right, these agile processes actually improve enterprise performance more than any org chart change ever could.

The Dell Management Model: A Real-World Example

Dell Technologies provides a compelling model for agile planning. After going private in 2013, Dell no longer had to focus on quarterly earnings and could aim for long-term growth. To support this shift, the company developed a new strategic operating approach called the Dell Management Model (DMM).

It starts with setting a clear ambition for future value. Leaders then compare that ambition to current projections and identify what needs to change to close the gap.

This process creates a multiyear roadmap and a backlog of initiatives, which is refined into a one-year operating plan. But here’s the agile part: that plan isn’t locked. Dell constantly revisits and reprioritizes its strategic agenda to stay responsive to new insights and market shifts.

A Focused Agenda That Avoids Multitasking

Dell doesn’t try to do everything at once. It narrows its focus to fewer than a dozen high-priority initiatives at a time—what it calls the Dell Agenda. These are supported by dedicated owners and reviewed monthly at the executive level. When new issues arise, Dell quickly estimates their value and, if they matter enough, gives them a spot in the agenda. The result is a flexible yet focused system that avoids the usual traps of multitasking and misalignment.

Agile Teams in Action: Dell’s Supply Chain

Dell applied agile methods within its supply chain to improve planning and forecasting. Instead of launching a massive overhaul, they used small, dedicated agile teams working in two-week sprints to test changes and gather feedback. This approach led to tools and processes that were better, faster, and more widely accepted. Over time, Dell scaled the effort from two to nine teams, showing how agile can drive real operational improvements.

What Agile Planning Looks Like

Across the board, agile enterprises take a different approach to planning. They:

• Gather customer input constantly to guide priorities
• Set clear goals but give teams flexibility on how to reach them
• Sequence and limit work to prevent overload
• Update plans frequently to reflect what’s working and what’s not

These practices allow agile enterprises to move with purpose and adapt quickly—without the waste and delay of traditional planning.

Rethinking Budgeting in Agile Enterprises

Traditional budgeting locks in funding for the year, often supporting projects that no longer make sense while starving innovation. Agile budgeting is different. It acts more like venture capital—funding early experiments and providing more resources only as value is proven. Agile leaders expect that many ideas will evolve, and some will fail. But that failure isn’t waste—it’s fast, cheap learning.

Take Target, for example. Its more than 250 product managers are treated like entrepreneurs. Those who deliver value get more funding and responsibility. Others don’t. It’s all about outcomes, not titles or hierarchy.

Welcoming the Unplanned

While strategic imperatives are prioritized, agile enterprises leave space for new ideas. The planning backlog is open to inputs from anywhere—customer research, employees, market shifts, or even failed projects. Amazon Web Services and Amazon Prime didn’t come from top-down planning. They emerged from experimentation and were scaled up because they delivered results.

Persistent Teams Over Temporary Projects

For problems that require long-term focus, agile companies use persistent teams rather than one-off projects. These teams stay together, adapt over time, and build deep knowledge of their customers and systems. As Jeff Bezos puts it, customers are always “wonderfully dissatisfied.” Persistent teams are best positioned to keep discovering and delivering what those customers need.

Funding Follows Outcomes

Agile companies tie funding to customer outcomes, not seniority or internal politics. Every initiative must prove its value continuously. Teams that stop creating value either pivot or disband. There’s no such thing as “set it and forget it” funding in a real agile environment.

At the Royal Bank of Scotland (RBS), for example, budgeting once focused on detailed feature specs and approval-heavy processes. Now, funding is tied to Customer Business Areas (CBAs) and their measurable outcomes. Journey teams within each CBA manage their own backlogs, and budget reviews focus on whether outcomes are being achieved. This has drastically cut down on the number of business cases and sped up innovation.

Scenario-Based Budgeting: Planning for Uncertainty

RBS also uses scenario-based funding. Business leaders present base, up, and down scenarios—what they could deliver with current, 20% more, or 20% less funding. This allows for smarter allocation of resources and keeps teams thinking in terms of value, not just cost.

Agile Reviewing: Less Show, More Substance

Reviews in agile enterprises are regular, informal, and focused on learning, not performance theater. There are no polished PowerPoints—just honest, transparent discussions about what’s working and what’s not.

At Riot Games, the CFO acts more like a coach than a gatekeeper. He trusts agile teams to own their finances, supports them with guidance, and helps them ask the right questions. RBS is also moving in this direction, focusing quarterly reviews on actual outcomes and continuous improvement.

Dell, again, offers a strong example. Every month, executives review strategic initiatives against promised results. This creates real accountability and ensures budgets are adjusted as needed. Their annual plan is created in Q4, then updated twice a year, balancing innovation and operations toward shared goals.

The Right Cadence Is Key

Agile companies avoid both extremes—too-slow cycles that lead to stagnation, and too-fast cycles that cause confusion. Most find that updating plans and budgets every few months is the sweet spot. It allows enough time to see results but is frequent enough to course-correct.

The Real Risk? Not Changing at All

Shifting to agile planning, budgeting, and reviewing might seem risky, especially for control-driven executives. But clinging to outdated systems is a bigger risk.

The transition doesn’t need to be a revolution. It can start with small pilots, supported by evidence and shared learnings. Connect CFOs with peers who’ve made the shift. Let teams prove the model before scaling it.

And remember: if done right, these changes unleash agility more effectively than any other single move.

Chapter 6 – Agile Organization, Structures, and People Management

Structure Isn’t the Whole Story

When companies decide to become more agile, the first temptation is often to jump straight into restructuring. It feels easy: shuffle boxes on the org chart, shift reporting lines, maybe cut costs or appoint new leaders. But the authors warn that this is a shortcut—and often a trap. Structure alone doesn’t create agility.

In fact, you can copy Spotify’s org chart all you want and still end up with the same bureaucratic behaviors. What really matters is the entire operating model—roles, responsibilities, decision rights, culture, collaboration, and leadership behavior.

Restructuring without addressing those deeper elements just leads to confusion or chaos. Agile transformation, the book argues, needs more thoughtful and holistic changes.

Don’t Copy. Customize.

It’s tempting to copy agile models from companies like Spotify, but that’s risky. Spotify’s structure works for Spotify because it reflects their unique strategy, culture, and needs. In other companies, agile teams may only make up 10–15% of the workforce. Just lifting the labels—like squads or tribes—without changing how people actually work doesn’t help.

The authors make three key points:

1. Structure is just one part of the operating model.
2. How you change the model matters as much as what you change.
3. Every operating model must be customized to the company’s strategy and situation.

Start With Strategy, Not Structure

A famous quote says, “Structure follows strategy”—and that’s exactly the starting point here. Before jumping into any redesign, companies need to be clear about where they’re going and how they plan to win. From there, they can define the number and type of business units needed to support that strategy.

But here’s a deeper insight: business units shouldn’t be defined by products—they should be defined by customer needs. That shift helps businesses avoid the trap of being disrupted by new competitors. If a company clings to its current product structures, it becomes vulnerable. Think of how physical retailers were disrupted by Amazon or how film photography was wiped out by digital.

Well-defined business units create space for agile teams to innovate close to the action—within the operations that will ultimately adopt and scale their work.

Structure Isn’t Just Reporting Lines

An agile structure isn’t about creating silos of agile teams—it’s about placing those teams close to where they can make a difference. They should be embedded within business units, not clustered in distant innovation hubs. This allows leaders to retain ownership and accountability while encouraging innovation. Scaling is usually the hard part of innovation, and when line managers own the outcome, things actually get implemented.

Agile teams don’t even need formal reporting line changes. People can remain in their original departments while working in agile teams, with their managers acting as long-term development coaches instead of day-to-day supervisors.

Move at the Right Pace

Agile companies have a built-in advantage: they already understand the principles of test, learn, and scale. So when it comes to transforming the operating model, they should use the same approach. No closed-door planning. No massive top-down rollout. The process should be transparent, inclusive, and iterative.

Bosch Power Tools is a great example. They started small—just one unit—and expanded only after learning from early pilots. Over three years, they reduced hierarchy levels, built 55 end-to-end accountable teams, and improved decision speed dramatically. The transformation was structured but flexible. And most importantly, they adjusted course along the way. They realized that culture and collaboration were even more important than structure.

The Underrated Hero: Talent

A common regret from executives? “We should have started work on talent earlier.” HR isn’t just a support function—it’s a key driver of agile transformation. Strategy and talent must align. Companies need to identify what skills they need, how many people, where they’re needed, and whether to hire or develop.

Agile teams can’t share scarce resources across 12 projects like in traditional setups. So workforce planning becomes essential. Gaps in expertise become more visible. And while hiring is one solution, it’s often cheaper and more effective to train existing people. After all, your current employees understand your customers, systems, and processes. That’s a huge advantage.

Agile Talent in Action: Walmart’s Hiring Helper

Walmart’s HR leader launched five agile teams focused on different parts of the employee experience—like hiring and learning. One team built a tool called Hiring Helper to reduce bias and improve match quality in front-line hiring.

They launched it in one market, gathered feedback, made improvements, and scaled it to others. Early results were impressive: 20% better hiring fit, lower attrition, and reduced absenteeism. This kind of agile innovation in HR is what accelerates transformation.

Principles for Agile People Management

The chapter outlines several key shifts companies need to make:

• Foster Leadership, Not Just Management: It’s not just about results—it’s about empathy, adaptability, and creating the right environment. At Bosch, leadership qualities were defined by a cross-functional group, and promotion was based on peer review, not just manager nominations.
• Make Career Growth a Choose-Your-Own-Adventure: Agile enterprises support learning and development without tying it strictly to promotions. Coaching becomes central. At Bosch, even a plant manager became a certified coach to support others.
• Attract Talent With Purpose, Not Prestige: Stripe is used as an example here. They prioritize mission and impact over flashy titles. This attracts people aligned with their culture—and leads to better engagement and productivity.
• Focus Performance Management on Improvement: Feedback should help people learn and improve, not just determine compensation. Bosch moved from annual reviews to continuous feedback loops, giving teams more real-time insight into how to improve.
• Enable Flexible Roles and Growth Paths: Agile companies simplify job levels and support cross-functional learning. People can grow in different ways—becoming agile masters, experts, or business owners. At Bosch, this created more versatile, T-shaped team members.
• Provide Tools for Team Effectiveness: Tools like team workshops and peer feedback sessions help teams set goals, define competencies, and continuously improve. HR supports these efforts by training facilitators and creating safe spaces for feedback.
• Reward the Team, Not Just the Individual: This part ends with a cautionary tale from Microsoft’s stack ranking days. Their focus on individual performance actually hurt collaboration and innovation. By contrast, companies like Apple and agile organizations reward both individual contribution and collective success—driving higher productivity.

Bringing It All Together

Agility isn’t just about creating teams—it’s about rethinking how the whole organization works. From structure and decision rights to leadership and talent, it’s the operating model as a whole that needs to evolve.

You don’t need all the answers up front. The most important step is to get started—and adjust as you learn.

Chapter 7 – Agile Processes and Technology

Starting with the Customer, Not the Process

The chapter begins with the transformation story of RBS (Royal Bank of Scotland), which wanted to shift its home mortgage business into a fully digital, customer-focused experience. Les Matheson, leading this transformation, saw the opportunity not just to improve a process—but to reimagine the whole home buying journey. But there were obstacles everywhere: a 66-page mortgage application, siloed departments, rigid systems, and internal structures based on products instead of customer needs.

To overcome this, Matheson didn’t just launch agile teams—he changed how they worked. He focused on customer journeys, built cross-functional teams around them, and tied funding to business outcomes. But he also realized that just forming teams wasn’t enough. They needed full-on agile practices and deep collaboration across business, IT, and change functions.

Organizing Around Customer Journeys

The new model put customer experience at the center. The teams used human-centered design to define a “North Star” vision for what customers wanted: quick, easy, guided digital home buying. They didn’t stop at wireframes and ideas. They built real, working prototypes in two-week sprints, gathered feedback, and adjusted rapidly.

What stood out here was how closely business, design, tech, and data people worked together. Everything was integrated—from writing code to training staff to gathering customer insights. The result? RBS launched the UK’s first paperless mortgage app, doubled digital mortgage switching, and cut processing time in half—from 23 days to 11. And because the team stayed together, they kept improving things even after launch.

When Systems Get in the Way

By now, we understand agile is about working in cycles, testing ideas, and adjusting fast. But there’s a huge blocker: legacy processes and outdated technology. These systems—built up over years, through mergers, silos, and bad habits—are slow, messy, and hard to change. The book explains how companies cling to them because replacing them feels too expensive or disruptive. So they patch and delay, until the system is barely usable. That’s not agility—it’s just inertia.

The Agile Way to Fix It

Agile transformation flips the script. It starts from the customer solution, then works backward to fix the process and the tech. The goal is to create what customers need—then build systems and operations that deliver it.

For example, a health insurer built a structure with five portfolios—members, employers, providers, brokers, and internal employees. Each portfolio had a chief product manager, with cross-functional teams working on customer solutions. Where capabilities overlapped (like claims processing), a chief capability owner coordinated efforts. This structure helped manage complexity, dependencies, and scale.

Process Innovation Done Right

Agile teams innovate processes like they do products: start small, test fast, and adapt. Two strategies help:

1. Design processes as modular capabilities—just like microservices in software. If each part of a process is clearly defined, teams can improve it independently without breaking the whole system.
2. Encourage open-market competition—internal capabilities should prove their value just like external vendors. If an outside supplier can do it better, that’s a clear signal for improvement. Amazon Web Services famously grew out of this mindset.

Realities of Internal Customers

Many agile teams serve internal customers, like finance or operations. These “customers” are trying to serve external ones, so understanding both layers is key. At RBS, the mortgage application team balanced feedback from customers and internal advisors. Sometimes the trade-offs were tough, but by involving both sides early, they built trust and alignment.

Agile innovation also means building bridges to operations. Otherwise, great ideas stay on the whiteboard. Product owners often come from the operations side to ensure credibility and relevance. Sprint reviews include frontline staff. Everyone shares the same business metrics—so goals stay aligned.

Technology Is Where Agile Shines—and Struggles

Software development fits agile perfectly: complex problems, evolving requirements, tight feedback loops. And yet, many companies have agile tech teams but not agile tech organizations. Why? Because the rest of the system—architecture, structure, culture—isn’t built to support agility.

The book highlights three blockers:

• Monolithic systems that can’t scale or adapt quickly
• Too much specialization, making teams too large or unstable
• Silos in IT—development, ops, security, legal—all pulling in different directions

To fix this, tech organizations need to mirror agile values. That means blended teams that own the product end to end. No more tossing code over the wall. With DevSecOps, teams build, test, secure, and release software together. RBS’s Home Agent, a complex digital solution for home ownership, was built this way—in just four months.

The Real Benefits of Agile Software Development

When agile is done right, the improvements are dramatic—up to three times faster delivery and better alignment with customer needs. It cuts out waste like waiting for approvals, redundant features, and clunky handoffs. Most of all, it delivers what customers actually want, not just what was spec’d a year ago.

To scale this, companies need a few things:

• Modular architecture so teams can work independently
• Cross-functional backlogs where teams own everything: dev, support, maintenance
• Talent upgrades and coaching to build deep tech and business skills
• Vendor models that reward collaboration and stable teams
• Functional partners (like risk or legal) that coach instead of control

Amazon is the gold standard here. Their architecture lets teams deploy code thousands of times a day. In contrast, most big companies with monolithic systems can only update once a week—if that.

Agile vs. Lean vs. Product Management: A Word of Caution

The chapter ends with a note of realism. Within companies, different teams often use different agile “religions”: Lean, Agile, Product Management. This can lead to tribalism, confusion, and even open conflict. People argue over terms, processes, and frameworks, instead of building together.

Here’s the difference, as the book lays it out:

• Lean production (Lean Six Sigma) is great for operational efficiency, but bad for innovation—it kills variability, which innovation needs.
• Lean startup and product management are closer to agile and focus on continuous learning.
• Product management emphasizes business ownership and full responsibility for the product—something many product owners lack.

Instead of choosing sides, the authors suggest harmonizing these approaches into a unified playbook, tailored to your company’s culture and needs.

Final Thought: It’s All Connected

Process and technology aren’t afterthoughts—they’re core to delivering customer value. Agile teams that take ownership of both can drive huge improvements. But only if the whole organization supports them: through funding, collaboration, smart architecture, and shared purpose.

Chapter 8 – Doing Agile Right

Agile: Not a Fad, But a Tool That Must Be Respected

The authors open this final chapter with a powerful reminder: agile should not be treated like just another management trend. It’s not meant to be a quick fix or a shiny new buzzword—it’s a real tool that, if used well, can make work better, organizations healthier, and people more fulfilled.

But if misused—through overhype, rigid fanaticism, or by turning it into a tool for fear and control—it could end up like many failed fads before it: discarded and disrespected.

They cite decades of research from Bain & Company’s massive database of management tool feedback. What kills most tools is misuse: when people overapply them to problems they weren’t built to solve, or rush in without understanding. Agile runs that same risk—especially if leaders try to impose it everywhere, use it to cut jobs, or turn it into yet another bureaucratic mechanism.

Agile Should Never Create Fear

People don’t fear change—they fear loss. Agile shouldn’t feel like losing control, expertise, or ways of working.

That’s why it needs to be implemented through real collaboration, testing, and learning in live environments. No one should feel like they’re being forced into chaos without support.

Agile Is a Tool, Not a Strategy

The book makes this metaphor beautifully clear: agile is like a chainsaw. It’s powerful—but not useful for everything. It’s perfect for cutting trees, not for slicing tomatoes or performing surgery. So companies don’t need an “agile strategy” or a “chief chainsaw officer.” They need a business strategy, and agile should serve that strategy—not replace it.

Agile is best when we don’t yet know exactly what to deliver or how. That’s when fast learning matters. But for routine, stable work that relies on consistency, standardized methods work better. Agile isn’t one-size-fits-all.

Don’t Use Agile for Layoffs or Damage Control

Agile is sometimes pitched as a way to cut 30% of the workforce while claiming to be modern and lean. The authors strongly push back against this. Real agile makes work more human, not colder. If it’s being used as a smokescreen for layoffs or as a way to hide bad leadership decisions, something’s gone very wrong.

Learning from Amazon’s Unique (and Messy) System

This chapter dives deep into Amazon—not because it’s perfect, but because it has sustained agility at scale over time. And that makes it worth studying. Amazon’s culture is intense, even harsh: described as combative, confrontational, and exhausting. Work-life balance is tough, and there’s no fuzzy social purpose front and center. Yet, it works—because the system balances itself.

Amazon is obsessed with customers. That’s not a slogan—it’s a lived reality. Engineers get woken up in the middle of the night to fix customer problems. Leaders sacrifice short-term profit for long-term customer delight. Most of Amazon’s key metrics—about 80%—are tied to customers.

From two-pizza teams to six-page PR/FAQ memos, Amazon designs its ways of working around deep ownership and constant customer thinking. Teams are “single-threaded”—focused on one big problem at a time—and enabled by microservices so they can move fast and fail fast without breaking the whole system.

Four Rules for the Agile Road

1. Learn to Love Agile Teams—Then Create Your Own

You can’t scale agile if you don’t first do agile well in small teams. That means building teams with autonomy, multidisciplinary skills, single-threaded focus, and strong customer feedback loops. Great agile teams don’t just follow rules—they understand why the rules exist and constantly seek better ways to work.

As more teams succeed, they inspire others. Success spreads. But don’t just watch—build your own agile team, even if you’re a leader. Use it to tackle real problems and demonstrate new behaviors.

Darrell Rigby even shares his own story: how he started practicing agile values in his day-to-day life, like breaking tasks into smaller pieces, celebrating learning, and expressing gratitude during stress. These simple shifts made him happier, more effective, and a better leader.

2. Master Agile at Scale—But Envision an Agile Enterprise

Scaling agile means having many agile teams working across the business. This alone can drive huge innovation gains and uncover waste—often showing that a third of current projects could be stopped immediately with no loss.

But real agility doesn’t stop there. The goal is to build an agile enterprise—a whole system that runs operations reliably while continuously adapting and innovating. It’s about balancing speed with stability, customer focus with efficient processes.

Agile enterprises don’t just follow markets—they shape them. They don’t just react to customer needs—they anticipate and redefine them. The transformation is holistic, strategic, and measurable in outcomes—financial, customer, employee, and societal.

3. Use Agile Innovation to Get There

Agile is perfect for journeys where we don’t yet know the destination. That’s what makes it ideal for moving from bureaucracy to agility. You can’t command-and-control your way to agile. You have to test, learn, adapt, and build confidence over time.

That’s why the authors recommend forming an agile leadership team. This team uses backlogs just like agile product teams do—except their backlog is full of strategic opportunities, not technical tasks. Prioritize what matters. Say no to distractions. Move with focus and clarity.

A great example: when an executive at Constellation Wines made a personal request to an agile team, they didn’t say yes immediately. They added it to the backlog and prioritized based on value. That’s what focus looks like.

And when teams can see better, more exciting opportunities in the backlog, they’re more willing to let go of failing projects—because there’s something better to work on.

4. Make It Fun

This part is refreshingly honest. Agile done right should feel good. If it’s making your team miserable, stop. That’s not the point. Agile should create a “runner’s high”—a sense of progress, teamwork, and meaningful wins.

Progress releases dopamine. Collaboration builds oxytocin. Overcoming challenges brings endorphins. Working with purpose fuels serotonin. Agile done right taps into all of these. It makes people feel alive at work.

Celebrate small wins. Use sprints to create momentum, not pressure. Help teams feel progress and purpose, not exhaustion. And above all—teach others. Teaching forces you to master what you know, opens your thinking, and creates deep satisfaction.

Final Thought: If Agile Isn’t Fun, You’re Not Doing It Right

That’s how the book closes. A reminder that agility is about improving the way we work and live—not about suffering for some distant payoff. If your agile transformation doesn’t make people more engaged, motivated, and joyful, then something’s off.

Agile is a tool for better results and a better workplace. Use it wisely. Scale it thoughtfully. Adapt it with humility. And, most importantly, enjoy the ride.

4 Key Ideas from Doing Agile Right

6 Main Lessons from Doing Agile Right

My Book Highlights & Quotes

“… In a truly agile enterprise, bureaucracy and innovation become partners. They create a system where both elements improve and where people in each camp collaborate to generate superior results. We’ll show how to harmonize the two in this book…”

“… There is an optimal level of change for every business, and for every activity within a business. Ideally, an agile business system would operate at the golden mean between change deficiency—leading to a static business system that adapts too slowly to survive—and change excess, creating a chaotic business system that constantly risks spinning out of control…”

“… Anyone contemplating it has to pass F. Scott Fitzgerald’s famous test of first-rate intelligence: “the ability to hold two opposed ideas in the mind at the same time and still retain the ability to function…”

“… Agile enterprises map the work that needs to be done to meet customer needs and deploy dedicated cross-functional agile teams to change the business…”

“… Talent system: Agile enterprises use performance-driven processes for determining how to acquire, deploy, assess, develop, reward, and inspire talent, and continuously improve the systems and approaches to people management…”

“… One more ingredient of fun: teaching and coaching others. Teaching—and watching others learn—is one of the most rewarding and satisfying human endeavors…”

“… One tactic for making the whole endeavor fun is to create and celebrate frequent wins…”

“… A critical tool for the team is a robust, adaptive backlog of opportunities that team members can tackle together. The backlog will give your team a realistic, itemized, fact-based vision of how much value is possible, and in what order the team should attack the work…”

“… The first step should be to create an agile leadership team, which will operate just like any other agile team…”

“… Agile enterprises create balanced systems that efficiently adapt to changing customer opportunities in order to deliver superior results…”

“… In an agile enterprise, executives do not focus on optimizing the performance of individual teams. They focus instead on improving the performance of the entire business system…”

“… We highly recommend lean production methods for improving operations. We do not recommend them for managing innovation…”

“… Lean is a source of considerable confusion because people apply the term to two very different approaches: lean production systems (also known as Lean Six Sigma), and lean product development (also known as a lean start-up)…”

“… Forming agile teams may not even require changing reporting lines for employees. Agile team members would still report to their home departments, but their managers would act as long-term professional development coaches rather than as day-to-day supervisors. Daily activities would be planned and executed with the teams…”

Conclusion

Doing Agile Right isn’t just a guide for running better teams—it’s a call to rethink how we lead, build, and adapt in a world that’s constantly changing.

It doesn’t sell shortcuts or hype. Instead, it offers something more valuable: clarity. Clarity on when to use agile, how to lead through it, and why it matters.

If you’re tired of agile being all talk and no transformation, this book gives you a smarter, more grounded way forward—one that’s not only more effective, but a lot more human.

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

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

Want to show your support and appreciation tangibly?

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

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

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

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

Navigate between the many topics covered in this website:

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

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

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

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

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