Introduction
In the field of software engineering the most popular development process adopted is the Waterfall model. This model encourages sequential phases of development whereby each stage of a project is completed before the next can commence, with a strong focus on structure. Despite the popularity of this method for software design and coding, the Waterfall model has continued to be criticised in the industry for being process heavy and resistant to the inevitable change which arises during development (McConnell 2004). The solution to this has come in the form of Agile development. Agile is an all-encompassing term that describes iterative approaches to software development that embrace the values described in the ‘Manifesto for Agile Development’. This manifesto was created in 2001 by 17 practitioners who advocated for a shift towards lighter development approaches and away from the heavy processes of Waterfall development (Ashmore & Runyan 2014). The manifesto states that Agile is a process for developing software that values “individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan” (Williams & Cockburn 2003, p. 39). In recent years, the use of agile methodologies for developing games has become common practice. Therefore, this report will examine the key concepts, advantages and disadvantages of eXtreme programming and scrum agile methods and then provide a discussion of why the scrum method would be an appropriate approach to develop an Indie game.
eXtreme Programming (XP)
The concept of eXtreme Programming (XP) was developed in the late 1990s by Kent Beck, Ward Cunningham, and Ron Jeffries during their time working at Chrysler and is often regarded as the original agile approach (Highsmith 2002, p.7). The methodology of XP is summarised by Beck and Andres (2004, p. 30) and includes three main components. First and foremost, XP is about social change. It recognises that certain habits and patterns which were adaptive in the past can interfere with a team’s ability to produce the best possible work in the present which may slow overall progress. Secondly, it is about being open about the team’s capabilities and expecting the same from others. Lastly, communication is an extremely important component of XP and ensures that there is clear and concise information shared between the team. All these components contribute to the philosophy of XP which is based on communication, feedback, simplicity, courage and respect (Beck & Andres 2004, p. 30). Further to this, XP favours smaller working teams. Within the team, key roles are established which allow the ability to provide technical advice to other members that may not be familiar with certain aspect of the project. These roles often include the customer, the tracker, the programmer, the tester, and the coach (Flewelling 2018, p. 82). Overall, the impact that XP has had on software development is that is forces organisations to re-evaluate whether their current processes are adding value to their organisations. The push for such programming often stems from the developers and testers themselves who are dissatisfied with the lengthy processes, metrics, and documentation imposed on them (Highsmith 2002, p. 7).
Advantages of XP
One of the clear advantages of XP is the focus on maximising communication (Murru et al. 2003, p. 39). In a systematic literature review conducted by Hummel et al. (2013) on the role of communication in agile methods, one of their key findings was that 95 of the papers reviewed reported that the most beneficial aspect of XP was more frequent communication within the team. Additionally, due to the structure of XP, projects which would traditionally take longer periods of time to complete can be cut down into shorted intervals, or stints. As the project times become shorter, distractions and time wasting are minimised as everyone is expected to work close together with open communication. As a result of this, overall project costs can be reduced as less time is needed to complete each task. A further advantage of the XP method is that the planning style is adaptive and therefore, mistakes are identified more frequently as feedback is passed between the team and testers.
Disadvantages of XP
In contrast to the above discussion, several disadvantages can also be identified when adopting XP. For example, as the focus is on programming and not the actual design of a project it is possible that issues may arise when the technical side of a brief is met, but not the design aspect. Further, whilst it has been noted that XP favours smaller teams, the implementation of this method within a larger team may lead to instances of over-communication. The advantage of informal face-to-face communication within smaller teams loses its effectiveness once more team members are added to the mix (Kajko-Mattsson 2008; Nevo & Chengalur-Smith 2011). The fact that smaller team sizes are favoured also means that the location of the team is often highly centralised, therefore, it is difficult for members to work from remote locations as this has an adverse effect on the flow of communication as the paradigm of XP is interrupted and interfered with. Finally, while it has been highlighted that the planning style of XP is adaptive, formal documentation is more difficult to process due to constant testing and reworking which in turn may result in avoidable errors reoccurring.
Scrum
Scrum is amongst one of the most popular agile methods and although first mentioned in the context of product development in 1986, it was formally announced by Ken Schwaber and Jeff Sutherland in 1995 (Flewelling 2018). This method applies the theory to software projects that development is unpredictable regarding the way in which things change during the cycle of production. The team environment is based upon daily communication and reference to goals that are achievable in short periods of time (Mahnic & Drnovscek 2005). The term ‘scrum’ is derived from an analogy of a software development team working like a rugby team towards a set goal. Traditionally, scrum has three primary roles. The first is the product owner, who is usually a member or stakeholder of the business who understands the job and is in direct contact with the team. The second is the scrum master. This role provides team members with the opportunity to lead and is often rotated upon completion of a project as it is not a role which requires someone in a position of power or of higher status. Last, but certainly not least, are the team members themselves who work on the project (Schwaber 1997). This method is structured around sprints which last between two to four weeks and are comprised of five main parts. The first is product backlog, which is reviewed by the product owner and scrum master before the start of every sprint and identifies the tasks that need to be assigned. This is followed by sprint planning meetings. These meetings outline the backlog of tasks and require all primary role members to be present. The final meeting before the commencement of the sprint is the aligning of tasks meeting. Once the backlog has been discussed, the team elects who is best suited to each task presented. A ‘burn chart’ is created which consists of time on the x-axis and scope on the y-axis. The chart is a visual aid to show the team how much work is remaining in the sprint. At the conclusion of the sprint there is a review whereby the team leader invites the stakeholders and demonstrates the progress made. The final meeting is the sprint retrospect. This is a short meeting which gives team members the opportunity to discuss the outcome of the sprint and what could be improved in successive sprints (Keith 2010; Ullman 2017).
Advantages of Scrum
Several advantages exist when adopting the Scum method in software development. For example, due to the direct relationship between the product owner, scrum-leader, and team members, the process of development is interactive. The conclusion of each sprint allows progress to be documented and measured at regular intervals and allows for more frequent feedback. Furthermore, the flexibility and structure of each sprint can alter the focus of what is being worked on which makes job burnout much less likely. Lastly, errors and mistakes can be identified quickly and efficiently due to daily meetings.
Disadvantages of Scrum
Conversely, disadvantages can also be identified with the scrum method. This includes the fact that documentation often takes a backseat to outputting software that works. This may cause issues when new members join the team as they can spend considerable time playing catch-up on how the software operates. It should also be noted that while burnout in the job can be considered a non-issue as every sprint varies, the end of each sprint can cause stress on team members to meet the deadline for development (Keith 2010).
Preferred Agile Method For Indie Game Development
As a newcomer to game development, my decision to adopt the scrum method for developing an Indie game arose from three contributing factors/thought processes:
- The ideology and methodology of how I would personally want to conduct a business fall within the limits of the scrum method. During almost 14 years in the workforce, my personal experiences in job satisfaction and fulfillment have occurred when I have built strong working relationships with managers/business owners and have been allowed the privilege of contributing to the decision making about business outcomes.
- As a typical Indie team does not have the same resources as a AAA company, time and money are a lot harder to come by. AAA companies have access to both these resources which allow them to produce content within a set timeframe. Since the time luxury is not as applicable to Indie companies, as less people usually work on a project, the scrum method can permit all members to have an input into the project. This is an advantage as it allows the game to evolve naturally. In the same way as time, money also plays a huge factor as it allows AAA games to be researched and developed by specialists. However, the same cannot be done by an Indie studio. It is not often that such studios will develop outside of what the team has/is already specialised in, and often the risks are not taken to venture outside of the known comfort zone.
- Lastly, as our current generation starts to take the reins of the workforce, newer adaptions of development standards should be a point of focus. The previous generations approach to design patterns using waterfalling project patterns and enforcement of strict boundaries to meet the project guidelines has seen a decline. An interesting report in Forbes magazine in April 2011 indicated that the use of any Agile method (and especially scrums) was:
“That hierarchical bureaucracy is a work culture that no longer fits the marketplace of 2011. Scrum works. It’s the traditional management culture that doesn’t work.” (Denning 2011)
As projects now desire more flexibility in features, engagement, etc; the old methods simply do not have the ability to keep up with agile methods when it comes to customisation and flexibility on the fly.
Outside of these factors, it is always advised to review the mistakes of others so that you can learn from them and progress from them. Post-mortems of games are a great way of gaining an insight into how some issues can arise. A common theme across most post-mortems are that design and communications are where it fails.
Conclusion
Agile methods in game development are a relatively new innovation which seek to provide lighter development approaches in comparison to the process heavy approach of the Waterfall model. This report presents a brief overview of eXtreme programming and scrum agile methods. A discussion of the advantages and disadvantages of both methods has demonstrated that agile methods are most effective when utilised in smaller teams. As the above personal statement highlights, it is important to consider which method will be best suited to the project at hand. Whilst there is a personal preference to adopt the scrum method for Indie game development, there is no universal approach to software engineering so the right agile methodology needs to be adopted to tackle the problems found in game development.
References:
Ashmore, S & Runyan, K 2014, Introduction to agile methods, Addison-Wesley Professional, United States.
Beck, K. & Andres, C 2005, Extreme Programming Explained: Embrace Change second edition, Addison Wesley Professional, United States.
Denning, S 2011, ‘Scrum is a major management discovery’, Forbes, viewed 26 September 2019 https://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/#5dc28b147782
Flewelling, P 2018, The Agile Developer’s Handbook: Get more value from your software development: get the best out of the Agile methodology, Packt Publishing Ltd.
Highsmith, J 2002, ‘What is agile software development?’, Crosstalk: The journal of Defense Software Engineering, vol. 15, no. 10, pp. 4-10.
Hummel, M, Rosenkranz, C & Holten, R 2013, ‘The role of communication in agile systems development’, Business & Information Systems Engineering, vol. 5, no. 5, pp. 343-355.
Kajko-Mattsson, M 2008, ‘Problems in agile trenches’, In Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement, pp. 111-119, ACM.
Keith, C 2010, Agile Game Development with Scrum, Addison Wesley Professional, United States.
Mahnic, V & Drnovscek, S 2005, ‘Agile software project management with scrum’, In EUNIS 2005 Conference-Session papers and tutorial abstracts, pp. 1-6.
McConnell, S 2004, Code complete: A practical handbook of software construction, Microsoft Press, United States.
Murru, O, Deias, R & Mugheddue, G 2003, ‘Assessing XP at a European Internet company’, IEEE software, vol. 20, no. 3, pp. 37-43.
Nevo, S & Chengalur-Smith, I 2011, ‘Enhancing the performance of software development virtual teams through the use of agile methods: a pilot study’, In 2011 44th Hawaii International Conference on System Sciences, pp. 1-10, IEEE.
Schwaber, K 1997, ‘Scrum development process’, In Business object design and implementation, pp. 117-134, Springer, London.
Ullman, D 2017, The Mechanical Design Process, David Ullman LLC, United States.
Williams, L & Cockburn A 2003, ‘Guest editor’s introduction: Agile software development: It’s about feedback and change’, Computer, vol. 36, no. 6, pp. 39-43.