Scrum and Monopoly

I always hated playing Monopoly. Any game of monopoly would take forever to play. Right at the moment when I was about to get the upper hand, one of my family members would pass money to someone else, give them a property, or win the big pile of money in the middle that grew larger everytime someone had to pay a tax. Most of our games never actually ended. The board would sit on the dining room table for days, and then finally Mom had enough and told me to pick everything up and put it away with the other board games.

Why did people even play such a stupid game?

Fast forward 20 years later. I was a father now myself, and my family and I were about to play Monopoly. I was rolling my eyes and thinking this was going to be another nightmare. I could not remember all of the rules, so I got out the little pamphlet that came with it and started to read it.

My eyes just about popped right out of my head in surprise! 😮 There is no pot in the middle of the board! All taxes and fees are paid back to the bank! If you run out of money, you have to mortgage your properties, and while they are mortgaged, you cannot charge rent on them! And there were other rules that were highly restrictive and forced players who were in a bad way to quickly run out of assets, lose everything, and exit the game. We played our game, and it was over in less than two hours.

What!!!

I did some research into Monopoly to find out what happened. Monopoly is a game that is derived from another one called The Landlords Game. It was created by Lizzie Maggie as a way to demonstrate that an economy rewarding individuals is better than one where monopolies hold all the wealth.¹ In other words, it was designed specifically to work this way. When families introduce house rules (their own way of playing the game), it becomes unbalanced and doesn’t work any more. The game board sits unfinished on the dining room table for days or weeks until someone makes you put it up.

The Scrum Guide

It would be years later before I realized that the way Scrum is done around the world is very similar to Monopoly with house rules. Managers and entire companies have decided their own way to do Scrum, and that is all most of them have ever done. They have no idea that there is a free, 13-page rule booklet out there called The Scrum Guide² created by Jeff Sutherland and Ken Schwaber the creators of Scrum.

Among the few people who are aware of the Guide’s existence, most have only read it once or skimmed through it. And most disturbingly, most people who claim to be certified Scrum Masters, the people who are supposed to be the teachers of Scrum to the world and coach teams in how to play this product development game, do not really know what the Scrum Guide says and are not very interested in it.

Among those who are highly familiar with the Scrum Guide, there is a lot of back and forth arguing about whether or not you have to follow the Scrum Guide. Some of these arguments become incredibly passionate, and reading them can be hilarious as the participants are every bit as non-self-aware as a group of nerds arguing angrily about what color Captain Kirk’s shirt was in episode 21 of Season 2 of Star Trek. Setting that aside for now, let’s focus on the Scrum Guide and how Scrum is designed to work by the guys who made it.

The Rules of Scrum

The Scrum Guide is a rule book. Teams that try Scrum are intended to follow the rules. You can see that on the cover of the pamphlet.

Maybe the authors should have adopted my pink underlining and arrows. There are other places where the authors let you know that that Scrum is intended to be played following the rules. Here’s a selection of favorites from around the Scrum Guide.

Scrum was designed as a framework. Contrary to a oft-repeated claim, that does not mean that you take from it whatever you want, although nothing is stopping you from doing that, and I do it myself quite often. By framework the authors mean that this is the stuff that doesn’t change. It is the foundation and the girders of the building. Everything in between – that’s up to you to define.

How Scrum Works

Scrum uses all of its rules to create a situation where you are encouraged to do a bunch of healthy things. Some of those things are in the Agile Manifesto³. Some of those things are from other places like research into lean manufacturing and getting high performance by empowering teams. If you follow all of the rules, you should end up with a small, empowered team that minimizes waste, focuses on value, eliminates bottlenecks, quickly responds to new information, continuously improves its process, incrementally, iteratively develops a product, improves quality, and works together in a collaborative way to harness the genius of everyone on the team through them volunteering it. Think of the rules as creating a squeeze on a team to push them in many right directions at once.

Scrum uses all of its rules to create visibility as to what is not working so well in the team and outside the team so you can see it and do something about it. In other words, Scrum illuminates problems.

The authors warn you right here. They tell you that scrum highlights management, environment, and working techniques so you see the problems and can fix them. Further up in the Scrum Guide is a warning that if you customize your Scrum, you might cover up those problems instead of highlighting them.

Let’s sum it up: the authors wonder what you will get from trying to do Scrum if you play it by house rules which cover up the problems that Scrum was designed to expose.

What Does Scrum Make Visible?

Here’s why you end up with Scrum by house rules: Scrum makes problems visible, and a lot of people don’t want things to be made visible in their organization. Leaders aren’t exactly lining up to have an autonomous team in their organization complaining that the organization is structured badly, the process has a bunch of unnecessary steps in it, and that the way work is managed should be completely overhauled.

But that is what the Scrum Guide is asking for. It is asking for teams to try this as a way of exposing what doesn’t work and with the assumption that your organization intends to prioritize performance over control and politics and be the very best organization it can be… even if that means highlighting some very uncomfortable truths.

Some examples of things I have seen Scrum done “by the book” illuminate:

