Recommended Reading for Agile Coaches


  • The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever – Michael Bungay Stanier
  • Agile Retrospectives: Making Good Teams Great – Esther Derby | Diana Larsen
  • Co-Active Coaching: The Proven Framework for Transformative Conversations at Work and in Life – Henry Kimsey-House | Karen Kimsey-House | Phillip Sandahl | Laura Whitworth
  • The Trusted Advisor – David H. Maister | Charles H. Green | Robert M. Galford
  • Agile Coach to Chief Agility Officer: Placing the Agile Coach on the Leadership Team – Steve Peacocke
  • I’m Sorry I Broke Your Company: When Management Consultants Are the Problem, Not the Solution – Karen Phelan
  • Enterprise Agile Coaching: Sustaining Organizational Change Through Invitational Agile Coaching – Cherie Silas | Michael de la Maza | Alex Dudinov
  • Becoming Agile: in an imperfect world – Greg Smith | Ahmed Sidky
  • The Agile Thinker: Better Ways of Living, Working, and Making Sense of Life’s Chaos – Jack Walser


  • Tribal Unity: Getting from TEAMS to TRIBES by Creating a One Team Culture – Em Campbell-Pretty
  • The Culture Code: The Secrets of Highly Successful Groups – Daniel Coyle
  • The Surprising Power of Liberating Structures: Simple Rules to Unleash A Culture of Innovation – Henri Lipmanowicz | Keith McCandless
  • The Primes: How Any Group Can Solve Any Problem – Chris McGoff
  • Culture Renovation: 18 Leadership Actions to Build an Unshakeable Company – Kevin Oakes
  • A Whole New Mind: Why Right-Brainers Will Rule the Future – Daniel H. Pink
  • Drive: The Surprising Truth About What Motivates Us – Daniel H. Pink
  • Joy, Inc.: How We Built a Workplace People Love – Richard Sheridan


  • The Goal: A Process of Ongoing Improvement – Eliyahu M. Goldratt
  • The Present: The Gift that Makes You Happy and Successful at Work and in Life – Spencer Johnson, M.D.
  • Who Moved My Cheese: An A-Mazing Way to Deal with Change in Your Work and in Your Life – Spencer Johnson, M.D.
  • The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win – Gene Kim | Kevin Behr | George Spafford
  • The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data – Gene Kim
  • The 6 Types of Working Genius: A Better Way to Understand Your Gifts, Your Frustrations, and Your Team – Patrick Lencioni
  • The Five Dysfunctions of a Team: A Leadership Fable – Patrick Lencioni



  • Kanban: Successful Evolutionary Change for Your Technology Business – David J. Anderson
  • Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework – Mik Kersten
  • The Principles of Product Development FLOW: Second Generation Lean Product Development – Donald G. Reinertsen
  • The Book of TameFlow: Theory of Constraints Applied to Knowledge-Work Management – Steve Tendon


  • Agile Software Development with Scrum – Ken Schwaber | Mike Beedle
  • The Enterprise and Scrum – Ken Schwaber
  • Lean-Agile Pocket Guide for Scrum Teams – Alan Shalloway | James R. Trott
  • Scrum: The Art of Doing Twice the Work in Half the Time – Jeff Sutherland | J.J. Sutherland


  • Extreme Programming Explained: Embrace Change – Kent Beck
  • Planning Extreme Programming – Kent Beck | Martin Fowler
  • Extreme Programming Explored – William C. Wake
  • Testing Extreme Programming – Lisa Crispin | Tip House
  • Extreme Programming Applied: Playing to Win – Ken Auer | Roy Miller
  • Extreme Programming in Practice – James Newkirk | Robert C. Martin
  • Questioning Extreme Programming – Pete McBreen


  • Scaling Software Agility: Best Practices for Large Enterprises – Dean Leffingwell


  • Leadership and Self-Deception: Getting Out of the Box – The Arbinger Institute
  • The Anatomy of Peace: Resolving the Heart of Conflict – The Arbinger Institute
  • The Outward Mindset: Seeing Beyond Ourselves – The Arbinger Institute
  • Leadership Agility: Five Levels of Mastery for Anticipating and Initiating Change – Bill Joiner | Stephen Josephs
  • The Advantage: Why Organizational Health Trumps Everything Else in Business – Patrick Lencioni
  • Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization – Dave Logan | John King | Halee Fischer-Wright
  • The 5 Levels of Leadership: Proven Steps to Maximize Your Potential – John C. Maxwell
  • Leaders Eat Last: Why Some Teams Pull Together and Others Don’t – Simon Sinek
  • Start with Why: How Great Leaders Inspire Everyone and Take Action – Simon Sinek


  • Accelerate: Building and Scaling High Performing Technology Organizations – Nicole Forsgren, PhD | Jez Humble | Gene Kim
  • Lean Enterprise: How High-Performance Organizations Innovate at Scale – Jez Humble | Joanne Molesky | Barry O’Reilly
  • Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness – Frederic Laloux
  • The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses – Eric Ries
  • The Fifth Discipline: The Art & Practice of the Learning Organization – Peter Senge
  • Remote Team Interactions Workbook: Using Team Topologies Patterns for Remote Working – Matthew Skelton | Manuel Pais
  • Team Topologies: Organizing Business and Technology Teams for Fast Flow – Matthew Skelton | Manuel Pais


  • Test Driven Development: By Example – Kent Beck
  • The Capability Maturity Model: Guidelines for Improving the Software Process – Carnegie Mellon University Software Engineering Institute
  • Software by Numbers: Low-Risk, High Return Development – Mark Denne | Jane Cleland-Huang
  • Working Effectively with Legacy Code – Michael C. Feathers
  • User Story Mapping: Discover the Whole Story, Build the Right Product – Jeff Patton | Peter Economy
  • Sooner, Safer, Happier: Antipatterns and Patterns for Business Agility – Jonathan Smart
  • Actionable Agile Metrics for Predictability: An Introduction – Daniel S. Vacanti
  • Pair Programming Illuminated – Laurie Williams | Robert Kessler


  • Training from the Back of the Room: 65 Ways to Step Aside and Let Them Learn – Haron L. Bowman
  • The Ten-Minute Trainer: 150 Ways to Teach it Quick & Make it Stick – Sharon L. Bowman
  • Using Brain Science To Make Training Stick: Six Learning Principles That Trump Traditional Teaching – Sharon L. Bowman
  • Resonate: Present Visual Stories That Transform Audiences – Nancy Duarte
  • Cracking the Code: How to Win Hearts, Change Minds, and Restore America’s Original Vision – Thom Hartmann

