Book Notes #10: Agile Coaching by Rachel Davies and Liz Sedley

Title: Agile Coaching
Author: Rachel Davies and Liz Sedley
Year: 2009
Pages: 221

Coaching a team sounds easy—until you actually do it. Suddenly, you’re not just helping people follow a process; you’re dealing with personalities, resistance, miscommunication, confusion, and everything in between.

That’s what makes Agile Coaching by Rachel Davies and Liz Sedley such a refreshing read. It’s not a book full of buzzwords or shiny new frameworks—it’s a grounded, human guide to helping Agile teams grow, collaborate, and improve in real life.

If you’ve ever felt unsure how to support a team without taking over or struggled to make Agile feel less mechanical and more meaningful, this book is for you.

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 Agile Coaching

Book Overview

What if coaching a team wasn’t about having all the answers—but about asking the right questions? What if leading change wasn’t about pushing people—but about helping them want the change themselves? Agile Coaching by Rachel Davies and Liz Sedley starts with the assumption that the role of an Agile coach isn’t to enforce a method, but to nurture a mindset. And from the very first chapter, it becomes clear: this book isn’t just a how-to for Agile teams—it’s a deeply human guide to helping people work better together.

The beauty of this book lies in its simplicity. It doesn’t try to impress you with jargon or overwhelm you with models. Instead, it walks you through the day-to-day realities of coaching Agile teams—what it looks like, feels like, and requires of you. It starts with the basics: how to build trust, how to listen, how to facilitate change without making people feel like they’re being dragged along. You quickly realize that being a great coach means paying attention to the little things—how people behave in meetings, what they’re not saying out loud, and what small, meaningful actions can move a team forward.

The authors don’t pretend this is easy. They talk about real resistance, real frustration, and real awkward silences in standups. They tell stories of teams struggling to define what “done” means, of developers who avoid writing tests, of retrospectives that fall flat. But instead of offering quick fixes, they give you tools to help the team figure it out themselves—like the PrOpER cycle for working through problems, the use of team boards to keep work visible, or even how to ask better questions that lead to better decisions.

What’s striking is how much of the advice in this book is about people, not processes. Yes, it covers the Agile basics—daily standups, planning sessions, demos, retrospectives—but always through the lens of human interaction. A standup isn’t just a meeting; it’s a chance for the team to sync and support each other. A retrospective isn’t a routine; it’s a moment of collective reflection. The process matters, but only if it serves the people doing the work.

As the book moves forward, the scope expands. It’s not just about guiding others—it’s about growing yourself. The final chapter is an unexpected gift: a personal call to action for the coach. It reminds you that coaching is demanding, and if you don’t invest in your own learning, reflection, and well-being, you’ll burn out or become stagnant. Whether it’s joining a local meetup, writing a journal, or simply going for a walk to process a rough day, the authors gently push you to take your own growth just as seriously as your team’s.

Reading Agile Coaching feels like having a conversation with two experienced mentors—people who’ve been in the trenches, made mistakes, and figured out what works through patient observation and honest reflection. It’s not about being perfect. It’s about being present, being thoughtful, and being willing to grow alongside the teams you support.

In the end, this book leaves you with a quiet confidence. You don’t need to be a guru to be a good coach. You just need to care, stay curious, keep listening, and keep learning. Agile, after all, is about continuous improvement—and that includes you.

Chapter by Chapter

Chapter 1 – Starting the Journey

This opening chapter sets the tone for what it means to be an Agile coach. The authors start by explaining that coaching is not just about teaching Agile practices—it’s about helping teams change the way they think and work. A coach’s goal isn’t to impose rules but to grow a team that’s capable of thinking for itself. The role shifts depending on the team’s maturity: for newcomers, you may need to be more hands-on, like a sports coach; with experienced teams, it’s more about listening, asking the right questions, and encouraging reflection, much like a life coach.

The chapter introduces the core coaching activities through a mindmap: noticing team behavior, giving feedback, facilitating discussions, educating through storytelling or training, and offering emotional support. But these are not things you throw at the team all at once. The real secret, the authors argue, is attitude—believing that change is possible and leading by example. That means living Agile values yourself, staying balanced during tough times, being patient, watching your language to stay inclusive, and constantly learning along the way.

One of the most useful tools introduced here is the PrOpER coaching cycle: Problem, Options, Experiment, Review. It’s a simple but powerful method to approach team issues thoughtfully, starting small and iterating. The chapter wraps with practical tips for getting started: preparing yourself with Agile experience, getting formally introduced to the team (to avoid awkward misunderstandings), and staying energized through small wins and support networks. It also reminds us that coaching isn’t forever—when the team can stand on its own, your job is done. That’s when you know it’s time to step back or move on.

Chapter 2 – Working with People

Helping a team become more Agile isn’t just about introducing tools or running ceremonies—it’s about people. This chapter explores the human side of coaching. It reminds us that every team is a collection of individuals with unique perspectives, emotions, and communication styles. As an Agile coach, your job is to connect with those individuals, build trust, and help the team grow by fostering better interactions. That means mastering key interpersonal skills like listening, giving feedback, resolving conflict, and building alignment.

Listening with Presence and Purpose
The authors begin with the foundation: deep, respectful listening. Listening isn’t just about being quiet while someone speaks—it’s about being fully present. Coaches are encouraged to give their full attention, avoid interrupting, and hold back from jumping in with advice or similar stories. This builds trust and helps the speaker open up. Techniques like eye contact, open body language, and gentle affirmations (like nodding or “mm-hmm”) show you’re engaged.

One of the most powerful parts of this section is about “reading between the lines”—watching for nonverbal cues, tone, and energy. The coach is invited to put themselves in the speaker’s shoes, paraphrasing what they hear to show empathy and confirm understanding. Even simple phrases like, “It sounds like you’re feeling frustrated…” can help someone feel heard. And listening doesn’t stop in one-on-ones. Coaches are also told to observe group dynamics, hallway conversations, and team energy. A buzzing, collaborative team sounds very different from a disengaged one.

Giving Feedback That Lands Well
Feedback is where things get tricky. It’s easy to criticize or offer praise too vaguely, but the book pushes for a more thoughtful approach. Coaches are taught to separate what they observe from how they feel about it. For example, instead of saying, “You were disruptive in the meeting,” a coach might say, “I noticed you stepped out several times to take calls. I was concerned because you missed Chris’s walkthrough.”

