Category: XP2011

Coaching Tool: Me We Us

Short Description: A facilitation technique (e.g. for retrospectives) or also for planning that helps the quieter people to also come up with ideas.

Original source: Facilitation training by Grape People.

Example Use:
Questions are prepared by facilitators. Three different rounds

  1. Me – Everyone writes down answers for him/herself using sticky notes
  2. We – Discussing with your neighbour and answers refined
  3. Us – Combine all issues into one big chart

Contributed from the participants of my XP2011 workshop

Coaching Tool: Circle of Questions

See Doc List’s original post.

Gets everyone involved. People understand better by explaining. It’s really about learning by teaching. Generative thinking. Works well if you go around twice. Widely applicable. Can be used for almost anything. Makes a non-talkative group more talkative.

Enforce the circle. One person at a time and use a talking stick/token. Egg timers work well for Italian and Spanish groups. The more challenge the team has to stay on time, the more rituals need to be introduced/enforced.

Contributed from the participants of my XP2011 workshop

Coaching Tool: The High Performance Tree

Short Description: A way to create a metaphor that reminds the team of the holistic view of the team

Original Source: Looks like it’s here.

Example Use:
Labelling the expected fruits, very useful when a team has the fundamentals but could be better. Used as a roadmap to move towards higher performances. Shows that many practices are rooted in values.

Doesn’t always work. Some people don’t connect to the metaphor. In that case, the technique should be dropped. Can be used in open spaces to show the value streams, etc.

Potential Variants:
Garden or orchard -> organic seems to work better than mechanic. Allows you to talk about the weeds

Contributed from the participants of my XP2011 workshop

Coaching Tool: 7 x 7 x 7

Short Description: What I’m doing in the next seven hours, next seven days, seven weeks put onto a board

Example use
Introduction of yourself as a coach, and used to articulate what the coach does in flip chart using visual information. Set up a board with three columns with the title “7 Hours”, “7 Days”, “7 Weeks” and add activities to demonstrate what you’re doing.

Contributed from the participants of my XP2011 workshop

Coaching Tool: GROW

GROW stands for Goals, Reality, Options, Will/Way Forward. This is quite a well known coaching tool that even has it’s own wiki page.

Contributed from the participants of my XP2011 workshop.

Coaching Tool: Coaching DOJO

Short Description:Group of people getting together and coaching each other potentially using GROW model. Use short rounds with time limits.

How to run it

  • Seeker (a role that rotates) shares the problem with 2 other coaches and 2 other observers watching. Time boxed to 5 minutes.
  • 2 coaches comment in an active coaching role. Time boxed to 10 minutes
  • 2 observers then comment about the interactions. Time boxed to 10 minutes.

Original Source:
Sergey Dimiticus in Oslo and Rachel Davies

Where it’s been used
In agile coaching camps, learning together to generate coaching ideas and developing coaching skills.

Contributed from the participants of my XP2011 workshop

Summary of XP2011

First full day of XP2011 was a pretty full schedule as I had to prepare for two lightning talks on different subjects. Fortunately both of the topics were very close to my heart, one about learning using the Dreyfus Model (slides) and the other about Systems Thinking (slides). The second day started off with a great breakfast selection at the conference hotel before kicking into the keynote by Esther Derby. Clearly jetlagged, Derby used a set of hand drawn slides to explain her topic, “No Silver Bullets”.

Her presentation style was very conversational and I can’t say that the crowd responded very well to this. Perhaps it was their jetlag as well, or the way the room had been set up. Nevertheless, through many of her stories, I still saw many heads nodding and a really great response on twitter to the things that she was saying.

I’ve followed Derby’s writing for years and could only wish more people would be exposed to them. As a result, I found many of the topics and opinions I found interesting reinforced, such as failing to address the management layer inevitably means agile adoption hits a hard ceiling. Or the oscillating behaviour that results when managers attempt to react to a system with long delays in its feedback cycle. I appreciated the very vivid term, “Bang! Bang!”-management style describing the style of managers who seem to have only two distinct and opposing reactions to a system, unable to moderate their use and wait for systems to find a new equilibrium. If you imagine these two opposing reactions the result of a huge iron lever being flipped, hopefully you can imagine where the noise comes from.

