We claim that by exploring the metaphors of Scrum, many of the common confusions and debates surrounding Scrum are easier to understand. It has been our experience that people often reach different conclusions with the same words because they are using different metaphors. Additionally, we have observed that that once people become aware of the differences in their applied metaphors they can see each other's point of view more easily.
This article explores the use of metaphors as a way to understand and reason about Scrum. We will explore how metaphors encourage us to reason. Our discussion will cover our experiences in both the benefits and pitfalls of these metaphors as applied to Scrum development.
Like all models that have been created to help us understand there are shortcomings. In this article we will be identifying the boundaries where the Scrum language can become confusing and hopefully make adoption and application easier.
Introduction to the Idea of Metaphor
Metaphors are powerful reasoning models that are deeply connected to how we understand and reason - but there are always limitations when applied. One of the strengths of Scrum is its powerful language, which has been built up to form a coherent metaphorical structure.
It has been established that many of our thought processes for understanding and reasoning are metaphorically based,[1] so we need to know {sidebar id=1} 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[2].
Metaphor is quot;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.quot;
Analogy is quot;correspondence between the members of pairs or sets of linguistic forms that serves as a basis for the creation of another form.quot;
Simile is quot;a figure of speech comparing two unlike things that is often introduced by like or as (as in cheeks like roses).quot;
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 lsquo;distinctions without a difference' and thus will make use of the notion of conceptual metaphor as defined by Lakoff and Johnson;[3] use the term metaphor for it, 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:
- quot;Let me make my point.quot; Is an argument really a point? Or do I visualize it in my head as a point? At the time I might be visualizing, quot;If I can make my argument pointy enough I can use it to punch through to my goal.quot;
- quot;Please stay at 50,000 foot level...quot; Will we really travel to or stay at the 50,000 foot level to have a discussion? How do we get there? What do we mean 100,000 foot view, 50,000 foot view or 100 feet off the ground?
- quot;Your statement is light.quot; Do we make statements heavier? I might be thinking that quot;If my argument has enough mass it will be valid because of the sheer size.quot;
Again, I might use all of these as techniques in one conversation to describe. 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.
Scrum's Metaphors
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 them and the strengths and weaknesses of each.
Scrum as a quot;Gamequot;
The metaphor quot;Scrum as a gamequot; evokes a sports concept in our heads and brings up the notion of competition or struggle.[4] This might cause us to ask: quot;What are we competing or struggling against?quot; or wonder if we are trying to create space in the organization by locking arms and keeping quot;intrudersquot; and quot;peddlersquot; out.[5] Another way of thinking of this metaphor is to evoke the notion of agility as a quot;cooperative gamequot; as popularized by Alistair Cockburn.[6]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 quot;Pile of Work To-Doquot;
The metaphor quot;the product backlog is a pile of work to-doquot; 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 quot;backlogquot; and encourages a product focus. This is powerful as it focuses the team on the needs of the product. The other deeper issue that gets highlighted as the deep struggle of quot;managing the workquot;[7] becomes apparent.
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 quot;product backlogquot; 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 them done as lsquo;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 resources. We also refer to it simply as quot;backlogquot; rather than quot;product backlogquot; in order to remove the bias that excludes work simply because it does not produce product directly.
The Sprint is a quot;Burst of Energy to Cross a Finish Linequot;
This is what a sprint is in track and field, and 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 you get there in a straight line. The distance is short (30 days or less) that 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 quot;formlessquot; An item can be anything is very open and elegant in it's lack of constraints. The very formless nature of a backlog item often anxiety when a person hears that it can be anything.
- Sprint Planning sets quot;driving directionsquot;
- Sprint Demo is quot;product that is ready to shipquot;
- Retrospection as quot;learning from historyquot;
- Product Owner is quot;the driverquot;
- ScrumMaster is quot;the doctorquot;
- quot;Scrum is a frameworkquot; or is an quot;outline that gets filled in.quot; 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 lsquo;owns its process' is often interpreted to mean that anything goes...
There are many metaphors that we like 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.
Summary
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 by 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 quot;Normingquot; 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.
About the authors
Douglas E. Shimp is a CST (Certified ScrumMaster Trainer), Use Case expert, Agile Process expert, and a Managing Partner at 3Back. He has 16 years experience in the technology field. One of his distinctions is his focus on the interaction of technology and corporate cultural issues. He is currently writing a book on quot;The Product Owner.quot; He is certified by both Cockburn and Associates to teach quot;Writing Effective Use Casesquot; and Advanced Development Methods as a ScrumMaster Trainer.
Dan Rawsthorne is a CST (Certified ScrumMaster Trainer) and a Use Case expert who lives at the quot;process endquot; of things at Danube. His focus is on helping organizations get products quot;out the doorquot; using agility, and he has been doing so for over 20 years. He has a PhD in mathematics from the University of Illinois, and is currently writing a book on how to be a Product Owner. He concentrates his training and coaching in Use Cases and Scrum.
[1] quot;Metaphors We Live Byquot; by George Lakoff and Mark Johnson, 1980.
[2] http://m-w.com/dictionary (simile, metaphor, analogy) , 2007.
[3] quot;Metaphors We Live Byquot; by George Lakoff and Mark Johnson, 1980.
[4] Agile Software Development With Scrum, Ken Schwaber and Mike Beedle.
[5] http://www.controlchaos.com , Schwaber, 2007.
[6] See http://alistair.cockburn.us/index.php/Cooperative_game_manifesto_for_software_development , Alistair Cockburn, 2006.
[7] See http://www.danube.com/docs/Scrum_Metrics_for_Management.pdf , Rawsthorne, Schauwber, Barton. 2005.
