Book Notes #26: Managing Agile Projects by Sanjiv Augustine

The most complete summary, review, highlights, and key takeaways from Managing Agile Projects. Chapter by chapter book notes with main ideas.

Title: Managing Agile Projects
Author: Sanjiv Augustine
Year: 2005
Pages: 229

There are books that teach you methods, and there are books that shift your mindset. Managing Agile Projects does a bit of both—but with a tone that feels more like a good conversation than a lecture.

If you’ve ever felt caught between wanting to lead with empathy and needing to deliver results, this book gives you the tools—and more importantly, the permission—to do both.

Sanjiv Augustine doesn’t just talk about agile practices.

He talks about people, trust, learning, and the kind of leadership that doesn’t try to control everything but instead creates space for good things to happen.

As a result, I gave this book a rating of 7.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 Managing Agile Projects

Real Leadership, Not Buzzwords

This book isn’t about trendy terms or frameworks—it’s about people. It shows you how leadership shifts when you start from trust instead of control. You’ll walk away with a clearer, calmer view of what it really means to guide a team.

Stories You’ll Recognize

The opening fable, Project Phoenix, mirrors the chaos so many of us have seen firsthand. It’s not abstract theory—it’s storytelling with purpose. Through that story, you learn the difference between a team that’s surviving and one that’s thriving.

Agile That Makes Sense

You won’t get overwhelmed with jargon or rigid rules. Instead, Augustine introduces agile in a way that feels grounded and usable. Whether you’re new to agile or already knee-deep in it, this book helps you see how it can actually work—with real teams, in real situations.

Book Overview

Most books on project management start with frameworks, tools, and templates. Sanjiv Augustine starts with a story—a messy, familiar one.

A project full of ambition, smart people, and all the right processes… that still crashes and burns. And that’s exactly what makes Managing Agile Projects so different.

It doesn’t just explain how agile works—it shows why we need a different way of managing altogether.

Right from the start, the book feels grounded in reality.

Project Phoenix, the fictional story Augustine opens with, could be any project many of us have worked on. There’s chaos masked as control, teams speaking different languages (sometimes literally, sometimes figuratively), and a whole lot of planning with very little progress.

It’s a relatable mess—and that’s the point. The story doesn’t shame anyone. It simply holds up a mirror and says, “See? This is why the old way doesn’t work anymore.”

But what makes the book special isn’t just that it points out the problem—it offers a better way. Not a silver bullet. Not a rigid method.

But a thoughtful, practical approach rooted in trust, collaboration, and continuous learning. Augustine calls it Agile Project Management (APM), and the way he explains it feels less like reading a manual and more like having a really good conversation with someone who’s been through it all—and wants to help you do better.

As you move through the chapters, you start to see the shape of this new way of working.

Teams are no longer treated as resources to be managed but as living systems—organic, evolving, capable of solving hard problems if given the right space. There’s a strong focus on building Organic Teams that are cross-functional, stable, and self-directed.

The book doesn’t just say “trust your team”—it shows how to actually build one worth trusting.

One of the most useful ideas is the Guiding Vision. It’s not about writing a perfect mission statement—it’s about helping the team see where they’re going and why it matters.

That clarity of purpose, when shared, becomes something people can align around. And it helps steer decisions when things (inevitably) get messy.

Then there’s the concept of Simple Rules—a reminder that we don’t need complex processes to be disciplined. In fact, the more complex things get, the more we need to simplify.

Augustine borrows from nature here, showing how even birds in flight follow just a few rules and still manage to navigate together beautifully. Teams can do the same, if we’re intentional.

Some chapters hit especially close to home. Like the one on Open Information, where Augustine reminds us that so many project delays come not from bad coding or poor design—but from waiting. Waiting on decisions, waiting on approvals, waiting on clarity.

It’s a quiet truth most of us have felt. His solution is as simple as it is powerful: make information flow faster, more openly, and more frequently.

And when it comes to leadership, this book doesn’t romanticize control. Instead, it introduces Light Touch—a leadership style that’s subtle but present. It’s about knowing when to step in and when to get out of the way. It’s about being available without hovering.

For anyone who’s ever led a team and wondered “Am I doing too much or too little?”—this chapter offers real, honest insight.

By the time you get to Adaptive Leadership, the pieces come together. Agile isn’t a set of rituals—it’s a mindset. It’s about being ready to learn, adjust, and grow as you go.

And leading in that world means being steady without being rigid. Calm in uncertainty. Clear without being controlling.

