Is Agile Not Agile Enough? A Study on How Agile is Applied and Misapplied in the Video Game Development Industry

Abstract

Video games have become the most dominant and successful entertainment industry worldwide; however, many video game development (VGD) projects and studios struggle to succeed. At present, there are no commonly accepted VGD best practices or frameworks that can bring together the complex and competing needs of software engineering and creative production. Although studios are reportedly using agile frameworks, the actual extent of application and effectiveness of agile practices in the VGD context is unclear. Therefore, the aim of this study is to empirically determine how and why agile frameworks are applied in VGD. Semi-structured interviews were conducted with eight New Zealand VGD studios. It was found that the agile frameworks, Scrum and Kanban, must often be adapted from their conventional use to meet the needs of different pipelines and delivery milestones within the phases of VGD. However, it seems that not all the needs of VGD can be met by current agile frameworks. Furthermore, inexperience with agile practices often leads to misunderstanding and misimplementing them in ways that seem to contribute to commonly experienced collaboration challenges.

Scrum, Kanban or a Mix of Both? A Systematic Literature Review

“…Mob,Web, Lrn, Lib, Agile,Game 7- [9], [30], [33], [36], [37], [4], [43] Easy for transition and use Data, Lrn, Agile, Soft development…”

Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations

“…• two related to the sprint demonstration, namely: (12) sprint does not end with a demonstration, and ( 13) demonstration to the wrong audience.…”

“…McKenzie et al [12] conducted interviews with eight New Zealand video game development studios with the aim to empirically determine how and why agile frameworks were applied. In this extent, the authors recognized several limitations due to the common misunderstanding in key areas around project management and collaboration, demonstrated by missing retrospectives, and ambiguity related to the status of tasks.…”

“…[10] Disordered product backlog [7], [6] Extensive requirements documentation instead of user stories [7], [6], [9] User stories that are too extensive [11] PO without authority, has negligible influence on the selection of tasks to be implemented [7], [6] Stakeholder indecisiveness -requirements come from multiple stakeholders and compete for prioritization [8] Lack of unanimity whether the task has been completed [8], [12] An indirect customer who is service provider of its own customer [13] PO delegated by a client and does not understand the role [7], [6] Exact estimation instead of relative estimation of items [7] Item estimation imposed to the team [7], [6] No estimation of resources available for the upcoming sprint [9] Sprint planning meeting has no agenda [9] Sprint goal set at the end of the meeting or not at all [9] Not breaking large user stories into smaller ones during a meeting [9], [11] Disruptions in the development process -other areas of the project are developed in turn without one being completed [8] Adding items during sprint [8], [11], [7], [6] User stories are not fully refined [9] A burndown chart is not used [10] Semi functional teams [7], [6] Insufficient technical knowledge [8] Lack of business knowledge [8] No or too long waiting for feedback (lack of Sprint review or stakeholders do not show interest) [7], [12], [9] The sprint does not end ends with a demonstration [9] Demonstration for the wrong targets [9] Missing retrospectives…”

“…A total of 81 articles were found, which were then filtered by title, abstract and content. Finally, 8 articles were identified that described common Scrum antipatterns [6], [7], [8], [9], [10], [11], [12], [13].…”