ACG2010 - Afternoon sessions

I decided to combine the following two because I do not have a lot on them. I started the slot in the first one but ended it in the second so I hope the notes I have can be useful.

The first session was “Game-sense approach to coaching” and was initiated by Steve Tooke. Also present were Matt Wynne, Patrick Kua, Enrique, Dave Harvey and The Bus – the latter being the main reason I changed sessions because I could hardly hear what people were saying.

The idea behind this session as far as I understood it was to link the coaching approach in for example coaching a Rugby team to working the same way with software development teams. Developing people’s skills while playing a game and developing a situational awareness. We tend to do coaching as part of the game in software development but in rugby for example you coach prior to the game. So we do not get opportunities to coach – we’re expected to help the team improve while they deliver. One suggestion to introduce practices is to start with a simple games and add more rules as you go.

At this point I left unfortunately even though the topic was very interesting..
And I joined Dadi’s session on Solutions Focused (Agile) Coaching. I believe it was inspired by a book “The Solution Focus – making coaching & change simple” by Paul Jackson & Mark McKergow

What is wanted?
Vs.
What is lacking?

We’re here to help teams improve. Not sharing info for solutions you know about is negligent – e.g. If the team identifies that there is not enough testing they may decide that the solution is to introduce more test engineers while you may know that TDD/BDD approach is an alternative solution.

Once again the issue about retro items becoming sprint backlog items came up. Makes you (and the team) think how much needs/can change.

Somebody asked if there really is one approach to everything? A tool perhaps is not always applicable. But this approach can be used for the definition of Done- e.g. What will satisfy you that you’ve done a good job?

This approach is also good for solving a problem perhaps not generally making the team better.

I made a reference to a book “Discussing the Undiscussable” by William R. Noonan