A Fun Way of Giving Feedback – The 360 Dinner

How does it work?

#1: Invite your team to a nice dinner: Let colleagues know in advance this will be a special 360 Degree Feedback Dinner.

#2: During the meal you’ll give each other feedback: One person will start and the rest of the team will take a few minutes telling that person both positive and negative things. The feedback must be honest and genuine with the aim of moving people forward, not roasting them or pounding them into the ground. 

#3: The person on the receiving end can answer questions or comments and then thank everyone for their thoughts. Once that person is done move on to the next. This can take a long time so carve out a few hours.

#4: This feedback works best if afterwards each person comes up with a few takeaways/themes based on the feedback they got for what they want to improve. They should then communicate that to the team so that colleagues can hold each other to account and check in every few months to see how they’re progressing. 

Change doesn’t happen in a vacuum, in fact when we tell people we’re trying to change it happens 90 percent faster than if we don’t tell anyone.

How I Used the Spotify Squad Health Check Model

The ‘Squad Health Check Model’ is an approach that visualises the ‘health’ of a team. It covers areas like teamwork, fun, easy to release, learning, the health of codebase. While discussing the different health indicators, the team builds up self-awareness about what’s working and what’s not. The broad selection of questions helps expand their perspective. Perhaps they were well aware of the code quality issues but hadn’t really thought about the customer value perspective, or how fast they learn. It also provides a balanced perspective, showing the good stuff as well as the pain points.

Read how Barry Overeem usde the Spotify Squad Health Check Model in this article: https://medium.com/the-liberators/how-i-used-the-spotify-squad-health-check-model-f226c6fe0fdb

An Exercise to Help Your Team Feel More Comfortable with Conflict

Have you noticed your organization becoming so focused on building a happy, engaged workforce that your leaders are becoming profoundly conflict-avoidant? I see examples of this all the time. One clue that your team is avoiding conflict is if the least bit of discomfort in a meeting causes someone to suggest that you “take it offline.” This, of course, triggers the meeting-after-the-meeting phenomenon — another hallmark of a conflict-avoidant culture.

You can normalize productive conflict on your team by using an exercise to map out the unique value of each role and the tensions that should exist among them. Here’s how. Draw a circle and divide that circle into enough wedges to represent each role on your team. For each role, ask:

1) What is the unique value of this role on this team? What should this person be paying attention to that no one else is? What would we miss if this role wasn’t here?

2) On which stakeholders is this role focused? Whom does it serve? Who defines success?

3) What is the most common tension this role puts on team discussions? What one thing does the person in this role have to say that frequently makes others bristle?

Read the complete article and other intersting articles related to handling conflict here: https://hbr.org/2017/04/how-self-managed-teams-can-resolve-conflict

How we do involve stakeholders?

One of the biggest challenges for Product Owners is to manage stakeholders. Often, there are many of them. And they all have different needs, requirements, and levels of involvement. How do you manage this?

The Stakeholder Map (PDF) is a simple tool that creates transparency and strategies. Print out a large version of the PDF and introduce it to your Scrum Team. Work together to identify all potential stakeholders (or groups) and write them on stickies. Distribute the stakeholders across the quadrants based on their level of influence over the product and their interest in what you are working on. Based on the distribution that emerges, you can devise strategies on how to best involve them:

  • Latents: Keep them up-to-date with frequent newsletters or videos and involve them when you need their input;
  • Apathetics: Its usually enough to keep this group up-to-date with periodic newsletters or pull-based information (like a website or page on your intranet);
  • Promoters: You want to involve this group as extensively as possible. Invite them to your Sprint Reviews, involve them during Refinement and meet with them frequently to re-order the Product Backlog;
  • Defenders: These are your biggest fans. Involve them actively by inviting them to your Sprint Reviews. Encourage the Development Team to seek out these people to validate assumptions about what you’re developing;

The stakeholders on the right are the most important at the moment, so focus the bulk of your time and energy on them. However, if you meet the needs of the stakeholders on the left, you can shift them to the right as they become more interested in your product. 

Subscribe to The Liberators Newsletter if you want to receive more of these great articles: https://theliberators.com

Agile Retrospective Smells Cards

During one of nlScrum meetups I heard about The Retrospective Smells Cards. A tool for Scrum masters, agile coaches, and anyone who facilitates agile retrospectives to recognize smells and solve problems or mitigate the impact.

You can find it – and other tools/games – here: https://www.benlinders.com/shop/agile-retrospective-smells-cards/

There are also a couple of interesting articles about smells like: blaming, passiveness and actions. You can find them here: https://www.benlinders.com/portfolio/retrospective-smells/

The Product Management @Scale game: How can Product Owners scale their role?

Now that many organisations are scaling their agile process one way or the other, Product Owners are faced with the challenge of scaling their already busy role. Kai Stevens created The agile product management @scale game that helps Product Owners identify how to focus on the essential product management activities while making sure that other product management activities will be handed over to other members of their team.

Read about it here: https://medium.com/the-liberators/the-product-management-scale-game-a-simple-way-to-figure-out-what-a-product-owner-should-do-cc143cb85ecd

Paper Plane Game

Copied from: https://agileparkinglot.blog/2018/11/25/paper-plane-game/

Purpose:

To demonstrate the power of time-box or Sprint that makes the heartbeat of an agile framework like Scrum.

Type:  Team Game

Paper_Plane-512
How many can you build in three minutes?

Time Needed: 45 minutes

Number of people per team: 6

Supplies Needed:

  1. Used Printer Paper 50 per team
  2. One flip chart and a marker to keep score

The goal of the game:

The goal of the game is for each team to create as much high quality tested planes that can fly a distance of at least 30 meters . The world record holder last checked in June 2016 was somewhere in Germany

Each iteration last 9 minutes.

IMG_0974 (1)
One fold at a time
  1. 3 minutes for planning,
  2. 3 minutes of actual build ( test included) time,
  3. 3 minutes for review/retrospective – 

Rules for playing the game:

  1. Build as many paper planes as you can in a 3-minute time box.
  2. One player can only do one fold at a time. That rules stays true for all three time-boxes.
  3. The planes should be built Rules and tested in the 3-minute increment
  4. Only planes that cross 30 meters will be counted
  5. Each team should give a count of how many planes they are going to build before the time-box starts.
  6. Subtract the final count of planes that actually flew from the planes that were built but were not tested or completed.  Eg: Team A said they will make 4 planes, 7 planes flew all the way but 5 were WIP ( work in progress). Subtract WIP so the actual is 7-5 =2
  7. The team has to come up with one idea of improvement at the retrospective. Have one member in the team be the counter.
  8. The front of the plane should be blunt to avoid injury to the team members.
  9. You cannot crush the plane into a ball and throw.

Please recycle the paper once done

Debrief: ( pick any two )

  • Each table talks about what made them improve over the three iterations
  • Talk about what would have happened if the time box was not there
  • Talk about how waterfall may be different from this.
  • Talk about who made the final design decisions in the team.
  • Talk about any wastes they removed from the system that helped them get better.

Disclaimers:

Original Creator: Not me. I am still trying to find out. I learned it from another trainer.

There are many variations of this game. This is one way I  use it in my workshops