Posts Tagged ‘game’

Scrum Ceremony Puzzle

Posted: November 19, 2018 in facilitation, Scrum
Tags: , , ,

Image result for puzzleThis is a “game” I played as a kick-off activity with a new team. Thought I would share in case someone might find it useful 🙂

The basic idea is to match the correct Purpose, Outcome(s) and Output(s) to each Scrum ceremony.

Preparation:

  • Print out the Ceremony Boards (each team will need its own set)
  • Prepare the Ceremony Cards (each team will need its own set)

Game Play:

  • Place the cards on the boards in the correct spaces
  • The cards are colour coded as a Purpose/Outcome/Output to help

How we played it:

  • I divided my participants into two teams and made a bit of a competition of it.
  • Both teams started in opposite corners of the room and ran to a table in the middle to try solve the puzzle.
  • When a team thought they had solved it, they would signal and both teams went back to their respective corners (think “Survivor style).
  • I would then check the solve against my solution. If the team had solved the puzzle correctly, then they were the winners. If the solution was not correct, both teams could return to their tables to continue working on the puzzle.

Feel free to try out the game and give me feedback!

Resources:

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?

Dark Stories

Posted: August 19, 2016 in Team
Tags: , ,

darkstoriesI was following one of the Australian Agile conferences on Twitter recently and someone posted something about a talk on “Black Stories”. The click-trail eventually led me to this link and I decided that the card game sounded quite appealing (regardless of whether it would prove to be useful as a tool or not). A search for “Black Stories” for sale to South Africans almost ended in vain, but thankfully I decided to submit a query to http://www.timelessboardgames.co.za/ and they got back to me almost immediately to say that they had a set of “Dark Stories” in stock. A quick Google confirmed that this was the equivalent thing and, seeing as it was a Friday afternoon and I was in the mood for shopping, I ordered a box, which arrived the following week.

Since then, I’ve played a couple of games with my team. Our organisation has a horrid culture of people being late for meetings (generally five minutes; when I’m planning a session I always plan for at least 10 minutes) so having something for us to do while people dribbled in seemed a great idea. And, if it encouraged people to get there on time, even better! At first, people didn’t really figure out what was going on (I only play one card per session and we time-box it to 10 minutes, so sometimes people arrive after we’re done) but they’re slowly getting the hang of it and I have noticed that the percentage of on-time arrivals is increasing. I also like that it encourages some lateral thinking, which is also something we don’t practice very often in our day-to-day, so hopefully it will stimulate some more creative problem-solving too.

So far, I haven’t managed to take my box home yet to play it in my personal capacity, but that’s OK. A chance to make meetings more fun is far more valuable. If you’ve been struggling with this or getting people to rooms on time, I’d really give this a try. Do you have any other easy tricks or tools you’ve used in the past to set a good tone for a meeting or encourage other helpful behaviours?

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

 

I recently played a Kanban game with my new Kanban team. I’ve never played an Agile game before so was not sure how it would work, but had heard about the airplane game and how successful it is at teaching teams about flow, pull systems, cycle times, limiting work in progress, etc. After doing some online research, I stumbled across some variations of the traditional game, and was attracted to the Kanban Pizza Game. It looked fun and something everyone could relate to, plus it created the opportunity of actually ordering pizza for afterwards 🙂 The link goes into some detail about how to facilitate the game, so I won’t go into that here. I’d rather highlight some of the lessons I learnt trying to facilitate a game I’d never played or watched being played for the first time.

You need a helper!

There is a lot going on this game, not least of which ensuring teams don’t leave the pizza slices in their oven for too short (or too long without penalties). Thankfully I roped our Product Owner in at the last moment and he also helped with quality control and counting up for scoring, as well as keeping track of which slices had been “spoiled”.

Enforce WIP limits at least once

When I facilitated, I mentioned work in progress limits and enforced that each team had at least three stations (of their choice). In the close-out, one of the teams mentioned that they had set WIP limits but had not really stuck to them – or had changed them on the fly. My feeling is that some of the Kanban principles may have been more clear had these been enforced for the round. In hindsight, it may have worked better from a demonstration perspective to have enforced certain base stations and base limits to start with and then allowed the team to tweak them as the rounds progressed.

Track cycle times

