As coaches, our opinions and unconscious biases can mislead or misdirect those we are coaching.
To see tangible results in your team’s performance, you need a way to structure your coaching.
Starting out as a new agile coach is difficult. Where do you go? How do you start? Learn to leverage a structured approach to coaching that defines a way to prepare and execute coaching activities. This starts with making observations and identifying what behavioural goals you would like the coachee(s) to achieve.
As coaches, our opinions and unconscious biases can mislead or misdirect those we are coaching. This bias occurs when an observer expresses their thoughts and expectations about a situation through tone, word choice, and body language in a way that influences the behaviour of people whom they are observing.
A classic example:
This is known as Observer Expectancy Effect, where our own ideas, biases and preconceptions would cause the thing we are observing to take particular actions.
Right about now, you’re probably thinking “Well I wouldn’t do that! I’m a professional!”. Bad news is that WE all do it. We can't help it because it's largely unconscious. Consequently, it is important that we are aware and careful of this effect. To help us avoid jumping ahead of ourselves, we can leverage a coaching structure.
E.g. Conversations in the daily scrum centers around the scrum master.
Does this sound like an observation to you? In fact this is an inference. An inference is where we add our own conclusions to observations. When we look at the actual events (i.e. making an observation), we may see every member of the team talking to the scrum master or team members speak primarily to the scrum master and occasionally to each other.
One of the most common problem is forming a hypothesis that closely matches our preconceived idea on why we are seeing what we see. For example, for a dysfunctional daily stand up, we may jump to the assumption that the team doesn’t understand the purpose behind this ceremony. However, could it also be that the scrum master is seeking to control the stand up? In order to avoid making assumptions, we want to form multiple hypotheses and tackle them one at a time by starting with the easiest ones first!
More often than not, we unintentionally validate the hypothesis by seeking for actions that prove it and filtering out evidence that disproves it. This is known as confirmation bias. One way to avoid this is to specially look for information that disproves the hypothesis and highlight any hidden assumptions.
Begin by asking yourself these questions:
E.g. As the owner of an e-commerce site, your goal is to increase sales revenue by 30%. If your website traffic remained the same, how likely are you to reach your sales revenue goal? In this case, website traffic serves as a leading metric that tells you whether or not you’re heading in the right direction. On the other hand, sales revenue is a lagging metric that allows you to know whether or not you have indeed achieved your goal.
Any action you take that potentially influences how the team or individual behaves is considered a tool. (Refer to the coaching card example.)
Coaching card is a template that walks through the TCF (make observations, formulate hypothesis, set goals, determine indicators, choose tools). agile42 coaches have created a repository of over 80 coaching cards that you can use. Please visit the Team Coaching Framework App - https://tcf.agile42.com. Feel free to use the templates or create your own coaching cards in the app.
- Pair with other coaches or scrum masters: Extra pair of eyes may result in a different set of observations.
- Share coaching cards with your team: Create transparency into your coaching. You can apply coaching cards to your 1-on-1 coaching conversations with team members.
- Use coaching card as a retrospective tool with your team:
The scrum master takes a very controlling role in the meeting - walking everyone through the three questions. He is quick to delegate work and ends the meeting by asking if everyone has “enough work for today”.
1) We think that the scrum master has not internalized the mechanisms he is expected to use. He may have difficulties understanding the role and the dynamics between scrum master and dev team.
2) The team may be afraid of taking responsibility and is happy to hand it to the scrum master.
3) Scrum master may not be familiar with mechanics of Pull versus Push.
***Pick one of the hypotheses to invalidate. (Recommendation: Go with the easiest one first.) It is important that we are trying to invalidate and NOT validate in order to avoid confirmation bias.
The goal is to make the team members talk to one another rather than only the scrum master. (i.e. they plan their Sprints and workdays as a team.)
i) Teach the scrum master in the role.
ii) Role model for the scrum master. Offer to run the daily stand-ups a couple of times, then explain to him what you did and why.
iii) Gently move the scrum master outside the circle in the daily stand-up. If team members still turn towards the ScrumMaster, move him all the way behind the speaking team member.
iv) Help the team create a pull policy.
For more information about the Team Coaching Framework™, click here >> Link
We are also starting a series of Coaching Card workshops in North America where our coaches will walk you through the process of creating a coaching card. Add yourself to the waitlist for the next workshop session >> Link