Derby covered lots of different areas, quoting a few people like Donella H Meadows, “The original purpose of hierarchies was to serve the sub systems, not the other way around.” And the work that George Lakoff does with word association with metaphors in our everyday use. Raising self awareness of your own in built biases and metaphors is another key thing she emphasised focusing on the judgements, habits, feelings, thoughts, mental models, beliefs, rules and values we tend to be intrinsically governed by. I particularly liked the phrase she uses to help people uncover their own and others’ mental models, “In what world would this make sense?”

She told one great story about the dangers of measurements as targets, using the example of the manager who decided to “Grade developer estimates”. This manager decided to give A’s to those who estimated on time, B’s to those who estimated over time, and C’s to those who estimated under time. Of course, you can imagine what magically happened as people’s grades mysteriously improved.

She also reminded me of the work of Ackoff, who I need to revisit, and the great work that he’s written about Systems Thinking. I have only been able to refer to the Fifth Discipline as a Systems Thinking book, but I really need to read his other ones to see if they would be of use, or are more accessible.

The rest of the day was a bit of a blur. A couple of highlights included seeing Marcus Ahnve take the work Luca Grulla and Brian Blignaut did with TDDing javascript to the next level and doing a demo of BDD.

David J. Anderson also reminded me of the importance to think in terms of the languages executives speak in order to better get our message across. He reminded me of all the great things that Ross Pettit has to say, although I think Anderson’s analysis on accounting for software development costs doesn’t seem to match with some of the data I’ve heard from Pettit.

There was so much more to the conference. Always the way great conversations emerged and the wonderful atmosphere of the hotel adding to the uniqueness to this event.

What’s in your coaching backpack?

This morning I facilitated a coaching workshop at XP2011 called, “What’s in your coaching backpack?” It was a four hour workshop, so lots of time to go into detail. I designed this workshop to focus more on depth than breadth for the four hours. After some introductions to the purpose and format of the workshop, I got everyone to move into groups and spend some time introducing themselves to each other. In these groups, we spent some time focusing on brainstorming various coaching tools, models and techniques and we came up with a huge variety. I’ll get around to writing each one of these up (there’s quite a lot of detail) so look out for them in future blog posts. Our coaching backpacks are now much fuller than what they were before.

After a break, we then reconvened and I asked people to focus on some case studies of some coaching situations where, in their groups, using the coaching tools to articulate how they’d approach each situation. There were some really great conversations and discussions, where I hope people got a better feeling trying to see how others might apply different techniques to the situation. Having been grounded in real world experience, people also wanted to know what did happen (even though there aren’t any correct answers to case studies).

I also had a quite mini retrospective, asking the questions, “What you enjoyed about the session?” and “Suggestions for improvement?” I had some great feedback and wanted to put it on line:

  • Like – Practices and real examples, discussion and division to groups, Scrum board or presentation agenda
  • Great format, loved the taskboard, posting on wall “backpacks”, case studies
  • Good group size, great group
  • Really well facilitated
  • Interesting content generated by the open conversations
  • Sitting in the sun was AWESOME!
  • Great opportunity to discuss different approaches to coaching and agile
  • Like the idea of showing progress of the workshop at the scrum board using tasks
  • Case studies/real life examples always interesting
  • Good, clear setup with backlog
  • This was the session I got more out for my work/myself than any other session 🙂
  • The workshop format
  • Working in small teams, all adding different perspectives
  • Sun
  • Nice with practices and your communications
  • Your excellent preparation and light-weight facilitation
  • Small groups
  • Interesting case studies
  • Exchange of ideas
  • Case study
  • Very well organised and structured
  • Good atmosphere, positive energy
  • The case study discussions
  • Living whiteboard agenda
  • Maybe switching up the teams between case studies might reduce effect of powerful personalities
  • Rotate members in tables to get more ideas?
  • Suggest you split groups with the knowledge spread more evenly – you asked experience and could have used that info
  • Same team all he time. Maybe we could have shuffled people in the middle of the session
  • Changing teams after a while (e.g. at lunchtime if in for whole day)
  • I could even have a whole day of doing this without being bored
  • More practises and making the descriptions of “methods” out from this
  • Produce example tool(s)
  • Put all coaches tool/methods together and have a global short discussion
  • Common discussion about the good practices
  • Would have liked to hear/learn more about coaching techniques
  • Would have been nice with an introduction to the methods/worksheet part to get the flowing associations
  • A conclusions panel to write the achieved results