The final chapter doesn’t pretend the shift is easy. Transitioning from the familiar takes time, patience, and a willingness to let go of the illusion of control.

But Augustine makes the case that it’s worth it. Not just because it makes teams faster or products better—but because it makes the work more human.

That’s really what sticks with you after reading Managing Agile Projects. It’s not a book full of hype or quick wins. It’s a steady, thoughtful conversation about what it means to lead when things are uncertain—when people, not plans, are the real drivers of success.

And in a world where change is constant, that message feels more relevant than ever.

If you’ve ever found yourself stuck between the old way of managing and the new way of working, this book won’t give you all the answers—but it will help you ask the right questions. And sometimes, that’s exactly what we need.

Phoenix Project again?

Despite the similar names, Project Phoenix in Sanjiv Augustine’s Managing Agile Projects and The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford are completely different works—with different goals, stories, and contexts.

Because both books feature a “Phoenix Project” at the center of their storytelling, it’s easy to assume they’re connected—or that one inspired the other. But they’re not. The similarities stop at the metaphor. Once you look a little closer, the differences in timing, content, and purpose become clear.

Sanjiv Augustine’s Managing Agile Projects came first, published back in 2005. It opens with a short fictional story titled “Project Phoenix: An APM Fable of Revival and Renewal.” This story isn’t the whole book—it’s more like a warm-up. It paints a picture of a struggling project being turned around through agile principles like trust, self-organizing teams, simple rules, and adaptive leadership. The story sets the tone for the rest of the book, which dives into Agile Project Management as a practical and human-centered way to lead complex work.

Fast forward to 2013, and Gene Kim, along with Kevin Behr and George Spafford, released The Phoenix Project. This one is a full-blown novel. It tells the story of a chaotic IT initiative—also called The Phoenix Project—that’s spinning out of control inside a fictional company. Through the lens of that story, the book teaches core DevOps principles, from systems thinking to flow management to cross-functional collaboration. It’s longer, deeper in narrative, and centered around IT operations and cultural transformation.

There’s no known connection between the two works. Gene Kim hasn’t cited Augustine’s book as an influence, and the overlap in naming seems to be symbolic rather than intentional. The phoenix—rising from the ashes—is a well-known metaphor for recovery and renewal. It makes perfect sense that both authors, writing about failing projects and transformative change, would land on the same image.

In short, these are two very different books. Managing Agile Projects uses a short fable to introduce agile leadership ideas, while The Phoenix Project tells a rich story to teach DevOps. They don’t copy each other. They just happen to use the same powerful metaphor to show that even the most broken projects can rise again—with the right mindset and practices behind them.

Chapter by Chapter

Chapter 1 – Agile Project Management Defined

The pressure on modern project managers

Sanjiv Augustine opens this chapter with a reality many managers will recognize: they’re overworked, under pressure, and often stuck doing tasks that don’t directly add value. He points to long hours spent filling out forms, writing reports, and updating outdated plans—activities that create the illusion of control but don’t move the project forward. The result? Lots of effort, but little customer value.

What actually matters: customer value and agility

To change this, Augustine argues we need to focus on customer value—delivering the right product, at the right time, for the right price. Agile methodologies like XP, Scrum, and Crystal are designed around this principle. They break work into small chunks, prioritize collaboration over process, and embrace change rather than resist it.

Agility, as defined here, is the ability to deliver customer value while navigating uncertainty. It’s not about rigid control or endless optimization—it’s about adaptability, learning, and responding to change with purpose.

A shift in mindset: projects as complex adaptive systems

One of the big ideas in this chapter is that projects are not machines to be controlled—they’re living systems. Augustine introduces the concept of Complex Adaptive Systems (CAS), where team members interact in dynamic ways, following simple rules that lead to emergent, intelligent behavior. This view replaces the old mechanical model with something more organic and better suited to the messy reality of projects.

The APM definition and principles

Agile Project Management (APM), then, is defined as the work of energizing, empowering, and enabling project teams to deliver business value while continuously learning and adapting.

APM is built on three core principles:

  • Foster alignment and cooperation – Get people moving in the same direction through shared vision, not top-down control.
  • Encourage emergence and self-organization – Let simple rules guide teams so they can respond creatively and effectively to change.
  • Institute learning and adaptation – Use feedback to stay flexible and continuously improve, without swinging into chaos or rigidity.

Introducing the six APM practices

To bring these principles to life, Augustine introduces six practical focus areas that will guide the rest of the book: Organic Teams, Guiding Vision, Simple Rules, Open Information, Light Touch, and Adaptive Leadership.

