Posts Tagged ‘retrospectives’

6hatsThis is my take on using “Six Thinking Hats” to reflect on a period of time. You could use a light version for a retro – or the full version to review something longer like the stage of a project or a release. It’s usually most effective after some milestone event and where the learnings can be applied going forward. There is still value in doing it at the end of a project, but what you get out of it for future teams may not be as valuable as you won’t always know what will be applicable.

Preparation

In order to save time in the session, you do need to do a fair bit of preparation. Try and collect as many facts about the time period as you possibly can before the session. Facts are anything backed by data and some common “facts” one might include are:
– Team changes (people joining/leaving)
– Events (e.g. release dates)
– Sprint information (velocity; commitment; actuals; sprint goal; etc.)
– Changes in process
– Special workshops or meetings
– Any data provided by metrics

I’ve found the most effective way to use the facts in the session (and the rest of my post assumes you have done this) is to map them onto a really large timeline. I typically use a sequence of flip chart pages that can be laid out so that attendees can literally “walk the line”. I’ve stuck them up on long walls or laid them out on a row of tables and even used the floor where I needed to.

It is also useful (for the reflectors in the team) to send out a description of the hats in advance and ask them to think about each one before the session.

Before you start your workshop, you have to set up the room (also see the tips at the end of this post):

  1. Lay out your timeline
  2. Ensure there is space for people to easily walk along it
  3. Have various stationary points along the timeline with pens and stickies
  4. Don’t forget to have a whiteboard or some other space for grouping the ideas

Materials

Besides your “timeline” of Facts, you will also need:

  • Small pieces of paper that people can write appreciations on
  • Pens
  • Stickies: one colour per hat
  • *Optional* Snacks

For the different hats, I usually use the following colours

  • Facts: N/A (people write directly on the timeline)
  • Instincts: Red
  • Discernment: Blue
  • Positives: Yellow
  • Ideas: Green

Process

The process I follow is largely based on this one and, as they mention, I have found that the order is fairly important.

For an average team, I time-box each section to about 10 minutes. Breaks need to be at least 5 minutes, but could vary depending on the time of the day (e.g. you may need a lunch break). If you are going to use the data in the session to come up with actions and improvements, then your time-box for that part will depend on what technique you plan on using. Obviously these may need to be adjusted based on the size of the group, but as most of the steps are self-paced, one advantage of this workshop is that it works quite well with larger groups.

Round 1: Facts

Have the attendees “walk the line” from the beginning to the end. This is a walk down memory lane and also a chance to fill in any blanks and ensure everyone agrees that the facts are correct. There are no stickies for this step – if people want to add or change anything they do that by writing directly onto the timeline (at the right point in time, of course). Remember to remind everyone that they should only be adding facts.

Round 2: Instincts

“Gut Feel”

Hand out your “instinct” stickies. Remind every one of the definition of an “instinct”. I sometimes skip this round because people struggle to differentiate between “instincts” and “positives/negatives”.

Appreciations and Break

Give everyone a chance to write appreciations (these will be shared later – either at the end of the session or afterwards). It’s also a good point to have a short break.

Round 3: Discernment

“Devil’s Advocate”

Make sure you’ve collected the “instinct” stickies and that the next colour of stickies is available. Remind everyone what the definition of “discernment” is. Everyone repeats their walk of the timeline, this time adding stickies to the timeline for things that didn’t go well or were disappointments.

Cool off

Have another break (in case things got emotional). Have people write more appreciations.

Round 4: Positives

“Keep doing this”

This is the last walk of the timeline. Again, remind people of the definition of “positives” and ensure there are only “positive” stickies lying around for people to use. They walk the timeline one final time and add stickies for things that went well.

Lastly: Ideas

“If I did it again”

There are various ways to capture and categorise ideas. The intention of this round is that attendees use the timeline to stimulate their thinking of how they could have done things better. Or how they would do things differently if they had to do it again. This is  sometimes also described as “green fields” thinking.

And then (now or later)…

If you were using this technique for a retrospective, you would ideally get actions from the information as part of your session. If the session was to reflect on a project, perhaps the data would be grouped into things like “Good ways to kick off” and shared with other teams. I’m quite a fan of the quadrant method of grouping similar stickies to find topics to address (see photos below for examples from a retrospective I did). What you do next all depends on the ultimate purpose of your session.

quadrants

