How i approach Coaching


This year i’ve been on a journey of discovery into Coaching. My official job title is “Agile Coach” and as the title suggests a key part of the role is Coaching. This blog explores how i approach Coaching with the intention that my experience will help others interested in the topic.

What is Coaching?

This was a question that troubled me for many months. It’s not an easy question to answer. It’s something i’m still discovering but through constant reading and practice i’m much more informed than i was 12 months ago!

When someone asks me “What is Coaching?” i typically refer to this quote from the Inner Game of Tennis:

“Coaching is unlocking a persons potential to maximise their own performance.”

Timothy Gallwey

I like this quote because it really highlights that the Coaching focus is always on the Coachee.

In practical terms, Coaching is a conversation where the coach uses questioning to help the Coachee build awareness of how to tackle a goal or challenge.

In my experience the question “What is Coaching?” results in many different answers so it is important to address this question directly with the Coachee early on. This helps ensure there is a shared understanding within the relationship. I have often found that to begin with people think the process is similar to Mentoring. I’ve blogged recently the differences between Coaching and Mentoring.

Types of Coaching

Coaching conversations can happen any time. It doesn’t need to happen in a formal setting or in “official” coaching sessions. Don’t let this fool you through, Coaching is a structured practice that requires practice and continual improvement.

The types of Coaching i’ve done are:

  • One-to-One Coaching in designated “Coaching Sessions”, usually 45mins – 1hr
  • Informal Coaching, for example at the “Water Cooler”.
  • Group Coaching, usually a whole team – A common realm for an “Agile Coach”

Whilst i’m embedding more coaching into my daily interactions with people my journey really started with One-to-One Coaching sessions. These sessions provided a safe environment to learn. Let me explain further how Coaching works in these sessions.


When it comes to One-to-One Coaching sessions i generally have two types of engagement:

  1. People approach me directly asking for coaching towards a specific goal.
  2. I approach others to offer coaching. In this case i’m always clear that the offer can be refused!

When i first started, rather than advertise my coaching services publicly I wanted to get some experience and practice. I spent time discussing with others my own personal goal to develop coaching experience. Eventually i found a a handful of people who were interested in being coached. I intentionally tried to find people that worked outside of my immediate influence, so not my direct team, and also people that i felt would be receptive of coaching. For the early sessions this felt like a safe environment to learn.


One of the most universally known Coaching models is “The GROW Model” and it was one of the first models i used too:


The GROW Model is a simple structure for a Coaching conversation. Personally i’ve found it incredibly useful as a mental model during the conversation to help give it structure. I also share this model with the Coachee so that it gives them a picture of how the conversation will be structured.

Whilst this is a good start, there is much more to learn. In my experience although the GROW model provides a good structure and its a great place to start, the more subtle skills are much harder to master. For example:

These topics are blog posts on their own but for now i’d recommend checking out the linked resources.


Since my early coaching sessions the number of people i’ve coached has broadened considerably. One of the fascinating benefits of coaching is the opportunity to work with people on a varied set of goals. Here are some examples (provided with consent):

  • Someone who wanted to improve prioritisation
  • Someone who wanted to find an opportunity to use physics in their career
  • Someone who was seeking a Promotion
  • A Scrum Master who wanted to build trust within their team

Although these were the stated goals at the start of the coaching engagement often the Goal might become something else. For example, a Promotion is a good example of an end goal. During the coaching we may explore some related performance goals in the control of the Coachee that could contribute to the end goal.

In the above examples it’s important to be clear that the focus is to get the Coachee to a point where they are comfortable either their goal has been met or they have made enough progress that they are happy to continue their journey without the Coach. In the above examples the length of the coaching sessions ranged from 2 – 6 1hr sessions. This is in contrast to Mentoring where the relationship may last for a longer period of time.

Now Start Your Journey!

Hopefully this has provided you with some insight into what Coaching looks like. I’ve linked to lots of resources during the blog that have really helped me in particular these 5 books.

Facilitation using Ritual Dissent


I recently read Black Box Thinking by Matthew Syed. In the book one of the topics Matthew explores is brainstorming. He talks about how an idea should be exposed to lively debate and challenge in order to refine the idea. Here is an extract from the book:

Perhaps the most graphic way to glimpse the responsive nature of creativity is to consider an experiment by Charlan Nemeth, a psychologist at the University of California, Berkeley, and her colleagues. She took 265 female undergraduates and randomly divided them into five-person teams. Each team was given the same task: to come up with ideas about how to reduce traffic congestion in the San Francisco Bay Area. These five-person teams were then assigned to one of three ways of working.

