SCRUM Software Development Methodology
Software development process or methodology (SDP) provides what to do to
undertake and advance a software product in finitely many steps which can be initiated,
repeated, defined, managed and optimized consequently. Apparently, the fundamental
partitioning of software development process into phases such as the analysis, design,
implementation, testing, release and maintenance phases respectively are however, depended
on the different SDP to fashion unique approach and technique on how these phases are to be
accomplished, including the order which must conform with the principles, rules and
pedagogy as reinforced by the SDP. (Lee, 2012) argued in the affirmative that, “Software
development is a process of communication. There are many approaches helping the
development to produce qualified software to stakeholders.” This distinctively altogether,
asserts that, the discretion of the deliverable expected for each phases are encompassed in the
organization of the SDP dialect of choice. SDP is under obligation to make adequate
description and decomposition of procedures, activities and tasks required to create desirable
outcome (Software product).
Advertently, software development starts as an expedition whose scopes is not
entirely predictable beforehand but which are discovered and unveiled along the line of the
development duration or after it is completed, (Lee, 2012) established the foregoing assertion
that, numerous software projects originated through insignificant size and were not disposed
to definite requirements pending when the projects have ended; this brands Scrum as most
suitable compared to any other development methodologies. Consequent upon the foregoing,
agile methodology and more precisely it Scrum variant will be discussed and analyzed in
great details. Scrum emerged as agile process for software development. However rather than
providing comprehensive, meticulous explanations of how the whole lot will be completed on
the project, considerable option is reserved to the software development team to choose. The
idea is so, for the reason that the team will know best how to resolve the difficult they are
encountered. For the reason discussed in the foregoing, a sprint planning meeting is
designated in relations of the anticipated outcome (an obligation to a set of sorts to be
advanced in the succeeding sprint) unlike the case with most methodologies. Scrum is
oriented on self-organizing, cross-functional team formation with no designated over all team
leaders as every member of the team can switch role interchangeably in the development
phases. There are two specific supports individual for the Scrum process, the Scrum Master
and the Product Owner respectively. The former assumed the role of the team coach, assisting
the team members in ensuring they observe the Scrum principles for the project. The later
assumed the responsibility of customers or users, business owner and guides the team toward
developing the right product.
(Gunga, et al., 2013) averred that Scrum, have productively delivered a solution to the
flaws of these customary prototypes. Through additional malleable lightweight processes,
agile methods purpose at supplying products earlier, with greater quality and decreasing the
risks of project botches by emerging greater value features in shorter repetitions. Suffice to
the foregoing, Scrum process is iterative and incremental, therefore the project is fragmented
into a sequences of consecutive sprints. Each sprint is time constrained, typically to between
a week and a calendar month. The Scrum model proceed with each sprint with a sprint
planning meeting, where the product owner and team discuss about the most important in the
order of priority items on the Scrum product backlog. The team members consequently
outline those items they can commit to and then create a sprint backlog, which represent the
tasks to be performed during the sprint. Scrum process recommends that each day of the
including the ScrumMaster and the product owner. The meeting is use to appraise issues;
discuss challenges and status update from each team member and as well as foster team
cohesion too. At the finish of each sprint the team members conduct a sprint review with the
product owner in attendance to provide feedback about the features which are added. To
close the sprint, a sprint retrospective meeting is conducted with all the team members,
product owner and the ScrumMaster in attendance to reflect on the past activities of the sprint
and opportunities which they present for the future sprints if any.
The primary artifact of Scrum project is the software product. The model expects each
sprint to complete or deliver a product or system that is potentially shippable at finish of the
sprint, other artifacts are the scrum product backlog that is a full list of feature that are not yet
added to the product. The product owner always ordered the Scrum product backlog so that
the team can accord attention to the foremost item in the ordered list. The product backlog is
created by populating it with user stories which is a description of feature from the perception
of the user or customer. There is however the difference between the sprint backlog and
product backlog, the former is the list of tasks to do by the team while the latter is the list of
features to be built into the product. The sprint burndown chart and release burndown chart
are other two artifacts which track the amount of work yet to be accomplished in either a
sprint or a release. This is useful to determine whether the sprint or the release is on schedule
if need be. (Ionel, 2008) however disposed that, “SCRUM is a management methodology,
developed in order to improve and maintain an existing system or a production prototype.
This methodology assumes the existence of a project and some source code sequences, which
almost always exist in the object-oriented software development due to class libraries.”
The Scrum process like any other disposed software development process is driven by
roles on whose shoulders rest certain responsibilities within the ecosystem of the whole
Owner and the Team. The ScrumMaster is responsible for instilling the doctrine and dogmas
of the Scrum process on the team and he is there to guide them through as demanded. The
product owner represent the interest of the customer and communicate customer requirement
to the team for development in a product backlog and he/she is available consequently during
the sprint review to ensure that the additional feature conform to the requirement. Lastly, the
third role is the team membership of the Scrum process which is formed as self-organized
and cross-functional body. There is no team leader appointed as every team member can
function in different responsibility in all the phases of the development. This idea draws close
team cohesion and together fostering the advantage of one indivisible team-work.
(Duraisamy, et al., 2013) argued that, “SCRUM is one of the famous Agile
methodologies which produces a product during small cycles called iterations and its
functionality of product increases during each iterations by adding new properties.” The
foregoing is where Scrum process draws it strength and the comparative advantage over other
methodologies, the fact that requirements cannot be entirely determined before or during a
development project disposed the Scrum process where development are segmented to
numbers of iterations or sprints as the best approach to such undertakings. Requirements can
be developed in a sprint and delivered while additional requirements can be requested
through subsequent sprints as scope change is unavoidable occurrence in software
development projects.
However (Mahnic, et al., 2012) opposed that, “Possible loss of management control is
one of the greatest concerns when adopting Scrum software development methods in
industrial practice. Therefore, monitoring progress of Scrum projects is an important issue in
the software industry.” This suggests that Scrum process is susceptible to loss of control at
the managerial level which can give rise to resources overrun for the development project, it
handicap of the scope, cost & budget, human and resource schedule and the quality
requirement of the project which can consequently lead to failure.
References:
Duraisamy, G. & Atan, R. 2013, "Requirement Traceability Matrix through Documentation for Scrum Methodology", Journal of Theoretical & Applied Information Technology, vol. 52, no. 2, pp. 154-159.
Gunga, V., Kishnah, S. & Pudaruth, S. 2013, "Design of a Multi-Agent System Architecture for the Scrum Methodology", International Journal of Software Engineering &
Applications, vol. 4, no. 4, pp. 1-18.
Ionel, N. 2008, "Critical Analysys of the Scrum Project Management Methodology", Annals of the University of Oradea, Economic Science Series, vol. 17, no. 4, pp. 435-441.
Lee, R.C. 2012, "The Success Factors of Running Scrum: A Qualitative Perspective", Journal of Software Engineering & Applications, vol. 5, no. 6, pp. 367-374.
Mahnic, V. & Zabkar, N. 2012, "Measuring Progress of Scrum-based Software Projects", Electronics & Electrical Engineering, vol. 18, no. 8, pp. 73-76.
Bibliographies:
NATHAN-REGIS, B. & BALAJI, V. 2012, "Evaluation of the most used Agile Methods (Xp, Lean, Scrum)", International Journal of Engineering Science & Technology, vol. 4, no. 1, pp. 23-29.
Paasivaara, M., Durasiewicz, S. & Lassenius, C. 2008, "Using scrum in a globally distributed project: a case study", Software Process: Improvement & Practice, vol. 13, no. 6, pp. 527-544.
Salo, O. & Abrahamsson, P. 2008, "Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum", IET Software, vol. 2, no. 1, pp. 58-64.
Hajjdiab, H., Taleb, A.S. & Ali, J. 2012, "An Industrial Case Study for Scrum Adoption",
Journal of Software (1796217X), vol. 7, no. 1, pp. 237-242.
