Gamification, Defer Commitment and Real Options

Last week we had a Scrum Master Gathering: 60 people from 8 countries and 5 different companies meeting to discuss and share thoughts about Agile coaching, one of the most challenging and yet the most exciting jobs in the world, during 2 days of learning, sharing and fun.

The first day was a full collaborative and self-organizing day, where everybody could contribute to the emerging agenda by proposing an Open Space about burning topics to share or issues they wanted help about from a fellow coach.

The second day was instead about Gamification and Learning Lean: a day of creative sessions to bring back home a number of brand new games to teach the Lean Discplines from Mary and Tom Poppendieck’s book. In fact true Lean Software Development requires that coaches help their teams achieve the necessary mind shift and find new ways of doing things. There is scientific evidence that one of the best ways to learn is by playing: that’s how kids learn and learn fast. And gamification is just the process of using game thinking and game mechanics to solve problems and engage audiences.

But creating a game is not easy; it requires a number of steps to define the main elements:

• What is the Goal of the game?
• Which Mechanics do you like to use? (e.g. levels, points, badges, mission)
• What are the Rules of the game? Are they clear and not ambiguous?
• How many Players does the game require?
• How much Time is necessary? 

A couple of us decided to pick a Lean discipline nobody had selected, being one of our favorites instead: Defer Commitment aka Decide as Late as Possible.

Inventing a game to teach this subject didn’t look so straightforward in the first place, but, being this discipline all around ability to keep your options open until the Last Responsible Moment and live with uncertainty, we decided to take inspiration from Real Options.

What are Real Options? I suggest you to have a look at this article to start understanding a bit more.

The authors explain that in the SW development world, we can learn the following from the Financial Option maths:

1. Options have value.
2. Options expire.
3. Never commit early unless you know why. 

Starting from these considerations, we created a game based on “Guess who?”

You know? The famous game where you must figure out the name of a mysterious character based on the information you manage to get by means of Yes/No questions.

Let me share how it works and the different components:

• Goal

The Goal is the same as the original game “Guess who?” except for having to reach it within a time box of 1 minute

• Mechanics

The game mechanics is based on Points: you start a round from a total of 40 points; each question is costing 5 points. If your answer is wrong you get no point. Who gets more points in 2 rounds wins.

• Rules
• Each rounds is time-boxed to 1 minute, which represents the Last Responsible Moment to take the decision and guess who is the character chosen by the other party
• You start from an amount of 40 points and can give your guess at any time before the 1 minute timer expires
• You can guess right away without asking any question: if you’re right you get 40 points
• Or you can ask how many Yes/No questions you want to get information about the mystery man within the 1 minute time-box. Each question costs 5 points, so if you ask only one question and you’re right with your guess, you get 35 points
• If you’re wrong, you get no point, so asking questions has a cost, but reduces the risk of failure
• All questions have the same cost, so it’s up to the asker find the proper question to maximize the amount of information and knowledge you can get

• Number of players

At least two: either individuals or teams

• Time

2 rounds of 1 minute for each player + 10 minutes debriefing at the end

The final debriefing is meant to let the players reflect on the game, conceptualize the experience and get all learning out of the proposed metaphor, i.e.:

• Exactly as “Guess who?” SW development is a discovery process based on the scientific method: make an hypothesis and verify it through empirical learning
• Options have an expiry date: the Last Responsible Moment
• Keeping your options open until that moment has a cost, but minimizes dramatically the risk of failure
• Since each experiment (like each iteration in Scrum) has the same cost, the key to get faster to success is always to run the most valuable experiment, the one which gives you more information 

Hope now you got curious to try it out. Let me know how it works.

Applying Agility to training and education

You know: I strongly believe that Agile values and principles apply and work very well whenever you have a complex problem to solve, something that you have never done before.

So, if you have a vision of what to reach, but do not know where exactly you’re going and your domain is not deterministic, there’s no chance you can define your path upfront: the most sensible approach you can try is to do one step at a time and strive for fast feedback to verify your assumptions and adjust consequently.

Therefore an Agile approach suit very well many different fields, even outside IT, given that people involved in solving the problem have the right domain knowledge. 

For instance, as a trainer, I use an Agile approach for designing and delivering my Agile and Lean courses to Product Owners, Scrum Masters, Teams and managers.

Last week I got interviewed by 4 students from a Human Resources Master (a psychologist, a sociologist and two economists) about my thoughts and experience on applying agility to training and education, which is actually a complex domain. The interviewers resulted to be very passionate about the subject and it was really an interesting 3 hours long discussion about many aspects.

I will try to summarize the outcomes here by using the same pattern we followed during the session: going through the values in the Agile Manifesto and try to understand how they can be concretely implemented in the domain of training development and delivery.

1. Individuals and interactions over processes and tools

We normally use a collaborative team approach (2-4 people) when designing a new course. We try to understand the learning needs of the client and ideate possible solutions that are pulled from the backlog and implemented incrementally by leveraging on pair working as much as possible. We use a task board to visualize the work and understand the progress.

We apply pair training for delivery and try to foster a collaborative approach in the class, where the trainers are mainly facilitators of people learning using different teaching techniques.

We use tools like working agreements to set a stage of ground rules for the class. Understanding is prioritized over delivery of a pre-determined content and physical tools and face-to-face conversation are preferred over other ways like web-based training.

2. Working software over comprehensive documentation

We try to get feedback as fast as possible as we proceed with the training design, by showing concrete examples of what we have in mind (slides, activities, other material) in order to validate our assumption and verify whether they match clients’ learning needs. That’s in contrast with detailing the training contents up front in a document and hoping to get feedback on that, where clients do not have necessarily the domain competence to understand and to map it with their needs.

We also think that learning is achieved by means of a complex recipe, where magic happens during live training delivery due to a combination of good material, inspiring activities, group collaboration and teachers’ skills. That’s why we do not aim at producing documentary or even self-explanatory material, which often gets the result of having neither good training material nor good documentation. Training should inspire, provide a vocabulary, create curiosity and new questions, which can best be satisfied on the web or by reading books.

3. Customer collaboration over contract negotiation

As I said, fast feedback is crucial. For that reason you need to get your client involved in designing the training with you. That’s why we engage an early collaboration which happens face-to-face when possible or remotely (via mail, chat or phone/video calls).

When our contact person is not the primary customer of the training, we try to get in touch as soon as possible with a number of training participants (when they are available) to interview and get a better understanding of their learning needs or even help to get themselves understand their needs.

4. Responding to change over following a plan

We try to keep our options open until the last responsible moment, both during course design and delivery.

We’re open to late requirement changes as much as possible, stated that they fit the allocated timing for the training and propose other items to down prioritize if we think it adds too much to allocate in the given time frame.

We divide the course in modules and monitor the progress of the delivery by means of tools like task board or burn-down chart, so that we’re ready to adapt. We follow a time-first planning approach: we always finish on time and if the timing doesn’t go as planned, we decide which modules to cut together with the class.

Looking forward to your comments, if you’re interested or have experiences in the field of agility applied to training.

P.S. Thanks Valentina, Lydia, Patrizia and Francesco for the awesome chat and all the best for your work.