What is a Mental Model? Scrum as a Mental Model

When teams ask what the mental model is, and how it connects to Scrum, they often find why Scrum doesn’t always "work."

For many years, Scrum has been a go-to framework for teams trying to adopt agile working methods. While some succeed, many struggle, not due to a flaw in Scrum itself, but due to how it's understood and applied. Scrum isn’t just a set of ceremonies, artifacts, or roles. It’s a way of thinking, a mental model.

As Agile coaches working closely with teams, Scrum Masters, and engineers, we’ve seen a pattern: similar struggles, repeated mistakes, and a tendency to use Scrum as a quick-fix tool. Teams often try to force-fit Scrum to their problems, or worse, reshape their problems to match the framework. Unsurprisingly, this leads to frustration and missed outcomes.

What is a Mental Model? 

A mental model is a simplified, internal representation of how something works. The concept of mental models originated in cognitive psychology and was popularized by psychologist Kenneth Craik in the 1940s. He proposed that the human mind builds small-scale internal representations of reality to anticipate events and make sense of the world. These representations, mental models, help us process information, solve problems, and make decisions.

A mental model can be defined as one’s internal thought representation of how the real world works. It’s how we interpret experiences, understand cause and effect, and predict outcomes. These models influence how we approach challenges, interact with systems, and even how we communicate.

As Shane Parrish, author of The Great Mental Models, puts it: “Since we cannot keep all the world's details in our brains, we create their representation.”

Think of mental models like maps, small enough to carry around, yet detailed enough to help us navigate complex terrains. They’re not perfect, but they’re essential for clarity, focus, and informed decision-making in any environment.

Everyday Examples of Mental Models

We all use mental models, often without realizing it. Some of our earliest mental models form in childhood, shaped by experiences, stories, or the way we’re taught to make sense of the world.

• Cause and effect: As kids, we learn that if we touch a hot stove, we’ll get burned. This simple cause-and-effect model shapes how we approach danger.

• Fairness: “If I share my toys, others will share theirs.” A foundational social model we carry into adulthood when collaborating or negotiating.

• Trial and error: Learned while riding a bicycle or tying shoelaces, this model teaches persistence and incremental learning.

• Scarcity vs. abundance: Growing up in a household where money was tight might lead to a scarcity mindset, believing resources are limited, which can shape financial decisions later in life.

Mental models are not fixed truths; they evolve. But the ones we carry from our early years often influence how we work, lead, and make decisions as adults.

What is the Scrum Mental Model?

I remember reading The Great Mental Models by Shane Parrish and instantly thinking, “We can look at Agile the same way.” Instead of clinging to one tool or framework, it’s much wiser to build a mental toolbox filled with diverse models, methods, and thinking patterns. That’s how we can solve real problems in complex environments.

Most teams see Scrum as a fixed set of steps—Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective, a recipe to follow. This is where many fall into trouble. They adopt the Scrum process model, thinking, "If we do these things, we’ll become agile." That’s a broken mental model.

However, they overlook the deeper reasoning behind Scrum: to facilitate navigating complex product development through empiricism, collaboration, and continuous learning. They are doing Scrum activities, but missing the mindset behind them:

• “Why are we doing Sprint Reviews?” → To get feedback early.

• “Why do we inspect and adapt?” → To navigate uncertainty.

Instead of treating Scrum like a checklist, we need to treat it like a map, a mental model for solving complex problems in a world full of uncertainty. And like any good map, it has symbols, tools, and coordinates to help teams find their way.

Scrum Process Model Diagram

To better understand Scrum as a mental model, it helps to visualize how the framework actually flows. The Scrum process model diagram represents the key events, roles, and artifacts that guide a team’s work within a Sprint. But remember,  this isn’t just a process to follow blindly. Each element in the diagram exists for a reason: to help teams inspect, adapt, and deliver value incrementally.

When viewed as a mental model, this diagram becomes more than just a flowchart; it becomes a tool to help teams think more effectively, make decisions faster, and navigate complexity with clarity. Here’s how it looks:

The Agile Scrum Models as a Mental Toolbox

Scrum is part of the broader agile scrum model, which emphasizes iterative development, customer feedback, and adaptability. But it only works when teams use it mindfully, not mechanically. The scrum software development model isn’t about doing Agile; it’s about thinking Agile.

Think of it this way: instead of fitting Scrum into problems, use Scrum to frame how you think about the problems. So how do we apply the Scrum model as a mental model? Let’s break it down by some core elements:

1. Empiricism

What it is: Learning through experience, observation, and experimentation.

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.

2. Rules

Example: Only one Product Owner per team.

Purpose: A Single accountable person to avoid digressions and make 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 than Pizza.

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

3. Values

Example: 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 Scrum theory and 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.

How the Scrum Mental Model Helps Teams?

Applying Scrum as a mental model means using its elements to think critically, respond adaptively, and solve problems together. Here's how it plays out across roles:

Scrum Masters: Scrum Masters must shift from being “process police” to “thinking coaches.” Their job isn’t to enforce the scrum process model diagram, but to help the team understand why each element exists. They help the team build the thinking patterns that turn Scrum from mechanics into mastery.

Product Owners: Product Owners benefit from using Scrum as a lens for value-based prioritization. It’s not just about managing a product backlog, it’s about asking: What’s the smallest valuable thing we can deliver? How do we measure success? They make trade-offs based on context, not rules.

Developers: For developers, Scrum is less about story points estimation or daily standups and more about shared ownership and iterative learning. When developers use the Scrum software development model as a mental model, they’re constantly thinking, "What do we know now?" What can we improve in the next sprint?