Playing Lean facilitator tips

Playing Lean is a business simulation, in the format of a board-game to learn about lean startup principles and practices.

The following facilitator tips are based upon those experiences. Some of the tips are more advanced (meaning these take time to prepare). You might not agree with all recommendations, but hey it’s up to you to try😉 (as an experiment)

1/ Don’t run sessions with less than 6 people

The minimum number of players is 8, the maximum is 16 and the optimum is 12.

Don’t make a team of only 1 player (there will be no “team” conversation)

Don’t run a game with only 2 teams (there will not be enough action on the market, and people will pre-calculate too soon who will win)

In case of 16 or more participants:

  • run 2 games in parallel (my preference)
  • or put each team on a separate table and let a team representative travel between the team and the table with the customer/market board (I haven’t tried this!)

In case of running 2 games in parallel:

  • a large enough room to create distance between the tables
  • a common intro with short introduction of the game rules, other detailed game rules are explained “just-in-time” during game-play
  • check with the other facilitator from time to time to check game progress (aim to finish both games more or less at the same time)
  • don’t wait with the retrospective when 1 game has finished (keep the retrospective per game)
  • have a common debriefing, closing asking about lean startup principles linked to the game
playing-lean-double-game

Playing Lean double game

2/ Optimise the session according to the available time, aim to optimise for learning

That seems straightforward, but Playing Lean takes time to play. If you aim for default game-play and optimise for speed, there will be little learning about specific lean startup practices. I’ve managed sessions with high-speed game-play and learning about experiments in a 90 mins time-slot.

My recommendation for a decent Playing Lean learning session is a time-slot of minimum 2 hours, ideally 3 hours. Yes that seems a lot, but otherwise you’ll have participants simply playing and not learning much about lean startup tactics.

As facilitator your aim is to make sure participants learn about lean startup tactics, for example by providing extra background information and examples for each experiment.

You must provide time for a retrospective (at least 10 minutes). Not having a retrospective at the end of a game, and players learning the session immediately at the end, counts as a failure.

3/ Don’t use the out-of-the-box experiment cards

The issue with the out-of-the-box experiment cards is that the outcome (numbers of customer tiles flipped) of the experiment is written on the experiment card. As a consequence, players will not be interested in the description of the experiment and have little or even no attention for any explanation given.

Using the out-of-the-box experiment cards, as facilitator you should not give the experiment card to the participants, meaning

  • draw the experiment card yourself
  • and read the experiment card aloud yourself

Some participants won’t like this and to my experience it’s better to put the chance of drawing a successful / failed experiment in the participant’s hands.

Hence: tip 4.

4/ Use custom-made experiment cards

The custom-made experiment cards

  • do not indicate the result of the experiment
  • only show the title of the experiment

As facilitator you explain the content of the experiment, and you can announce the result of the experiment.

playing-lean-custom-experiment-cards

Playing Lean custom experiment cards

Optionally you can provide a set of cards for the results of each experiment (so each experiment has a pair: the experiment card and a corresponding experiment result card).

5/ Let the teams keep their experiment cards

Simple objective: at the end of the game, each team can easily count their number of experiment card. You have some statistics to talk about in the retrospective.

6/ Provide experiment background info

For each experiment provide explanation about the technique applied in the experiment, and provide some background info and ideally provide a real-life example.

I like to have this well-prepared: my recommendation is to have a set of digital slides ready, and each experiment has a slide with that additional info (you can use some very visual examples, not simply text-on-slide examples).

playing-lean-session-with-experiment-slides

Playing Lean session with experiment slides

7/ Manipulate the set of experiment cards available

Using the full set of experiments cards, the game might miss out on experiments explaining essential lean startup techniques. You can manipulate the set of experiment cards available during the game (be careful: do not manipulate for experiment outcome).

8/ Don’t let the same team start each round

Feedback often heard is that the “first-mover” has a specific advantage in the game. In the real-world being a first-mover often isn’t an advantage.

To minimise the dependency on the “first-mover”, a recommendation is to change the team starting a round. For example each round the subsequent team will start. You could further randomise this, but this aspect of the game should not get too complicated.