The goal is to invite reflection, not provoke defensiveness. Once you share your observation, give space for the other person’s perspective. Maybe there’s more to the story. Then, together, you can explore ways to improve things moving forward. Positive feedback is also encouraged, but again, not with over-the-top praise. Just pointing out something concrete—like a faster build or a helpful suggestion—shows appreciation and encourages the behavior without putting anyone on a pedestal.

Navigating Conflict with Care
Conflict is inevitable, especially in tight-knit Agile teams. Sometimes it’s out in the open, and sometimes it simmers under the surface. Coaches are advised to first observe and understand, rather than rush in to fix things. Listening to all sides separately can uncover root causes and emotional undercurrents. When needed, the coach can facilitate resolution using techniques like Nonviolent Communication, which involves gently exploring what someone observed, how they felt, what they needed, and what they might request.

Importantly, the coach isn’t there to take sides or act like a referee. Instead, they frame the conflict in terms of team goals and shared context, helping members move past personal differences. And there’s a subtle reminder here: not all conflict is bad. A team that always agrees may actually be suppressing ideas. It’s healthy to debate when the goal is better outcomes.

Building Agreement Without Forcing It
When introducing change, it’s tempting to look for quick consensus. But the authors introduce a more nuanced tool: gradients of agreement. Rather than yes/no decisions, the team marks their level of support on a scale—from full endorsement to outright blocking. This surfaces hidden concerns, helps avoid forced decisions, and invites discussion about what’s actually holding people back.

Rachel shares a story about a team hesitant to use continuous integration. By using the gradient tool, they discovered there was agreement on running daily automated tests but hesitation around full automation. This helped the team focus on a realistic first step rather than pushing for something they weren’t ready for.

The chapter closes by acknowledging that things don’t always go smoothly. Emotional outbursts, lack of people skills, and cultural misunderstandings are all part of the reality. Coaches are encouraged to respond with empathy and reflection. Sometimes that means pausing a meeting, having a one-on-one chat, or simply giving someone space.

There’s also a reminder not to reduce people to models or labels. Tools like Myers-Briggs or the Dreyfus model can help you understand communication styles, but every person is more than a category. Respecting that individuality is part of what makes a great coach.

In the end, this chapter is a powerful reminder that Agile is built on human connection. And coaching is about being present, respectful, and supportive—one conversation at a time.

Chapter 3 – Leading Change

In this chapter, the authors explore the crucial role of leading change when adopting Agile practices. Introducing change isn’t as simple as telling a team what they need to do—it’s about creating a shared understanding of why change is necessary and how it benefits everyone. The key here is gradual engagement. Coaches should give the team time to reflect on the changes, letting them process and discuss before diving into action. This helps them understand the “why” behind the change, making them more likely to embrace it.

Introducing Change
When introducing Agile practices, resistance is inevitable. Even when the change seems necessary, people often have concerns about the risks involved. The authors stress the importance of not pushing too quickly and instead using stories from other teams or examples to paint a picture of what’s possible. Coaches should present Agile as a tool to help, not a strict mandate, and use positive language like “When we…” rather than “If we…”, to build confidence. The book also warns against becoming an “Agile zealot,” as pushing too hard or criticizing others can backfire, making them less likely to listen.

Show Them How
It’s not enough to tell the team about a new Agile technique like unit testing; you must actively show them how it’s done. Coaches should lead by example—demonstrating practices and providing support to help the team implement these changes. They can even use the PrOpER cycle to work through challenges with the team. For example, instead of just suggesting unit tests, coaches can pair with developers to write tests together and make the process visible, so everyone feels supported and confident in the change.

Leveraging Resistance
Resistance isn’t just something to overcome—it’s something to use as a resource. The authors suggest listening carefully to objections, viewing them as valuable feedback that can guide the coach to tweak their approach. Instead of pushing for change right away, coaches can focus on explaining the benefits in more detail, using real-world examples to make the change more relatable. By presenting objections as opportunities to address valid concerns, coaches can shift the perspective from resistance to collaboration.

Building Ownership for Change
For any change to stick, the team must feel ownership over it. The authors suggest that coaches involve the team in designing solutions, discussing the pros and cons of different approaches, and making sure the team sees how the change will benefit them individually and collectively. Retrospectives are an excellent starting point for this, as they give the team a chance to regularly review and iterate on their processes. The key is to avoid overwhelming them with too many changes at once—focus on one small change and let the team build momentum from there.

Asking Questions
Rather than always telling the team what to do, coaches can engage them by asking questions that prompt reflection. Thought-provoking questions can help uncover assumptions and guide the team to find solutions themselves. The book suggests using open-ended questions like “What could we do to prevent this bug from happening again?” to encourage critical thinking and collaboration. The Five Whys technique, which digs deeper into the root cause of a problem, is also highlighted as a powerful tool for revealing underlying issues that might otherwise go unnoticed.

Encouraging Learning
Change doesn’t happen overnight, and the team needs time to learn and adapt. Coaches should create an environment that supports continuous learning. Whether it’s setting up study groups, organizing tech talks, or encouraging team members to attend conferences, the goal is to keep the learning process dynamic and accessible. It’s also important for the coach to model the behavior they want to see—making time for personal learning and sharing new insights with the team.

Facilitating Meetings
Introducing new Agile practices often involves new types of meetings, such as retrospectives or planning sessions. Coaches should not only facilitate these meetings but also teach the team how to run them themselves. By offering guidance on meeting structure and facilitating the first few sessions, coaches can help the team become more comfortable with the new practices. The chapter offers practical tips on making meetings effective, including focusing the discussion, encouraging everyone’s participation, and summarizing key points to ensure understanding.

The chapter wraps up by discussing common hurdles like resistance to change, office politics, and conflicting agendas. Coaches are reminded that some people will naturally be more resistant to change, while others may see it as a threat to their authority. The best approach is to be patient and neutral, especially when dealing with team members who may feel that their position is being undermined. Ultimately, successful change depends on building trust and offering support, rather than pushing too hard or engaging in power struggles.

In summary, this chapter emphasizes that leading change is about more than just implementing Agile techniques. It’s about understanding the team’s concerns, engaging them in the process, and building trust. The key to success lies in thoughtful communication, gradual implementation, and giving the team ownership of their own transformation.

Chapter 4 – Building an Agile Team

In this chapter, the authors discuss how to build a high-performing Agile team. The key idea is that cohesive teams don’t form overnight; they require time and intentional effort. The success of an Agile team depends not just on the processes and practices but on how well the individuals work together. Creating a culture of trust and openness is crucial to helping the team gel and operate smoothly. Coaches are encouraged to facilitate team bonding, provide opportunities for people to get to know each other, and help the team create a shared sense of purpose.

