Day 0.5 of Agile Coach Camp US – Games Day

It’s lunchtime at ACCUS Games Day. Tobias Mayer warmed us up with some exercises that involved the whole group (60 – 70 people!) One was doing a “failure bow”, similar to the Language Hunters “How Fascinating!” If you feel you failed, raise your hands in a victory pose and shout out something happy. We will be doing this all weekend, I am sure!

One interesting insight came from comments on the enemy-shield/friend game. Often, a ScrumMaster or manager feels their role is to “protect” the team. Tobias noted that we are all adults and can protect ourselves. That made me think. I think our manager sometimes tries to protect us from the bureaucracy and silliness of our new parent company, with the best intentions, but I think sometimes that backfires. For example, if a manager proposes some half-arsed technical implementation for something the parent company wants, thinking it will reduce pressure on us and save us time, that isn’t really helping us. Better to let us be told directly about the business problem to be solved, then let us find the right way to solve it.

I tweeted that quote (really a paraphrase), and several people disagreed, saying that development teams may need protection from undue outside or management pressures. That’s valid. When my team first transitioned to agile, our manager convinced the business executives to let us have all the time we needed to learn good ways to develop software. Practices such as TDD are hard, and if you’re pressured to deliver, you won’t take the time needed to master them. If you’re punished for failures, you won’t experiment. So there is definitely a place for some protection of the team. Conversely, nobody should inhibit good communication between the development team and the customer team.

Coaching Skills Dojo

There were five track sessions to choose from after the warm-up, and it was hard to choose, but I went with Michael Sahota’s coaching skills dojo. This was a great chance to practice coaching, and learn by observing others and by playing the role of the client.

We started out by identifying observation, listening and questioning skills that coaches need. Then we took turns playing client, coach and observer. When playing client, we used real problems that we have. We had 20 minute sessions with five minutes for each ‘turn’, then five minutes of debrief.

I feel my coaching skills are lacking, so I was fearful of this, but knowing I could use the “failure bow” gave me courage to take risks. It is so interesting to ask good questions, use appropriate body language, listen and observe well to help a client understand his problem and think of possible experiments to solve it. I have takeaways both in terms of coaching skills – I shouldn’t be afraid, I do have the skills, I need to remember and listen more, and help the client clarify the problem – and on what I learned from being coached on actual problems!

This afternoon, there are three timeslots, each has five sessions. So many choices, so little time! I’m looking forward to learning some new games, honing my coaching skills, and also getting help developing my own game to help testers and developers learn to communicate and collaborate better.