top of page
IMG_7934 - scaled.JPG
degradee.png

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?

​

you build it you run it you improve it -

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

DevOps loop.png
  • Improve: gradually improve your way of working, by investing in all the different activities of all the stages of the DevOps cycle

degradee.png

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.

full board - technical debt + change failure.png

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.

Example front maturity 0.png
Example front maturity 1.png

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.

degradee.png

What can possibly go wrong?

incident die.png
security breech - white glow.png

A new security vulnerability got reported. Solve it before it becomes a security breach.

bug - white glow.png

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.

Example back maturity 0.png
hacker - white glow.png

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.

downtime - white glow.png

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.

excessive load - white glow.png

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.

performance issue - white glow.png

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 ...

​

bottom of page