A serious game for learning ‘built-in quality at the source’
Skip studying queuing theory! Play this 1h15 serious game for learning why building-in quality at the source leads to a productive and sustainable pace.
The company I work for, Murex, is currently going through a large transformation. This transformation involves training teams to new skills and practices. One such training is the lean concept of “Built-in quality at the source”.
Built-in quality at the source is first of all a set of practices (Software Crafting, Test Driven Development, Behavior Driven Development, Continuous Integration…). Unfortunately, the training was too theoretical. Attendees reported that it was painful and, in the end, useless.
💡 Stop of boring people out with theory of queues. Play the built-in quality serious game for learning why software best practices matter!
I had played the Dice of Debt game with some other Murex agile coaches. They asked me if I knew of a serious game for learning Built-in quality at the source. I did not, and that’s why we decided we could build our own!
Before finishing this story, let’s first see why this subject is so important.
Why built-in quality at the source matters
When we postpone quality, we discover problems late and they come back messing up the value flow. It can create so much perturbation that nothing gets done without tremendous efforts.
Imagine you are working on user story X when a bug appears. This creates at least 3 problems:
- You’ll receive useless stress
- You’ll lose some time switching from one task to another
- People who might be waiting for story X will have to find something else to do…
Things get even worse at a larger scale. Suppose your team has been building a new feature for 6 months before it goes live and … users don’t like it! You might need to throw away everything and start with a new feature… Leaving a code architecture that is not adapted to what you now need.
This is not a sustainable pace.
In summary, without built-in quality at the source, people get stressed, which makes them take shortcuts and neglect refactoring, which degrades the code quality, which makes building-in quality at the source even harder…
💡 Build-in quality at the source to enable a sustainable pace and continuous refactoring.
The first test with other coaches
As I said earlier, the first inspiration came from the Dice of Debt. It’s another serious game for learning the perils of technical debt. From the Dice of Debt, we kept:
- the dice
- simulating a software development team
- playing over a few iterations
- tracking what we were are building
We wanted to show the value of a few built-in quality practices, on the flow. We naturally thought of a Kanban board.
I created just enough material and rules to test the game. We had a test session with volunteer agile coaches at Murex.
This first session was encouraging. The feedback was positive and we got plenty of ideas to improve the game.
For example, we decided:
- to simplify the Kanban flow
- to write the mechanics of the game on the material as much as possible
- to assign roles to players to start more quickly
Special thanks to Damien Menanteau, Hicham Ghorayeb, Joseph Soares, Julie Jeru and Matthieu Tournemire
The training day
Once we finalized the material, we were ready for our first real-life training.
They were about 40 people attending the training. We had 6 teams of about 7 people play the game at the same time.
As part of a day-long training, we had agenda constraints for our game. We decided to use a faster “real-time” version, where all roles can play at the same time. Indeed, it is faster, but at the cost of lower learning. I definitely recommend to use the turn based version if you can.
Even with this small glitch, the feedback and engagement were great. For example, teams understood that continuous delivery is better than big batch deployment.
The coaches gave great feedback too. They said they would love to use this serious-game for teaching “Built-in Quality at the source”. That’s why I decided to open source it.
Try it yourself!
The game is only 1h15, it’s not too hard to find the time to play it.
If you are a team-member, try it with your team. Next time you do an end-of-sprint celebration, or when you have a bit of Slack Time. You could also organize a team lunch and play the game at the same time.
If you are a coach, the game is a good substitute for a training. People are usually happy to play instead of attending a classroom training.
All material is available through Github: the boards, the cards, the rules and an animation guide.
If you try this game, I’d love to have your feedback so that we can improve it.
It’s all under Creative Commons, you are welcome to contribute improvements.
Leave a comment