[DreamTeamLab #2] Game of Scrums

I like games. I’m sure you do, too. Whether it is sports, or board games, or puzzles, or some titles on a PlayStation / Xbox / PC - one way or another, every single person in the world likes games. This is how our human brains are wired, from early childhood till our sunset years.?

When you think about it for a while, you realise that all social interactions are games as well. They have their own sets of rules, and those who understand them are the ones who we typically describe as people with good communication and collaboration skills.?

The software development process frameworks, such as Scrum or Kanban, are no exception either. But as with every single game in the world, you only have fun when everyone around you plays the same game and everyone knows the rules.

Basic rules

Imagine playing chess when the only thing you know is the basic rules: how every chess piece moves and what is a checkmate. Technically you can play chess like this, but I think you agree that such a game would be far from what real chess looks like. You would randomly move the pieces around the board, and if your opponent has similar proficiency, then you might even win. But you would have no clue how it has come about, and probably you wouldn’t get much satisfaction from such a match. Also, a real chess player would have no fun playing with you.

Unfortunately, this is exactly what Scrum or Kanban looks like in most cases. The basic rules are easy and everyone knows them, but only a few know what the point of the game is and how to play it properly. Everyone knows what a Kanban board looks like. Some even know that it’s supposed to have WIP (work in progress) limits, but that’s about it.

People know very well that in Scrum they are supposed to have a planning session, stand ups, a retrospective and a review. When you google “Scrum”, most articles will focus exactly on these basic rules. Equipped with mere essentials, people start to practice Scrum, without actually understanding how to make it work.?

Unsurprisingly, it doesn’t work too well.

How to actually be good at the game

To actually be good at chess, you also need to know the structure of the gameplay, the strategies, useful positions to place your pieces and how to effectively utilise them in combination with each other.?

To actually be good at Scrum, you also need to know and understand the Scrum Values: openness, courage, commitment, focus and respect. Each ceremony is designed to reinforce them. For Scrum to really work, employees should strive to maximise those values in their behaviour. Scrum fails, when it is implemented in teams and companies with a culture that is incompatible with Scrum Values. How are you supposed to be open, if your boss gets angry at bad news? How are you supposed to be focused, if the stakeholders flood the team with unexpected ASAP tasks? How is your team supposed to agree on anything, if there is no respect between the team members? The Scrum ceremonies alone won’t fix these problems for you.

To actually be good at Kanban, you also need to understand the theory of constraints. Any improvement outside the bottleneck won’t enhance your performance. So, you also need to understand your process well enough to be able to identify the bottlenecks in it. WIP limits may help you with that, but they won’t work if you disregard them and just keep pulling more and more tasks from To Do to In Progress. Kanban won’t work if you don’t practice Kaizen - the culture of continuous improvement. This is exactly why adoption of the Toyota Production System - the cradle of Kanban - failed in so many western companies. They tried to replicate only the basic routines without a deeper understanding of the underlying idea.

To actually be good at any "game" (process):

• Remember that there’s always more to it than just the hard rules.
• Be curious: search for examples of someone having great results with it and analyze how they do it. Learn about how this process was created. Who invented it? For what purpose? In what environment? What problems was it designed to solve?
• Experiment: when you understand the process well enough and know what to focus on, try out different ways to optimize the important parts.

Why should I care?

If you are a software engineer, you surely know that the majority of employers are looking for a “team player”. Most literally, it means “proficient in the software development frameworks” - you know how to play the same game together with your team. If your current place of work has a good agile coach, use this to your advantage! Ask questions, clarify the bits that you can’t seem to make sense of, discuss how you can make it work even better in your specific environment. This will make your own work smoother and will also increase your market value as a specialist.

If you are upper management, ask yourself: does my organization’s culture support the frameworks that we (intend to) use? Same as with the team level, the department level processes like OKRs, Scrum of Scrums or SAFe are also “games” to master. Do they align nicely with the team level processes, or get in each other’s way? Once again, team managers and coaches are there to help you.

Finally, if you are a team manager, a coach or a scrum master - you are the “Game Master”. It means that not only you are supposed to deeply understand the process yourself, but you also need to be able to teach the rest of the “players” how to play this “game”.

Context matters

Scrum doesn’t work in the culture of command-and-controlism, but applied properly, it creates astonishing results in an environment aligned with Scrum Values. Kanban doesn’t work when the kaizen culture is missing, but it shines in the lean companies that understand and follow Toyota’s philosophy. Similarly, absolutely every process will perform better or worse depending on the context and problem to which it is applied.?

In the next article, we will explore how to pick the most suitable process for your team, project and company environment!