Chapter 7 of Badass Agile Coaching: The Journey from Beginner to Mastery and Beyond introduces The Agile Coaching Wheel and begins the second section of Extraordinary Badass Agile Coaching, which is focused on coaching models and practice.  


The SPaMCAST 733 features a reflection on a reflection. As I was reading Chapter 5 of Extraordinarily Badass Agile Coaching: The Journey from Beginner to Mastery and Beyond (check out the re-read at and retrospecting on my own behavior, I replayed some past coaching experiences. The point today is less the linkage to our current re-read than the confluence of continued learning and reflection.

We also have a visit from Mr. Jeremy Berriault. Jeremy and I talk about coaches who let their own biases run away with them.  


Chapter 9 of Coaching Agile Teams by Lyssa Adkins (SPaMCAST Amazon affiliate link: explores the role of the coach in navigation conflict.  Some conflict is always present when humans are involved. Well-managed conflict feeds creativity and is an important component of high-performance teams. Teams without conflict rarely change course or challenge the status quo. A coach can help manage the resolution of conflict. Conflict without a path to resolution will end badly, every time – this might be one of the few things that are absolute in the world (death being another). 


This week, Chapter 7 of Coaching Agile Teams by Lyssa Adkins. While observing and facilitating might be the most prolific coach activities, at times teaching takes front and center. As an experienced coach, I find myself slipping between different roles based on context. Teaching encompasses a wide range of behaviors, but the goal is always the same – to elevate the person or team you are teaching. Teachers are there to help PEOPLE to become better at something. My piano teacher in Waterloo, Iowa existed in my life to make me a better piano player, not a better dog walker or Agile Coach. In my role as coach-teacher, I have had to learn to focus on the immediate goal rather than possible knock-on effects. I recently sat in on conversations between two coaches that had been hired to a team test-driven development (TDD). Their sponsor wanted them to teach the team to have a more agile mindset under the guise of TDD. The goals are conflicting. To paraphrase a quote from Harry Potter, “they need to sort out their priorities.” In all teaching scenarios, clear and transparent priorities are critical to both building trust and success.


I am still recovering from a Covid infection I picked up at or getting to Agile 2022. All in all I have been lucky (and prepared) and have weathered a mild brush with this disease. My chest still feels like I was mugged, but every day I am getting better. The lack of self-awareness that I was getting sick until things were full-blown is fairly startling. It was more startling when I was re-reading Chapter 3 of Coaching Agile Teams by Lyssa Adkins (SPaMCAST Amazon affiliate line – buy a copy) again this week in preparation to write this essay. 


This week we began our re-read of Coaching Agile Teams by Lyssa Adkins (SPaMCAST Amazon affiliate line buy a copy).  The entire title is Coaching Agile Teams; A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition published by Addison-Wesley Signature Series copyright 2010. I am re-reading my Kindle version of the book. The front matter includes Forwards by Mike Cohn, Jim Highsmith, Acknowledgments, Introduction, and a section titled, About the Author. The main body of the book is in three parts comprised of 13 chapters. It is indexed — useful for reference books! I estimate 16 or 17 weeks to complete the re-read depending on my travel. Note: The Kindle edition of the book has not been updated and will not run on the Paperwhite Version 10 models, so we will re-read it on the iPhone and Laptop — I did not have a happy chat with Kindle support on this issue.  Wake up, Addison-Wesley!


The Software Process and Measurement Cast 612 features a conversation with Woody Zuill and Allan Kelly on the topic of being an agile guide. I have felt that the term coach was overused for more than a few years. Woody and Allan put a voice to a topic that I started writing about earlier this summer describing the term ‘agile guide’. Over the past 14 years, there have been a number of conversations that changed how I think and work.  This is certainly one of those gestalt moments.  


The discussion of whether a coach is using a directive or non-directive coaching approach is not an academic discussion. As a person that has held internal and external coach positions, the primary reason to explicitly understand the expectations of the role and how those expectations can evolve is so that you can manage those expectations. As noted in Directive or Non-Directive Coaching, coaching one way or the other is neither good nor bad depending on the context. The big but is that when a person, team, or organization expects or needs you to act one way and you act the other things go awry.  Three basic scenarios can be used to illustrate when one approach is indicated over another. They are:  (more…)

Move you head this way!

The word coach is used so indiscriminately that the meaning is hard to discern. Saying you are a coach still sends a signal, but the signal is at the mercy of the person that hears the term and it might not be what you’ve intended. In Agile Coaching Techniques: Styles of Coaches we used two different coaching approaches to define a continuum: directive and non-directive.  We used athletic coaches to mark the directive end of the spectrum and life coaches to mark the non-directive end. Each style has a very different approach to involvement.

To get a sense of how the market is leaning on the coaching involvement level scale, I grabbed a handful of job postings from LinkedIn from the US (some from the East Coast, Central Plains, and West Coast). I pulled out the job requirements and sorted them into categories. These categories could then be interpreted as directive or non-directive based on the verb they used.  For example, if the requirement used the active verb “manage” I put the requirement in the directive column. Verbs like advise and mentor I put in the non-directive category. I threw out things like projects and activities to be assigned as needed.

Coaching styles, as noted earlier, can be separated into two macro styles: directive and non-directive.  The basic approach of a directive coach is to “tell, show, do.”  The coach will teach the coachee (individual or team) how to perform a behavior or ceremony, then demonstrate, and then oversee the coachee performing the activity. The train-the-trainer approach used for transferring the knowledge to teach classes is a form of directive coaching. In directive situations, the coach needs to have deep levels of knowledge about the subject matter. For example, if you were coaching a team on behavior-driven development (BDD) you need an understanding of not only the theory but the practical knowledge of how to write and execute BDD tests.  

Directive job requirements included action verbs such as: 

  • Enforce,
  • Implement,
  • Lead,
  • Manage,
  • Methodologist,
  • Participate,
  • Improve (process), and
  • Measure.

The basic approach of non-directive coaches works by helping the person or people they are coaching to discover and apply their personal experience to solve their problems.  Lyssa Adkins, the author of Coaching Agile Teams, uses the phrase, “ask the team” which is reflective of non-directive coaching. This style is very popular in agile circles.  

Job requirements whose action verbs include one or more of the following were judged as non-directive:

  • Facilitate,
  • Mentor,
  • Coach (this feels like defining a word with the word being defined), and
  • Train.

Even though the non-directive style of coaching is more popular in the agile community, the small sample of job descriptions include substantially more directive type responsibilities (about a 60/40 split). Styles are just styles; I have used directive and non-directive techniques. The context and my agreements with the people involved provide a way to navigate between the two camps.  

August 4:  Why understanding style matters

August 6:  I am an agile guide

Stories are full of metaphors and similes.

Many of us spend at least a plurality of our day in meetings or talking with people. The give and take of conversation is core to software development. Ron Jefferies stated that user stories included a card, conversation, and confirmation. The problem is immediately apparent to anyone that has been involved with getting work done; language is imprecise. Metaphors are one of the culprits. Clean Language, borrowed from psychotherapy, is one of the tools that can be used to shine a light on what a speaker means when they use a phrase. In Clean Language – Basic Concepts it was noted that clean language can be used to establish the underlying meaning of a metaphor. It turns out that identifying metaphors is not as easy as the literature suggests. Exploring metaphors and why we care is an important digression. (more…)