Notes from Michael Feathers’ Brutal Refactoring

Here’s my notes from the four hour workshop by Michael Feathers on Brutal Refactoring. I’m trading off timely information for something that probably could be more succinct or polished with a bit more time.

Michael opened with the discussion on what is Clean Code versus Understandable Code, and why each is important. He makes the point, using some good examples from different languages, we can live with understandable code, and there is a cost to having Clean Code, particularly when you have it. He explained it through good relationship with Behavioural Economics, taking about how the incentives for people maybe aren’t quite set up right.

He asked a question, “Is it easier for people to add code to existing place than to create a new method/class/etc? Why?” It’s a good analogy, and something that you even seasoned, diligent programmers often fall foul when working in small increments.

There were some further good discussions about “Understandable” being contextual. Such as, a C++ macro might seem “magic” to non C++ users, but could be quite familiar. This remind me of the learning curve, my former colleague Dan North is going through with Rails at the moment. A nice reflection on some messages I talk about in my “Beginner’s Mind” talk.

Anyway, back to the tutorial. Feathers says, “We should’t be surprised by very large methods. incentives are set up wrongly. Though not sure what we can do about it.” He further acknowledged it wasn’t a “bad coder’s” action, but a systemic effect, “It’s the result of the system between us and the code.” I think this is quite important to note because I think the social system that software development occurs in is important as to what code you get up. For example, when you build teams, having an agreed code standard and consistent technical direction is essential into setting up a different system that incentivises different behaviour. If you know you’ll need to come back to something, and change it, you’ll want to leave it in a good state. If you want the respect of your peers, you’ll want to leave it in a good state.

Feathers then talked about some great visualisations he’s been working on. He’d get on great with many of my colleagues, particularly Erik Dörnenburg who loves to champion this sort of stuff. I agree when Feathers says, “Code has a particular shape,” when you’re looking at a particular system.

Feathers than covered a good deal of stuff as shown in the Mind Map. I have some rough notes.

Feature Clustering

  • Listing out features and looking for commonality. Sometimes you look for common arguments across classes/methods. Sometimes it’s about common data (Data Clumps as Fowler talks about in his book).
  • Look for Locality of information (or encapsulation in OO talk)

Rapid Scratch Refactoring

  • A bit of regret not focusing more of it in his book.
  • You learn a lot my attempting stuff out and then seeing, “What could be?”
  • Some discussions on the danger of making these too much of a big leap and never reaching for it. (Just another reinforcement about clear vision and essential leadership to keep people heading in the right direction”
  • I found it interesting he liked to do it in a plain text editor instead of an IDE. Feathers talked about the distractions of syntax highlighting. I find that I learn a lot more information (and can try things out faster with an IDE like IntelliJ or Resharper)

Twisting Classes

  • Breaking down a class based on use rather than adding more
  • Step by step process of creating a new role (via interface or superclass and using that in a consumer rather than the original)
  • Feathers recommends a very riguourous command query separation

There’s lots of other small gems included. Some notable tweets worth saving:

  • “Branches often biggest impediment to refactoring in large orgs.”
  • “Narrowing scopes: often we gain leverage by moving temporary variables coser to their points of first use”