Scrum Simulation Game – The Product Box

Preparation

• 5 minutes: room preparation
• 5 minutes: information about the product and seleciton of product owners
• 5 minutes: briefing with POs
• 5/10 minutes: writing user stories and prioritization

Iterations

A SCRUM lesson delivered using….SCRUM

Last week I had the pleasure to teach Agile and SCRUM. The class was quite challenging because the attendees were all PMP certified, with a deep experience in managing ITC projects. The class was also quite heterogeneous because of the different types of projects they manage and because of the different expertises.

In a class like that, teaching agile could be tricky because the experience and the approach of the attendees is such that topics like Planning, estimating, risk management are paramount and you will be challenged for sure when explaining how agile embodies those topics.

This is the reason why in courses like that one, I make huge use of games, exercises and confrontation sessions (a little bit of coaching never hurts) in order to facilitate the learning process of the participants letting them to consolidate the knowledge just aquired.

Knowledge is only a rumor until it’s in the muscle (Papua New Guinea proverb)

One another trick I use when teaching SCRUM is to arrange the lesson using SCRUM itself.

First of all, I arrange a fantastic taskboard with three columns: Backlog, Running, Done.

The backlog column contains the topics I’m going to cover, as post-its. In every post-it I write the name of the topic and on the left or right corner I write also an estimation in story points.
This estimation is a blend of these factors: number of slides covering the topic, importance of the topic, difficulty of the topic and finally how much space I should left, to let the attendees to reason, talk, discuss, confront about that.

Then arrives the calculation of the total story points I muyst deliver in that session, summarizing the points of each topic.

Good, now it’s time to draw the burndown chart.

I decided that the duration of my hypotethical day is one hour.
The burndown chart is a standard one: on the Y axis I report the total story points just calculated; the X axis, however, is divided into the N days available (the number of hours available for that teaching session).

The preparation is finished, now it’s time to work, explaining the contents of the lesson.
Every time I start a new topic, the relative post-it is moved from the Backlog column to the Running column. On the other way round every time a topic is completed it goes from the Running to the Done column.

Every hour I check the status of the work delivered (topics covered), how much work is again in the backlog, the time remaining and I say to myself and to the class what we are going to do in next hour and if we are on track or not. Think of this as what a team does every morning conducting the SCRUM Daily Meeting.
Then, the burndown chart is updated with the story points left.

I found this approach very usefull.
Visualizing what topics are still in the backlog, helps you to remain focused and to decide to slow down or accelerate.
Visualizing the burndown chart reinforces what just said in the point above.

The class sees how many topic must still be covered (taskboard), it sees what this does mean in relation with the time available (burndown chart).
This actually, allow the class to automatically regulate the way the attendees ask for questions, the need of any break, the way how they discuss: they obviously want to cover all the topics, maximizing the value and reducing any waste of time.

I think, however, that the most important point here is to let the class see how SCRUM works.

This helps the attendees in the process of digesting the SCRUM knowledge, transforming it from a only rumor in their brain into an abilities they can train and use soon.

What I hear, I forget.
What I see, I remember.
What I do, I understand.
(Confucio)

SCRUM Simulation, the Resort Brochure Collaborative Game

On thursday and friday 24th and 25th, I gave a SCRUM training course for the European School of Project Management in Turin.

One of the most important thing, in my opinion, when in a training course you talk about a project team and its ability to collaborate, self-organize, learn from the experience, and communicate effectively (that’s SCRUM actually) is that you should find a way to let the attendees, work as a team, in order to test the knowledge just learnt, simulating one or more iteration sprints.

I know some collaborative games, such as SCRUM lego city game, that can be used to simulate SCRUM and iterations, but I prefer the resort brochure game or product box collaborative games because they are easier.

On friday, during the last hour of the course, we played the resort brochure game.

Let’s see what it is and what are the rules of the game.

Create teams of 5/9 people.

The goal is to create a brochure for a brand new resort. The brochure should contain the right layout, messages, images  in order to promote the activities and the strengths of the resort.

