Category: verified

Posted on

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

Posted on

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

Posted on

Common or severe Agile mistakes

Mike Cohn from mountaingoatsoftware.com mailed a nice list of common agile mistakes:

Being way too ambitious in how much work was selected for the next iteration. A few people reported doing this even in the absence of management pressure to do so.

Trying to facilitate a meeting using someone else’s style. We each have our own style. Use that. Teams recognize when we’re pretending we’re someone else and facilitating with their style.

Holding meetings or other events at the wrong times. A few people reported doing sprint reviews a few days early, but then not having everything ready to demonstrate.

Telling people what to do. This seemed like a common problem, especially for any of us who worked as traditional project managers before adopting an agile approach. Other Scrum Masters reported the opposite problem, saying they remained too silent during team discussions.

Letting a story into the sprint without enough clarity about what was needed. A few people emailed that this happened because a product owner pushed for the story to be included. Others, though, said it was the team that wanted to bring the story in despite a lack of clarity.

Trying to fill every hour with planned work during sprint planning. Some teams fear an unallocated hour. When sprint planning seems done but a few people have extra hours, they planned work into those hours and then learned they’d overloaded the sprint.

Not asking enough questions. A couple of Scrum Masters said they didn’t ask enough questions. I’m pretty good at that by now, but early on, I would literally track the number of questions I asked versus the number of statements I made in each meeting to try to improve.

Forgoing the usual meetings because the team size was small. A few people replied to say they took the already-lightweight Scrum framework and lightened it further by leaving out some meetings because their teams were 2-3 people. They learned this was a mistake and that even small teams benefit from every Scrum event.

Not pushing teams a little harder at improvements they’d decided to make. In their retrospectives, some teams chose to improve at things like demonstrating to users more often or improving collaboration between coders and testers. And a few of you said you didn’t push your teams hard enough to make the improvements they’d chosen themselves.

Allowing too much discussion into the daily scrum. A few Scrum Masters and coaches emailed to say they changed the format of the daily scrum away from the standard three questions, and that didn’t work as well. Other said they let teams discuss problems too long and daily scrums started to take much longer. Another had let the daily scrum turn into a design meeting.

Not letting go of a mistake. A number of people said that they tend to replay mistakes in their heads or let mistakes gnaw at them. Once the mistake has been made, learn from it. Then let it go.