Helping a Team Jell
Effective teams don’t just follow routines—they adapt, collaborate, and respond to challenges by stepping in to support each other. The authors emphasize the importance of building social connections among team members. For instance, having casual meals together, like lunch or bowling, can be a simple but powerful way to strengthen team bonds. These informal settings allow team members to discuss issues openly, share ideas, and build rapport that translates into better collaboration during work hours. Trust is the foundation for a successful team, and it can be built by leading with transparency, admitting mistakes, and showing vulnerability.

Creating a Team Space
The physical and virtual environment in which the team works is another critical factor in fostering collaboration. Ideally, an Agile team should be co-located, with everyone sitting in the same room. This setup encourages continuous communication and helps the team stay focused. The chapter suggests creating a comfortable, personalized workspace that reflects the team’s identity—this can make the environment feel safer and more conducive to collaboration. On the virtual side, the team should set up shared repositories and communication tools that support easy access to information.

Balancing Roles
In an Agile team, everyone needs to understand their role and the roles of others. The authors stress the importance of defining clear responsibilities, especially between the customer and the development team. The customer sets the priorities, but the development team decides how to deliver the product. Confusion about roles can lead to inefficiencies and frustrations, so it’s important to clarify who is responsible for what. One practical approach is using “near-customer” and “far-customer” roles to balance the workload and ensure effective communication.

Energizing the Team
Maintaining team motivation is a constant challenge, especially during tough or long projects. The chapter highlights the importance of setting reachable but challenging goals that keep the team engaged. If work is too easy, the team gets bored; if it’s too hard, they may feel overwhelmed. A coach can help by breaking down large tasks into smaller, manageable ones or by encouraging experimentation to solve complex problems. The chapter also introduces the concept of “Gold Cards,” where team members are given time to explore new ideas, learn new technologies, or improve processes. This time for innovation can greatly boost morale and creativity.

The chapter concludes with a look at some common obstacles Agile teams face. One major issue is the lack of cross-functionality within teams, where roles like testers, analysts, and developers are segregated, making collaboration difficult. The authors recommend pushing for a cross-functional team setup to avoid handoffs and delays. Another challenge is working with remote customers or distributed teams, which can lead to communication barriers. To address this, the authors suggest using webcams and encouraging regular face-to-face meetings to build stronger relationships and improve collaboration.

In summary, this chapter offers practical strategies for building a cohesive, high-performing Agile team. It emphasizes trust, communication, clear roles, and motivation as the core elements for success. The chapter reminds coaches that team building is an ongoing process, and it requires intentional actions like facilitating informal bonding activities, designing an effective workspace, and encouraging experimentation.

Chapter 5 – Daily Standup

In this chapter, the authors focus on the daily standup meeting, an essential component of Agile teams. While it may seem simple—just three questions to answer daily—there’s more to it than meets the eye. The daily standup serves as a tool for team synchronization, allowing everyone to quickly share what they’ve accomplished, what they plan to do next, and if anything is blocking their progress. However, the real challenge for a coach is to ensure the meeting isn’t just a formality but a powerful tool for self-organization and collaboration.

Standing Up
The authors emphasize that standing during the daily standup isn’t just a quirky Agile tradition—it has a practical purpose. Standing encourages brevity and focus. Although initially, team members might feel awkward, especially in traditional environments, it’s important to highlight how it helps keep the meeting short and purposeful. The chapter suggests running the meeting in the team’s workspace so they can stay close to their team board, making it easier to discuss and update tasks. If this setup isn’t possible, they recommend using a portable board, so the team can bring their work with them to the meeting.

For the Team, by the Team
The daily standup is primarily for the team, not for managers or stakeholders. The team must take ownership of the meeting, ensuring it serves as a time to coordinate work, not to report to others. As a coach, your role is to help facilitate the flow without dominating the meeting. The focus should always be on the tasks at hand, and the meeting should avoid getting sidetracked by unrelated topics. When team members become comfortable with the format, they’ll naturally evolve the standup to better suit their needs, and the coach’s role will gradually diminish. The team may even move beyond the three-question format, adding their own reminders or questions to enhance the discussion.

Handling Issues
When someone mentions an issue in the standup, it’s essential to prevent the meeting from turning into a problem-solving session. Instead, issues should be noted and dealt with after the standup. To help manage this, the authors suggest using a “parking lot” for issues—keeping a visible list of problems that need attention but ensuring the meeting doesn’t get bogged down by them. Once the standup concludes, the team can prioritize these issues and determine the best course of action. This keeps the standup focused and time-efficient while ensuring that problems are addressed.

Team Ownership and Flow
A critical point in this chapter is about giving the team ownership of the daily standup. The team should control the flow of the meeting, not the coach or a manager. One technique the authors suggest is using a “speaking token” to keep the conversation moving and ensure everyone has a chance to speak. The token is passed around as each person updates the team, ensuring that the flow is equitable and that no one dominates the conversation. This also encourages people to be mindful of their time, as they have to pass the token to the next person.

Setting the Time
While the timing of the daily standup may seem trivial, it can significantly affect the team’s engagement and efficiency. The authors recommend that the team decide when the standup should take place, based on everyone’s availability. This fosters commitment to the meeting time and reinforces the idea that the team is responsible for managing their own process. For teams that are distributed or work in different time zones, flexibility is key. Teleconferencing or alternating meeting times may be necessary to ensure all team members are included.

The chapter concludes by addressing some common challenges that can arise during the daily standup. One common issue is lateness. If people regularly show up late, it disrupts the flow and undermines the effectiveness of the meeting. The authors suggest tracking tardiness on a visible chart, which can help raise awareness and encourage accountability. Other challenges include large teams, which can make the standup feel disjointed, or when the meeting is hijacked by non-team members looking to use the time for unrelated discussions. The key here is to maintain focus on the team’s needs and prevent the standup from becoming a catch-all for other activities.

In summary, this chapter provides practical insights into running effective daily standups. The focus is on creating a meeting that is fast, focused, and owned by the team. With the right balance of structure and flexibility, the daily standup becomes a valuable tool for fostering collaboration, accountability, and communication within the team.

Chapter 6 – Understanding What to Build