Tips

  • Only let the attendees have access to the writing materials relevant for the round i.e. gather up the stickies from the previous round and “change colours” for the next round.
  • Have a number of “stationary points” – so that people can grab stickies and pens as soon as they have a thought.
  • Related to the above, have an excess of stationary and pens so people don’t have to wait for each other.
  • When preparing your timeline, try use pictures/symbols/colours to create visual patterns and cues for repeat facts e.g. document your sprint information in the same colour and layout for every sprint on the timeline or have a bug symbol where you have added statistics around bugs.
  • Don’t forget to share the appreciations! Especially if you’ve decided not to do so in the session.

I have applied this technique a couple of times and used the output for various things:

  1. We’ve used it to gather data for a team which was unfortunately not very transparent and then used that data to paint a “real picture” for external stakeholders.
  2. We’ve used it in retrospectives to identify improvements to team / process / products.
  3. We’ve used it at the end of a project to create guidelines and lessons learned for future projects and teams.

timeline

Have you used this technique before? What worked or did not work for you? Where might this approach be useful?

Advertisements

chasm1I’m currently a member of a coaching circle and our topic last week was “Non co-located or distributed teams”. Then this week someone from our marketing department approached me. We’ve decided to bring our public website in-house and they need a new team, but history has shown us that finding new developers of the calibre we want is no easy feat. One option we haven’t explored to date is developers who work remotely (which would mean we could look farther afield) and he wanted to know what my opinions were. I offered to compile some information for him, including some of the conclusions from my coaching circle discussion, and then figured it was worth adding it to my blog too.

I have worked in distributed teams before – from formal project teams with developers on-site in Cape Town working with off-site analysts, testers and project managers in London; to informal ‘leadership’ teams across offices over three locations and two countries; to performance managing direct reports working in an office 2000 km away. The common point of success or failure every time? The people on the team. The next biggest point of frustration every time? The type and quality of communication tools available.

People

There is a lot of literature out there around the types of behaviours you want in agile team members and, obviously, each company also has its own set of values and culture it looks for in new hires. This list is a list of traits that stood out for me as things that made someone great to collaborate with when working in a distributed fashion. All too often, people without these traits made distributed collaboration quite difficult and sometimes impossible!

  • Emotional maturity – able to communicate without getting emotional about things; can handle openness.
  • Strong team norms – when the team agrees to try something or work in a particular way, this person will take accountability for whatever they have to do even if it wasn’t their preferred way of doing things
  • Effective communication – verbal and written. Can write and read well. Can get their point across and summarise well.
  • Takes responsibility for preparation – if things are distributed beforehand for people to read or prepare, then this work is done. Doesn’t walk into meetings “blind”.
  • Knows how to use tools and knows about conference call etiquette (this could be covered as training for the whole team).
  • Is proactive in staying ‘in the loop’ – will ask questions if they see something that they don’t know about (defaults to information gathering rather than assuming if it was important enough someone would let them know).
  • A T-shaped person – or at least someone who is prepared to do tasks that are not ‘part of their job description’

 

Other Success Factors

This list was compiled by my coaching circle:

  1. Face-to-face is necessary for initial trust building and to create coherence. Where possible, having everyone co-located for a period at the start of the project makes a huge difference. Also gets people used to the way others work without the ‘noise’ of not being co-located.
  2. Would be helpful to find ways to have online virtual interaction (outside of work) e.g. online games/ice breakers/other experiences.
  3. Face-to-face tools are a must.
  4. After an extended period, it helps to have team members ‘rotate’ as traveling ambassadors.
  5. Need to understand cultural differences. Probably worth having a facilitated session to highlight/understand these.
  6. If you have teams working in areas, then have an on-site SM/coach per team.
  7. Keep teams small.
  8. Try pair/collaborate with an offsite person as often as possible.
  9. If you have teams in different locations, have a dedicated facilitator in each location for meetings (like planning, review).

CoherenceCulture

Links

What has your experience been with working in or with distributed teams? What did and did not work for you?

Happy

A great thing happened today: my team took control of their retrospective!

I arrived to a white board with a proposed agenda already laid out. As it had all the necessary components (check-in, fact gathering, and actions), I encouraged the team to run with it and all I did is help the team nominated facilitator steer the group back on track at times. It was great! There was a lot of open conversation and it was nice to have the team members driving themselves towards the outcomes. Considering where they were 4-6 sprints ago, it’s also a lovely sign of just how far they have come as a team.

StoriesThis photo is the list of actions/changes/learnings one of my teams came up with in their most recent retrospective. This did not come from someone who went on training or read an article. It also didn’t come from a new Agile coach or Scrum Master. It came from them missing their sprint commitment and goal. This team only managed (on paper) to complete 8 out of 18 points; but they all knew they had delivered and learned a lot more than that measure reflected.  Here are some things that they decided to do going forward:

