Masters Dissertation

Advantages and Disadvantages of Scrum Methodology (Agile PM)

Advantages and Disadvantages of Scrum Methodology

Abstract

Designed with the primary intent of correcting many of the limitations of traditional methodologies, Scrum has risen fast to become the most preferred project development methodology today. This paper seeks to present an objective appraisal of Scrum’s capabilities and to recommend a sound approach to maximizing the outcomes of Scrum by facilitating its strengths while suppressing its weaknesses.

Advantages and Disadvantages of Scrum Methodology

Photo by David Travis on Unsplash

Introduction

Project development is a complex process with countless variables and obstacles which are hard to keep track of simultaneously for maximum efficiency. In order to overcome this hurdle project developers use systems development methodologies (SDMs) which are essentially a collection of processes and procedures that are designed with specific obstacles in mind (Ferreira et al., n.d.; James, 2014). The traditional project development methodologies, prominently including waterfall are formulated with only the unpredictable aspects visible at the beginning of a project development cycle in mind. The waterfall model is linear and sequential and this has the implication that once the process has reached a certain stage, there can be no turning back to review the process (Scheid, 2015). The waterfall model points to the analogy of a waterfall where the water cannot turn back to the top once it has started falling over the edge of the cliff. As such, these methodologies are limited in terms of their responsiveness to the changes that occur once the project has begun (Sundararajan and Mahalakshmi, 2013). Many methodologies have been developed along the way to afford flexibility along the life of the project. Such methodologies are known as Agile methodologies. Both Agile and waterfall methodologies employ an iteration based model where the product is not passed on to the next iteration until the workload for that iteration is done (Maximilien & Campos, 2012). The real difference between Agile and waterfall is that in Agile, there is evaluation of each iteration before it is passed along while in waterfall, the project flows along without stopping and the chances of a good outcome are pegged on hope (Scheid, 2015, Ashbacher 2010).

Short preview of Agile methodologies with a special focus on Scrum

Agile project development refers to a group of frameworks that are based on an iterative and incremental format. Agile came into being with the drafting of the Agile Manifesto in 2001 by a group of project development pioneers at a meeting held in Utah (Cobb, 2011). The main aim of the Agile Manifesto was to overcome various shortcomings associated with traditional plan-based project development approaches. The main emphasis of the Agile Manifesto was on communication and collaboration, team self-independence, continually functioning software and flexibility to new business realities (Erquicia, 2005). The more recognizable Agile technologies include extreme programming, feature-driven development (FDD), dynamic system development method (DSDM), adaptive software development (ASD), Crystal and notably Scrum.

Scrum is one of the most popular Agile methodology and in fact, the two terminologies are often erroneously interchanged. In reality though, Scrum is a subset of Agile. Scrum was proposed in 1995 by Ken Schwaber with an aim to eliminate the inefficiencies caused by what he termed as “heavy methods” (Sutherland, 2015). According to the Agile manifesto, the highest priority of Scrum is client satisfaction. The main characteristic of Scrum is that the project is implemented in fixed length iterations known as sprints. Each sprint typically lasts between one and four weeks. At the end of each sprint, stakeholders, including the client meet and an iteratively shippable product is presented (Sutherland, 2015; Cobb, 2011). This means that unlike in traditional software development methods where a working product in many cases only emerges after the very last step in the process, in Scrum the product remains functional throughout the development process. During each sprint, the requirements remain fixed in order to increase the probability of success. Scrum, as is the case with most Agile frameworks is suitable for projects that have rapidly changing requirements (Cobb, 2011).

The team in Scrum is composed differently from traditional methodologies, with three main roles defined; the product owner, the Scrum master and the development team. The product owner can be viewed as the overall authority over the product and he or she is responsible for providing product vision. The Scrum master is the bridge between the product owner and the development team. They are deeply knowledgeable in the work being done by the team and they have the duty to coach the product owner and the team. Szalvay (2015) describes the role of the Scrum Master as that of putting out fires. They enforce the rules, remove impediments to the team’s progress while encouraging communication and self-organization. Szalvay classifies the impediments that obstruct the team as either technical (broken equipment), personal (e.g. a non-cooperative member), organizational (lack of support from management), situational (lack of a conducive workplace) or developer-centric (technical debt arising from a legacy system). The Scrum team, or development team are the actual work horses and it is made up of individuals with varying skill sets. The ideal size of a team in Scrum is between 5 and 7 members (James, 2014). In the respect that Scrum emphasizes a unitary approach, the term Scrum as applied in this methodology has superficial parallels with its application in rugby. In rugby, Scrum refers to a team pack in which each member works in unison with other members of the pack to move the ball down the field.

The various Scrum meetings are a prominent aspect in Scrum methodology and are important factors in its success.

Sprint planning meeting: this takes place at the beginning of each sprint. During this meeting, the team decides which items in the product backlog are most important. These are then determined as components of the team’s agenda during the course of the sprint.

Daily Scrum and sprint execution: the daily Scrum meeting is held for a brief period (about 15 minutes) each day to allow each member to brief the team on what they did the previous day.

Sprint review meeting: this meeting is held at the end of each sprint. Here, the development team demonstrates a working product increment to the client and other interested stakeholders. Incomplete items are returned to the product backlog for implementation during latter sprints.