The first group were given the instruction to brainstorm. This is one of the most influential creativity techniques in history, and it is based on the mystical conception of how creativity happens: through contemplation and the free flow of ideas. In brainstorming the entire approach is to remove obstacles. It is to minimize challenges. People are warned not to criticize each other, or point out the difficulties in each other’s suggestions. Blockages are bad. Negative feedback is a sin.

The second group were given no guidelines at all: they were allowed to come up with ideas in any way they thought best.

But the third group were actively encouraged to point out the flaws in each other’s ideas. Their instructions read: “Most research and advice suggests that the best way to come up with good solutions is to come up with many solutions. Free-wheeling is welcome; don’t be afraid to say anything that comes to mind. However, in addition, most studies suggest that you should debate and even criticize each other’s ideas[my italics].”

The results were remarkable. The groups with the dissent and criticize guidelines generated 25 percent more ideas than those who were brainstorming (or who had no instructions). Just as striking, when individuals were later asked to come up with more solutions for the traffic problem, those with the dissent guidelines generated twice as many new ideas as the brainstormers.

Today i facilitated a brainstorming session where we applied this principle using an approach called Ritual Dissent. Here is how it worked:

Context: We had 3 Groups. Each group had an idea which they felt would solve a particular problem we are facing.

  1. Each group nominates a Spokesperson
  2. Spokesperson rotates to one of the other groups which now becomes the reviewers
  3. Spokesperson presents the idea to the reviewers (~3 Minutes) (Silence from the reviewers)
  4. Spokesperson turns around and faces away (Silence from Spokesperson)
  5. Reviewers attack (dissent) or improve (assent) the ideas (~3 Minutes) (Whilst this happens the Spokesperson records the feedback)
  6. Spokesperson returns to their original group
  7. Group decide what to do with feedback (~6 Minutes)
  8. Repeat 1 – 8 until ideas suitably refined or ditched

Some feedback points from the session were:

  • “It was good to present my idea without getting interrupted.”
  • “When we were reviewing the idea it helped that the person turned around, it made it feel less personal.”
  • “We got lots of feedback on our idea.”
  • “Our ideas are in a much better position.”

You can read more about Ritual Dissent here


Are you really Coaching?


I recently read “Brilliant Coaching” by Julie Starr. The book explores practical ways you can apply Coaching in the workplace. She provides great examples how you can apply a Coaching style moving from Directive leadership to empowering others(Self Directed)

In the book Julie presents a model; the Scale of Influence. This can be used as a model to build self-awareness in your Coaching conversations.


Scale of Influence: Brilliant Coaching, Julie Starr

In a Coaching conversation we may use different levels of influence but we want a good coaching conversation to be more self-directed (left of hand side of the model). In particular Julie recommends that new coaches should try to avoid giving advice or instruction at all.

I’ve recently started using this model to reflect upon the conversations I have with people around me. It has helped to identify times where I could have taken a less directive approach.

As many of my blog readers are Testers I’ve translated what the model might look like in Testing context. For example a conversation between a Tester and a Developer on deciding how to test a particular User Story.


This is a good way to reflect upon the conversations you have with people and understand “Are you really Coaching?”

Next time you are engaging in a Coaching conversation use this model and reflect:

  • How often do you tell someone else what to do?
  • How do you feel listening to someone share an idea when you think there is a better approach? How often do you follow with an opinion rather than asking further questions?
  • When you feel you are the expert, how often do you refrain from sharing advice and ask a question instead?
  • How does silence make you feel?

5 Books about Coaching


A common question i get asked is “What Coaching books do you recommend?”

Here is a short list of some Coaching Books i’ve read and some that are on my reading backlog.

1. Coaching for Performance: Growing People, Performance and Purpose


What i liked?

  • This book explores the popular GROW Model
  • There are some great chapters about crafting good goals
  • Explains well what Coaching actually is
  • For many this is the go-to book about modern coaching techniques. A best seller thats been around for many years.

Recommended for: Anyone new to Coaching


2. The Coach’s Casebook: Mastering the Twelve Traits that Trap Us

41+I4lOgqEL._AC_UL320_SR216,320_What i liked?

  • Very practical examples of coaching conversations
  • Real Life Case Studies from high profile and famous figures
  • Easy to relate to (I often found personal examples in each of the traits)
  • Promotes Coaching Supervision which was a concept that was new to me until i read this book

Recommended for: Scrum Masters (Co-Author Geoff Watts also Authored Scrum Mastery)


3. Time to Think: Listening to ignite the human mind

1020273 (1)

What i liked?

  • This book has had a dramatic impact of my coaching approach
  • It will fundamentally challenge you
  • Excellent examples and well written
  • Case Studies towards the end of the book of how to apply the Thinking Environment are very interesting.

Recommended for: People involved in organisational change



4. Coaching Habit: Say less, Ask more & Change the way you lead

