Saturday, February 1, 2014

Recap of the Ready-Steady-Sprint! session at the APIL14 conference

This week I had the pleasure and honor to attend the Agile Practitioners IL 2014 conference - not only as an attendant but as a speaker for the first time.

Together with Shirly Ronen Harel and Dan Kuida (my partners in the AgileLife initiative and other projects, and close friends) we ran an interactive session called "Ready-Steady-Sprint!". It was a fast paced card game developed by us, which teaches first-hand what working together as a scrum team is like - both in terms of team-dynamics, pressure under a timebox, and specifically utilizing Scrum and XP practices.

So if you don't have the patience to read further I'll save you the trouble and just say 


Dan and Shirly are so proud of me...
...making fun of myself on the podium

Some boring history:
The game was originally prototyped by my eldest son (Michael) and myself. BTW he got it straight away! He understood what a bug is, what refactoring means and how important automated tests are. Go figure.

Original prototype cards - to be sold on eBay for a small fortune soon

It was later crafted into a card game (printed in a home printer on cardboard and manually cut with a knife) as a recap activity for a team I worked with - summarizing the things they had learned throughout their first scrum project.

This was their first project together as a team, and their first acquaintance with agile and scrum.
During the project I was designated to teach them Scrum and some XP practices and of course to lead the project to success...

The project was for a big government office and a public, high profile, high country-wide PR initiative.
Yikes... not something you'd like to fail in.
However - the project was a huge success (I know I know - this sounds unbelievable). The client was delighted, the project was #DELIVERED on time and on budget, it had lots and lots of scope changes throughout and we adapted to the changes and managed to deliver the right product in the designated timeframe.

Also the team itself had a chance to learn and practice some interesting Scrum and XP practices and later matured to work together on other agile projects.

The hand-cut home-printed cards for the original project-X team

Some time later we formed the AgileLife group - composed of Agile professionals who wanted to take Agile practices and mindset outside of the software realm into real life - including arts, education, community and more - and take some real-life wisdom back into the software world as well.
We adopted the card game as one of our group projects, and I teamed up with Shirly and Dan to present the game in AgileSparks' Agile Israel 2013 conference. We submitted a call-for-papers but were rejected. Awwww...... :(

So when Ilan approached me asking if I'd like to give a talk in the APIL14 conference - I had no question about it. We would give the game as an interactive session. By hook and by crook we would.
The focus of the conference was "Learn from the best" - so I figured the best way to learn is from experience, and the best teachers are our teams. Nice twist and a great excuse to submit the game :)

Fresh from the print-shop

One of our biggest challenges here was working with a large number of participants - until now, the game had only been tried with small teams, so the entire team would play together and I would act as the facilitator of the game.

Now in the conference - we were faced with the horrifying possibility that more than 10 people might attend... So after overcoming the initial urge to opt out and run for our lives, we decided to embrace the challenge and devised a format which would fit multiple teams - actually simulating a scaled-out agile adoption. This meant having several teams each playing their game, and scrummasters doing Scrum-Of-Scrums syncing between the teams. Wow! talk about getting a chance to fail big-time :)

Another dilemma we had was how to plan for the session - we didn't really know how many people would attend. We didn't know if to plan for a scrum-of-scrums session or for a single-team session. Seeing this as any other kind of product risk in agile planning, we took Mike Cohn's advice and did both - we devised two game plans - one in case we have only a handful of attendees and another for in case we have more. We had a third plan for in case nobody attended, but that's another story altogether...

The cards we used in the conference - professionally produced for us by Dina Kuida of DDK graphics studio

Enough bullshit - let's hear the Game Plan
The game is similar to the "Race" game if you happen to know it.

The objective of the game is to complete "tasks" using "time" cards.
The players are grouped into teams (each table had a team of 7-9 people) and each team elected one member to be the scrummaster for that team.

In the beginning each player gets 5 task cards (this is their "TODO" pile) and 5 other random cards (this is their "Hand"). In the middle of the table we placed a pile of cards ("the Pile") with their backside facing up.

Each player in his or her turn takes a card from the pile and needs to use a card (either the new card or another card in their hand).
Some cards are pretty straightforward - for instance, you can use a "time" card to complete a "task" - in which case you throw both the task and the time cards into the "DONE" pile.
But some cards are more challenging - there is for instance a "bug" card - which needs to be placed on the TODO pile and later handled using another time card.
Or there is a "Code Smell" card - if you get it you need to place it on your TODO pile and from that moment on - each task will take more time (=more time cards) to complete, until the code smell is taken cared of - using another "Refactoring" card.
Also there are special "Protection" cards - which once used, protect the player from various problems. For instance, if you use an "Automated Tests" card - you are protected from bugs for the rest of the game.

Our mugshots in the conference PR
The teams have 25 minutes (a Pomodoro) to complete all the tasks of all the players.
In addition - In the beginning each player can only complete his or her own tasks (high truck factor).
There is a special "Pair Programming" card that enabled two players to reduce truck factor - and combine their piles into one.

Throughout the game - the scrummaster maintains a sprint burndown - counting how many tasks remaining each minute of the game - and is responsible for encouraging and helping the team succeed, as well as making sure nobody cheats.

Every 5 minutes - the scrummasters would be called to a "Scrum-of-Scrums" - gathering together to share insights and ask for help from each other on things their teams have been doing and problems their teams are facing.

