It has been our experience that people often reach different conclusions with the same words because they are blending different metaphors together with different outcomes. Additionally, we have observed that that once people become aware of the differences in their applied metaphors they can quickly see each other’s point of view. These metaphors are powerful reasoning models that are deeply connected to how we understand and reason. One of the success factors of Scrum as an agile product development framework has been its powerful language. The language of Scrum has been built up to form a coherent metaphorical framework that encourages the adoption and emergence of agile product development practices. As with all models we create to help us understand, we need guides on how to use the tools. We will be pointing out the boundaries where the Scrum language can become confusing—and, in so doing, hopefully make adoption and application easier.
Many of our thought processes for understanding and reasoning are metaphorically based, so it stands to reason that we need to know something about metaphors. First, let’s look at the dictionary definitions of metaphor and its cousins simile and analogy as found in the Merriam-Webster Dictionary
Metaphor is “a figure of speech in which a word or phrase literally denoting one kind of object or idea is used in place of another to suggest a likeness or analogy between them (as in drowning in money); broadly”.
Analogy is “correspondence between the members of pairs or sets of linguistic forms that serves as a basis for the creation of another form”.
Simile is “a figure of speech comparing two unlike things that is often introduced by like or as (as in cheeks like roses)”.
As we see, the definitions of analogy, simile and metaphor are all similar, which may be why we struggled in school to keep them distinct. We believe these are “distinctions without a difference” and thus will use the term metaphor for the purposes of this article and leave analogy and simile for English class. Throughout this paper we will apply the use of conceptual metaphor and metaphorical reasoning as has been defined in Lakoff’s and Johnson’s work to explore where the metaphors of Scrum lead us.
Before exploring Scrum’s metaphors, let’s pause briefly to explore some common examples of metaphorical reasoning that we often encounter in everyday language. This will help us build context for exploring the metaphors at work in Scrum. Here are a few examples:
- “Let me make my point.” Is an argument really a point? Or do I visualize it in my head as a point? At the time I might be visualizing, “If I can make my argument pointy enough I can use it to punch through to my goal”.
- “Your statement is light.” Can we make statements heavier? I might be thinking, “If my argument has enough mass it will be valid because of the sheer size”.
I might use all of these phrases in one conversation to help me communicate. This would be blending the metaphors together to reason about something. Even as I write I am forced to use metaphors to express my thoughts. Thus, we are constantly playing with our words in metaphorical ways in order to help understanding. In other words, we are constantly using these conceptual models to help us reason.
Now we will discuss some common metaphors that we find in the Scrum language. These metaphors are not necessarily right or wrong—they are just ones that we have found that work for us when reasoning. Our goal here is to consider the strengths and weaknesses of each.
Scrum as a “game”
The metaphor “Scrum as a game” evokes a sports concept in our heads and brings up the notion of competition or struggle (see Mike Cohn’s website and Ken Schwaber’s website). This might cause us to ask, “What are we competing or struggling against?” or to wonder if we are trying to create space in the organization by locking arms and keeping “intruders” and “peddlers” out. Another way of thinking of this metaphor is to evoke the notion of agility as a “cooperative game” as popularized by Alistair Cockburn.
The most obvious pitfall of this metaphor is that one might conclude that our job is to fight against the organization or against other people.
We have found that it is better to use this metaphor to mean that we are competing against the complexity of the universe to bring a product to life. Our opponent is the universe, not other people or the organization. Indeed, in various conversations we have found this is often closer to the dominant model at work in the author’s heads.
Product Backlog is a “pile of work to-do”
The metaphor “the product backlog is a pile of work to-do” evokes a concept that we have a specific product with lots to do that is not being done. It sets up a sense of urgency by the very use of its name “backlog” and encourages a product focus. This is powerful as it focuses the team on the needs of the product. The other deeper issue that this metaphor highlights is the deep struggle of “managing the work.”
We have found two common pitfalls in using this metaphor. The first is that the team is often late and must be pushed to clear up the backlog. This force to produce often leads to technically unsound work, resulting in systems that quickly become brittle.
The second common pitfall is the use of the word product. When people hear “product backlog” they often conclude that there exists an actual product and only things that actually produce part of the product go in the backlog.
This second pitfall is actually the worst. Often we see teams struggling because they have not included things in the backlog, and thus must get done as ‘overhead,’ if they get done at all. For this reason we have a simple rule for detecting if two things belong in the same backlog: two items belong in the same backlog if they compete for the same resources. We also refer to it simply as “backlog” rather than “product backlog” in order to remove the bias that excludes work simply because it does not produce product directly.
The Sprint is a “burst of energy to cross a finish line”
This is what a sprint is in track and field, and it leads to the notion that Scrum’s Sprint creates a constant sense of urgency. But do people conclude that they will run out of breath by running as hard an absolutely possible for the duration? What about sustainable pace? We have seen people shy away from this language when they are thinking that work is now going to be a series of exhausting breathless races.
We prefer to think of the sprint not by the speed, but the track. You can see the end line and get there in a straight line. The distance is short (thirty days or less) and has a clear end point based on the product owner’s definition.
Other Common Metaphors
There are other metaphors about agility that we could explore at some point in the future. We plan to keep a growing list of them at AgileAnalyst.com, but here are some of the more popular ones:
- Backlog items are “formless.” An item can be anything is very open and elegant in its lack of constraints. At the same time, the very formless nature of a backlog item often produces anxiety when a person hears that it can be anything.
- Sprint Planning sets “driving directions.”
- Sprint Demo is “product that is ready to ship.”
- Retrospection as “learning from history.”
- Product Owner is “the driver.”
- ScrumMaster is “the doctor.”
- “Scrum is a framework” or is an “outline that gets filled in.” Well, not exactly and not all the time. Scrum out of the box provides many prescriptive starting points. However, Scrum’s big rule that the team owns its process is often interpreted to mean that anything goes.
There are many other metaphors that we use when we discuss agile software development but, for the sake of brevity for this paper, the authors will limit the discussion to what we have discussed so far.
We hope that it is now apparent that we use metaphors all the time to reason about the world. Scrum is described by a collection of powerful metaphors that have been used successfully to engage and focus the intellectual energy of teams that are working on projects in the face of complexity.
We have found that being aware of the metaphors in Scrum (and agility in general) and how they are being applied in common dialog can have a tremendous influence on teams and get them up to “norming” much more quickly.
It is our hope that this paper will help raise the consciousness of the Scrum community and organizations seeking to implement Scrum. And it will serve to guide others in their application of Scrum’s metaphors to reason about product development.
The works contained here are creative commons license.