Coaching-HabitWhat i liked?

  • Simple and accessible introduction to Coaching
  • Suggests some power Coaching questions such as the AWE question
  • Techniques can be applied straight away
  • Does not promote a rigid process but looks at how coaching can be built as a habit in everything you do

Recommended for: Managers



5. Art of Coaching


What i liked?

  • Visual!
  • Covers many core coaching concepts but using visual aids
  • Provides great inspiration of how to apply visual techniques to coaching.
  • Techqniues for both individuals and the team

Recommended for: Experienced Coaches looking for new ways to engage clients



Some more books on the backlog:

XP2016 – Katherine Kirk – Herding Cats: Coaching Techs and Execs


One of the best talks at XP2016 was from Katherine Kirk @kkirk. If you happen to be at a conference where she is speaking make sure you attend!! Katherine was one of the most engaging and entertaining speakers I’ve seen for a long time.

Insight Facilitation

In Katherine’s talk she introduced us to the concept of Insight Facilitation. Katherine talked about the importance of enabling people to figure out their own solutions in complex adaptive situations. Often “Agile Coaching” is about Process Education. This might appear to have some early success but once the big problems happen the teams are unable to adapt to the changing world around them. Through Insight Facilitation we want to empower people to handle these situations on their own.

It isn’t easy

As Coaches we can often fall into dysfunctions which can be damaging for the people within our organisations. Katherine talked about 3 common dysfunctions:

  1. Comforter“Trying to make people happy”
  2. Controller“Being the person who always knows best”
  3. Coercer “Leading the witness to your conclusions rather than their own”

These dysfunctions can lead to the following problems:

The Journey

Taking a Coaching approach can lead to interesting reactions from people. Katherine gave an example of an executive who joined a new company and during the early months people would come to his office asking for advice on how to solve problems, his response: “What do you think you need to do?” The simple act of asking this question was promoting empowerment of the individual and ownership.

This example made me think of a book I’ve been reading recently which is all about asking powerful questions; “The Coaching Habit: Say less , Ask More & Change the way you lead forever“. In particular the  book talks about the‘AWE’ question which is incredibly powerful to help explore other possibilities. AWE = And What Else?

Katherine also shared the different reactions she has seen and the journey people take through Coaching which I thought summed it nicely:

Excellent talk and great learning points about Coaching.

Thank You Katherine!

Some of my other posts from XP2016 are here:


XP2016 – Does the Test Automation Pyramid matter and who really cares? – Panel Discussion


At XP2016 there was a panel discussion focused around the “Test Automation Pyramid”


The discussion was facilitated using the “Fish Bowl” technique. The starting panel was:

Left to Right: Elisabeth Hendrickson, John Fergusson Smart, David Evans, Simon Brown, Steve Freeman

The discussion kicked off with the following are questions:

So what did we talk about?

The 90 minute discussion covered the following:

  • All models are wrong, some are useful
  • Does it matter? Maybe
  • Who cares? Not sure
  • It sucks because it ignores other types of automation that support testing. Automation can extend beyond Units, Integration and UI. I thought of Richard Bradshaws comments about “Automation in Testing”
  • The Exploratory Testing bubble that is sometimes placed on the top is stupid
  • What is the definition of a unit? No real clarification here
  • What is the the definition of an Integration Test? Tumble weeds……
  • People treat items higher up the pyramid as second class citizens. Tests at the top still add value although the feedback is traditionally slower
  • Pyramid can sometimes be used to assign responsibility. Testers focus on the top(E2E), developers do the bottom(Unit), someone somewhere does tests at the middle (Assuming they know what an Integration Test is)
  • The pyramid is based upon an old “3 tier architecture” model where the Front End was difficult to test and could only be done using “In Browser” tools such as WebDriver. In todays world, this is not the case. With front end frameworks such as AngularJS the front end can be broken down into Unit Tests.
  • What is Testing? Talked about the difference about Testing v Checking. Most of the discussion was about Checking but we should also think about Testing which is not currently part of the Test Automation Pyramid. The Pyramid is not about testing.

  • Uncle Bob Martin talked about how the Test Pyramid is commonly inverted, with most of the business rule tests implemented through the Front End.
  • There was talk about “Plumbing” and the Test Automation. I forget what we discussed exactly.
  • Did the Test Automation pyramid come from the “Food Pyramid“?


  • The focus of the discussion towards the end of the panel discussion moved into documentation
  • Uncle Bob Martin compared a well written code based to an “Encyclopedia”; It contains a robust collection of state transitions but its hard to search.
  • The Test Automation Pyramid exists because we like to talk in Metaphors.
  • Final comment;
    • Horizontal axis = Amount of Tests
    • Vertical axis = Amount of Pain