Sprint retrospective meeting: The main aim of this meeting is to review the team’s operation during the concluded sprint and it signifies the end of the sprint. The team then comes up with actions to help it improve its delivery during future sprints.

Backlog refinement meeting: during this meeting, the team deliberates on the product backlog for the next sprint planning meeting. In short, the team seeks to identify impediments and out forward possible solutions to these inefficiencies.

Advantages and Disadvantages of Scrum Methodology

Figure 1: Scrum flow (James, 2014)

Aspects of Scrum flow

This is an ordered list of requirements towards the product that is maintained throughout the project. The product backlog items are ordered in terms of priority by the product owner and are shared with all stakeholders.

Sprint backlog: This is the list of work items that the development team is supposed to handle during the next sprint.

Burndown chart: This is a chart that that shows the remaining work in the sprint backlog. It is updated every day and gives a simplified representation of the sprint progress.

Research Methodology

The research method employed in this dissertation involves a combination of documentary analysis and firsthand information collected from interviews with some experienced industry players. This research approach seeks to harmonize conclusions from three case studies and other literature in order to state postulations and support these with solid evidence.

Case Study 1

This research effort involved a development organization with operations in Malaysia and Norway seeking to carry out an assessment of the success of Agile practices on a small distributed system. Granted, this case cannot be classified as an integrated project, which is the main subject of investigation in this paper. However, its findings qualify as valuable insights into the implementation of integrated projects due to the uniformities that exist across different types of projects. The researchers specifically set out to find a globally distributed project which had used one or more agile techniques for some time, settling on this one. The developers were in the course of developing a program known as EnergySoftware for oil and energy companies. The product is already rolled out for several customers so the current development seeks to create a new versions of the program. The development effort is distributed between two countries, Norway and Malaysia. The operations in Malaysia were put in place as part of a larger plan to lower costs by moving operations to offshore destinations. The organization in the case study is an IT company with operations around the world. Its main activities are located in Europe and the offices in Malaysia are its main operations base in Asia. The project development team is composed of 40 people, divided equally between the Norway and Malaysia at the time of the study the company had been using scrum for one and a half years. Before that, the development process was a combination of various waterfall models. The transition to scrum was facilitated by a three month trial run after which it was deemed worth implementing. The company employs a scrum team of between two and nine members and this kept changing across different projects and from iteration to iteration. All the product owners as well as three scrum masters are based in Norway, with Malaysia playing host to one Scrum master. This means that some teams in Malaysia have all developers in Malaysia and only their product owner in Norway. The development teams worked in sprints of four weeks each. Each team held a daily 15 minute scrum meeting with product owners and Norway-based developers participating through teleconferencing. The researchers collected data using semi-structured, open-ended interviews with various stakeholders in the product development process. In total, the team interviewed four people in the Norway arm face to face and three (two over the phone and one face-to-face) from Malaysia, with each interview lasting between one and two hours. The recorded interviews were then transcribed in the presence of one of the interviewers who had participated in the interviews.

Case study 2

The second case study featured was carried out by Telematicum Inc in 2013 with the aim of developing a communication product known as TeleWeb as well as the redesign of their user interface christened Smart Client. The name of the company as well as those of the products is altered in order to hide the real identity of the case company. The company turned to Scrum for the development of TeleWeb while the redevelopment of Smart Client followed the Sashimi Waterfall methodology. This diversified approach allowed the team to draw comparisons on different aspects of the two nearly homogenous products as they were developed following the two competing methodologies. The TeleWeb project consisted of around 100 members divided into several development teams each varying in size from 7 to 12 members. The project lasted 10 months and was divided into sprints of 4 weeks each. The teams shared a common backlog from which each team was assigned tasks. The only major deviation from the Scrum manifesto was the number of team members which was markedly different from the recommended range. The Scrum master of the TeleWeb team was interviewed using questionnaires in order to evaluate the project.

Case Study 3

The third case study is essentially a pilot program that sought to assess the suitability of scrum as a product development engineering (PDE) tool at Intel. Intel was at the time using variations of waterfall techniques which had been optimized to provide the best path to success. Danube Technologies were earmarked as the scrum coach and sought to help Intel introduce scrum to the organization at the beginning of a project. The thinking of the company was that if scrum could work at during the early phases, then it could also be applicable at latter more complex phases. The entire development team was comprised of 50 people. In order to fulfill scrum principles, they were divided into 7 sub teams each of which represents an actual scrum team. The project is presented in three phases; Preparing for Silicon, Surviving Silicon and Preparing for Manufacturing. The first phase was basically a training run, with experts from Danube Technologies conducting a two-day Certified Scrum Master training course with group and technical leads. A retrospective meeting among was held by participants in the absence of Danube representatives, with the team leaders agreeing to commit to three months of implementing scrum in the company. At the end of the three month trial period, the team would start working with an external client rather than the team functioning as its own customer. The qualitative data that resulted from the case study was mainly collected through an observational approach with unstructured interviews being used periodically at the researchers’ discretion.



Copyright © 2023 Author(s) retain the copyright of this article.
This article is published under the terms of the Creative Commons Attribution License 4.0