My family has been playing a fair amount of the board game Settlers of Catan lately and, as happens with me, I got to considering the balancing act of the game versus the balancing act of moving to full-on DevOps. Most orgs have some amount of DevOps running at this point, but most have not made the transition, and I think the similarities have something to do with why. So, let’s consider …
In Catan, you put a settlement at the intersection of three hexagonal tiles. Each tile has a number on it, and those numbers run the quasi-bell curve created by rolling 2d6. There never seems to be a great set of numbers, so you go for the best you can arrange (there are more considerations, such as the type of resources you get for a given hex, but we’ll get to that later). Then you hope that your numbers come up enough to keep you in the game. The game is pretty hot/cold, with the dice seeming to pick a number (regardless of bell curve) and roll it more often in a given game.
The resources part is important. In Catan, each hex represents one of five resources, each of which you need to win the game. But you can trade resources (at a loss) for other resources, so you don’t have to sit on a hex for each type. This leads to some interesting attempts to get around the fact that the dice rolled against you or there were no good resource/number combinations when it was your turn to set up.
The parallels are intriguing, though not perfect. You have resources (people/systems/software) and you have goals (project/product/portfolio) that you are trying to reach. Random things (system failures/hackers/budgeting changes) interrupt you more than is convenient (this last one is equivalent to die rolls in the game, but also another game concept called the robber that I only mention for those who play, since explaining the game would make for a long blog). And you have to be a success.
Choosing to move people to DevOps creates a short-term problem with an eye to long-term gains, since those people moving are both out of their comfort zone and using tools that are new to them. Choosing to dedicate systems to DevOps processes/deployments removes them from the pool of resources available to longstanding systems/processes. It creates a tension of temporarily stretching things so that in the long run you will be better off (much like saving to build a city in Catan when the dice really want you to build roads).
The difference is, of course, obvious. Catan is a game, and if you lose horribly you just reset the board and demand a rematch. You can laugh at the pernicious nature of the dice when they turn on you just as you were about to do something cool. But in DevOps transformation, you just can’t do that. People’s jobs are on the line, and even if you are at a place where job security isn’t an issue, people’s stress levels still will change based on such wild events. If you haven’t experienced this, have your company announce budget cuts that keep you from implementing part of a transformation stage or have your systems compromised that require the attention of staff that were in charge of moving an application portfolio. It isn’t pretty.
The key is to keep the goal in everyone’s mind. The end result of a DevOps transformation should be the ability to get changes done faster with better focus on business needs, more complete testing and better communications. Keep talking this up, as there are always roadblocks to large change in any organization. Those improved communications should help people work together to overcome issues and move on. Even if something such as a data breach brings the effort to a halt for a while, when it resumes, an increased focus on the security of data will only make the transformation stronger.
So figure out how to deploy those resources to the best advantage, keep rolling the dice (so to speak) and keep trying to improve on what the last iteration did. The odyssey will continue unless the org gives up on it; your task is to make the most of each step while you continue to keep those core business systems running.