The High-Wire Safety Net

Coach: “I’m concerned about the quality of delivery. The defect counts seem very high.”

Manager: “That’s why we have testers. To root out the defects.”

Coach: “I understand the value your testers are bringing. I’m referring to the frequency with which they bring it.”

Manager: “What difference does it make? The bugs are getting addressed.”

Coach: “The difference? It’s one thing to HAVE a safety net. It’s another thing to USE it.”

Real-Life Conversation
Continue reading “The High-Wire Safety Net”

The Coaching Dilemma

Voice on phone: “I need an Agile Coach.”

Me: “Great! Tell me about where you are in your agile journey.”

Voice on Phone: “I’m at the part where I need a coach.”

Me: “Okay. What kind of coach?”

Voice on Phone: “…”

This happens a lot these days. The understanding that there is more than one type of coach has not sunk into the corporate psyche yet. Perhaps because in the greater scheme of the 20+ year arc of agility, we have only recently come to the realization ourselves.

Let’s examine a couple sources of “coaching”…

The Scrum Master as Coach

There was a much simpler time, when all we had was single teams and coaching was performed by the Scrum Master. If you wanted to be a Scrum Master, it helped to be certified (or so we assumed). Later, it became obvious that a certificate alone proved nothing more than you had survived a two-day class. You theoretically knew what Scrum did. It took a painstaking process of trial and error for most fledgling Scrum Masters to reach true maturity.