These practices are not a checklist—they’re flexible tools. The key is applying them thoughtfully, based on the needs of your team and project environment.

This chapter lays the philosophical and practical foundation for APM. It calls out the traps of traditional management and offers a clearer, more human way forward. By shifting our mindset and tools to focus on value, collaboration, and adaptation, we can lead projects that actually work—not just on paper, but in reality.

Chapter 2 – The Agile Manager

Beyond command and control

This chapter challenges the traditional image of a project manager as a planner, controller, and taskmaster. Sanjiv Augustine argues that agile environments call for something different. Instead of directing every move, the agile manager becomes a facilitator—someone who energizes the team, removes obstacles, and helps everyone focus on what matters most: delivering value.

The agile manager doesn’t chase status updates or micromanage tasks. Their role shifts from enforcing a plan to creating an environment where the team can thrive. It’s about supporting, not steering.

The four roles of the agile manager

Augustine outlines four key roles that an agile manager plays. These roles are not fixed job titles, but mindsets and responsibilities that adapt to what the team needs at different times:

  1. Team Leader – Building relationships, guiding the team through uncertainty, and helping them stay motivated.
  2. Customer Representative – Keeping the team connected to business goals and user needs.
  3. Project Facilitator – Managing risks, navigating organizational hurdles, and helping the team stay on track without controlling them.
  4. Evangelist – Advocating for agile values inside and outside the team, and helping others understand the benefits of the approach.

These roles require flexibility. The agile manager might lean more heavily into one role over another depending on the context—but they’re all grounded in collaboration, trust, and adaptability.

Values over tools

A big takeaway here is that tools and techniques are only as good as the values behind them. Augustine highlights five personal values that an agile manager should embody:

  • Trust – Believing in the team’s ability to deliver.
  • Respect – Valuing each person’s contribution and perspective.
  • Openness – Creating a safe space for honest communication.
  • Courage – Facing tough situations without backing down.
  • Focus – Prioritizing what truly drives value.

These aren’t just buzzwords. They’re daily practices. When a manager leads with these values, the team becomes more resilient, more motivated, and more capable of navigating complexity.

Management redefined

This chapter is all about redefining what it means to manage. It’s not about giving up control entirely—but about giving the right kind of control. Agile managers still play a critical role. They still guide, influence, and support. But they do it by building trust and helping others succeed, not by trying to hold all the strings.

This chapter puts the spotlight on the manager—not as the hero of the project, but as the enabler of the team’s success. It challenges outdated assumptions and shows that agile leadership is about presence, not power. It sets the tone for everything else in the book by asking a simple but powerful question: How can we lead better by letting go of control and focusing on what truly matters?

Chapter 3 – Organic Teams (Part 1)

Teams don’t just happen—they’re built

In this chapter, Sanjiv Augustine focuses on something that sounds simple but is surprisingly hard to get right: building a real team. Not a group of people working on the same project, but an actual team—one that’s cohesive, committed, and capable of adapting together.

He starts by making a key distinction: traditional project teams are often structured like machines, where each part does its job in isolation. But agile teams need to function more like living organisms. That means they need flexibility, interaction, and shared purpose.

What makes a team “organic”

Organic Teams are at the heart of Agile Project Management. These are cross-functional teams that self-organize, learn together, and grow stronger over time. They aren’t “managed” in the traditional sense—they’re supported, nurtured, and given room to evolve.

To get there, teams need three key ingredients:

  • Structure – Not rigid hierarchy, but clear roles and boundaries that create a safe container for collaboration.
  • Discipline – Regular rhythms, clear commitments, and accountability to each other.
  • Shared identity – A sense of belonging and mutual respect that helps individuals see themselves as part of something bigger.

Forming the team intentionally

Augustine stresses that teams don’t become organic by accident. It starts with formal team creation. That includes selecting people with diverse but complementary skills, making sure each member is committed to the project, and clearly defining the team’s boundaries and responsibilities.

This part of the chapter explores common mistakes—like forming ad hoc groups with unclear roles or pulling team members into multiple projects at once. When people are constantly context-switching or reporting to too many stakeholders, real teamwork never gets off the ground.

Getting the foundation right

One practical tip here is to name the team and treat it as a unit. This helps create identity. It’s also important to co-locate the team whenever possible—shared space makes shared purpose easier. But even in distributed setups, rituals like daily standups and visible boards can create a sense of unity.

