Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

The TechDebt Game -- Enabling Discussions about Technical Debt

Marion Wiese, Angelina Heinrichs, Nino Rusieshvili, Rodrigo Rebouças de Almeida, Klara Borowa

TL;DR

This paper addresses the difficulty of communicating Technical Debt (TD) concepts to diverse stakeholders by designing the TechDebt Game, a board game that emulates TD dynamics in a safe, collaborative setting. The authors evaluate the game with 46 practitioners across 13 sessions (offline and online), analyzing aha-moments, perceived realism, and attitude/behavior changes toward TD management. Results show the game realistically mirrors real TD experiences, yields new insights—especially for business and junior stakeholders—and can shift perspectives toward more proactive TD management, though long-term impact remains to be demonstrated. The work offers a practical tool to harmonize TD knowledge, stimulate discussion, and serve as a starting point for embedding TD management into software development life cycles, with future work needed on longitudinal effects and company-wide deployment.

Abstract

Context. Technical Debt (TD), defined as software constructs that are beneficial in the short term but may hinder future change, is a frequently used term in software development practice. Nevertheless, practitioners do not always fully understand its definition and, in particular, conceptual model. Previous research highlights that communication about TD is challenging, especially with non-technical stakeholders. Discussions on this topic often cause conflicts due to misunderstandings related to other stakeholders' perspectives. Goal. We designed a board game to emulate TD concepts to make them tangible to all stakeholders, including non-technical ones. The game aims to encourage discussions about TD in an emulated and safe environment, thereby avoiding real-life conflicts. Method. To evaluate the game's effectiveness, we surveyed 46 practitioners from diverse domains, positions, and experience levels who played the game in 13 sessions following extensive testing during its development. In addition to the players' general feedback, we examined situations where players recognized new insights about TD or connected game scenarios to real-life experiences. Results. Overall, the feedback on the game and its enjoyment factor were highly positive. While developers and software architects often connected game situations to their real-world experiences, non-technical stakeholders, such as scrum masters, product owners, and less experienced developers, encountered multiple new insights on TD. Numerous players have shifted their attitudes toward TD and have outlined a plan to modify their behavior regarding TD management. Conclusions. Although the game may not lead to long-term behavior change among stakeholders, participants' feedback provides evidence that it might serve as a valuable starting point for team discussions on technical debt management.

The TechDebt Game -- Enabling Discussions about Technical Debt

TL;DR

This paper addresses the difficulty of communicating Technical Debt (TD) concepts to diverse stakeholders by designing the TechDebt Game, a board game that emulates TD dynamics in a safe, collaborative setting. The authors evaluate the game with 46 practitioners across 13 sessions (offline and online), analyzing aha-moments, perceived realism, and attitude/behavior changes toward TD management. Results show the game realistically mirrors real TD experiences, yields new insights—especially for business and junior stakeholders—and can shift perspectives toward more proactive TD management, though long-term impact remains to be demonstrated. The work offers a practical tool to harmonize TD knowledge, stimulate discussion, and serve as a starting point for embedding TD management into software development life cycles, with future work needed on longitudinal effects and company-wide deployment.

Abstract

Context. Technical Debt (TD), defined as software constructs that are beneficial in the short term but may hinder future change, is a frequently used term in software development practice. Nevertheless, practitioners do not always fully understand its definition and, in particular, conceptual model. Previous research highlights that communication about TD is challenging, especially with non-technical stakeholders. Discussions on this topic often cause conflicts due to misunderstandings related to other stakeholders' perspectives. Goal. We designed a board game to emulate TD concepts to make them tangible to all stakeholders, including non-technical ones. The game aims to encourage discussions about TD in an emulated and safe environment, thereby avoiding real-life conflicts. Method. To evaluate the game's effectiveness, we surveyed 46 practitioners from diverse domains, positions, and experience levels who played the game in 13 sessions following extensive testing during its development. In addition to the players' general feedback, we examined situations where players recognized new insights about TD or connected game scenarios to real-life experiences. Results. Overall, the feedback on the game and its enjoyment factor were highly positive. While developers and software architects often connected game situations to their real-world experiences, non-technical stakeholders, such as scrum masters, product owners, and less experienced developers, encountered multiple new insights on TD. Numerous players have shifted their attitudes toward TD and have outlined a plan to modify their behavior regarding TD management. Conclusions. Although the game may not lead to long-term behavior change among stakeholders, participants' feedback provides evidence that it might serve as a valuable starting point for team discussions on technical debt management.

Paper Structure

This paper contains 28 sections, 4 figures, 2 tables.

Table of Contents

  1. INTRODUCTION
  2. RELATED WORK
  3. THEORETICAL BACKGROUND
  4. Game-based Learning
  5. Game Design
  6. TECHDEBT GAME
  7. Game design, elements and mechanics
  8. Game Design Iterations
  9. Summary
  10. METHOD
  11. Sample
  12. Data collection
  13. Data Analysis
  14. RESULTS
  15. RQ1: To what extent does the game emulate the real-life experiences that technical stakeholders encounter?
  16. ...and 13 more sections

Figures (4)

  • Figure 1: Overview of the Game Board (details see AdditionalMaterial
  • Figure 2: Example for dependencies created by incurring TD (red tiles) -- only rolling a six will complete tasks
  • Figure 3: Percentage of players that had the respective aha-moments for all players and per stakeholder category
  • Figure 4: Average new insights (I had the aha moment, and it is new to me) and average real-life connections (I had the aha moment, and it is not new to me) per stakeholder category.