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 implemented around the world is very similar to Monopoly with house rules. Managers and entire companies have customized their own way to do Scrum. They have no idea that there is a free, 13-page rule booklet out there called The Scrum Guide written by 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 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, have also only read it once or skimmed through it.
Let’s dive into the Scrum Guide and how Scrum is intended 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 adopt my pink underlining and arrows in a future version. 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 an oft-repeated claim, that does not mean that you take from it whatever you want. By framework the authors mean the stuff that you don’t modify to fit your context. 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 Manifesto for Agile Software Development. 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, cross-functional, 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.
Trying to follow the rules of Scrum in your workplace will 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 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.
Why Are There House Rules?
Here’s why you end up with Scrum by house rules:
- Scrum requires self-management, and managers don’t know how to do their jobs in an environment where teams manage themselves. Some brave souls try to empower teams, but being habituated to being told what to do, the team just sits there, so the manager comes back and rescues them from themselves and starts “driving” again.
- Scrum requires cross-functional teams, and the company is organized into functional silos with the top performer as the manager of the function. If teams are made cross-functional, then those managers are no longer able to trade on the capacity of their functional teams and assign work to people as they prefer.
- Scrum requires lean thinking, and lean is a boring topic that most people have not studied at all. Concepts like constraining WIP and batch size to lower utilization to improve flow are counterintuitive and seem wrong to managers trained to maximize resource utilization and prevent idle people from getting paid for nothing.
- Scrum is based on empiricism to manage uncertainty, but managers are trained that through estimation and comprehensive planning a risky future is possible to predict and manage.
- Scrum is based on short horizon planning, but managers are trained that short plans are inefficient. They are right to loath short horizon plans when their process is so filled with control and approval steps that it takes 90 days to deliver anything.
Scrum makes those problems visible. Most attempts to follow the Scrum Guide to the letter instantly expose that the team is not empowered, the team is not cross-functional, management balks at short plans of small scope delivered in an empirical way, and management balks at lowering WIP because idle people are waste to them.
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.
What Does Scrum Make Visible?
Some examples of things I have seen well-executed Scrum 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
In an organization led by people who truly desire to improve the performance of their product development teams, these revelations are pure gold. In a company where people believe “things are working pretty good,” these sorts of revelations could be meaningless or unwelcome.
House Rules
It has been my experience that the house rules I encounter usually are covering up problems that could have been solved. Scrum wasn’t intended to be adaptive and flexible itself to meet you where you are. It was intended to be a set of rules you try to follow, and when you cannot follow them, you realize you have obstacles to achieving real agility. The adaptive and flexible part of being agile is delivering working software frequently, very frequently, for customer satisfaction. Those fast feedback loops allow you to achieve a level of business maneuverability that has information rolling in at a fast pace so you can make new, different decisions quickly.
It isn’t Scrum that is supposed to be flexible. It is your organization that becomes flexible by learning to operate fast feedback loops and make more frequent decisions.
Saying, “This is agile, so we should be flexible,” is just an excuse to leave things the same as they are now. That means no change in how you do things today and no change in the results you get. If you want different results, you have to change what you are doing. Out with the old. In with the new. Experiment, check results, run another experiment.
House rules disable Scrum from helping you change how you work.
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.
Wikipedia contributors. (n.d.). Monopoly (game). In Wikipedia, The Free Encyclopedia. Retrieved [September 15, 2024], from https://en.wikipedia.org/wiki/Monopoly_(game)
The Scrum Guide. Sutherland & Schwaber, 2020, https://scrumguides.org