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.

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.