SCRUM Methodology
PART I
Description
Scrum methodology is an approach used in the field of software technology development. This approach or better yet methodology is based on process management. The word ‘scrum’ is defined in English as a formation of players in a rugby game (a tight formation in which the players are united in a specific position). The term SCRUM in software technology, was first coined from a definition by Takaechu and Nonaka. According to these two it would be considered as a kind of ‘black box’. This methodology is an improvement of the iterative and incremental methodologies.
The SCRUM management methodology was developed in order to improve and maintain an already existing production prototype. What this approach does is that it assumes the existence of a project and some source code sequences that always exist in the object-oriented software development due to class libraries.
In essence, scrum may be defined as a framework within which one can employ various processes and techniques…within which complex products can be developed (Schwaber &Sutherland, 2009, p.3).
SCRUM features it uniqueness in form of the fact that it has an ‘empirical process control’. What this means is that it is uses the real world progress of a project to plan and schedule releases rather than guessing or using an uninformed forecast. It also ensures that projects are divided into succinct work cadences, known as sprints. These may last for between one to three weeks. At the end of each sprint, stakeholders and team members are supposed to meet to assess the progress of a project and in necessary, plan their next steps. This essentially allows the project’s direction to be adjusted or reoriented based on the already completed work and not assumption or predictions.
The releases in a SCRUM are usually planned taking into consideration variables such as user requests, meaning the needed improvements to the current system and the time pressure which is the needed timeframe to obtain a competitive advantage over others. Other variables include the predicted actions of the competitions, the work quality needed, the desired vision of the project and lastly the resources-both human and financial-needed for the successful completion of the project. These variables form the initial plan for any information system improvement; however, they can be altered during the project. SCRUM already puts this into consideration these variables and their dynamic nature.
Scrum, which is based on the empirical process control theory, employs an iterative or rather incremental approach to optimize predictability and control risk. It is able to do so through three main pillars.
SCRUM core pillars
Transparency ensures that all aspects of the process that affect the outcome are visible to those managing the outcomes. What this means is that should someone inspect the project and find it done, then it is well and truly done. The second pillar requires that the process have frequent inspections by experts to ensure that unwanted variances are detected and weeded out. The last pillar is adaptation and it requires that if the inspector determines from an inspection that one or more aspects of the process are outside acceptable limits, and therefore the resulting product will be unacceptable, the inspector must adjust the process or the material being processed. This has to be done as quickly as possible to avert further deviation.
SCRUM teams and their roles
A typical scram framework consists of two major components; scrum teams and their roles.
Scrum teams are meant to optimize maximum flexibility and productivity. This means that they are self-organizing, cross-functional and work in iterations. Each scram team has three major roles to play; the Scrum Master is responsible for ensuring the process is understood and followed; the Product Owner is responsible for maximizing the value of the work that the Scrum Team does; and the Team, which does the work.
Key features of the scrum methodology
The SCRUM process is divided into three general phases: planning and system architecture, development sprints and closure. These phases consist of well defined processes that work in tandem to ensure the successful completion of the project. Due to this fact, there are key features that pop up when the scrum methodology is employed. These features are integrated in the development process that makes it strong.
Iterative
The SCRUM process is iterative. This means the project is realized during successive cycles also known as iterations or sprints. This means that the functionality of the product increase during each sprint by adding new functions to the project. This also allows for the project to be open for further development up to the closing phase. Here, the deliverable can be changed at any time during the planning and the SPRINT phase. This allows or the project to remain adoptable to the complexity of the environment including the time pressure, competitive pressure and the financial and quality pressures that would be involved in the project management.
Flexibility
The planning and closure phases consist of processes very well known and defined. This allows for the project to be more flexible. The sprints flexibility allow for use of explicit knowledge about the process where applicable and where not possible the use of trial and error.
Unpredictability
The SPRINT phase processes which are undefined, uncontrolled, nonlinear and unpredictable. In short, the phase is impossible to control and as a result the phase is treated as a black box that needs no external control whatsoever. This control, which includes risk management, is however automatically placed on the iterative of each sprint to avoid chaos and to maximize flexibility.
Adoptability
The SCRUM process is not isolated from external factors such as financial, time, or competitive pressure up to its last phase. It can easily adapt to changing environmental conditions. The deliverable of the project is always based on the environment during the project.
Consistency
Scrum process is reviewed as often as necessary. This allows for the team to be able to work changes in or out of the project to be able to better the quality of the final product.
Where in terms of projects, SCRUM has been or is being used
The scrum methodology has been applied in a number of fields since its inceptions. This fields range from application in the successful running of big company projects such as the expansion of Google, the increase of sales in companies such as IBM or even the implementation of a web based application, to small individual matters such as wedding planning or house moving. The key issue if one wants an alternative that is watertight and with lesser failure rates then scrum would be the way to go.
PART II
Difficulties that may associated with SCRUM
The first potential weaknesses of SCRUM, is highlighted in the literature by Highsmith and Cockburn titled The Business of Innovation, this literature points out the fact that, when the project is developed for an external client, they have to be greatly involved in the project in terms of time input. This means that the client has to be able and available to test the monthly/periodical releases or deliverables, and to be able to suggest new or modified functionalities.
There is also the fact that in the projects using SCRUM, the vision of the client highly influences the developments outcome. Highsmith showed that if the client does not have a clear sense of the product’s direction, then, members of the development team will probably behave in the same manner, leading to a difference in the final production than what was originally anticipated. This in essence makes a one greatest strength of scrum its potential weakness.
The clients’ lack of ability to intervene in the project is also another potential weakness of SCRUM that may crop up over a relatively long period in. Although in principle this may look like an advantage, there have been situations in software development where the client’s intervention has to be done within a SPRINT. The risk over the project is usually significant if the methodology cannot accommodate specific interventions.
The small size of the project team can also be considered an Achilles' heel. This weakness is experienced in the way in which the methodology approaches large projects is easily viable with large teams but not easily implementable.
SCRUM has another potential weakness in that, it is very difficult to estimate a projects estimated duration or its eventual cost; where external clients are involved, it will be hard to ascertain in cases where bidding is used to determine the contractor for projects. This may offer a major hindrance when utilizing SCRUM.
SCRUM versus PMBOK
Project initiation
When initiating the program in PMBOK, Project value is assessed and has a fixed budget, the initial scope is defined meaning there is a fixed scope, resources are allocated and timeline is determined. Afterwards Stages and gates are revisited depending on the project. On the other hand in SCRUM, the Vision is established, goals are determined/set, teams are identified and timeline is determined. The vision of this project is revisited at the beginning of each iteration.
Planning and execution
In PMBOK, Subsequent project plans are initially created and updated throughout the project at the very beginning of the project while in the other, a release plan is done in the beginning and later sprints are planned throughout the project. On the other hand, in SCRUM, a Team Driven Development team works on product backlog that the product owner. Teams then advise the Product Owner which stories can be done during the sprints. In PMBOK on the other hand, High-level plans are created and updated throughout the project. There are also Signoff and approval from stakeholders for work to start.
Monitoring and closing
In SCRUM, the Time and Cost is Change is depending on the business need of the customer. During closing of the project, there is no formality on feedback because it given throughout the project. On the other hand, in PMBOK, Time, Cost, Quality, and Risks are constantly monitored throughout the project while at the end of the project, a Formal process of closing the project signoff and approval from sponsors and stakeholders is held and a Lessons Learned meeting is also held to determine and provide feedback on the project.
Integration of SCRUM and PMBOK
There are a few major similarities that both this systems share. Both deliver the right thing, both insist on communication during the project both offer progressive elaboration and finally both are cyclical meaning they insist in following the method of plan, execute, monitor and control.
Therefore, if one was to take the key strengths of SCUM which include efficient self-organizing team Collaboration, shared responsibilities and commitments, Allowance for adjustments and the learning of more to produce better results, Risk management ,smaller units of work fewer surprises, accurate Frequent checks & delays and Welcoming customer opinions. And the strengths of PMBOK which include Process oriented Clear project kickoffs & administrative initiation Enumeration of stakeholders, formalized communication planning and More explicitly calls for cost management Outlines risk management approach which include identification, qualitative and quantitative analysis, response planning.
When the strength of this two are brought together as was the case of Yahoo Company, then they would provide sufficient outcomes such as quality delivery of what was promised, flexibility within sprinters and higher levels of involvement and time management which would translate to greater satisfaction.
PART III
Project Management Methodology
In the modern sense Project management began in the early 1950s, driven by businesses that realized the benefits of organizing work around projects, and the critical need to communicate and co-ordinate work across departments and professions. At the time Communication and collaboration were the solution for establishing productive work relationships between the teams and departments within similar organizations. However, the most recent definition of Project Management Methodology is that it is a strictly defined combination of logically related practices, methods and processes that determine how best to plan, develop, control and deliver a project throughout the continuous implementation process until successful completion and termination. It is a scientifically-proven, systematic and disciplined approach to project design, execution and completion. The purpose of project methodology was to allow for controlling the entire management process through effective decision making and problem solving, while ensuring the success of specific processes, approaches, techniques, methods and technologies. Typically, methodologies provide skeletons for description of every step in depth, so that a project manager knows what to do in order to deliver and implement the work according to the schedule, budget and client specification.
References
Ibbs, C 2000, 'Assessing Project Management Maturity', Project Management Journal, 31, 1, p. 32, Business Source Complete, EBSCOhost, viewed 17 April 2013.
Ionel, N 2008, 'CRITICAL ANALYSYS OF THE SCRUM PROJECT MANAGEMENT METHODOLOGY', Annals Of The University Of Oradea, Economic Science Series, 17, 4, pp. 435-441, Business Source Complete, EBSCOhost, viewed 17 April 2013
Lee, RC 2012, 'The Success Factors of Running Scrum: A Qualitative Perspective', Journal Of Software Engineering & Applications, 5, 6, pp. 367-374, Computers & Applied Sciences Complete, EBSCOhost, viewed 17 April 2013.
Khan, A, Qurashi, R, & Usman Ali, K 2011, 'A Comprehensive Study of Commonly Practiced Heavy and Light Weight Software Methodologies', International Journal Of Computer Science Issues (IJCSI), 8, 4, pp. 441-450, Computers & Applied Sciences Complete, EBSCOhost, viewed 17 April 2013.
Munns, A. K., and Bassam F. Bjeirmi. "The role of project management in achieving project success." International journal of project management 14, no. 2 (1996): 81-87.
De Wit, Anton. "Measurement of project success." International journal of project management 6, no. 3 (1988): 164-170.
