Posts Tagged ‘retrospectives’

I did this retrospective with one of my teams recently, and seeing as the feedback afterwards was really positive, I thought I would share. First off, kudos to The Virtual Agile Coach for creating this retrospective in the first place. I don’t have a paid Miro account so had to recreate the experience in Powerpoint (file attached), but he had done the heavy lifting and Miro templates are available on his amazing site for those with the power to import.

Some context to add is that I have had some push-back from the team in the past when it came to activities in meetings that they did not regard as “work”. For example, some people don’t like random check-ins while others complain when we have to interact with a visual aid (“can’t we just talk?”). As an experiment, for this retrospective, I explained the “why” behind each of the facilitation activities I was using. And I believe it helped šŸ™‚

Another note is that although I have indicated the timeboxes I used, it’s worth mentioning that this was a fairly large group (14 people) which brings its own challenges. For example, if you have a smaller team, then potentially break-out rooms would not be necessary.

1) Setting the Scene [10 minutes]

First I shared the Miro board link in the chat (I had already shared it before the session, but wanted to make sure everyone could get there) while we were waiting for people to join.

Then we started with an activity. I pasted the following instruction in the chat:

Take turns to answer this
==========================
What FRUIT are you today? (and, if you want to share, why?)

We used https://wheeldecide.com/ (which I had set up with the team names and to remove an entry after each spin) to decide the order for people to share in.

I also gave the instructions verbally.

Before we started, I explained why we were doing the activity:
“When a person doesn’t speak at the beginning of a meeting, that person has tacit permission to remain silent for the rest of the session (and often will). We want to ensure that no one has a subconscious barrier to speaking up in our retrospective because it is important that everyone feels able to contribute equally.”

Remember to pause before you spin the wheel for the first time so people have a chance to think about what they will answer.

After the “fruit” check-in, we went to the Miro board and I reminded everyone why we did retrospectives (The Agile Principle) and the mindset we were meant to have during the discussion (The Prime Directive). I also ran through the agenda.

2) Gather Data (1): Silent Writing [4 minutes]

Gather Data

I pasted the next instruction into the chat before I started speaking (it included a link to the correct Miro frame):

Silent writing for 4 minutes. Add stickies to the sections on the Miro board.

I explained why we were doing silent writing:
“Some people need time to stop and think or are not able to think while other people are talking. We’d like to give those people a chance to gather their thoughts before we move into a stage where we want them to listen to the “speak to think” people in the room. Another reason we’re doing silent writing is it is easier for the human brain to stay engaged and focused when we engage at least two of our senses. So in this instance people are seeing and typing (movement). And having a whiteboard in general means you can capture notes (movement) and listen at the same time. Another reason it’s good to capture notes is sometimes people might have to step away, or will be briefly distracted, and then there is a visual representation of what they might have missed and they can catch up with the rest of the group. We also have some team members who cannot be here today, and this creates something they can refer to when they are back at work. Lastly, our brains can only hold 5-8 items at any one time, so by writing down our thoughts before we move into conversation, it means we can focus on listening rather than trying to remember what we want to say.”

I then reiterated the instruction and played the song “Another One Bites the Dust” while they performed the activity (because the length of the song is almost 4 minutes).

3) Gather Data (2): Conversation [6 minutes]

Once again, I started with pasting the instructions (the same link as for silent writing) into the chat:

--- Breakout Rooms: Discuss Queen ----
Discuss what's been written. Add any new thoughts.

I explained that we would be going into break-out rooms of 3-4 people randomly assigned by Zoom and that each group would have about five minutes to discuss what they could see on the board plus add any new thoughts out of the discussion.

I explained why we were using breakout rooms:
“We want everyone to have a chance to speak, and because we are so many people, to do so in one group would take a long time. Breaking up into smaller groups means we can have some of those conversations in parallel. It’s also easier for people to connect online when they are in a smaller group and our brains find smaller groups less tiring, particularly when using a tool like Zoom.”

I then repeated the instructions and sent everyone into break-out rooms.

4) Generate Insights [15 – 17 minutes]

Generate Insights

Once everyone was back, I added the next instruction to the chat (with a new link to the relevant frame on Miro):

----- Breakout Rooms: Generate Insights ---
Talk about what stands out? What surprised you? What patterns do you see? What is missing?
(You can add notes -> miro_link )

I then told the group we would be going into break-out rooms again (this time with new people) and this time the idea was to step back and look for patterns or trends. To try see things from a new/different perspective. I mentioned that the instructions were in the chat and that there was a space on the Miro board to add notes (if they wanted to). I also said that we would be having a debrief of what was discussed as a single group when everyone came back from the break-out rooms.

Before I opened the new rooms, I checked in as to whether the first break-out slot had been long enough. One group mentioned that they hadn’t really managed to get to everything so, as we were running ahead of schedule, I added an extra two minutes to the five-minute break-out room timebox.

While people were in the break-out rooms, I added a funny hat to my Zoom attire.

When everyone had returned from the break-out rooms, we made time for discussions. This is where, as a facilitator, you need to be prepared for awkward silences! Once the first group had had their turn, things flowed again. I was ready to add any additional comments/notes that came out of the debrief however, in this instance, there were none.

5) What could we do? [5 minutes]

The chat instruction:

Please add ideas for what we can try next sprint to the "Ideas" section -> miro_link
We will then have a 10 minute break until xx:xx

