patkua@work

The intersection of technology and leadership

Page 44 of 53

Retrospective Exercise: Mr Squiggle

I’ve pondered on a question from the last Retro Gathering where someone asked how do you prompt people to tell their story by starting them with a common seed. I’ve thought about a couple of them since then, and got to run a new exercise with some people at the Calgary Mini Away Day we just had (thanks all for participating!) This exercise was inspired by the childhood TV show in Australia, of the same name (Mr Squiggle). Kids would literally send in a set of squiggles to the show to be put in front of a blackboard, where the main character, a puppet with a pencil on his nose, would turn them into complete drawings. See this link if you want to know more.

What is it: A variant of the Art Gallery exercise except using a common drawing to start the creative juices.

Time needed: 10 minutes

Mr Squiggle Template

What you need:

  • An index card per participant prepared in the same way (see below)
  • A marker pen

How to run it:

  • Before the retrospective, prepare each index card by drawing a set of symbols on it (I started with two lines and a circle)
  • Hand out the cards
  • Explain that you all have the same set of symbols and you would like everyone to spend the next five minutes turning it into a picture that represents the state of the project
  • After five minutes, ask participants to share their story with the group

Tips for facilitating Mr Squiggle

  • Ask participants to avoid writing words as this exercise is meant to be a visual, creative process.
  • Provide other colours and markers to help with the creative process.

Summarising:
Mr Squiggle brings a different take on the Art Gallery picture at demonstrating how a simple set of symbols can be converted into completely different stories when explained by participants.

When Retrospectives Go Wrong: Controlling the conversation

One of the most important points that Kerth, Larsen and Derby emphasise in their books is that the facilitator should not have an interest in the conversation. As I heard someone once say most succinctly, “If you have a point of view to share, you should not be facilitating”. This particular bad smell typically happens when this rule is violated. I’ve first hand seen this the most when a person in a naturally authoritative position (think project manager, technical or team lead) facilitates.

I remember sitting in one retrospective where the facilitator (a project manager) ran the retrospective pointing at people asking them for a single item (what went well/less well). They would often literally drill the person, asking for more details, and often commenting on their input, saying things like “that’s a pretty stupid idea”, or “you really should’ve done … instead of …” before turning around and writing it up on a flip chart. When they had finished, they decided which topics they wanted to talk about further, then returning to the group without even involving them in the decision making process. I sat, aghast, silently observing as people uncomfortably shifted in their seats wanting to get their stories out in the open yet afraid it wouldn’t go anywhere productive, and worse, be judged for it.

The result… an empty ritual, empowering a single individual, and the only outcome of no beneficial change.

Crowd Control

The above image comes from Misschelle’s Flickr stream under the Creative Common’s licence

What to do about it?
The first step is to get an independent Retrospective Facilitator. Try really hard to get one. I know that finding facilitators are easy, and finding a retrospective facilitator may be more difficult though I’m sure you’ll find the results will be much better.

If you can’t find one and you’re the one facilitating, focus on the process, and less about the content. Your goal should be to ensure everyone has an opportunity to build the shared story, everyone has an opportunity to add their insights and everyone has input into the final solution. Do not push for the solution you think is best, and do not ignore people when they have something to say. Make it clear when you are expressing an opinion as a person-with-a-stake. Empower the group with a mechanism that gives you feedback when they feel you are directing the conversation too much. Believe me, it’s hard but it’s definitely worth it.

And what about the previous situation? Continue reading

Leveraging (Technical) Debt

We all know that technical debt, in general, is one of those things best avoided. Well I’ve got a little dirty secret to share… On almost all projects I’ve worked on that I can think of, we’ve had some form of technical debt. Gasp! Shock! Horror!

The funny thing is that I think there is a time and place for certain amounts of technical debt. Similar to the financial concept of debt, leveraging (sometimes called gearing) allows you to use a certain set of resources in such a way to magnify the potential outcome. In terms of software, the outcomes you might want to achieve include meeting certain deadlines based on opportunity cost or prior customer commitments, or trying something risky in a market that will reward you (albeit potentially negatively). It is a lever you may choose to play with.

The difficult thing with software technical debt is that it’s difficult to understand the associated interest you pay with it. At least with classic financial debt, someone has already done the hard work of converting the calculated risk into a number.