Thats me ^

So….what do you think? Leave a comment below.


How to do Example Mapping


A few months ago i came across Matt Wynne’s post about Example Mapping on the cucumber blog. During XP2016  I attended Matt’s Example Mapping workshop. I’ve been using the technique with teams for a few months now. This post will share what Example Mapping is and some of the experiences i’ve had using it.


What is Example Mapping?

Here is the process taken from the Cucumber blog:

Example Mapping uses a pack of 4-coloured index cards and some pens to capture these different types of information as the conversation unfolds. As we talk, we capture them on index cards, and arrange them in a map:

We start by writing the story under discussion on a yellow card and placing it at the top of the table.

Next we write each of the acceptance criteria, or rules that we already know, on a blue card and placing those across the table beneath the yellow story card.

For each rule, we may need one or more examples to illustrate it. We write those on a green card and place them under the relevant rule.

As we discuss these examples, we may uncover questions that nobody in the room can answer. We capture those on a red card and move on with the conversation.

We keep going until the group is satisfied that the scope of the story is clear, or we run out of time.

And that’s it. I told you it was simple!

How I’ve used it?

Teams I work with follow a simple principle called “Three Amigos”


We apply this to our story conversations ensuring that in each conversation we have:

  1. Someone who knows the problem domain (Usually a Product Owner)
  2. Someone who can technically implement (Usually a Developer)
  3. Someone who can critique the product/solution and think laterally (Usually a Tester)

Usually that results in 3 people but it could be more. We want enough people to have a good conversation.

Our Three Amigo conversations happen in two ways:

  1. Formal – A scheduled session run three times a week. In the calendar at a set time. Voluntary session where the team self-organise and decide who should attend. These sessions last maximum of 30mins.
  2. Informal – Conversations at someone’s desk where a small group gather to discuss a particular feature/story.

It is during these Three Amigo Comversations  that we use Example Mapping.

Benefits I’ve seen with Example Mapping

Benefit #1 – Getting past the first Question

Often during Three Amigo conversations i’ve found that teams struggle to get past the first question. When a difficult question arises the team get stuck on that one question. To overcome this we use the Diverge/Merge/Converge technique with Example Mapping. This allows us to get all our current understanding on the table first. We structure the conversation as follows:

  • 0 – 5 Minutes – PO/BA presents the story and potentially a handful of rules. Just enough information to start a conversation.
  • 5 – 10 Minutes – Individual Brainstorming of Rules(Acceptance Criteria), Questions and Examples.
  • 10 – 30 Minutes –  Discuss

Benefit #2 – Colour Heuristics

As the different elements are colour coded it is very easy to use this as a heuristic for the readiness of the story. For example:

  • Lots of Blue (Rules) story is too big
  • Lots of Green (Examples) might mean our rules are not specific
  • Lots of Red (Questions) might mean we don’t have clarity or there are too many unknowns

Benefit #3 – Knowledge Capture

Often in less structured Three Amigo sessions you can have really good conversations but there is a risk that the knowledge is not captured. In this process you have those great questions and examples captured.

Benefit #4 – Rules not Specifications

I’ve often seen teams write their acceptance criteria as designs or technical specifications. Example Mapping reinforces Acceptance Criteria as Rules. This leads to better examples and ultimately better stories. I’ve seen this be a particular challenge for some teams. If the Acceptance Criteria is written as Specifications its much harder to find good examples which aren’t tied to the technical implementation. Ultimately this process helps you get much better Acceptance Criteria.

Benefit #5 – It’s fast!

Prior to implementing Example Mapping for our Three Amigo conversations our sessions used to be an Hour long. We have now reduced the sessions to 30minutes but run them more frequently. The team finds short, frequent sessions better than longer less frequent discussions.

Benefit #6 – It supports remote teams

We have run the example mapping session digitally. Sometimes we have team members who are out of the office so we use a virtual post it note board.

Benefit #7 – Example format

Sometimes people get lost in the syntax of Examples. Given/When/Then can force people into a certain thought process. This approach allows people to declare their examples in a simple way.

Share and Visualise

It is also important to socialise your conversations. As Three Amigos is a subset of the team it’s important to share any key findings with the rest of the group. A good way to do this is to post your example Mapping sessions on the wall next to the Scrum Board. This way the team can keep track of the conversations. If you have a remote time simply sharing the link to the virtual whiteboard is a good way.

What happens next?

Typically we want to make the decision – Is this story ready? The main driver we’ve found is Questions. Do we have outstanding questions that mean we cannot proceed. It’s fine to have  some questions open if you are confident they won’t impact your ability to proceed in the Sprint. To aid this process a simple Roman vote can help the group decide if the story is ready.

For more about Example Mapping head to the Cucumber blog here