Scrum as a Mental Model

For many years Scrum has been one of the go-to frameworks for teams adopting or trying to adopt agile working methods. Some teams have been successful, while others struggle to leverage the benefits of Scrum, achieve agility, and deliver value to their stakeholders.

As we work with more and more teams, scrum masters, and engineers, we tend to see that most of them (if not all) have similar problems and challenges. They all are trying to fit Scrum to solve those problems or fit these problems within the Scrum framework to find a solution — Neither of them works.

The Problem Statement

Software Development is a specific discipline that can be addressed through predefined approaches, methods, or activities. If we follow them step by step, we can deliver a software product. Hold on! That's not true. But that is exactly what we do. It doesn't matter what approach we take. We tend to fall into a trap and start doing things as prescribed, step by step, eventually moving away from the cognitive reason of adopting the process.

Same is being repeated with Scrum. We looked into the prescriptions of Scrum and started following it step by step. For every sprint, we need Sprint Planning checked. Every day there has to be a "Daily StandUp" checked. We must do the "Demo" and "Retro" checks every sprint. That is our Mental Model of a software development process.

As a result, Scrum, which was to be adopted as an empirical process that would help us to ‘Inspect’ and ‘Adapt’ as we make progress, is now just a set of practices and events to follow with little or no focus on the purpose of adopting Scrum. Instead of adopting Scrum to do the right thing, we adapted Scrum to fit our existing Mental Model.

What is a Mental Model?

The mental model can be defined as one's internal thought representation of how the real world works. Mental models define our thought processes, help us solve problems, make decisions, and often determine our biases. As Shane Parrish, author of the bestselling book - The Great Mental Models - puts it.

"Since we cannot keep all the world's details in our brains, we create their representation." The mental models are like maps, small enough to fit into our pockets yet having all the information needed to traverse a city, a country, or even a continent.

The Answer

We need to start looking at Scrum from a different perspective. Let us not treat Scrum as a set of practices or a mere framework. Instead, we must use Scrum as a Mental Model to solve complex problems. Software/Product development is complex, and it is not about understanding the requirements and then churning out the code to meet those requirements. It is much bigger than that.

As Scrum Masters, we need to help our teams to start thinking about the bigger picture. What is the customer's need, and how should we address it? We must help our teams think critically about the problem we are trying to solve. Let me take the analogy of maps to elaborate a bit more. A map has various elements, for example - the scale, the legends, directions, latitude, and longitude. All these elements help us navigate the terrain easily using the map.

Similarly, Scrum has various elements like - empiricism, values, rules, accountabilities, events, and artifacts. We need to use these elements of Scrum similarly (as we use maps) to navigate through Product Development.

Elements Used as Mental Models With Examples

Empiricism

• Meaning: Learning from our experiences
• Purpose: Improve decision making

Often in Product Development, teams have to make choices. Some choices take the teams forward, while others not so much. So what should the team do with those choices that did not work well? Learn. Apply those learnings in the next Sprints and improve the team decisions.

Rules

• Only One Product Owner
• Purpose: Single accountable person to avoid digressions and quick decisions

Consider you have guests over at your place for a house party. And you decide to ask each person what they would like to eat. How soon could you come to a consensus on the menu compared to if you pre-planned the meal on your own? Probably, it would be a never-ending debate if Noodles are better or Pizza.

The same could happen if too many stakeholders decide what should be built into the product. The result is probably nothing gets built. Hence, we need ONE person accountable for the Product.

Values

• Focus, Openness, Courage, Commitment, and Respect
• Purpose: Provide a sense of direction, like a compass, if we do things right.

Scrum guide provides a good interpretation of these Values, but it does not prescribe that the values are limited to the meaning/interpretation given in the Scrum guide. Therefore, each team can interpret these values in a way that best suits their context.

However, each team should determine whether their interpretation of values is helping to create Transparency and Upholding Scrum or is it detrimental to the Scrum team's success. For example, I teach that the Scrum team should FOCUS on QUALITY to create DONE Increments.

To Conclude

As in the above examples, you would want to connect each element to its purpose and start defining a Mental Model that helps you address the complex problems in your context.

Once you have that in place, instead of changing Scrum to fit into your context, you can use Scrum to address the issues at hand and start seeing the benefits of Scrum.