9/ Retrospect

You must retrospect after finishing the game:

  • Let the participants tell their immediate feedback
  • Let teams indicate their journey throughout the game: what made them win or lose`
  • Look at statistics: number of experiments, number of successful sales, number of unsuccessful sales, number of unneeded features in the product
  • Further retrospect by explicitly linking Playing Lean game-mechanics to lean startup principles and concepts:
    > Build-measure-learn
    > Pivot or persevere
    > Innovation accounting
    > Technical debt
playing-lean-busy-market-board

Playing Lean end of game: very busy customer market: collect some statistics

10/ Make technical debt heavier (experimental)

This tip contains tweaking of the game itself.

To make teams feel the consequences of a bloated product (= a product with unneeded features), you could make technical debt count heavier.

For example:

  • penalise selling a product with unneeded features to a customer
  • removing features is more expensive than indicated on the company board (for example removing a features costs 2x people than indicated)

 


More impressions of Playing Lean sessions

Worrying interpretations of Scrum

Misconceptions about Scrum. Why don’t you read and understand the Scrum guide?

Ullizee

At an Agile event I attended recently the speaker surveyed the audience about the 9 elements that form Scrum. My suspicion was immediately raised with mentioning of “9”. It only got worse when the speaker came up with:

Definition of Scrum (9)

It got me wondering how many misconceptions of Scrum can be expressed in no more than two minutes:

Definition of Scrum (9?)

I was hoping that by now (2016), and certainly given the availability of the Scrum Guide (since 2010), the basic understanding of Scrum was better.

What worries me the most however is not the formality of the wrong and missing elements, but how this reflects an ineffective use of the Scrum framework, a limitation to how Scrum supports teams in creating great software products:

  • Accountability over the self-organized creation of Increments belongs to the Development Team as a whole. Synergy is key, not individualism.
  • Transparency is optimized when Product Backlog holds all types of work and requirements for…

View original post 227 more words

The Future Present of Scrum (Are we Done yet?)

Ullizee

Scrum turns 21. Thank YOU!

Scrum was for the first time publicly presented and described in the paper “Scrum Development Process” in 1995. Scrum is turning 21 years old.

It starts and ends with people.

Scrum can only last and prosper -across the globe, across industries- because thousands and thousands of people, organized in teams, departments, organizations, employ Scrum to deal with complexity, to tackle difficult challenges, to create valuable product. Day in, day out. (Depending on the source, 70-90% of all Agile teams worldwide say they use Scrum.)

Regardless of region, organization, culture, or background, every individual has the intrinsic capability to self-organize and thrive by working in the context that Scrum creates. Through people those benefits can be unlocked to wider ecosystems.

Are we Done with Scrum?

Verheyen, Gunther - Scrum - A Pocket Guide (A Smart Travel Companion)In my book “Scrum –  A Pocket Guide” I present 2 major challenges, that will help define the future state of Scrum:

1/ The Power of the Possible Product

From…

View original post 567 more words

Essential Agile

The essentials of Agile software (product) development:

Accept that you start not knowing the solution. Understanding is emergent.

Take the following approach:

  1. Find out where you are
  2. Take a small step towards your goal (and if there are multiple choices here, take the path of least regret, or the one that makes future change easier)
  3. Adjust your understanding based on what you learned
  4. Repeat

(Yes, that’s it).

by Pragmatic Dave

Iterative Vs Incremental approach

EmbracingAgility

 Iteration is to beautify what increment is to expansion.

Lot of times we hear these terms as iterative development or the incremental development. So whats these are or what is the basic difference in between these two?

Iterative development is the revising and improving on the things. We prepare the basic framework  or the skeleton and  then start beautifying on it. Output of an iteration is the analyzed for further refinement.

Whereas Incremental approach is start from zero and scaling it.Its just like the expansion and integrating things. Different parts are developed and integrated.Output of an increment is used as input for next increment.

 

 http://www.infoq.com/resource/news/2008/01/iterating-and-incrementing/en/resources/Patton_Incremental_Iterative_MnaLisa.jpg

 

View original post