This is a great example of the Dunning-Kruger Effect. When you first learn a thing, you know all that you know about a thing, and have no idea of how much else there is to learn. It looks a little like this:

When learning a new competency, it is easy to fall into the trap of knowing all there is to know about a thing, because you’ve never seen how much more there is to learn. True enlightenment is a journey.

I won’t belabor the point. A lot has changed since those days, but one thing remains the same: No amount of training can take the place of the experience of doing. And no amount of doing will be truly effective until you understand the “why” behind the doing.

In those days, every freshly certified Scrum Master came out of their two-day class with a level of confidence that frankly was born of ignorance. Well-meaning, innocently contrived, but ignorance, nonetheless. The lucky ones (and I count myself among them) managed to have their challenges unveiled in small, manageable chunks and had time to work them out. But every Scrum Master seemed destined to earn their expertise in the same way. Through trial and error.

Some people were better equipped to handle the abstract nature of the agile learning curve. Some people were ‘wired for agile’ – which absolutely gave them a leg up in “leading” their teams to success. (By “leading”, I mean they embraced their role as enabler and supporter. The teams’ successes were their own doing.)

The Project Manager as Scrum Master

Then there were those Scrum Masters who arose from the old guard – who embraced direction and enforcement. They were very much wired for the deterministic/directorial role of a Project Manager, and dismissed as unimportant the servant leader aspect of the Scrum Master role. When coaching fell into the lap of a recovering Project Manager, the teams didn’t learn the ‘why’ of agility, and instead focused on execution of the process (the ‘what’ of the agile frameworks).

It wasn’t so much coaching, as it was check-listing. And believe me, they were excellent at checking boxes! Predetermined, uniformly sized boxes. The philosophical underpinnings of agility were de-emphasized. In other words, more “doing Agile” and less “being agile”.

This was a critical point for agile adoption at large, and it was a major point of failure. Many organizations were taking their most trusted executors of delivery and handing them a job (they thought) the individuals would continue to thrive in: namely, being responsible for all aspects of project delivery.

So why didn’t this work out so well?

One of the biggest disconnects here is that Project Managers assign work, collect status, manage risk, and report status. In agile, all of those activities are owned by the people who do the work and are largely built into the framework. Instead, we had these Project Managers, sitting at the head of the Scrum Room table (as they do), feeling responsible for the Scrum Team’s success, feeling accountable for their failures, and feeling justified in stacking the deck toward success by hanging onto the oversight and reporting of the work.

As a result, we had all of these beginner teams being paired with beginner Scrum Masters, who were not the experts in agility we needed them to be. The Teams never grew to maturity. They never embraced autonomy. They simply waited for the inevitable orders to be handed down. The term “agile” became a euphemism for “micro-management”. Rather than feeling empowered, the teams experienced the exact opposite.

Coaching Within and Without

According to the Scrum Alliance, the Scrum Master is the primary coach of the team – and that is absolutely true in a world where there is one team working from one backlog answering to one product owner. A Scrum Master at this level helps their team grow in their agile maturity by learning how to work together to achieve their sprint goal. They will help identify impediments, and work with the team to find solutions so the work can continue. This is an inward-facing stance, and it’s what most Scrum Masters spend the majority of their time on — working within the team, for the team, on the team.

Occasionally, impediments will come from outside sources, and this will be the first gateway opportunity for the would-be coach to show what they’ve got. This is when the Scrum Master faces outward, beyond the team. Maybe it’s a dependency with another team. Maybe it’s a stakeholder who isn’t providing needed information in a timely manner. Maybe it’s a manager who just can’t stop assigning little one-off assignments to individual team members. Maybe it’s a director demanding to see allocation and utilization figures for all the developers on the team. This is the point that the Scrum Master needs to embrace Courage.

They may intellectually accept that they are required to protect their team, but are they prepared to do the next part? The part where they identify the source of the conflict, and if necessary, offer to educate the offending party on a more effective way of interacting? This will likely involve having an uncomfortable conversation with someone who outranks them on the corporate org chart – maybe by a lot.