I explained that we had gathered data and highlighted any trends or observations, and now we had to decide what we wanted to try in our next sprint. The first part of that process was to capture and share our ideas. We would do this by having five minutes of silent writing, followed by a 10 minute break, and when we returned after our break we would discuss the ideas on the board. I told the team that I would be playing music for the silent-writing part, however people could use the time as they chose, as long as they had captured their ideas by the time we returned from our break. After checking for any questions, I started playing the song: “I want it all“.

While the song was playing, I kept my camera on as a visible indication that the break hadn’t officially started. When the song finished playing, I turned my camera and microphone off (we generally stay in the Zoom room for breaks) and re-iterated in the chat window what time everyone was expected to be back.

6) What will we do? [Remainder of the timebox – approx 30 min]

I changed my Zoom hat again for the final part of the session, and reminded the team that we were aiming to shape our ideas into at least one action or first step that we wanted to try in our next sprint. We started with a debrief of the ideas that had been added to the board, particularly the ones that were not so specific and more like thinking items (so that we could generate some specific ideas for what we could try).

Once we were done discussing, we used Menti to rank vote the actions we’d come up with. One could also use something like dot voting. I used Menti because my team are familiar with Menti and I find it’s quicker to update ‘just in time’. As an aside, before we rank vote, we also usually get the team’s input as to the impact/effort for each of the proposed actions. For this session, it actually led to further discussion, because one team member realised that they didn’t know enough about the action to be able to rate the effort to do it.

Effort vs Impact of Actions

Once ranked, we took the top ranked action and ensured that it was SMART. At that point we were out of time, so I asked the team if we were OK to end the session. Sometimes in the past we have decided to take more than one action into our sprint (but we try limit it to no more than three).

We also always do a fist-to-five to ensure everyone can live with the SMART action(s) as described. I like to use a Zoom poll for this.

7) Close

To close the session, I re-capped what we had done during the session (starting with the check-in activity) and that we had agreed to one action for the next sprint. I reminded people who had specific actions from our discussions about their tasks. Finally, I asked the team if they would give me feedback on Miro by

  1. Dragging a dot to rate the retrospective out of five
  2. Where they had comments (things to keep doing, things to stop doing), adding those thoughts to a sticky

And, with that, we thanked each other and ended our sprint retrospective.


If you give a similar retrospective a try, let me know how it goes. I would be interested what did and did not work for you and your team.

Image result for yes but improv gameRecently my team played a loose version of the “Yes, But” improv game at the beginning of a retrospective (retro) as an icebreaker. I say loose, because we played it in a round (rather than in pairs) and did two rounds. I started each round with the same statement: “I think we should have snacks at Retro” (this is something that often comes up – tongue-in-cheek – during retro conversations).

For round one, the next person in line always had to respond starting with “Yes, but”. At the end of the round (we were seated in a circle), I asked the group to silently pay attention to how they felt and what they experienced during the exercise.

For round two, the next person in line had to respond starting with “Yes, and…”. At the end of the second round I asked some questions about how the team experienced both rounds:

  • How did the first round feel?
  • How did the second round feel?
  • What made a round difficult?
  • What did or could you do to make a round easier?
  • What does this mean for how we respond to each other as a team?

Interestingly (and unexpectedly), my team struggled more with the “Yes, and” round than the “Yes, but” round. To the extent that one team member couldn’t even think of something to say for the “Yes, and” round! At first I was a little stumped, but as we discussed further we realised that:

  1. As a team, we found it more natural to poke holes in ideas rather than add to ideas we didn’t completely agree with.
  2. When we didn’t agree completely with a statement, we got “stuck” and couldn’t think (easily) of a way to add to the statement.

As an example for point 2, above, one person responded to the statement with: “Yes, and we will need to do exercise”. The person following them really struggled to respond (because they don’t like exercise) and didn’t really come up with anything convincing. As a group, after some thought, we eventually realised that “Yes, and it can be optional” would have been a perfectly valid response. However, as a group, it took us a while to get there. So it definitely wasn’t something that came naturally to us.

For me, these were quite cool insights, and probably good for a team to be aware of, particularly when we’re struggling with new problems or trying to find creative solutions.

Have you tried similar games? What did you learn or experience? How has it helped your team?

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?

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

 

Scrum happens in a Retrospective

Posted: September 18, 2014 in Scrum
Tags: ,

agile-manifestI recently did a De Bono exercise on retrospectives. First, because I needed to practice; second, because Retrospectives and keeping teams engaged is currently an ongoing challenge for me. I won’t bore you with the detail, but one of the ideas that popped up was “Scrum happens in the Retrospective”. At face value, that may seem a silly statement or idea. But the more I mulled it over, the more I could see how that idea was more true than false.

First, let’s consider the Scrum process/ceremonies. You have planning (decide on the what and the how), a review (to evaluate what has happened, progress, and the future of the product/project), and a retrospective (how can we do it better). This ties in pretty neatly with a retrospective: set the stage (review), gather data (review), generate insights (planning), decide what to do (planning), close (retrospective).

Second, the team. Scrum requires a cross-functional team. A good retrospective needs a cross-functional team too. You need thinkers. You need do-ers. You need facilitators. You need scribes. You need those more comfortable with facts and stats. You need those more comfortable with people and relationships.

Finally, the values. Retrospectives value:
– Individuals and interactions over processes and tools
– Working teams over comprehensive documentation
– Collaboration over job descriptions
– Responding to change (learning) over following a plan

What other parallels can you draw?