Many people are now moving into agile coach roles and looking for ways to improve their skills. In response to this demand, I've developed an Agile Coaching Skills workshop aimed at practicing agile coaches, to compliment my "Agile Coaching" book. If you're interested, the next public workshops are in London on September 15th and Belgium on 17th.
Training can give us a boost but there are still gaps to be filled as we grow into a new role. We need a way for agile coaches to support their ongoing learning without relying on trainers (who are few and far between). Agile Coach Camps and Gatherings provide another great opportunity for agile coaches to get together on a weekend to explore ways to improve their practice and network with other agile coaches but these events tend to be months apart.
Over the years, I've got a lot of help from London's eXtreme Tuesday Club so I know that there's great value in talking through the problems I face as a coach with other coaches more frequently. However, getting together for an evening pub chat is often a bit hit and miss. We need to create a safe place to practice coaching that exposes budding coaches to different coaching styles.
So I've been experimenting with a new format that can be used by groups of agile coaches to support learning from their peers. It's inspired by the popular Coding Dojo format used by coders.
What's a Coding Dojo?
A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in deliberate practice in order to improve their skills, by coding in front of others. You can find out lots more at, http://codingdojo.org/
There are coding dojos run all around the world rather like local user groups. The coding dojo format has also been adopted within companies for groups of interested developers to learn together.
I've seen coding dojos particularly useful where the team is not using Java or C# and can't get off-the-shelf training in agile practices like Test-Driven Development and Refactoring.
How might this translate to an Agile Coaches Dojo?
Agile coaches work with people rather than computers. So unlike a coding dojo, we don't need to setup laptop computers or a projector to run an agile coaches dojo. A coding dojo simply needs a circle of chairs for the participants.
I tried out my first Agile Coaches Dojo at Agile Open Holland - here's a photo of one of the groups so you can see the setup we used. Basically, splitting the group into circles of 4-6 people.
The other big difference is that coding dojos require participants to prepare for a "kata" on a programming challenge. Here's an example: Write a program that solves word chain puzzles (cat -> cot -> dot -> dog). You can find more example kata at pragmatic Dave Thomas's Code Kata and the Kata Catalogue maintained by Emily Bache.
Coding dojos focus on the pattern of choreographed steps you take towards creating an elegant solution. Coaching dojos would focus on the same thing. The "how" aspects of what we do as coaches, such as what questions we ask and how we work with the person to help them solve the problem.
What would a kata look like for an agile coach? Well, part of the art of agile coaching is to explore a problem domain with a person (rather than a computer). I could probably create a catalog of canned challenges based on my own experience that might be used as coaching katas. Where I would struggle is how to share enough context for a coach to work on those challenges. So in the Agile Coaches Dojos I've run, we have based the coaching kata on real challenges that the participants had experienced. This enables us to explore live situations with the person who needs coaching help. Here's an example of a challenge faced by an agile coach in her own words.
For Agile2010 conference, I added a demo round where I presented a challenge and two experienced coaches took turns to coach me towards finding a solution. Thanks to David Hussman and Dave Rooney for helping me out with this.
Although I've seen a number of conference sessions for agile coaches based on triads of coach/coachee/observer. I deliberately wanted to break out of this grouping so that people in the circle could see different coaching styles demonstrated (as in a coding dojo). I also prefer to call the person who presents a coaching challenge a Seeker rather than coachee. There's something about the word coachee that bothers me, seems to me like a passive recipient of coaching rather than an active player in the situation. You can download my Agile 2010 slides for some more detailed instructions on the timings we used.
The Agile2010 session got very positive feedback and lots of ideas on how to improve the format. More time would have allowed us to try multiple rounds and also to rotate roles. Some structured sheets for things that observers could look for might also be useful.
Some of my favorite comments from the feedback forms:
- "I was a guinea pig and I liked it."
- "It gave me very concrete ideas for organizing similar dojos in my area. I want to do this more!"
- "excellent session I want to bring it back home."
- "You did teach people to listen. Thanks for that."
My only worry about the idea of an Agile Coaches Dojo is that using Japanese nomenclature will obfuscate the intent of the agile coaches dojo, which is: to create a safe place for agile coaches to practice and be exposed to different coaching styles.
I want to encourage people to experiment with the format (like programmers have done with coding dojos) and so I will be interested in hearing what's worked for you. So please post comments about that, when you've tried an Agile Coaches Dojo in your area.