The team should also have a shared understanding of their goal. That’s where tools like team charters and working agreements come in. These aren’t just checkboxes—they’re living documents that help people align on how they’ll work together, how they’ll make decisions, and how they’ll deal with conflict.

This chapter reminds us that agile is not just about sprints and sticky notes—it’s about people. The way we form and support teams can make or break a project. Augustine makes a strong case that investing time in building real teams isn’t optional—it’s essential. Because when teams are organic, they’re not just faster or more efficient—they’re smarter, stronger, and more resilient when things go wrong.

Chapter 4 – Organic Teams (Part 2)

Teams within teams: embracing the larger system

In Part 1, Augustine laid the groundwork for building cohesive, organic teams. In this chapter, he zooms out to show that even the most self-organizing team doesn’t operate in a vacuum. Agile teams exist within a larger organization, and how they connect to that environment can either support or sabotage their success.

This chapter is about integration—helping teams stay agile while working with external groups like other teams, departments, or business units. It’s about building bridges without losing identity.

From isolation to collaboration

Augustine introduces the idea that teams often fall into two traps: isolation or overload. In isolation, they become disconnected from the rest of the organization, building great software that nobody’s ready to use. In overload, they’re so entangled in meetings, dependencies, and external demands that they lose their rhythm.

The goal is balance. Organic Teams should maintain internal cohesion while cultivating healthy external connections. That means managing boundaries deliberately—knowing when to say yes, when to say no, and how to coordinate without being consumed.

Shared roles and responsibilities

One key strategy is defining clear interfaces between the team and external stakeholders. This includes roles like product owners, customer representatives, and even liaisons to other teams. When these roles are clear, it reduces confusion and helps the team focus on delivery.

Augustine also touches on the importance of having team members wear “multiple hats.” For example, a developer might also participate in testing or customer demos. This kind of role flexibility builds empathy, speeds up feedback, and reduces silos.

Supporting autonomy without chaos

Even as teams take ownership and make more decisions on their own, they still need some support from leadership. Augustine emphasizes that the agile manager plays a critical role here—protecting the team’s autonomy while ensuring they’re aligned with larger business goals.

He introduces the metaphor of a boundary manager: someone who helps filter distractions and external requests, shielding the team so they can focus without becoming isolated. It’s a balancing act between openness and focus.

Nurturing a learning culture

As teams mature, their ability to self-correct becomes one of their greatest assets. Augustine points out that healthy teams reflect on their work regularly, give each other feedback, and constantly improve. This can be fostered through simple practices like retrospectives, informal check-ins, and space for experimentation.

What’s powerful here is that the learning isn’t just about fixing problems—it’s about deepening trust, refining collaboration, and evolving the team’s identity over time.

This chapter reminds us that agility isn’t just about what happens inside the team—it’s also about how the team interacts with the world around it. Augustine shows that true agility requires both strength and flexibility: strong enough to stay focused, flexible enough to connect meaningfully with others.

By managing those connections wisely, agile teams can avoid isolation, reduce friction, and create real momentum—not just for their own work, but across the organization.

Chapter 5 – Guiding Vision

Sanjiv Augustine starts this chapter with a powerful idea: vision is not just a concept on a whiteboard—it’s a force that lives in people’s hearts and minds. Drawing from Peter Senge’s work, the chapter emphasizes how shared vision helps teams align, stay motivated, and move together toward a meaningful goal. When vision is missing, projects suffer from misalignment, unmet expectations, and confusion about direction.

Three visions, one purpose

The core of this chapter is the idea of the Guiding Vision, which combines three separate but interconnected elements:

  • Team Vision – How we want to work together.
  • Project Vision – How we deliver business value as a team.
  • Product Vision – What we’re building and why it matters.

These three visions together form a shared mental model that drives behavior. They help teams answer not only what they’re doing but how and why they’re doing it.

Building the team vision

The team vision is all about identity and culture. It sets the tone for how people treat one another, how they work together, and what kind of team they want to be. Augustine shares that great team visions don’t usually come from management alone—they emerge from real conversations among team members about their aspirations, values, and how they want to operate.

One of the key practices here is getting personal commitment. It’s not enough to hang a vision statement on the wall; people need to believe in it and hold each other accountable to it.

Creating a bold product vision

Product vision gives the team a future to aim for. Augustine encourages teams to think big and build a compelling picture of what success looks like. This includes defining outcomes, clarifying scope, and estimating effort. Tools like “vision boxes” (a creative exercise where teams design the front and back of a hypothetical product package) and elevator pitches help make the vision tangible and communicable.

