Michael Feathers of ObjectMentor led a three-hour workshop, “Coaching Software Development Teams”.
If you’re after a quick fix, jump straight to Michael’s patterns below.
The Nature of Coaching
Discussion prompted by definition of coaching as causing change. Coaching in the business community is more about fostering change, like counselling - don’t have to have the business knowledge. In IT, tends to be more about leading, provoking on design, etc. Is the coach part of team? In XP, yes; a bit like a sport coach, usually a player as well.
Coaching and Human Behaviour/Psychology
Coaching must build on model of human behaviour. “Agile about people, but people and human behaviour not often talked about”. Also, we rarely talk about whether people want to be working - many people treat it as “just a job”, don’t want to devote too much mental effort. Age and lifestyle effects too.
Stereotyping
Stereotyping and pigeonholing people was a major theme of this workshop.
Important to avoid stereotyping, try understanding reasons for behaviour. Two problems with stereotyping:
- Warp the team’s perspective on someone - an individual becomes “the guy who can’t write test code”, etc.
- Can be a self-fulfilling prophecy…people will see themselves according to the label and act accordingly. [Cognitive dissonance?]
Role-playing stereotypes exercise.
Being aware of emotions
Some research indicates men tend to be less capable of reading emotions, and this is probably even more true for software developers. Due to selection bias or reinforcement or both? Don’t know. But if that’s the case for a coach, then the coach needs to be aware of blind spots.
Seeing the group as an individual
Groups tend to act as a whole. Every class has its own personality. So it can be interesting to anthropomorphise the entire team as an individual, although Michael admits that this is a bit funky, not something that will resonate with everyone. A participant mentioned that when people leave, others ends up filling the same role. Which is interesting if true, because certain ways of doing things are systemic. This indicates firing someone for not being part of the team may not solve a problem because someone else might solve the problem.
Understanding motivations
Listed motivations for working in software - about 15 of them (achievement, money, learning, etc.)
How can such a model be used?
-
Understand impact on interventions. Point about agile is how it topples some of those, e.g. people’s sense of prestige and status can be destroyed if they feel like they’re just another coder again.
-
Hiring strategies. Michael observed that greater companies devote much greater care to hiring people, to ensure they fit in. They don’t just focus on the technical side, look more at collaboration skills. A participant noted this can be a problem for companies in growth phase - companies hiring too quickly often end up with different types of people.
Learning and Tension
See Ward’s Cunningham’s “Episodes” pattern language (especially the graph, apparently not online). Tension can be a tool. Ideally, let people learn the lesson themselves by resolving tension. So creating that tension, in the right way, can be good. Coaches should learn to feel the tension in the room, helps them find the right level.
Ethical Questions on Coaching
Should manipulations be conducted? Above board? One view, to paraphrase Kent
Beck, is that manipulation is when you wouldn't get the same effect if you
were upfront about the intervention. Or is there an issue about the coach
seeing themselves as more experienced, qualified, etc. Should they use that
knowledge to encourage someone to do something they wouldn't normally do,
because they see the genuine benefit? And the person may see the benefit in
hindsight, but not upfront. (Here I'm thinking the Karate Kid snatching flies
with chopsticks.) Ultimately, the distinction may come down to respect: a
care for the individuals and the outcome.
One view: Sometimes, it’s simply not possible to explain why we’re doing everything in advance. People can only learn some things by doing.
Michael presented these patterns towards the end. Note: I missed a couple of these patterns!
**Go Sideways:** Look at another problem completely. Usually people are still
working on it in their background.
**Go Home:** Just stop working on it - go get some water, etc. We all have
experiences of the answer coming to us in the shower, while jogging, etc. So
can be good if team members are able to suggest taking
**Antennae Up:** Develop a sensitivity for what's happening. Focusing on the
human side. ** Gerald Weinberg: when called in for what's perceived as a technical
problem, it's usually a people problem. Participant: Can be useful to
keep a diary to order your thoughts, and even better to discuss it with
others. Writing is good for looking at things analytically.
**Pair Coaching:** Discuss with someone who knows the team. Can check
observations before acting.
**Ask the Room:** Encourage team to think hard when they feel like they need
to break a rule that's been adopted.
**Active Listening:** With minimal judgment. When it's not recognised,
*resistance* has been identified. Participants mentioned the virtues of
paraphrasing what's been said, and this can overcome listening based on the
stereotype. Also, it's about checking your own understanding. Sometimes,
coaches can have a great technical theory in the head, but the developer has
a real code that doesn't fit the textbook.
**Advance/Retreat:** Judiciously retreating from helping someone with a
problem and helping them take control of the problem themselves;
**Tending 'Pat':** If this team was a person, what would the person be right
now? Is Pat tired? Scared, relaxed?
**Personal Encouragement/Discouragement:** Most coaching is one-on-one.
"Know the person, know the feeling, feel it first, address." Will often be
wrong, but better preparation. Someone also mentioned getting beyond the
technical issues.
**The 'Flounce':** Identifying the elephant in the room (i.e. a big issue
no-one wants to talk about). Pointed questions, soliciting comments, ending
with silence ... and suddenly a stark, emotional, assessment of the problem.
Then "leave" the conversation (probably stay there, but quieten down and
withdraw in body language, etc.) Again, quite idiosyncratic (Used by a
former colleague of Michael. Sounds very dramatic!) The intention is to open
the floodgates and let people discuss it openly among themselves.
**Team Surgery:** Perform surgery on 'Pat'. Can be difficult due to politics,
etc. Adding a person forces the greatest change.
**Push in the Water:** Sometimes have to ask people to confront their fears
and go beyond their limits.
**Self-Disintermediation:** Works well with Tension-Release. Encourage
people to help each other rather than go to the leader. Someone noted it's
difficult for consultants, because no-one wants to pay them anymore. (Maybe
that's why it doesn't happen so often - people like to see big
interventions.)
**Cheerleading:** Not necessarily overt, but identifying what's gone well,
which means relating back to goals.
**Cultivate Respect:** Sometimes people develop intimacy by complaining
about others. Coach's reaction makes a big difference.