The facilitator’s guide says measuring this is optional (perhaps because you really will need more helpers to do this). My feeling is that we lost a lot of the point by not tracking the cycle times between different rounds and changes to the process. We saw a significant improvement in the number of slices produced between rounds 1 and 2 (and one of the teams did observe that having a pull system – the orders – contributed to this), however, as things became more complicated, the points scored at the end of the round did not always correlate to improved efficiency. Cycle times would have also helped illustrate just how much value was being lost through wasted inventory.

Have a practice round

The group all said that they were more efficient in the second round merely because they had a better grasp of the process and rules. It may be an idea to run the first round twice before introducing Kanban concepts to mitigate this ‘learning’ effect on the outcomes.

Don’t give them timelines

The facilitator’s guide does warn why the team shouldn’t know how long a round is (watch out for clever teams timing a round for better planning!). I did let them know when we were busy with the final round, which in hindsight I probably should not have, as then they paced themselves to make sure there was no excess inventory at the end of the round rather than working towards getting as many orders filled as possible. I guess in real development this approach might make sense, but it didn’t really help from a demonstration perspective.

Outcomes

Things I felt came through quite strongly

  • Having stations.
  • The advantages of a pull system.
  • The group had fun!
  • The fact that the whole process was important: it was not helpful to have a highly efficient stickie cutter if the end-to-end process was too slow to consume the parts.

Things that didn’t come through as well

  • Limiting work in progress.
  • Impact of limiting work in progress on cycle times.
  • Having explicit policies (team felt that they were implicit).
  • Idle time.

Have you run this game before? What did or did not work for you?

Links

Learning about Kanban

Posted: March 6, 2014 in Kanban
Tags: , ,

One of the teams I’m newly responsible for is called the “Kanban team”. This made me a bit nervous when I joined as my knowledge of Kanban was completely limited to some reading I did when trying to find a better way to visualise work while a team I was Scrum Master of at my previous company was going through a Lean Start-up phase. The Kanban team appeared to be functioning and was getting stuff done, but I found the board completely confusing and there didn’t seem any easy way to understand inefficiencies. My first task was, obviously, to try to find out a little more about Kanban and understand its principles, and I did this through conversations with colleagues who had been on the training and a lot of Google searches!

The first ‘retro’ I had with the team, I highlighted the main principles of Kanban, which are:

  1. Make workflow visible
  2. Limit work in progress (WIP)
  3. Measure lead time

We agreed that although the workflow was visible (via the board), we were not currently limiting WIP nor were we able to track our lead/cycle times. The first exercise was to review the workflow itself, which we approached with a ‘blank canvas’ approach, mapping the steps various items would go through to eventual release. This team is responsible for maintaining the system on a day-to-day basis, as well as building smaller features, which means some work is very ad hoc and other work is more structured and ‘plannable’.

The second session I presented a proposed version of the board (which was basically the existing board plus some additional columns) plus some suggested WIP limits for us to argue about. After much debate, we eventually agreed on a board that had similar columns to the existing board and was flipped (so that work items bubbled up the vertical rather than along the horizontal axis). The team agreed to track WIP at a ‘story’ rather than task level (although tasks were still added to the board for visibility), and we agreed on some WIP limits. It was a tiring session but it was nice to see the team take some ownership, although it took them at least a week to adjust to the new board once we got going.

Since then, we’ve made some minor changes. I posted up some policies (exit criteria) based on info we had, but we still need time to review and flesh them out (particularly our Definition of Done). I was also trying to track cycle time by tracking when stories moved, but this was proving difficult and time-consuming and prevented the team from moving items backwards (which is something they wanted to do), so we bought a date stamp (like they used to use in libraries) and agreed to stamp stories at three points in the process:

  1. When the story/item hits the board
  2. When it moves into the build phase (starting with design)
  3. When it’s tested and ready for release (done)

We haven’t been tracking tasks long enough to have any useful data yet, so I’ll have to see how this goes. The main thing I have noticed is that the team is still struggling with the concepts of lean, so my next big session will be to a play a game with them (similar to the airplane game) to try to demonstrate how the pull system is supposed to work. I’m hoping that they will then have an ‘a-ha’ moment and we can start focusing on improving our process. Think of it as a change management exercise 🙂

Useful links:

  • I found this comparison of Kanban and Scrum really useful as I could work from my existing knowledge.
  • I liked some of the task board ideas in this article.
  • And, in case you don’t know what it is, here’s more on the Airplane Game.