This vision isn’t fixed—it evolves. But even a simple, clear product vision can help teams make better decisions and stay aligned.

Clarifying the project vision

The project vision bridges the team and product visions by answering: how will we work together to make this happen? It includes the elevator pitch, but also roles, responsibilities, and expectations. Augustine introduces tools like “project sliders” to visualize trade-offs between cost, scope, time, and quality—helping everyone align on what’s most important.

He also emphasizes managing expectations early. Misunderstandings about roles, deliverables, or criteria for success can derail a project fast. Good project vision work brings these conversations forward before they become problems.

Leadership and management in action

Throughout the chapter, Augustine makes a clear distinction between leadership and management responsibilities. Leaders create the space for vision to emerge and inspire people to commit. Managers help translate those visions into plans, scope, and timelines.

Activities like release planning, stakeholder interviews, and shared workshops bring these roles together. The vision is built collaboratively and refined over time—not dictated top-down.

This chapter shows that vision isn’t fluff—it’s the glue that holds agile teams together. A strong guiding vision helps people move with confidence, even when things get messy. It reminds everyone why they’re here, what they’re aiming for, and how they’re going to get there together.

Chapter 6 – Simple Rules

Discipline doesn’t have to mean complexity

Sanjiv Augustine opens this chapter with a striking contrast: some organizations bury teams under mountains of rigid processes, believing complexity equals discipline. But he argues the opposite. True discipline lies in applying a few simple rules, consistently. The best agile teams don’t follow heavy procedures—they work within a flexible framework that’s just enough to guide behavior without limiting innovation.

To explain how this works, Augustine brings in a metaphor from nature: birds flying in formation. Each bird follows a few simple rules—stay close, align direction, don’t crash—and out of that, beautiful and complex group movement emerges. Agile teams, he suggests, can operate the same way.

The goal: adaptability through simplicity

The purpose of the Simple Rules practice is to define a minimal set of process rules that align with the environment and allow agile teams to deliver value quickly and reliably. This doesn’t mean working without structure—it means finding the right amount of structure, customized to the team’s context.

To do this, Augustine offers two main sets of activities:

  • Customizing the rules to the environment
  • Implementing the rules in practice

Customizing to fit your context

Before defining any rules, the agile manager must understand the team’s environment. That means assessing the organization’s stability, culture, structure, and technological landscape. Is it bureaucratic or organic? Centralized or flexible? Is innovation welcomed, or is risk feared?

Once that’s clear, managers can customize a methodology to match that environment. Augustine warns against a cookie-cutter approach. Instead, agile methods like XP should be adjusted depending on team size, business goals, and organizational constraints.

Team involvement is essential

Change can’t be imposed. That’s why one of the most important leadership actions is to enlist the team for change. Using tools like force field analysis, the agile manager invites the team to explore what’s helping and what’s holding them back—making them part of the transformation instead of victims of it.

Implementing the rules: XP as an example

The second half of the chapter shows how to bring Simple Rules to life using Extreme Programming (XP) practices. These include defining the release plan, iteration plans, backlogs, and then facilitating the full development cycle—design, code, test, deploy. XP becomes a toolkit of simple but powerful practices that create rhythm and focus.

Each rule can be classified using categories from strategy research:

  • How-to rules (e.g. Test-Driven Development, Continuous Integration)
  • Boundary rules (e.g. customer/programmer rights)
  • Priority rules (e.g. Planning Game)
  • Timing rules (e.g. one-week iterations)
  • Exit rules (e.g. stopping a feature when no longer valuable)

Augustine includes two rich examples—one where speed to market is the goal, and another where a failing project needs stabilization. Both use XP practices, but applied very differently. This shows how agility comes not from the rules themselves, but from how thoughtfully they’re applied.

Simplicity requires constant attention

Finally, the chapter touches on the need to adapt rules over time. What works early in a project might not work later. Through retrospectives and ongoing feedback, the team can fine-tune its rules and evolve its way of working. This isn’t optional—it’s part of staying agile.

This chapter flips the script on traditional process-heavy thinking. Instead of layering more control onto teams, Augustine shows how fewer, smarter rules can lead to better outcomes. The secret isn’t in having more process—it’s in having just enough of the right process, shaped by the team, and refined as you go.

Chapter 7 – Open Information

Information is energy

