What do the players of the online game Farmville have in common with the members of a project team? At first glance, not much & #8211; some build a virtual farm, others develop a product. A closer look reveals one thing in common: Both invest time and effort in achieving goals.
What happens if a Farmville player gets tired of continuing to play? The hard-earned progress in the game disappears again. And this is where the problem begins: the decision to continue playing is not made rationally. Instead of thinking about what the future costs and benefits will be, consider how much time has already been invested in the game. This time invested cannot be regained. However, so that it does not become "lost time", the player decides to spend more resources.
So although rationally it would have been the right decision to quit the game because there would be more value in spending time differently, you keep playing. A good concept that the Farmville developers came up with.
Example of “sinking costs”
The following example shows what this has to do with a project team: After a long product development phase, the finished product is finally ready. The team is satisfied, after all, they put a lot of resources (both temporally, cognitively and financially) into the development. The next step is the presentation to the customer.
The team goes in optimistically, it comes out shaken: The customer imagined the finished product differently, the requirements have changed. Now the team is faced with a decision: Either it starts from scratch and develops a new product, or it retains the product that has already been developed (but does not meet customer requirements) and changes a few small things.
The team should rationally decide to develop a new product that meets the requirements and wishes of the customer. If it weren't for the many resources it has already invested in development - those stupid sunk costs.
Why can't we let go?
The Sunk Costs-Fallacy describes exactly this case, in which further resources are invested in something that has proven to be unsuccessful or even wrong (Arkes & Blumer, 1985). People or teams who are subject to this decision error usually have three things in common (Bryer, 1992):
- You have already invested a lot of time, money, work, etc.
- The resources invested did not lead to success.
- You can decide what to do now: invest more resources in the project or cancel the project.
The question remains why we are trying to save the ship that has already sunk. The psychologist and Nobel laureate in economics Daniel Kahneman holds with his Prospect Theory an explanation ready: people are afraid of losses (Kahneman & Tversky, 1979). This fear goes so far as to invest in the unlikely opportunity to successfully complete a doomed project, rather than accept the sure failure.
Sunk Costs vs. Customer orientation - Scrum as a solution?
It is obvious that sticking teams to failed projects goes against any customer benefit. But what can teams do to avoid that Sunk cost fallacy to succumb to? The answer to this lies in agile working. Customer orientation is one of the most important principles there. With this prioritization of customer benefit, the investment of even more resources can be prevented.
When Scrum teams work, the customer is involved in the entire development process so that it can react quickly to changing customer needs. A constant exchange ensures that the moment of shock does not occur at the end of the development phase, when it becomes clear that the customer has expected a different product.
We are willing to discard work done when new insights about customer needs demand it. (Echometer item)
Specifically, it looks like the teams in short sprints work. Initially, it is determined what will be worked on in the next few weeks. At the end of the sprint, it is checked whether the goals set have been achieved. An important tool that Scrum teams should use is user stories. These translate the customer's requirements into a user-centered statement about the product according to the format:
As a role
After creation, the user stories are transferred to the product backlog and provide the substantive basis for the work of the development team. Like many concepts in Scrum, user stories are not static: when the customer's requirements change, the user story also changes.
This enables extremely high customer orientation. Since Scrum teams are self-organized, it is important to analyze the user stories of the last sprint in the sprint retro. For example, reasons can be collected for why a certain story went well or badly to ensure continuous improvement.
Would you like to develop as a team? And to take the latest psychological findings into account? Then we recommend our team workshop Retro Tool. Here are Holger's experiences with it:
In a nutshell...
The iterative approach of Scrum teams and the constant review of customer needs helps to avoid wasted costs. The product increments developed in the sprints should ideally not be too resource-intensive. As a result, the team gets involved with the new goals when the requirements change. Have you already experienced the problem of sunk costs in your team? Try to take up the topic in a retrospective and develop solutions together!
And if you are interested in more methods of increasing your performance in a team, you can use ours, for example article on the amazing truth behind the agile mindset watch.
Arkes, HR & Blumer, C. (1985). The psychology of sunk cost. Organizational Behavior and Human Decision Processes, 35, 124-140.
Bryer, J. (1992). The escalation of commitment to a failing course of action: Toward theoretical progress. Academy of management review, 17(1), 39-61.
Kahneman, D. & Tversky, A. (1979). Prospect theory: An analysis of decision under risk. Econometrica, 47, 262-291.