First of all, the team shall create the user stories in terms of how and what the resort should be (e.g. As a manager, I want meeting rooms, completely accessoried, where I can arrange business meetings, so that I can arrange projects’ kick-off or As a husband, or  I would a resort with a spa inside, so that I can celebrate my wedding anniversary).
During this phase, the team should also choose a product owner which is in charge of prioritize the user stories, write them down in index cards and put them into the task board in the TODO or Backlog Items column.

This period should last no more than five minutes.

Then, the team is ready to start.
Arrange 2/3 iterations of 3 days (5 minutes each day, a total of 15 minutes for each iteration).
The team starts the first iteration conducting the sprint planning meeting, during which the members decide about what stories they commit to finish and asking for some more details to the product owner.

Every day starts with the Daily Meeting, the team members say about what they did the day before moving the index cards through the taskboard, what they are going to do during the current day and finally if they have any road-block; immediately after, they begin to use scissors, rulers, glues, markers, paper to create the product: the resort brochure.

When an iteration finishes, the team shows the results to the stakeholders in order to demonstrate how is going and to elicit any feedback in order to adjust the product.

Actually, what the attendees of my course did yesterday, was amazing. They unfortunately hadn’t have three iterations because of time, but only one and what they produced was incredible.

I saw a great collaboration between them, one member of the team was actually a graphic and she facilitated the birth of the concept and the layout definition; the team decided what kind of images to choose and how to arrange them.
Another attendee was in charge to propose some claims and inspiring message to introduce into the brochure. The other ones helped the graphic cutting images from magazines, drawing, writing, glueing, composing the brochure.

I think that this games worked so well because most of the attendees were women. Actually the men helped but actually, they were not so confident with magazines, scissors and rulers.

With courses where the most part of the attendees are men, I use to play the Product Vision Box (Managing Agile Projects, Sanjiv Augustine). The scope of this game is similar to the previous one in terms of materials to use, but the team must create the box of a product. The team shall decide about which product they want to sell and after they decide about the box layout.

Playing Collaborative Games

It often happens that I teach in IT and project management courses.
What I’ve experienced is that one the of hardest thing to do in those situations, is to maintain high the level of interest and concentration of the attendees, allowing them to gather the greatest benefit from the course itself.
Actually there’s a secret…let them play!

On january I was in Scotland to attend to the SCRUM Master Certification Training Course.

In that occasion Simon, the trainer, organized some interesting games where the attendees, me included, were physically involved.
As usualy happens we were initially reluctant, but once the ice was broken the involvement of each one was really high, as well as the enthusiasm for the results.

Another occasion during which the collaborative games were used as training tools, was during the Italian Agile Coach Camp in Umbria. Unfortunately, I did not participate to those games because contemporarily there were other interesting tracks and I could not avoid to participate; it was really a pitty!

But, lucky me, we had retrospectives about those game sessions and I had the possibility to understand the actual worth of doing those games.

Both the two occasions were triggers for me. They helped me to deeply understand what such a powerful tool the collaborative games is!

Why?!?

1. First of all, they are games. People love to play games, even more if their company pays for it!
2. Second, players have still to pay for playing: you pay, leaving your comfortable zone and putting yourself into a new situation.
3. Third, the attendee is physically, not only mentally, involved. This helps the process of learning and facilitates the brain to store and consequently to remember and recover it.
4. Fourth, is a stimulus for the attendee to immediately activate the passive knowledge s/he has just learnt listening to the trainer.
5. Fifth, a game establishes a cheerful environment and creates a team building effect.

In other words, playing games help us to better understand because of the short feedback cycle (it sounds familiar, doesn’t it?).

Playing collaborative games is a quite sure way to energize the attendees, having them concentrated during the entire course. Which games I used to play in my courses?

A must game is the penny game, but also the specifiers and doers game using a set of role cards to introduce biases or, again, the alphabet games to consolidate what was learnt and the planning poker game.

Furthermore, I also use information radiators such as whiteboards, flipcharts, note cards stuck on the walls,  a task kanban board that shows the progress of each topic of the course, which helps the attendees to see progresses.