Build - Run - Improve - Repeat
How do you explain to someone (your manager?) that you shouldn't think about delivering new software faster if you can't manage to deliver better quality? How do you tell them to forget about continuous delivery for a while and focus first on continuous integration first, especially if they have already set their mind on a certain toolsuite or a certain tool vendor?
​
What if you could make them experience the impact of their decisions? In a safe environment? That is exactly what this game aims to do. It facilitates experiencial learning about agile and DevOps, inspired by the quote of Amazon's CTO Werner Vogels: you build it, you run it.
-
Build: agile development practices, the left side of the DevOps cycle
-
Run: all activities to put the changes into production and make/keep them running properly
-
Improve: gradually improve your way of working, by investing in all the different activities of all the stages of the DevOps cycle
It's all in the game...
This game is designed as a board game in which you need to deliver new features, by going through all the activities of the different stages of the DevOps cycle.
Delivering features means earning revenue you can invest in improvements. Initially this delivery of features will go slow, but with the right investments and improvements you will benefit gradually and steadily. You build up a foundation of good practices that pay back later. You do this by improving the maturity level of the different activities of the cycle. You start with zero maturity and can already invest in improving some activities.
The game lets you experience what happens when you invest in the wrong things, or rather, in the wrong order... And believe me: a lot can go wrong! Mainly incidents, and not always in your own control.
What can possibly go wrong?
A new security vulnerability got reported. Solve it before it becomes a security breach.
A bug was found in your code. Depending on how fast you detect this (determined by your performance level), this bug will cost you more or less money. And then you sill need to fix it.
Your system can be hacked. Again, depending on how fast you detect this cyberattack (determined by your performance level), you will lose more or less moneyy. And then you need to fix this breach too.
Your system crashed. This will certainly have financial impact, depending on your performance level, how fast you can detect and solve the problem. Off course, your system has to be operational again as soon as possible.
Your system had to process exceptionally high load. Wasn't the capacity of your system properly scaled? Can you easily adapt your capacity to changes in load? Make sure your system is working properly again as soon as possible, because you're losing income due to timeouts and refused connections.
Your system has a performance issue. This could be an infrastructure issue - not enough system resources to process the load - but also a design problem. Anyway, with long response and processing times your customers will run away, causing financial losses. Fix this as soon as possible.
The fact that incidents - not the reported security vulnerabilities - lead to financial losses for your organization, means that you need to be very cautious with your investments: not investing is fatal, but investing too much at once and not having enough financial buffer can lead to bankruptcy. And you never know up front what the impact of an incident will be ...
​