After the game is done - we hold a retrospective - each player (or some players from each team) shares some of their experiences and insights from the game.
Also the scrummasters share their experiences as scrummasters.
We would also go over the burndowns of each team - figuring out what story the chart is telling us and gaining insights from it.

In the end - each player is asked to take with them one card which they especially related to - so it would remind them of things they need or want in their day-to-day work.

The timer we used during the game - was projected on a large screen
Grab it at""

Oh! Some more boring blah blah!
The game itself is rooted in the star coaching model (strengths, obstacles, resources and goals).
In this case - the goal is completing tasks,
the basic resource is time
The obstacles are bugs, code smells, lack of time, panic etc
and the solutions to the problems are refactoring, pairing etc.

The "secret ingredient" of the game is this: There is NEVER enough time to complete the tasks, especially if we spend it on "firefighting" (refactoring, fixing bugs etc).
The best strategy to win the game is through investing in protection cards (automated testing, pairing, pomodoro, planning etc) - which makes us untouchable by the problems and leaves us free time and hyperproductive to proceed with completing tasks. 

Funny, but I've never yet seen a team grok that - at least in a first game... 

The Game Reality
In the APIL14 conference we ended up having some 40-50 attendants - so we quickly switched to "scrum-of-scrum" mode.

We allotted 10 minutes for the opening (explaining the game) - but time ran out quite quickly. We didn't have time to go over all the cards - and we decided to "throw the folks into the cold water" - assigning to the scrummasters the responsibility of explaining (and figuring out) what each cards means.
We did equip the scrummasters with a "cheat-sheet" explaining the cards, and told them they can ask us if they need to (we also walked around the tables and offered insights). Also the Scrum-of-Scrum was an opportunity for each scrummaster to ask things that they did not understand yet.

"Who's got some time for me? I need time!"

The game itself was loud, messy and highly energetic - like you'd expect from an agile software project.
Some teams were quite quick to figure out what to do,
some teams got stuck in analysis-paralysis for most of the timebox,
some scrummasters decided that doing a burndown each minute was wasteful and decided to update it every 5 minutes.
One team was stuck deciding if to invest time in pair programming on a pile of smelly code, or if they should wait until the developer refactored it first. Their scrummaster was frustrated - since he thought they should do the pair programming but was unable to convince them of it.
All in all everyone was highly engaged!

Scrum-master at work with his team

Toward the end of the 25 minute timebox we found out that we somehow had magically only 7 minutes to the end of the session (damn time... can never trust it to go as planned) and the organizers threatened to throw us out. So we shortened the 25 minute bomb-timer to 2 minutes and started "pouring oil into the fire" - telling folks "Ok 2 minutes to deadline", "The offshore customer is about to enter the building" and other kinds of stressing but not really helpful remarks - of the kind you'd expect when heading a project deadline.

We then only had 3 minutes left for the retrospective - so we just asked one member of each team to tell us an insight they'd gained and invited them to take a card they related to.

Whew! done in time but not in scope. Adapted to change and had fun throughout.

Blurry but productive

My own personal retrospective:
All in all I'm glad we tried, and glad we were challenged with the Scrum-of-Scrum format - which like I mentioned, was a first time for us.
We made some mistakes and intend to learn from them for next time.

In the midst of the mess - a smile that makes it all worth while :)

To Keep:

  • Do the game! We got some feedback that it was extremely helpful and educational.
  • Keep it fun - that helped keep people involved and engaged.
  • Invest in it - we did put a lot of time planning it through and some money in printing the cards professionally. It was worth it.

To Change:

  • Plan scope according to time - if we only have 10 minutes to explain the game, I'd use a smaller subset of the cards so we have a chance to explain them all. If we have a longer session - I'd plan a longer explanation to make sure we have all the rules covered. Also make sure we have enough time for the retrospective - I'm a bit sad that part was skimmed.
  • Make sure to have it properly video'd and photographed - throughout the game we tried to take photos, but most of them were blurred since we were shooting while running around from table to table and the people themselves were in constant motion. I would invest in a professional or dedicated photographer.
  • Coordinate ourselves - we (Dan, Shirly and myself) never had a chance to get together and run a simulation before the session - and I must admit we paid the price. We should take a bit of our own medicine for next time and make sure we at least do a dry-run or short planning session before the next game.

Shameless plug:
If you have attended the game - I'd love to hear what you thought - and especially what you experienced in it. Any feedback is more than welcome - except bad feedback - keep that to yourself :)

BTW The game itself is designed to be customized and tailored to specific teams and needs - for instance we have a variation where we run several sprints allowing a chance to inspect and adapt between each sprint.

If you haven't attended the game and find interest in it - please be sure to contact us at or by phone +972-54-5995983 (Avi) - and invite us to give a similar session in your workplace or event. I'ts sure to be a good learning experience and a fun attraction.

Thank you!
Avi - and I believe I speak in the name of Shirly and Dan as well on this :)

And just because you've read this far - here's a special bonus track - the most-embarrassing-promo-video-ever-made-for-a-geeky-software-conference. Don't let Shirly see it - she'll absolutely have me skinned, chopped up and delivered in incremental potentially-shippable bits to the sharks if she sees it:

Personalize funny videos and birthday eCards at JibJab!

No comments:

Post a Comment