Sanjiv Augustine opens this chapter with a simple but powerful insight: information is not just data—it’s the energy that keeps a team alive. Without timely and relevant information, teams can’t self-organize, innovate, or deliver value. But in many traditional environments, information is locked away in silos, delayed by hierarchy, or lost in the noise. The result? Slow decisions, poor alignment, and frustrated people.

Agile, with its roots in complexity theory and organic systems, promotes continuous information flow. Yet, Augustine argues, even agile methods often fall short when it comes to exchanging information across external groups or generating deep, action-based exchanges within the team. This is where the Open Information practice steps in.

Three fronts for better communication

The chapter introduces three areas that agile managers should work on to unlock the full potential of Open Information:

  1. Agile practices for real-time flow
  2. Reducing information cycle time
  3. Creating transforming exchanges

Let’s unpack each one.

Agile practices: Keep it visible, fast, and human

The first set of activities is about setting up the team environment to make information flow naturally. Augustine suggests simple yet effective steps:

  • Collocate teams to encourage quick conversations.
  • Hold daily standups so everyone is on the same page.
  • Use information radiators (like visible boards) to show status openly.
  • Pair programming and on-site customers keep communication direct and continuous.

These techniques may seem basic, but together, they create an environment where people can share what they know, ask for help, and adjust quickly.

Information cycle time: Don’t let things wait

Next, Augustine dives into a less visible but critical issue—information delays between the team and external groups. Often, it’s not the coding or testing that slows things down—it’s waiting for approvals, inputs, or decisions. This “information cycle time” adds friction and reduces agility.

To tackle this, Augustine introduces the value stream map—a Lean tool for visualizing the flow of information across the project. By charting out touch time (when work is being done) and wait time (when nothing is happening), teams can spot bottlenecks and work with external groups to fix them. Assigning liaisons and tracking improvements are practical ways to shorten the loop.

Transforming exchanges: Speak to create action

Finally, the most interesting part of the chapter is about what Augustine calls transforming exchanges. These are not just status updates or technical clarifications—they are conversations that change people’s understanding, reveal insights, or spark new ideas.

One powerful example is the acceptance test demo, where a customer sees a working feature for the first time. The team learns from the customer’s reaction. The customer learns what’s possible. It’s not just a checkmark—it’s a moment of mutual learning.

Augustine highlights three kinds of conversations that create these transformations:

  • Conversations for action – making clear requests and promises.
  • Conversations for possibility – exploring what could be done.
  • Conversations for disclosure – sharing thoughts, concerns, and realities.

He also emphasizes building trust. Without it, people won’t speak openly, and information will stay hidden. Agile teams, he says, must begin by trusting—waiting for trust to build slowly doesn’t work in fast-moving environments.

This chapter reminds us that agility isn’t just about process or tools—it’s about people talking, listening, and learning together. Information is the fuel that drives adaptability, and without it, even the best teams will stall. Augustine’s Open Information practice provides practical ways to keep that fuel flowing—inside the team and out.

Chapter 8 – Light Touch

Freedom with responsibility

In this chapter, Sanjiv Augustine tackles a big question: how do you maintain control in agile projects without slipping back into rigid command-and-control management? His answer is Light Touch—a way of leading that supports autonomy and flexibility, without losing focus on results.

The idea is not to micromanage, but also not to disappear. It’s about striking a balance—guiding the team with care and subtlety so they can thrive, deliver customer value, and stay aligned.

Intelligent control, not over-control

Augustine introduces the concept of intelligent control. Instead of top-down decisions, this approach gives teams control over their day-to-day work while the agile manager focuses on guiding broader direction. It’s not about removing all control—it’s about distributing it wisely.

He breaks this into several key actions:

  • Decentralize control: Teams decide on small, frequent tasks. Managers only step in for strategic or high-risk decisions.
  • Establish a pull task management system: Work is not pushed down from the top; teams “pull” tasks when they’re ready. Tools like “job jars” help visualize and manage this.
  • Manage the flow: Control the movement of customer value, not the people. The focus is on ensuring value flows smoothly from idea to delivery.
  • Use action sprints: Encourage teams to solve problems and take action in short, focused bursts rather than long planning cycles.

Leadership in the background

The agile manager also supports roving leadership—a concept where leadership emerges naturally from whoever is best positioned to act, rather than from formal titles. This creates a more dynamic team culture and empowers members to step up when needed.

Augustine encourages managers to fit their style to the situation. Sometimes a direct approach is needed; other times, it’s better to step back and let the team lead. Learning to “go with the flow” is part of this light touch mindset.

Whole-person recognition