So what can you do about it?

  • Start by identifying the technical debt on your project. Put this list up somewhere – on a Big Visible Wall, or a wiki shared by the team somewhere. Keep it up to date.
  • Review the items constantly. Understand their rough impact (the interest payments) and how large they are (how long it will take you to pay it back). Sometimes the difficult part is knowing how to pay it back most effectively (trade the debt for equity? trade it for a different type of debt?)
  • Pay back what you can. If it’s small amounts, it’s probably better just to get them out of the way so you can focus on paying back the larger debts.
  • Make careful choices about what you add to it. Don’t keep making short cuts all over the place as it all adds up in the end. If you add to the list, consider what benefits you’re trying to get and if it’s really worth it in the long run.

Reflecting on the 2008 Retrospective Facilitators Gathering

Every year, a group of Retrospective Facilitators gather for a small residential conference alternating between US and European borders to share, inspire and better further the retrospective practice. This year, we ran it in Radstock, located just outside of Bath, UK. As far as I know, the conference has always run using Open Space rules – the result? In this case, thirty five participants (almost 35% of them new) ran and participated in sessions throughout a week.

Recurring Topics
Similar questions returned to the community including best ways to run retrospectives across distributed locations, what to do to ensure change is long lasting, and how do people run retrospectives differently.

Lessons (Re-Learned)
The conversations at the conference reminded me of a number of lessons I’ve learned before and certainly reinforced my own thoughts. Some of these include:

  • Retrospectives aren’t just limited to What Went Well/Less Well or the Retrospective Starfish – In one open space session, the community contributed another 30 or 40 different new exercises to the fold. See the Project Retrospectives or the Agile Retrospectives book for some more ideas. Try something new! Facilitation is a difficult thing – Not everyone makes (or can be) a great facilitator. Poor facilitators will have a negative impact on retrospectives.
  • Facilitators and participation create a conflict of interest – The most ideal situation is to have an independent facilitator. Those coming from an agile community seem to run into this dilemma the most.
  • Preparing for retrospectives is essential – People don’t spend enough time working out who is the sponsor, what they want out of it, and how to design the session to meet those goals.
  • Retrospectives have many outcomes – Some of these include a common story, shared vision, and a point of change
  • Change is hard – Retrospectives play a role in change, it doesn’t guarantee it. Ensuring change happens or is sustained goes further than a retrospective.

Stories and Retrospectives
Norm wrote the original book on Project Retrospectives and intentionally focused it on telling stories. The retrospective was designed to ensure everyone has a chance to talk about their story, and also to work towards some sort of long lasting change. With heartbeat retrospectives and even project retrospectives, sometimes we don’t spend enough time on either of these aspects.

A really good model I learned that works even beyond this, and what every effective conversation is has is based on the ORID model (Objective, Reflective, Interpretive and Decisional). In many teams I’ve worked with or on mailing lists I read, I’ve noticed most statements formed in terms of only Reflective and Decisional. As an example, “I think we should do … because I feel this is wrong.” Effective conversations include all ORID aspects.

The People
I noticed the majority of people at the conference came from the agile space (of whom, seemed to label themselves as Scrum practitioners). Only a small handful of people seemed to come from outside the agile space, and in one way, I felt it diminished the conferences with many of the conversations focused around retrospectives in agile situations.

I would like to see more people practicing retrospectives who work outside of the agile space to attend to bring a different focus.

Beware the Meta Monster
Last year, I felt like something wasn’t quite perfect at the gathering and couldn’t quite place my finger on it. One metaphor that might explain it is the Meta Monster (talked about at previous gatherings). The metaphor of the Meta Monster exists when you put a bunch of experienced facilitators together. Instead of participants fully participating in each session, participants facilitate the facilitator (or at least suggest ways they would do it better). I would find it interesting to compare the gathering to a conference by the International Association of Facilitators. It’s not especially noticeable perhaps tempered by the retrospecting nature of this community. There is still something there though.

Meta Monster

Here’s my quick attempt at picturing what the meta monster might be like (made online here)

New Books to Read

  • The Art of Possibility by Rosamund Stone Zander
  • The Black Swan by Nassim Nicholas Taleb
  • The Art of Making Things Happen by Philip B. Crosby
  • The Reflective Practitioner by Donald Schon
  • The Skilled Facilitator by Roger Schon
  • Art of Focused Conversation by R Brian Stanfield
  • Difficult Conversations: How to Discuss what Matters Most by Stone, Patton, Heen & Fisher