Here There Be Dragons

I’ve seen it many times. The challenge arrives. It’s affecting the team in a bad way. The Team asks the Scrum Master for help. The Scrum Master sees the direction from which the challenge came, takes a deep breath, gazes into the abyss, and… turns back shaking their head. “That’s just the way we do things around here.” The impediment goes un-answered. The team learns to “just live with it”. Another coffin nail is driven into the heart of organizational agility.

To be fair, sometimes an organizational culture acts as though challenging a superior is unthinkable. For one reason or another, the Scrum Master has legitimate reasons to fear that raising such a challenge will be a career-limiting move. In their mind, retribution will surely follow. If not today, then at the end of the year when annual reviews come around. Hell, it seems, hath no fury like an executive rebuked (or something like that).

To be equally fair, the leader in question may not be the petty ogre the Scrum Master fears. They may be perfectly willing to listen, to learn, to change. But odds are, that somewhere in that Scrum Master’s past, they either faced it themselves, or heard a story of someone else who took the risk and paid a hefty price. And that’s sad.

Regardless of the source, real or imagined, the urge to step away an let the problem live on, is the source of many of the ills I’ve seen when beginning an engagement with a new client.

The Agile Coach as an Independent Entity

And hence, the Agile Coach as an independent role came into being. The Agile Coach is an individual who comes from outside the normal chain of command in which a team operates.

Often the coach is a consultant (or at least a contractor). They ride into town in response to a cry for help. They diagnose the problems, and help the townsfolk learn how to stand up and hold their own against the things that are plaguing them. And then they leave, riding off into the sunset having equipped the townsfolk with the skills they need to continue their agile journey on their own.

So going back to that external impediment that resides in the corner of the organization where the internal angels fear to tread… this is where the external coach has an advantage. The external coach comes from outside the corporate structure. They are not beholden to the status quo. They don’t know that they’re “supposed to” be afraid of asking hard questions. And in that ignorance, they are blessed with the opportunity to be effective! (And yes, they will occasionally fall prey to upsetting the wrong apple-cart, and getting shown the door as a result.) An experienced coach has probably been fired at least once for trying to do the right thing. A skilled coach has adapted their approach to minimize that potential outcome (usually in the form of a coaching agreement).

I have heard it argued that if you’re not willing to risk your job, you aren’t really being an effective coach. And obviously, the intent of the external coach is to be a temporary factor anyway. They already plan to go – it’s just a matter of when they leave. (See Black Hat / White Hat for a little more on this topic.)

Who Should Coach?

So, setting aside for the moment that all Scrum Masters are a form of coach, let’s focus on this concept of the stand-alone coach role. That is, the person wielding the title of “Agile Coach”. More and more, I see organizations stepping away from the contractor coach, and building this capability in-house. From a financial standpoint, this makes sense – especially if you intend to keep the coaches around for an extended period of time.

Some organizations will hire someone who is already an experienced coach. Others will try to find someone in-house to fill the role. That can work – absolutely that can work. But it can also backfire. It’s similar to the idea of taking a project manager and expecting them to be wired for the Scrum Master role. The potential challenge here, is that someone from inside the organization, is already familiar with the established culture. They know the corporate hierarchy, and their place in it. Further, they have become accustomed to ignoring the elephant in the room. That big, ugly elephant that is crushing your organization’s ability to move forward – the elephant that nobody speaks of. This internal coach will likely remain silent about it, because that’s just the way we do things around here.

I suppose it depends on intent. If someone is looking to be an agile coach simply to have a little more authority over telling teams how to do their work — to essentially be a bigger, badder Scrum Master — then I would argue they’re not really coaching.

If on the other hand, someone sees the team as a part of a larger ecosystem, and can not only see the team’s place in that maelstrom, but how other teams, departments, individuals, policies and practices are impacting the ability of organization to function. If they are adept at seeing the trouble-spots (even if they don’t know the answer yet) and have the curiosity to seek a root cause and the ability to bring others along with them on that journey… those folks are likely capable of effective coaching.