1. If the team cannot reach consensus about the size of a story, then split it into two stories and size the smaller stories

One of the main reasons the team had such a poor burn-down is that they took in one quite large story which did not quite meet the INVEST requirements. For one, it was a ‘common component’ that was to be used in most of the later stories (so not independent). It also was not small enough – and turned out to be even bigger than the team had thought. During sizing, there had been some debate about its size and eventually reluctant consensus was to make it the smaller size. Turns out the less optimistic team members were right. This was one of the stories that was not done at the end of the sprint.

2. Keep Planning II – and use it to verify the sprint commitment

This is a team that often decides to skip Planning II (I don’t like it, but ultimately it is the team’s decision and so far we’ve muddled along without it). For this sprint, they decided that they did need a session to unpack the stories and how they would be implemented. Everyone agreed that without Planning II we would have been even worse off. They also realised that at the end of Planning II, there were already some red flags that the big story was bigger than everyone had thought and they could have flagged,  at that point, that the commitment for the sprint was optimistic. The team agreed that, in future, if going into the detail during Planning II revealed some mistaken assumptions, then the team would review the sprint commitment with the Product Owner before kicking off the sprint.

3. Feel free to review story-splits in-sprint

Early in the sprint, the team were already aware that the big story was very big and probably could be split into smaller components. Their assumption was that this wasn’t possible once the sprint had started. For me, re-visiting a story split mid-sprint or once you start the work is not a bad thing: sometimes you don’t know everything up-front. It also, in the case where a story is bigger than expected, gives the Product Owner some more wiggle room (negotiation part of INVEST) to drop/keep parts of the story to successfully meet the sprint goal. Of course, where we have got things really wrong, then sometimes the sprint goal cannot be rescued and the sprint would be cancelled.

4. Raise issues as they happen

Pretty much summarises most of the above points. One of the agile principles is responding to change over following a plan, so when change happens make it visible and decide how to adjust the plan at that point. There’s no point in battling on as planned when you know that the planned path is doomed to fail.

Some references:

2015 Desktop Motto

Posted: January 28, 2015 in Quotes
Tags: ,

Motto

Focus On / Focus OffRecently another team, that had recently read an article around team dysfunctions and appreciation exercises and wanted to explore the health of their team, particularly their trust levels, more closely, asked me to facilitate a retrospective for them. Facilitating a team you don’t know or regularly observe is usually a challenge, but it was one that I was up for, and thankfully the team member who arranged the session had a good idea of the feel/discussions he was hoping for as an outcome.

I started the session with the Focus On / Focus Off exercise. As English was not everyone’s first language, I prepared cards with synonyms for each of the word pairs. I had the team discuss each word pair and what they understood the differences to be together, and then gave them the synonyms to arrange under the correct ‘word’ in the pair. After we had been through the exercise for each word pair, I asked the team whether they were willing to commit to continuing the session with the correct focus (and, thankfully, they said yes!).

From there we moved to a simple Sad/Mad/Glad exercise with a strong focus on the team and its interactions. I’d found out before that the team members were more introverted, so I opted for silent brainstorming separately before each team member shared their feedback. The first two parts of the session actually went by more quickly than I’d planned, so I took the opportunity to then allow the group to move their Sads and Mads into physical circles of control, influence and soup. While they were doing this at the whiteboard, they automatically moved into a space of discussing what actions they wanted to take for the issues within their control. It was nice to see them being so pro-active about taking control.

We finished the one-hour session with a Temperature Reading. As this session was more about sharing and uncovering information rather than actions, I wanted to leave the team with some items for them to possibly work on or think about more deeply in their next sprints. The temperature reading also includes an appreciations section, which I have found really energises teams and helps end the session on a positive and optimistic note.

Feedback is that the guys really enjoyed the session and would be keen to have me back to facilitate another. Hopefully this one wasn’t a fluke! 🙂 Have you ever had to do a once-off session with a team you don’t work with? What tools or activities did you find generated the most valuable outcomes for the session?

Resources

Story Oscars

Posted: September 30, 2014 in Scrum
Tags: , , ,

We recently used the Story Oscars game from Retr-O-Mat in a retrospective to gather data. It’s a fairly simple tool but the team seemed to really enjoy it! We even applauded the eventual winners. The third category (selected by my team) was “Best Horror”. We also discussed the stories as they were nominated, rather than waiting until the end and only discussing the winners.

Oscards