• a team member was not doing any work and was hiding
• the team was too large and needed to split
• the organization was pushing work into the team instead of allowing the team to pull
• the team’s domain caused dependencies
• functional silos were causing handoffs and delays caused by the functional silos
• employees had to ask permission to change anything they did, and the answer was always “No.”
• none of the stakeholders were aware of how Scrum works, and none of them liked the idea
• the scrum master was merely a glorified meeting host and status reporter
• the team was being micromanaged
• the organization did not have a way to tell if work had started or was finished
• status reporting was inaccurate and work was often in jeopardy long before that fact was reported
• there were too many things being worked at one time for anything to get done
• previously invisible queues
• the company did not believe in uncertainty as a concept and handed the team a fixed scope backlog to complete by a date
• story points did not work as advertised
• the tool the team was using was in fact not very good for anyone but management and that’s why it was never updated

You can imagine that in a lot of traditional, control-oriented organizations, these sorts of revelations could be fairly unwelcome.

House Rules

I have seen some fascinating and creative ideas that some really great teams have invented which depart from following the Scrum Guide in order to better suit their own context. So, don’t think for a second I think that everyone has to follow the Scrum Guide as their best way to do work. But, it has been my experience that the house rules I encounter usually are covering up problems that could have been solved:

Examples:

• Extending the length of a sprint to hide the fact that the team can’t get anything done.
• After putting in measurements to expose that cycle time was greater than a sprint, which it shouldn’t ever be because the team desires feedback from customers as frequently as possible, the team started creating “design stories” and “code stories” and “testing stories” to hide their terrible cycle time without changing anything.
• Creating functional teams and claiming developers hate to be on cross-functional teams in order to prevent exposing that a lot of people in a particular functional silo are dead weight or to maintain the status quo where the manager of a functional area continues to gatekeep the capacity of the team for the purpose of political favor-trading.
• Assigning business analysts to Scrum Teams to cover up the fact that no one in the organization on the line owns the product and all decisions are made upstairs.
• Continuing to work on fixed scope projects via Scrum teams, which is a thing that can be done, in order to cover up that the organization’s reward system is outdated and continues to reinforce completing entire projects instead of engaging in empiricism.
• Ordering teams to all do Scrum the exact same way to ensure the cover-up is organization-wide.
• Continuing to make Scrum teams come to project status meetings while also doing Scrum to cover up that the project status meetings, if everyone engaged in Scrum, are now unnecessary, and were probably never really effective in the first place.
• Extracting status reports out of scrum teams during the sprint in progress, which is waste, to cover up the fact that the team doesn’t really need that kind of guidance and can work on its own with its product owner present daily.

Do Whatever You Find Useful

I have come to the conclusion that most organizations doing Scrum don’t know any of this. I wonder if they had known these things, would they have agreed that anyone should do Scrum in their organization? More likely such groups would be open to a lighter touch by adopting Kanban as a visualization of work, and then some gradual introduction of lean principles into the organization rather than introducing autonomous problem-reporting teams.

Kanban has a great way of being modified through policies over time that can land you in some of the best ideas of Scrum. Cadence to events, events to plan, review, and retrospect, daily events to massage the queue and address the things that are not moving, etc. A lot of people will argue that their house rules Scrum is basically that. It think they may be correct.

Expecting an old-fashioned, heavily regulated institution with a rigid hierarchy and control culture to allow a team to really follow the Scrum Guide… I think that is often asking too much. But also be aware that when people saying that “Scrum doesn’t work here,” often what they mean is that they don’t want Scrum to work there.

For the people out there who hate Scrum, I wonder if they ever did full Scrum following the pamphlet that comes with the game. If every development team had a chance to fully follow the Scrum Guide, experience the autonomy, mastery, purpose, and connection that the experience a real team can have on the job, then I think a lot of people would really love Scrum. A lot.

Business Outcomes

Businesses do not hire us to enact our game nor our revolutionary vision of how companies should work. They hire us to help them achieve their goals and desired business outcomes. If the goal is to expose what isn’t working using a pilot team that attempts to work in a self-managing, cross-functional way, then Scrum is a great tool for that. Applying change for the sake of change, no matter how convinced we are that the change would yield great results in many areas whether currently desired or not, is unlikely to be a successful approach.

We didn’t play Monopoly so the makers of Monopoly would be happy and we would learn useful things about economics. Mostly we played just so we could have fun together and teasing, laughing, and cheating.

Do not adopt Scrum to be good at Scrum and make the authors of the Scrum Guide happy. Adopt whatever you do in order to achieve a business outcome. That’s why you go to work – not to enact cool working techniques you find online, but rather to accomplish a business goal. If Scrum helps your team and organization improve everything they do, great! If it just causes problems that you cannot solve, maybe dump it or change it up and try something else. But make sure you get a positive change to the value your team delivers.

1. Wikipedia contributors. (n.d.). Monopoly (game). In Wikipedia, The Free Encyclopedia. Retrieved [September 15, 2024], from https://en.wikipedia.org/wiki/Monopoly_(game) ↩︎
2. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The definitive guide to Scrum: The rules of the game. Scrum.org. https://scrumguides.org/scrum-guide.html ↩︎
3. Beck, K., Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org/ ↩︎