Beyond tasks and tools, this chapter reminds us that people are not just resources—they’re humans. Augustine urges managers to lead with empathy through whole-person recognition. That means:

  • Maintaining quality of work life: Teams need space to breathe, not just deliver. Overtime should be the exception, not the norm.
  • Building on personal strengths: Rather than fixing weaknesses, help team members do more of what they do best.
  • Managing commitments through personal interactions: Real collaboration happens through real conversations—not email chains or status updates. This involves being present, listening actively, and tuning into people’s emotions and energy.

Light Touch shows that leading agile teams is less about having power and more about using influence wisely. It’s about creating the conditions where teams can perform at their best—without being controlled or abandoned. Augustine offers a clear, respectful alternative to both extremes, showing that trust, responsibility, and small adjustments in leadership style can make a big difference.

Chapter 9 – Adaptive Leadership

Leadership on the edge of chaos

Sanjiv Augustine starts this chapter with a bold claim: agile teams do their most creative and valuable work at the edge—where there’s just enough structure to avoid chaos but enough freedom to innovate. But this sweet spot isn’t stable. Projects can either take off or spiral down fast. That’s why adaptive leadership is so important—it’s about steering the team through complexity, not with rigid plans, but with constant learning and thoughtful presence.

The goal of this practice is threefold:

  • Monitor project progress and APM practices in real-time
  • Build in learning and adaptation as a continuous process
  • Maintain a leadership presence that energizes the team

Double-loop learning: Adjusting the system, not just the actions

Augustine introduces the idea of double-loop learning—a concept from systems thinking. In single-loop learning, you fix problems without questioning the rules. In double-loop learning, you step back and ask, “Are we even following the right rules?”

To make this happen, agile managers are encouraged to:

  • Get Plus-Delta feedback daily: A simple feedback mechanism where team members share what’s working (+) and what could be improved (Δ).
  • Monitor and adapt the Simple Rules: Make sure rules are still useful—if not, change them.
  • Track APM practices: Not just if they’re being followed, but if they’re delivering value. Augustine even provides tables to help managers assess each APM practice.
  • Conduct project reflections: Unlike traditional lessons learned at the end, these reflections happen during the project—allowing real-time adjustments.
  • Use scenario planning: Think ahead about possible futures and prepare flexible responses instead of rigid plans.

These actions help managers and teams stay aware, stay nimble, and keep learning as they go.

Embodied leadership: Lead by presence, not power

The second part of the chapter shifts from process to presence. Augustine argues that in agile teams—where command-and-control doesn’t work—the most effective managers lead by example, energy, and trust.

He introduces embodied leadership, which includes:

  • Cultivating presence: Being grounded, aware, and emotionally in tune with the team. Not distracted, distant, or overly reactive.
  • Practicing embodied learning: Taking time to reflect, analyze, and deeply think about the project—not just rush from one task to the next. Solitude, silence, and personal discipline become key tools here.

This isn’t soft stuff. It’s the kind of leadership that quietly aligns the team and gives them confidence. The more volatile the environment, the more this calm, centered presence matters.

Adaptive Leadership is the glue that holds all other APM practices together. It’s what lets the team operate with just enough structure while embracing change. Augustine makes it clear that this kind of leadership is demanding—it requires courage, clarity, and self-discipline. But it’s also what makes the difference between a team that reacts and one that evolves.

Chapter 10 – Transitioning from the Familiar

Shifting mindsets, not just methods

In this final chapter, Sanjiv Augustine speaks directly to managers coming from traditional, plan-driven environments. He doesn’t dismiss their experience—in fact, he acknowledges the comfort and familiarity of structured processes, defined roles, and predictable outcomes. But he makes a clear case: Agile Project Management (APM) requires more than swapping tools or adopting new practices. It’s about reinterpreting management itself.

Rather than calling for a total reset, Augustine encourages a gradual, thoughtful transition. He presents this not as a rejection of everything familiar, but as a necessary evolution in how we think about teams, leadership, and value delivery.

From command to collaboration

A central message in this chapter is that people—not processes—are the real long-term investment. In traditional models, managers often focus on organizing tasks, controlling timelines, and optimizing processes. But in agile environments, the focus shifts to growing people, nurturing collaboration, and creating space for self-organization.

Augustine brings back the complex adaptive systems (CAS) metaphor introduced earlier. Agile teams, like living systems, thrive when given the right conditions to adapt and grow. That means stepping away from rigid control and trusting in the team’s ability to self-correct, learn, and deliver.

