I have moved to a new wordpress address.
You can find it here: https://tobysinclairblog.wordpress.com/
How i approach Coaching
StandardThis 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.
Who?
When it comes to One-to-One Coaching sessions i generally have two types of engagement:
- People approach me directly asking for coaching towards a specific goal.
- 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.
How?
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.
Examples
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.
https://www.linkedin.com/pulse/please-more-brainstorm-sessions-how-innovation-really-matthew-syed
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.
- Each group nominates a Spokesperson
- Spokesperson rotates to one of the other groups which now becomes the reviewers
- Spokesperson presents the idea to the reviewers (~3 Minutes) (Silence from the reviewers)
- Spokesperson turns around and faces away (Silence from Spokesperson)
- Reviewers attack (dissent) or improve (assent) the ideas (~3 Minutes) (Whilst this happens the Spokesperson records the feedback)
- Spokesperson returns to their original group
- Group decide what to do with feedback (~6 Minutes)
- 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?
StandardI 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
StandardA 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
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
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
What 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
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
StandardOne 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:
- Comforter – “Trying to make people happy”
- Controller – “Being the person who always knows best”
- 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:
- XP 2016 – Dan North – Software Faster
- XP2016 – Day 1 – XP at Scale – Elisabeth Hendrickson
- How to do Example Mapping
- XP2016 – Does the Test Automation Pyramid matter and who really cares? – Panel Discussion
XP2016 – Does the Test Automation Pyramid matter and who really cares? – Panel Discussion
StandardAt 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
StandardA 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:
- Someone who knows the problem domain (Usually a Product Owner)
- Someone who can technically implement (Usually a Developer)
- 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:
- 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.
- 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
XP2016 – Day 1 – XP at Scale – Elisabeth Hendrickson
StandardSome notes from the opening Keynote at XP2016 from Elisabeth Hendrickson.
Some Principles at Pivotal:
- Separate what & how
- Sustainable Pace
- Automate
- Ensure fast feedback
- Team Own Quality
- Reflect, Adapt, Experiment
Pairing is really important. Do it as part of your recruitment.
Scaling problems are highlighted in the analogy “Tragedy of the Commons”
“Without intervention work rolls down hill!” Sometimes teams need to help and guidance.
Why isn’t XP practiced widely?
Some more Pivotal Principles…..
- Use Conyway’s law to your advantage
- Teams own things
- Team that owns that thing tests that thing
- Relentless feedback cycles
- Increase Empathy
- Collaborate, reduce Hand Offs
Empathy is our advantage….
“Don’t do it for me, do it WITH me”
If Field engineers encounter problems they are encouraged to pair with the team to get it resolved. Pair all the time with everyone!
Some new techniques Pivotal have applied……
- Big team standup
- Cross team retros
- Allocations/Rotations
- Cross Team Pairing
- Regular Exploratory Testing
Some new roles at Pivotal…
- Engineering Director / Leadership Liaison
- Product Director
- Product Manager
Closing comment…
Excellent Keynote!
I will be blogging throughout the conference. You can check out my previous post about Dan North’s workshop here
XP 2016 – Dan North – Software Faster
Standard
Today I attended Dan North’s @tastapod Workshop “Software Faster” at XP2016.
Here are a few things I learnt:
Learning #1
What is the goal of agile? Predictability
Learning #2
5 Steps in an Organisatonal Change journey:
- People Break
- Tools Break
- Governance Breaks
- Money Breaks
- Organisation Breaks
Typically alot of Agile Transformations focus on stages 1 and 2. They struggle to move to stages 3, 4 & 5. Often there is a conflict between people at each stage. In many cases stages 3, 4 & 5 are controlled by the “Frozen Middle”; Middle Management. Real breakthroughs only occur once issues are tackled at the later stages. Dans tip to change these stages is to “Use the system to change the system”
More: https://www.amazon.co.uk/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521
Learning #3
Marginal Gains will focus on optimising the existing system. For example if we focus on a 10% improvement we won’t rip up the rule book. For example, people might just starting working longer hours or doing over time. However if we focus on a 50% or higher improvement it will often make us think more fundamentally about our currently processes.
Learning #4
The point of Agile is not to create Software, it is a tool to deliver business capability.
Learning #5
The Goal of software is to:
“Minimise lead time to Business Impact.”
Lead time defined as:
“Having a need to having a need met”
It is easy to improve Lead time once or twice in isolation but it’s really hard to increase lead time “Sustainably”
When does the lead time clock start? As soon as you make a commitment to the person who requested it.
Can you measure lead time if you cannot measure business impact? No.
The big challenge is that measuring business impact is hard! Often teams use proxies such as Story Points rather than genuine impact: Number of users, Profit etc.
If you just focus on Lead Time it will lead to local optimisations.
More: https://dannorth.net/2013/07/05/are-we-nearly-there-yet/
Learning #6
Definition of a stakeholder: “People who’s lives you touch”
Learning #7
A good facilitation technique is to use the analogy of travelling between islands to explain the days agenda.
“Today we will start on Organisation Island, the swim across to Legacy Land, then drive to Core City and finish at the Planning Plateau.”
Learning #8
Three Ages Model can be used to explore where an organisation is:
Age 1 = Explore
Age 2 = Stabalise
Age 3 = Commoditisation
Often Organizations will misuse the ages. For example: try to commoditise testing by offshoring when it is an inherently exploratory activity.
More: https://www.slideshare.net/mobile/AdrianTreacy/dan-north-embracinguncertaintyv3
Leaning #9
PARC Model
More: https://www.amazon.co.uk/Modern-Firm-Organizational-Performance-Management/dp/0198293755
Learning #10
Apply “training from the back of the room” Encourage the attendees to teach each other. Example: In the next 3 minutes put together a pitch to explain what the PARC model is. At the end you will present this to another group”
Here is a group teaching each other:
More: https://www.amazon.co.uk/dp/0787996629/ref=cm_sw_r_cp_api_rshrxbDSR808Y
Learning #11
Value Stream Mapping Tips:
- It’s easy
- Get the real people who do the process involved
- Don’t worry about rounding numbers
- Make it viable
“Become less efficient to improve flow. Introduce sub optimisation.”
More: https://www.amazon.co.uk/dp/1935401009/ref=cm_sw_r_cp_api_6HhrxbNF4G6C6
Learning #12
Focus on reduction of Value at Risk(VAR) by working incrementally.
More: https://en.m.wikipedia.org/wiki/Value_at_risk
Learning #13
Dan finished the session playing a game called Taboo. Each person had to create a taboo card and then we played the game in groups.
This was an excellent way to reinforce the learning. Also another great example of “Training from the back of the room”
More: https://en.m.wikipedia.org/wiki/Taboo_(game)
Thanks Dan for a great day. Now onto post workshop drinks!
Toby The Testers Blog 