New Links
NASAGA (http://www.nasaga.org/) – An organisation who also run a conference around simulation games

Memorable Quotes
“There is no resistance to change – just a lack of support”
“People don’t like to talk about their fears, so talk about challenges instead”

Current Reflections on the Retrospective Gathering 2008

It’s near the near the end of my second Retrospective Facilitator’s Gathering and just thought I’d post a few observations I’ve already made. I’ll write up the conference report soon enough.

It’s great to be part of a community of people that remain passionate about a tool, and in many ways, share many other passions about sharing, learning and teaching. I’ve been able to reconnect with participants I met last year, connect with many more new people and even got to spend some time with some Thoughtworks alumni.

This year’s gathering included thirty five people, just fewer than ten more than last year. It’s still small enough to build relationships with people and just the right size to still have those great conversations. We held it just outside Bath, UK this year, and if not for my current project in Calgary, I probably would have been more coherent the first two days without the jetlag.

For me, the conference has been great so far. For some reason, I look back at last year and still think that I had some much deeper conversations with people. That doesn’t at all mean I haven’t had any great conversations though. I haven’t put my finger on why just yet. The community continues to impress and re-energise my own beliefs in the usefulness of this tool, and I’m very proud to be a part of and help contribute towards growing it even more.

Expect the conference report soon enough.

Please Don’t Tell Me What I Like

Ticketmaster sent me an email this morning suggesting a concert for, apparently, “one of my favourite performers”.

Ticketmaster

They’re as far off as they could be. Much as I have a lot of respect for some of the music this artist produces, I doubt I’d ever place it on my favourite artist of all time list. Ever.

Respect for customers is really important in today’s world. Choosing what language and words you use demonstrates this. It’s even more important if you only send emails.

Amazon uses recommendations or suggestions when offering alternatives, as they know they get it wrong sometimes. At least they’re honest about it. In case you wonder, I prefer a more local site (GigsAndTours.com or Stargreen.com) for buying tickets.

When Retrospectives Go Wrong: Conflict of Interests

I heard one story recently from a colleague where a technical lead facilitated the retrospective. They’d collected sticky notes from everyone, placed them around an exercise at the front and began reading them out. The strange thing is that they read only the ones they wanted to read out, blatantly skipping many of the others.

Why the lead would only read out the ones they did, I don’t know. Perhaps they thought they were the most important (based on their point of view), perhaps they were a random selection. I’m not sure. It’s clear what impact it had on the participants. People became frustrated that they weren’t being listened to, didn’t feel appreciated for their input, and I’m sure many of them felt the activity a waste of time. Apparently it broke down to the point where they started shouting out for the lead to read out the notes.

Tug of War

Image taken from TimmyGUNZ’s Flickr photo stream under the Creative Commons licence.

What to do about it?
Kerth emphasises getting an independent facilitator (though versed in the industry) to run your retrospective. From experience I know this to be difficult for heartbeat retrospectives. If so, people who have direct significant influence (i.e. typically project managers, technical or team leads) either shouldn’t facilitate, or be extremely aware of this conflict of interests and do something about it.

I’ve learned it’s important to be clear which, of your roles, you represent when you say something. Something like, “With my technical lead hat on, I’m wary of this suggestion because of …” Another technique is to accept you will be biased and ask the group to raise a flag you when they don’t feel you’re being neutral. If you see the flag, you must do something about it.

Concluding Thoughts
Facilitation is not for everyone. Participants and facilitators should understand where conflicts of interest lie and how it may affect some of the conversations. Mitigate for this by planning to have an independent facilitator or by putting another system in place to prevent these biases creeping in.

Why XP is the most popular agile methodology

XP, like many of its waterfall breathen makes it easy to follow. It caters to those people in the Shu phase of learning. It’s easy to follow and it’s easy to get wrong without guidance. It provides a set of values and principles as well as a set of practices to help you achieve them. It’s probably less useful for people in the Ha or the Ri phases of learning.

I don’t want to criticise XP since there’s plenty of material already out there about for that. Rather, I want people to understand where it fits in. I thank the XP community for showing us how practices help to bridge the gap between principles and values as well as showing us that simply focusing on practices (or one approach) proves limiting. I also want to emphasise that XP’s practices aren’t the only way of doing this. The fact that XP works for beginners is both its strength and weakness.

As an agile coach, I often use different sets of practices to help bridge people into the other phases that brings more awareness and thought into everday processes. After all, part of respecting people is understanding each of their specific needs.

A state of mind

I was reminded today of a simple principle, especially when working in new environments and with new people to, “Keep an open mind”. Easy to say, yet first hand observation of others seems to imply it’s hard to do. I’ve seen a lot of people come into a new environment, judge a situation and state an outcome.

They share nothing about what they are concerned about, what they observed, and why they reached the conclusions they did. It’s no wonder that people can’t relate to the outcome immediately. Keeping an open mind helps to resolve jumping to solutions too early. Better yet, sharing your mind and the process you went through helps others to relate to you and for you to realise if you got any of it wrong.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