I have been at many organizations, and within each one, found individuals who I recognize as having that spark. I always try to encourage those folks to expand their horizons. I will have frequent mentoring sessions with them. I will engage them in discussions about motivation and drivers. To see if they can discern the root problems beyond the symptoms. Sometimes they can. Often their vision is clouded by being too deeply mired in the system.

Organizational Antibodies

Many corporations function like a living organism. There are distinct structures and roles within the organization. They not only exist to preserve the life of the organization, but to also preserve their own function within the organism. They are always on the lookout for threats to their health or station. It’s a natural byproduct of the cutthroat nature of corporate America.

I recall one time, when I was a full-time, internal employee, trying to advise my superiors about ways to support agile teams and how approachs within our organization would have to change. At one point in the conversation, one of the leaders asked, “We’re trying to be Agile now, Mike, you’re the agile expert, what does that mean we would do in this instance?” And I answered him. And he looked me dead in the eye and said, “We’re not going to do that.” And I was thanked for my input and sent back to my day job. The struggle to be recognized outside of your corporate “role designation” is real.

Now, fast forward a few years and I’m an external coach for another company, sitting in a near-perfect copy of that other meeting. Same ranks. Same questions. They turn to me and ask, “We’re trying to be Agile now. Mike, you’re the agile expert, what does that mean we should do in this instance?” And I answered him (the same way I’d answered before). And he looked me dead in the eye, nodded, and said “Okay!” And they did it.

The External Coach as Trusted Advisor

The difference? A paid opinion over a paid role? Perhaps? It wasn’t that the information in the room was any different. I honestly think it was me and my role. An external, paid consultant, recognized as being a trusted advisor, versus being one of their own employees, who by virtue of rank, was not allowed to render an opinion.

I’m not saying it’s every organization. But I’ve seen more than a few of them do it. I’ve even heard them say things like, “That person is JUST a B.A.”, we’re not giving them that kind of authority”, or “That’s my job to make those decisions. Not yours.” It seemed more like they were protecting turf and status, than seeking solutions to problems.

So that external coach. By virtue of the fact that they are being paid for their opinion and recognized as having expertise in the transformation space. Bolstered by their ability to see the things that others fear to recognize. Are able to transcend the chain-of-command and enable the organization to change. To teach. To mentor. To guide. To build capability.

And then to move on and do it again somewhere else.

Personally, that’s why I do this. I love being that guy.

Tens, Romans & Lettermen – Part 2

Far be it from me to leave well enough alone. Let’s amp this discussion up to the next level. **

Part 2 – Advancing the Discussion

In Part 1 of this topic, we demonstrated why multi-tasking is bad for productivity. Some of you will be just fine with that conclusion. You probably are perfectly comfortable waiting for all three columns of the grid to be generated in sequence, and then just accepting the end result.

But what if there was a reason not to be so comfortable with that result? If that were the case, this discussion could get pretty interesting.

Note: If you haven’t read Part 1 yet, you should go back and do that first.

Continue reading “Tens, Romans & Lettermen – Part 2”

Tens, Romans & Lettermen – Part 1

A simple game to illustrate the cost of task-switching *

The title of this post is a terrible play on words. Every time I think about it, I’m reminded of the opening lines of Mark Antony’s funeral oration. It’s cool if you don’t agree with the title. Lend me your ears anyway…

Multi-tasking via Task-Switching is a costly practice. This game can be used to illustrate this point with things you can probably find readily available in your desk or office-supply closet. The material is presented in 2 parts. Part 1 reveals the exercise in its most basic form. Part 2 expands on the original premise to learn even more…

Continue reading “Tens, Romans & Lettermen – Part 1”

If I Had a Tractor – Introduction

Here the metaphor of lawn care serves as a gateway into a discussion of defining and estimating work in a manner similar to what new agile teams are first called upon to learn. We then build on those concepts to demonstrate the rationale for maintaining cross-functional teams. And finally how to budget for these activities.

Continue reading “If I Had a Tractor – Introduction”