This chapter focuses on the essential concept of user stories in Agile, which serve as the foundation for all work within an Agile team. The authors argue that user stories are more than just requirements— they are about facilitating conversations that help the team understand the needs of the users and the business. These conversations are vital for uncovering details, clarifying questions, and refining the work to ensure the team is building the right solution. However, many teams fall into the trap of treating user stories like rigid requirements documents, rather than using them as a dynamic tool for engagement and refinement.

The Life Cycle of a User Story
The life cycle of a user story is compared to that of a butterfly, with each phase representing an evolution of understanding. It begins as an idea (like an egg), then grows through discussion (like a caterpillar), refining into specific test cases (a chrysalis), and finally emerging as working software (a butterfly). This process highlights that user stories should evolve through conversations and continuous refinement rather than being frozen into a final form too soon. The mantra “Card, Conversation, Confirmation” is introduced to emphasize the three critical components of user stories: writing them down (card), having discussions to clarify and break them down (conversation), and confirming the acceptance criteria (confirmation).

Encouraging Conversations
The chapter stresses that conversations are the heart of user stories. These conversations, primarily between developers, testers, and the customer, ensure that the team is building the right product. The authors suggest that when a team struggles with understanding a user story, it’s crucial to ask the customer for clarification rather than guessing. Coaches can play a vital role by initiating these conversations, facilitating communication, and stepping back once the team becomes accustomed to self-managing these discussions. Early conversations about user stories should not wait until planning meetings. Instead, smaller groups should work together with the customer to refine the stories before sharing them with the larger team.

Working with Cards
The authors introduce the use of index cards or sticky notes as a way to facilitate discussion and organization around user stories. This method encourages active participation, as anyone in the conversation can write down a new story or modify an existing one. The chapter advocates for a physical, tangible approach to managing user stories, as it makes it easier to visualize and rearrange them in real-time. This method contrasts with the digital approach, which often leads to passive observation rather than active engagement. Additionally, using cards allows for flexibility—stories can be easily modified, discarded, or rewritten as the understanding of the requirements evolves.

Confirming the Details
Once the team has a basic understanding of the story, they need to confirm the details, particularly the acceptance criteria or story tests that define when the story is complete. The chapter outlines a simple way to write these tests using the “Given-When-Then” format, which provides clarity around expected user actions and outcomes. This step ensures that the team and the customer are aligned on what the software should do and how it should behave. The authors encourage collaborative creation of story tests, involving both the customer and the technical team to address different scenarios and edge cases. The goal is not to have a complete set of tests at the beginning, but to capture enough information to start development and refine the details as the story progresses.

The chapter concludes by addressing common hurdles teams face when using user stories. One challenge is dealing with non-user-facing functionality, such as infrastructure work, which doesn’t fit neatly into the “As a user, I want…” template. The authors suggest adapting the user story format to reflect the purpose of the work and its benefit to the customer, even if the functionality is technical. Another obstacle is the need for formal documentation in regulated industries. While user stories are inherently informal, the authors recommend ways to document them quickly and effectively, such as taking photos of story cards or writing executable requirements.

In summary, this chapter emphasizes that user stories are a tool for engaging with the customer and refining the team’s understanding of the work. They should evolve through ongoing conversations, be actively managed with simple tools like cards, and be confirmed with clear acceptance criteria. By using user stories effectively, teams can better align with user needs, improve their understanding of the work, and ensure they are delivering value.

Chapter 7 – Planning Ahead

In this chapter, the authors discuss how Agile teams can plan effectively without getting bogged down in long, inefficient meetings. The key message is that good planning involves striking a balance between long-term goals and the details of the next iteration. Rather than relying on rigid, overwhelming plans, teams should create flexible, realistic plans that they can adjust as needed. The planning process is compared to cooking a stir-fry: preparation is essential, but the meeting itself should flow smoothly, with each part of the process happening in the right order and at the right time.

Preparing for Planning
The chapter encourages teams to prepare ahead of time by working with the customer to clarify user stories before the planning meeting. This helps set the stage for a focused conversation. The authors stress that planning meetings should have a clear agenda, so the team knows what to expect. Breaking down the planning into smaller steps—understanding priorities, sizing the work, and agreeing on what can realistically be delivered—keeps the meeting productive. For teams that are newer or dealing with complex projects, the authors recommend breaking the planning into separate meetings to prevent overwhelming the group.

Understanding Priorities
The customer should begin the meeting by explaining the goal for the iteration or release and prioritizing the user stories. This helps set expectations and focuses the team on what is most important. The team is encouraged to ask questions, challenge assumptions, and look for opportunities to break user stories down into smaller, more manageable pieces. The authors advise that stories should be as small as possible but still meaningful in terms of business value. Ensuring that everyone understands the acceptance criteria for each story is essential for making accurate estimates.

Sizing the Work
Once the team has a clear understanding of the stories, they need to estimate the work involved. The chapter highlights the importance of discussing the technical details of each story before estimating, as this helps ensure the estimates are grounded in reality. The customer is often encouraged to leave the room during these discussions, as their presence can sometimes put pressure on the team to rush their estimates. The team should focus on understanding what needs to be done, with the customer rejoining the meeting later to finalize the estimates and priorities.

Decomposing into Tasks
For larger stories, the authors recommend breaking them down into smaller tasks. This makes it easier to share the workload among the team and ensures that the work is clearly defined. Tasks should be small enough to complete in a day or less, and they should help the team stay organized and track progress throughout the iteration. However, if the team already has a good understanding of the work, breaking down stories into tasks might be unnecessary.

Estimating, Not Guessing
Estimating the work is an essential part of planning, but it’s important to approach it realistically. The team is encouraged to avoid padding their estimates to account for unforeseen problems, as this can lead to unrealistic expectations. If the team is unsure about a particular story, they can conduct a “spike,” which is a time-boxed investigation aimed at gaining more clarity on the story before estimating it. Once the team has a better understanding, they can return to the story and make a more accurate estimate.

Review and Commit
The final step of planning involves grouping the user stories into an iteration schedule that the team can realistically complete. The team needs to assess their capacity based on their past velocity, ensuring they don’t overcommit. The authors emphasize the importance of setting realistic expectations, especially when there is pressure from the customer to deliver more work than the team can handle. Teams should always strive for a sustainable pace, planning for the same amount of work as they delivered in previous iterations unless there are clear reasons to adjust.

Several common obstacles in planning are addressed, such as customers not being prepared, teams being asked to overcommit, or planning meetings dragging on too long. The authors offer practical solutions, such as holding preplanning sessions to help the customer prepare or using tools like “Planning Poker” to involve everyone in the estimation process. The chapter also notes that sometimes planning doesn’t make sense, particularly when the team is dealing with issues like bugs or team members being unavailable. In such cases, using a Kanban approach or adjusting the planning process can help keep the team focused.

In conclusion, this chapter provides a comprehensive guide to effective planning in Agile. By breaking down planning into manageable steps, engaging the team in discussions, and focusing on realistic estimates, teams can create achievable plans that support successful iterations. The key is to avoid overloading the team and to ensure that planning is both flexible and aligned with the team’s capacity.

Chapter 8 – Keeping It Visible

This chapter emphasizes the importance of visibility in Agile practices. The authors stress that just like how people use visible reminders in their everyday lives (like sticky notes or fridge magnets), teams need to make their work, progress, and challenges visible to encourage responsibility and improve collaboration. A key concept introduced is the team board, which serves as a powerful tool to track the status of stories, tasks, and progress throughout the iteration. The idea is to create an environment where everything the team needs to pay attention to is openly visible—nothing hidden away in digital files or forgotten in meetings.

The Team Board
The team board is central to this chapter. It’s more than just a way to track work; it’s a reflection of the team’s priorities and culture. The board typically divides work into columns—such as “Stories,” “In Progress,” “Awaiting QA,” and “Done”—to show the flow of tasks throughout the iteration. Each story is listed in priority order, and as tasks are completed, they move across the board. This not only helps the team visualize progress but also keeps everyone aligned on what’s being worked on and what’s left to do. A well-maintained team board helps the team avoid spreading their efforts too thin across too many stories at once. The goal is to get a few stories all the way across the board before starting new ones.

Making It Easy to Read
The authors advise that the team board be easy to read and engaging. The key here is legibility and simplicity. Cards should be written clearly so everyone can understand them at a glance, especially during the daily standup. Color-coding or stickers are introduced as a way to track progress visually. For example, red stickers indicate “Not Started,” yellow for “In Progress,” blue for “Under Review,” and green for “Done.” This visual system allows anyone to see at a glance where the team stands and whether any issues need immediate attention.

Who’s Working on What?
A unique aspect of the team board is the ability to see who is working on each task. By tagging tasks with team members’ names or even avatars, everyone can quickly see who is responsible for what. This visibility also helps identify if someone is overloaded or stuck. If a team member has their name on multiple tasks, it could signal that they need support or that there’s a bottleneck. In these cases, the team can discuss the issue and help redistribute the work to maintain a steady flow.

Choosing Materials
The chapter also touches on the materials needed to create the board. While it might seem obvious, the authors stress the importance of using good-quality materials—whether it’s sticky notes, magnets, or a whiteboard. The board should be easy to interact with and portable enough to bring into meetings or to different areas of the office. This flexibility ensures that the team can keep the board updated wherever they are, helping maintain constant visibility.

Big Visible Charts
In addition to the team board, the authors recommend using “big visible charts” to track team performance or specific goals. For example, a pairing ladder to encourage team members to pair program with different colleagues can be a great tool. Other charts like burndown or burnup charts can help track progress during the iteration, providing real-time data on whether the team is on track to meet their goals. The chapter also suggests that teams periodically assess whether the chart is still helpful. If a problem is solved, it’s time to retire the chart.

Maintaining the Team Board
A team board is only useful if the information on it is up to date. Therefore, the authors recommend that the team takes time each day to update the board, ideally during the daily standup. If necessary, the team can assign a “tracker” role, so that the board is maintained without one person doing all the work. Regular updates help the team stay on top of their progress and adjust quickly when problems arise.

Despite its effectiveness, creating and maintaining a team board comes with its challenges. Teams may struggle to find space for a physical board, or they may face resistance to updating it regularly. The authors suggest solutions such as using windows or cupboard doors as makeshift boards, and making the board fun and interactive to encourage team members to use it. If the team isn’t updating the board, it’s important to discuss why and work together to find solutions.

In summary, this chapter stresses that visibility is key in Agile teams. By using a team board and other visual tools, teams can stay aligned, track progress, and encourage ownership of the work. The chapter emphasizes that the board should not only be a tool for project tracking but also a reflection of the team’s culture and priorities.

Chapter 9 – Getting to “Done”

This chapter focuses on the concept of “Done” in Agile, a critical point that often trips up teams. The authors explain that, just like kids in a soccer game who chase the ball without understanding the broader strategy, Agile teams sometimes focus on individual tasks without fully understanding what it means to complete a story. To succeed, the team must work together, not only building functionality but also testing it and ensuring it works in every way. The challenge often arises in underestimating the time and effort required for testing and debugging. The chapter highlights that getting to “done” means more than just writing code—it’s about completing all necessary steps, including testing and collaboration.

Who Does the Testing?
Testing in Agile is a team responsibility, not just a task for testers. Developers must ensure that their code passes the story tests before it is handed off to testers. This avoids wasting testers’ time on incomplete code. The authors recommend that developers automate as much testing as possible but note that they may miss issues with the code they just wrote. Testers, on the other hand, focus on destructive testing and edge cases, areas where the system may be vulnerable. They should work closely with developers to automate tests and verify that the story tests pass. External teams may also conduct specialized testing, such as security or usability testing, which should be considered during release planning.

Defining What “Done” Means
The chapter emphasizes that the entire team must agree on what “done” means. It starts with a basic definition: the customer is satisfied, and all story tests pass. From there, the team should collaborate to build a more detailed checklist, which might include code reviews, unit tests, automated tests, exploratory testing by the team, updated documentation, and performance testing. Once everyone is on the same page, the checklist should be visible to the team at all times, ideally on a whiteboard or team board. This helps everyone stay aligned and accountable. Over time, the definition of “done” can evolve, especially in retrospectives, as the team learns from past iterations.

Planning in Testing
To avoid leaving all testing until the last minute, the chapter encourages the team to talk about testing during iteration planning. Testing tasks should be broken down into specific actions like writing automated tests, preparing test data, and setting up test environments. Testers should be actively involved in the planning sessions, and their concerns should be addressed. The authors stress the importance of integrating testers into the team’s day-to-day work, especially because they are often outnumbered by developers and may feel sidelined. Pairing developers with testers can help improve collaboration and ensure that testing is done throughout the iteration.

Managing Bugs
Managing bugs effectively is critical for completing stories. The chapter advises that when a bug is found, it should be flagged on the team board for visibility. If the bug is not critical to the user story, it can be deferred to a future iteration. However, if fixing it prevents an imminent release, it must be addressed immediately. The chapter also introduces the concept of treating bugs like new stories, adding them to the backlog if they can’t be fixed in the current iteration. This prevents a “hidden backlog” from accumulating, which can lead to confusion and inefficiency. It’s also suggested that rather than using a separate bug tracker, the team should use their existing board to track bugs and prioritize them with the rest of the user stories.

Getting Feedback Early
The authors stress the importance of early feedback to avoid surprises later in the iteration. Developers often delay seeking feedback because they fear criticism or worry it will slow them down. However, getting feedback on small slices of functionality earlier ensures that the team stays on track and avoids the bottleneck of untested, incomplete work. The chapter encourages developers to share their work with customers or testers as soon as they have a piece ready, rather than waiting until the entire user story is “complete.”

Recovering from Not Getting Done
Despite best efforts, sometimes the team won’t finish all the stories by the end of the iteration. The chapter advises that this should be treated as a serious issue and discussed openly in the demo or retrospective. The team should reflect on why they couldn’t get everything done and what they can do to prevent this in the future. The authors also recommend adjusting the team’s velocity to account for the incomplete work, helping them set more realistic goals in the next iteration. The key is to maintain a balance between optimism and realism in planning.

Finally, the chapter outlines several hurdles that may arise, such as team members having a rigid view of their roles (e.g., “testing is for testers”). Coaches should encourage everyone to take responsibility for the entire process, from coding to testing. Additionally, remote testers or teams may create delays, and it’s essential to plan for how to manage that communication and ensure that feedback is received in a timely manner. The chapter also addresses the issue of organizations mandating the use of bug trackers, recommending that teams focus on visible boards to prevent the creation of a hidden backlog of unresolved issues.

In summary, this chapter provides essential guidance on defining what “done” means for the team, ensuring collaboration across roles, and handling bugs and testing throughout the iteration. By focusing on clear communication, early feedback, and realistic planning, teams can improve their ability to complete work successfully and deliver quality software.

Chapter 10 – Driving Development with Tests

This chapter explores the challenges and benefits of adopting Test-Driven Development (TDD) in Agile teams. The authors highlight the common issue of teams claiming to be Agile yet still relying on manual testing. TDD allows developers to create automated tests before writing the code, ensuring a strong foundation and reducing the back-and-forth between developers and testers. This process not only improves code quality but also boosts efficiency by catching issues early, which would otherwise take hours or days to identify during manual testing.

Introducing Test-Driven Development (TDD)
The chapter stresses that transitioning to TDD is a gradual process, especially when moving from a traditional development approach. Rather than forcing a quick switch, the authors suggest introducing TDD in small, manageable steps. For teams with existing code, wrapping tests around legacy systems can be particularly challenging. It’s important to start with small tasks, writing a few automated tests per day, and gradually build up skills and infrastructure. The authors emphasize that TDD encourages developers to think about the code from an external perspective (the user interface) first, leading to better design decisions.

Challenges in Implementing TDD
One key story in the chapter illustrates the difficulties of introducing TDD too quickly. A team was eager to adopt TDD but faced technical and human obstacles. Some developers had difficulty with basic principles of object-oriented programming, while others used different IDEs and struggled with the integration of third-party libraries. The takeaway here is that technical barriers aren’t the only challenge—team alignment and commitment are equally important. The team needs a clear, shared understanding of the benefits of TDD and how it can help solve specific problems, like reducing the burden on testers.

Getting Team Buy-In
To effectively implement TDD, the team must agree to commit to writing and running automated tests. The authors recommend using the PrOpER cycle (Problem, Options, Experiment, Review) to address blockers and engage the team in finding solutions. They suggest getting the team together to build consensus on a test strategy and agree on how tests will be organized and run. This collaborative approach helps build ownership and a deeper understanding of why TDD is worth the effort.

Coding Dojos for Skill Building
The authors recommend using coding dojos as a way to improve test-writing skills. In a coding dojo, developers work on a pre-prepared programming challenge, rotating every few minutes to keep the session interactive. This allows the team to practice test-driven coding in a supportive, collaborative environment while developing their design and coding skills.

Continuous Integration (CI)
TDD is closely linked to Continuous Integration (CI), where code changes are frequently integrated into the main codebase. The authors describe CI as an attitude rather than a set of tools, with the key idea being that the team commits to checking in code frequently and ensuring that all tests pass. The chapter explains how synchronous CI—where developers check in code and immediately run the build to see if tests pass—helps foster accountability and teamwork. Over time, the team can shift to an asynchronous CI process with automated tools. But the emphasis is on building a culture where developers take responsibility for fixing broken builds quickly.

Sustaining TDD
Once TDD and CI are established, maintaining them requires vigilance. The chapter warns about slow-running tests, which can hinder the team’s ability to integrate code and catch errors early. It encourages teams to improve the speed of their test suites by focusing on tests that cover the most critical paths. The authors also stress the importance of keeping test coverage visible and regularly reviewing the test strategy to ensure the team continues improving its testing practices.

The chapter also addresses various hurdles teams may face, such as resistance to writing tests first or using continuous integration tools. It highlights the importance of keeping tests fast and making sure all team members can run the entire suite of tests. If there are no testing tools available for the team’s programming language, the authors suggest the possibility of developing a simple custom framework to get started.

In conclusion, this chapter emphasizes that introducing TDD and CI isn’t just about implementing new practices; it’s about creating a shared mindset in the team. By addressing both technical challenges and team dynamics, the authors guide the team through the shift to a more efficient, reliable development process that can reduce bugs and improve collaboration.

Chapter 11 – Clean Code

This chapter focuses on the importance of maintaining clean code within an Agile team. Just as a tidy home is easier to live in, clean code is easier to maintain, understand, and improve. The authors stress that clean code should be an ongoing effort, integrated into the daily work of the development team. The chapter provides various techniques for keeping code neat, including incremental design, collective code ownership, and pair programming. It also highlights how coaches can guide the team through challenges in maintaining clean code and avoiding technical debt.

Incremental Design
The chapter introduces incremental design as a fundamental practice for ensuring code remains clean over time. Rather than trying to design the entire system upfront, the team should focus on improving the design with every user story. Incremental design ensures that developers regularly refine the system’s design as they write tests and code, making it easier to adapt to changes without overcomplicating things. The key challenge is finding the right balance between spending time on design and focusing on code implementation. Developers are encouraged to avoid analysis paralysis and embrace design decisions that can be refined and adjusted later as the project progresses.

Refactoring
Refactoring, or improving the code’s design without changing its behavior, is an essential part of maintaining clean code. The chapter discusses how refactoring should be done in small, manageable steps to prevent overwhelming the team. Frequent, incremental refactoring allows the team to improve code without risking major disruptions. The authors also emphasize the importance of writing clear, understandable code, which can be easily shared among team members and maintained over time.

Collective Code Ownership
The authors introduce collective code ownership as a practice where any developer can work on any piece of code. This approach reduces bottlenecks caused by developers specializing in specific parts of the codebase. For collective code ownership to work, the team must collaborate closely and adhere to a consistent coding style. This includes establishing coding guidelines that the team agrees upon to ensure consistency and readability. When team members follow a shared coding style, they can contribute to different parts of the codebase without wasting time reformatting or adjusting to different styles.

Pair Programming
Pair programming, where two developers work together on the same task, is another method for maintaining clean code. The chapter describes how pair programming enhances collaboration, knowledge sharing, and the quality of the code. It encourages developers to take turns between the driver (the one typing) and the navigator (the one reviewing the code). Pair programming helps prevent errors, improves code readability, and ensures that all team members are familiar with every part of the code. The authors also highlight the concept of ping-pong programming, where pairs swap roles frequently, enhancing engagement and learning.

Several challenges are addressed, such as resistance to pair programming or a developer not following the team’s coding practices. The authors recommend using the PrOpER cycle to guide discussions around disagreements and encourage team collaboration. Additionally, they suggest fostering a sense of pride in clean code and giving developers the permission to care about the quality of their work. Finally, they warn against the broken windows theory, where small signs of neglect can lead to bigger issues, and encourage teams to fix problems early rather than letting them accumulate.

In conclusion, this chapter emphasizes the importance of continuous effort in maintaining clean code. By integrating practices like incremental design, refactoring, collective code ownership, and pair programming, teams can ensure their code remains manageable, high-quality, and adaptable to change.

Chapter 12 – Demonstrating Results

This chapter highlights the importance of the iteration demo as a way to showcase the team’s work and demonstrate progress to stakeholders. Despite its value, many Agile teams treat the demo as an optional activity, often dismissing it for reasons such as not having anything to show, already releasing the product live, or having the customer directly involved in the iteration. However, the chapter argues that skipping the demo undermines its role in building trust and accountability between the team and the business. A well-run demo helps the team feel motivated and accountable, reinforcing the importance of demonstrating tangible results.

Preparing for the Demo
Preparation is key to running a successful demo. The chapter recommends that the team plan ahead during iteration planning by ensuring at least one or two stories can be demonstrated. It stresses the importance of clear communication about who will attend the demo and invites the customer to decide which stakeholders should be present. This ensures that relevant parties, including sales, marketing, and technical teams, are involved. The team should also decide on the order of the stories to be presented, who will present each story, and rehearse the demo beforehand to ensure smooth execution.

Technical Setup
To avoid technical issues during the demo, the chapter encourages teams to test all required equipment, such as projectors, conference phones, and network connections, before the demo starts. It also suggests preparing a checklist of key resources and links to streamline the process. Teams should ensure that the demo runs from a clean integration environment that has been fully tested, as the last thing they want is a technical glitch to ruin the demo.

Everyone Plays a Part
The chapter emphasizes the importance of collaboration during the demo. While the customer can kick off the meeting with an overview of the iteration’s goals, the spotlight then shifts to the team. Each team member should have a part to play in presenting their work, though they should not be forced into presenting if they are uncomfortable. Having multiple team members participate in the demo helps build confidence and keeps the presentation dynamic. The team should be transparent about any unfinished work, and feedback, both positive and constructive, should be captured and reviewed at the end.

Releasing the Software
The chapter goes on to discuss the final steps after the demo: releasing the software. While the iteration might be finished, the release decision requires careful consideration. The team must ensure that all testing has been completed, there are no critical bugs, and the release is appropriately timed for end users. The chapter recommends automating the deployment process to reduce the potential for human error during the release. Additionally, it suggests creating deployment tests to ensure that the environment is suitable for the software to run correctly.

Several potential hurdles are addressed in the chapter. These include instances where no stories are completed by the end of the iteration, which may necessitate canceling the demo. However, it’s important for the team to remain transparent about the situation, even if the demo can’t be fully completed. In such cases, the team should use the opportunity to gather feedback on what is working and focus on getting a few stories to “done” in future iterations. The chapter also discusses issues like software relying on components from other teams, or having no user interface, both of which can make a demo difficult.

The chapter concludes with a comprehensive checklist for running a successful demo. It includes planning demonstrable stories, ensuring all necessary stakeholders are present, preparing technical setups in advance, rehearsing the demo, capturing feedback, and celebrating the team’s achievements afterward. If things don’t go as planned, the chapter advises using the retrospective to identify issues and develop an action plan for improvement.

In summary, this chapter emphasizes that iteration demos are a vital part of the Agile process. They not only showcase progress but also foster accountability, communication, and trust between the team and stakeholders. Proper preparation, team collaboration, and clear communication are the keys to running a successful demo that motivates the team and provides valuable feedback.

Chapter 13 – Driving Change with Retrospectives

This chapter dives deep into retrospectives as a key practice to help Agile teams learn from experience and continuously improve. The authors open with a quote comparing teams without retrospectives to being stuck in a loop—like Groundhog Day—repeating the same mistakes. Retrospectives are the team’s moment to pause, reflect on what worked and what didn’t, and decide what to do differently next time. But many teams abandon them too soon, often because they don’t know how to run them effectively. This chapter shows not just why retrospectives matter, but how to make them work.

Facilitating an Effective Retrospective
A good retrospective bridges past iterations and future improvements. Half of the session should focus on what happened in the last iteration, and the other half on what actions the team will take moving forward. The authors emphasize that this time shouldn’t be rushed—just because it doesn’t produce immediate output doesn’t mean it’s not valuable. Coaches should help teams share their perspectives without judgment, using tools like timelines, mood charts, and even metaphorical drawings (like someone feeling “boxed in”) to surface real issues.

But there are “retrospective smells” to watch for: listing ideas without context, vague actions without owners, or turning the session into a complaint fest without accountability. The goal isn’t just to vent or brainstorm—it’s to identify specific, achievable actions. And those actions need to be visible and prioritized, or they’ll just disappear. A neat tip from the chapter: if you want those actions to be remembered, put them on the team board—not buried in someone’s drawer.

Looking Forward and Taking Action
The second half of the retrospective is all about moving forward. Before setting new actions, the team should revisit the last ones—did they get done? If not, why? Often it’s because they weren’t clearly defined or didn’t have time allocated. Here, the authors introduce the idea of “baby steps”—small, realistic actions the team can commit to within the next iteration. They also borrow a fun concept from Edward De Bono’s Six Action Shoes to categorize different kinds of actions, from quick fixes (orange gumboots) to data-gathering (gray sneakers) and emotionally sensitive issues (pink fluffy slippers).

There’s also a smart technique for action planning: individuals write their own ideas, pair up to merge them, and gradually combine into a team-wide shortlist. This prevents the usual few voices from dominating and helps the whole team feel ownership over the outcomes. And once actions are chosen, they need to be visible and integrated into planning for the next iteration—otherwise, they’re forgotten.

Designing and Scaling Retrospectives
Retrospectives should be tailored to the team’s needs and shouldn’t always follow the same script. The chapter provides a suggested structure, from reviewing past actions to identifying improvement areas and planning next steps. But variety is key to keeping them fresh. The authors also stress the importance of creating psychological safety with the “Prime Directive”—reminding the team that everyone did their best with what they knew at the time. This shifts the focus from blame to learning.

For bigger teams or post-release reviews, the chapter introduces broader retrospectives. These include people from outside the team—like marketing or support—and help surface cross-team challenges. These sessions can be trickier to run and require more prep, but they provide valuable insights. Prework like surveys and reminders of what happened in the project help participants engage more meaningfully.

The chapter closes with a look at common hurdles: repeating the same actions, silent team members, or sessions that spiral into complaints. Solutions include breaking down large goals into smaller steps, encouraging written input for quieter voices, and redirecting complaints into constructive ideas. Coaches are reminded to stay neutral and not dominate the meeting. And if you’re part of the team, consider having someone else facilitate so you can fully participate.

In the end, retrospectives are where real change happens—not just by naming problems, but by working together to improve, one small action at a time. The authors encourage coaches to treat retrospectives as essential—not an afterthought—because over time, the consistent habit of reflection and action is what truly transforms teams.

Chapter 14 – Growing You

After spending the entire book focused on how to support Agile teams, this final chapter shifts the spotlight to you—the coach. The authors remind us that to be a great coach, you need to keep growing yourself. Coaching is emotionally demanding and mentally intense, so you need regular doses of reflection, learning, and self-care to stay sharp and inspired. Personal growth isn’t a luxury; it’s part of the job. And it starts with taking ownership of your own learning journey instead of waiting for someone else—like your employer—to hand you the next step.

Ways to Grow What You Know
The chapter offers a rich set of ideas to help you keep learning: read books, join webinars, listen to podcasts, attend local interest groups, or start a blog. It’s about finding what works for you and making learning a regular habit. Whether you go deep on one topic or skim broadly across many, the key is consistency. The authors suggest keeping a reading journal, taking notes on key takeaways, or even trying mind mapping to retain knowledge better. But the most powerful technique? Share what you learn—through talks, discussions, blog posts, or mentoring. Teaching others helps you understand the topic more deeply yourself.

Make a Plan, Build a Network
Rather than learning passively, the chapter encourages you to build a personal development plan. Set goals, identify areas to grow, and don’t wait for your manager to fund it—invest in yourself. At the same time, surround yourself with others who care about Agile and software craftsmanship. Local meetups, Agile conferences, and even mailing lists or online forums can offer inspiration, perspective, and community. These conversations help you see beyond your own context, challenge your assumptions, and even improve your coaching skills through real dialogue.

Personal Reflection and Self-Care
Growth also comes from self-awareness. The authors encourage coaches to keep a journal—writing daily or weekly about experiences, mistakes, and wins. It helps you process emotions, identify patterns, and track how far you’ve come. A variation called the “success journal” focuses only on what went well, reinforcing confidence and momentum. There’s also wisdom in simply taking time to walk, think, or pause without distraction. These quiet moments give your subconscious space to work through challenges and bring clarity.

Getting Comfortable With Discomfort
Coaching isn’t always easy. People may resist your help, ignore your advice, or project their own frustrations onto you. The chapter gently reminds you to develop a thick skin, not take things personally, and always assume good intent. People act the way they do for reasons you might not see—so be curious, not judgmental. And just as important: be kind to yourself. You’re going to make mistakes. You’re going to feel doubt. That’s normal. The key is to keep learning, forgiving yourself, and moving forward with purpose.

Keep Your Career Energized
Finally, the authors challenge you to stay on your toes. If you’re bored or too comfortable, it might be time to switch things up. Can you mentor someone new? Take on a different team? Speak at a conference? The goal is to keep your work just a bit beyond your current comfort zone so you’re always growing.

This chapter closes the book with a deeply human message: to be a great Agile coach, don’t just teach change—live it. Stay curious, stay connected, and most importantly, stay kind to yourself and others along the way.

4 Key Ideas from Agile Coaching

6 Main Lessons from Agile Coaching

My Book Highlights & Quotes

During stand-up meeting, make sure each team member is reporting to the team and not to one individual in particular. This is not a status reporting meeting, but an opportunity for the team members to coordinate their day’s work. At Insidr, we have the scrum master take notes during the meeting, and it can very easily devolve into each member reporting status to the scrum master, each in turn, while nobody else pays attention. This is the opposite of what the stand-up meeting is meant to be

Have the stand-up meeting at the task board, or bring the task board to the stand-up meeting. The meeting is more meaningful if the tasks being discussed are right in front of everybody

Approach reading a book like building a jigsaw puzzle: peruse all the pieces, find the edges, work out the easy parts of the interior, and keep the most difficult pieces for last. When dealing with a book, scan all the headings and illustrations to get the overall message, then read the parts that provide the overall structure, skipping hard passages to focus on breadth over depth, then coming back to parts of interest

Conclusion

In the end, Agile Coaching doesn’t just teach you how to run better meetings or introduce Agile practices—it teaches you how to support people through change with empathy, clarity, and confidence.

It reminds you that coaching isn’t about being the expert—it’s about creating the space for others to grow.

And whether you’re an Agile coach, a team lead, or just someone trying to help people work better together, that’s a lesson worth carrying with you.

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

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

Want to show your support and appreciation tangibly?

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

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

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

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

Navigate between the many topics covered in this website:

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

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

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

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

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