Craftsmanship over compliance

Another shift is moving from software engineering to software craftsmanship. In traditional environments, success is often measured by hitting deadlines and staying within scope. In APM, success is about building something valuable—with quality, care, and pride. It’s not about squeezing the most out of the process; it’s about creating space for mastery and learning.

To support this shift, Augustine emphasizes project context over strict content. Instead of just managing schedules and deliverables, agile managers should understand the broader picture: business goals, team dynamics, user needs. It’s a more holistic view of success.

New structures, new roles

Augustine also addresses the need to rethink familiar tools. For example, instead of using traditional Work Breakdown Structures (WBS), he recommends Feature Breakdown Structures (FBS), which are more aligned with agile values and help teams focus on delivering customer-facing features rather than internal tasks.

Even the manager’s role evolves. They become facilitators, boundary managers, and adaptive leaders—guiding without directing, influencing without dominating. It’s a subtle but powerful shift that requires emotional intelligence, patience, and a willingness to experiment.

Welcoming discomfort as part of the journey

This transition isn’t easy. There will be resistance—from within and from others. Augustine encourages managers to acknowledge the discomfort and move through it intentionally. Agile isn’t just a new set of practices; it’s a new way of seeing work, teams, and leadership.

He ends with a reminder: transitioning from the familiar is less about abandoning what we know and more about building on it—choosing flexibility over rigidity, people over process, and learning over perfection.

This final chapter brings everything full circle. It invites managers to reflect on their habits, assumptions, and instincts—and to begin the shift toward a more adaptive, people-centered approach to project management. Augustine doesn’t promise ease, but he does offer clarity: the path to agility starts with changing how we lead.

4 Key Ideas from Managing Agile Projects

Organic Teams

Agile teams thrive when they’re treated like living systems. They grow stronger with trust, flexibility, and clear purpose. Managing them means nurturing, not controlling.

Guiding Vision

A clear vision aligns the team even when things change. It’s not a slogan—it’s something everyone believes in. When the vision is shared, teams move with focus and energy.

Simple Rules

Discipline doesn’t require complexity. A few clear, consistent rules help teams self-organize. Less process, more purpose—that’s the magic.

Adaptive Leadership

Leadership isn’t about having all the answers. It’s about creating space for learning and responding as things unfold. Feedback, reflection, and presence are your most powerful tools.

6 Main Lessons from Managing Agile Projects

Lead with Trust

Give people room to grow and make decisions. Focus on support, not supervision. Trust creates real accountability.

Embrace the Mess

Projects rarely go as planned—and that’s okay. Learn to lead through uncertainty without panicking. Good leadership happens in the gray areas.

Start with Purpose

Every project needs a “why” that people care about. Make sure your team sees it, feels it, and works toward it. Clarity beats control.

Keep It Visible

The more open your communication, the better your team will flow. Show work, share decisions, and talk often. Transparency builds momentum.

Adjust as You Go

What works today might not work next month. Stay curious, test changes, and adapt without drama. Agility is a mindset, not a checklist.

Be Present, Not Perfect

You don’t need to lead with all the answers. Show up, listen well, and stay calm when things shift. Your presence matters more than your plan.

My Book Highlights & Quotes

When first placed in the position of leading an agile team nearly five years ago, I had precious little guidance to assist me in my job. This is the book that I wish I had then—I have endeavored to capture my subsequent experience and learning and present them in a form that is accessible to managers new to agile methodologies. Other managers more familiar with the agile landscape should enjoy it as well, albeit with the sense of the familiar. In the agile spirit of continuous learning and experimentation, I have drawn on many diverse disciplines to augment and extend agile methodologies on my projects, including complexity theory, organizational learning, and Lean Thinking

Leadership goes beyond the mundane in daily work life. Agile managers require the leadership skills necessary to connect with the needs and hopes of their team members. Tichy and Devanna identified several characteristics of transformational leaders—people who effect transformational change in organizations: They identify themselves as change agents; they are courageous, believe in people, are value-driven, lifelong learners, and able to deal with complexity, ambiguity, and uncertainty, and they are visionaries. These are elaborated from an APM perspective in the following sidebar

Conclusion

This book isn’t about becoming a perfect agile expert—it’s about becoming a better leader, one who sees projects as more than just deadlines and deliverables.

Managing Agile Projects helps you move from managing work to supporting people, from enforcing process to enabling growth.

And in a world where everything is moving fast and unpredictably, that kind of leadership might just be what we need most.

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:

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:

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: