Scrum and Agile Methods

Scrum and Agile Methods
Submitted By:
Adnan Qutubuddin
Independent Study Report
Abstract
Scrum is used in by many organizations in thousands of projects to manage and control work. Scrum embeds an organization's existing engineering practices; they are improved as necessary while product increments are delivered to the user or marketplace. When requirements change frequently Scrum process adopts it efficiently. Agile approaches have changed software development processes and the way software is developed, taking the industry in the direction of lean, simple, and adaptable development methodologies. With Scrum, projects progress via a series of two to four weeks iterations called sprints. All functionalities are listed in the Product Backlog, which is a list of all desired changes to the product. A Sprint Planning Meeting is held at the start of each sprint during which the Product Owner prioritizes the Product Backlog and negotiates it with Scrum Team on selected tasks they should complete during the coming Sprint. These tasks are then shifted from the Product Backlog to the Sprint Backlog. Each day during the sprint a short meeting is held called Daily Scrum, which helps the team stay on track. A Sprint Review Meeting is held at the end of each sprint to demonstrate the completed functionalities. The following study is an attempt to understand Scrum in a much broader way by comparing it with other agile programming methodologies, highlighting its pros and cons and concluding with suggestions that may refine it further.
II
Table of Contents
Preface.....................................................................................................................................II Acknowledgement...................................................................................................................III Abstract...................................................................................................................................I V
Chapter 1
Introduction
1.1 Agile Software Development.........................................................................................1 1.2 History............................................................................................................................2 1.3 Agile Manifesto..............................................................................................................3 1.3.1 Principles Behind the Agile Manifesto..................................................................3 1.4 Scrum............................................................................................................................4 1.4.1 Roles....................................................................................................................5 1.4.1.1 Product Owner..........................................................................................5 1.4.1.2 Scrum Master...........................................................................................5 1.4.1.3 Scrum Team.............................................................................................5 1.4.2 Pre-Game Phase.................................................................................................6 1.4.2.1 Product Backlog.......................................................................................6 1.4.2.2 Architecture/High Level Design................................................................6 1.4.3 Development Phase............................................................................................7 1.4.3.1 Sprint........................................................................................................7 1.4.3.2 Sprint Planning Meeting...........................................................................7 1.4.3.3 Sprint Backlog..........................................................................................8 1.4.3.4 Daily Scrum Meeting................................................................................8 1.4.3.5 Sprint Review Meeting.............................................................................8 1.4.3.6 Sprint Retrospective.................................................................................8 1.4.3.2 Burndown Chart.......................................................................................9 1.4.4 Post-Game Phase...............................................................................................9 1.4.3.1 Integration................................................................................................9 1.4.3.2 Testing....................................................................................................10 1.4.3.3 Release Planning...................................................................................10 1.4.5 Scrum Values....................................................................................................10
III
Table of Contents
Chapter 2 XP and Agile Methods
2.1 Scrum Vs. XP.............................................................................................................11 2.2 Scrum Vs. Crystal.......................................................................................................11 2.3 Scrum Vs. FDD..........................................................................................................11 2.4 Scrum Vs. ASD..........................................................................................................11 2.5 Scrum Vs. DSDM.......................................................................................................11 2.6 Software Development Life Cycle..............................................................................12 2.7 General Features.......................................................................................................13 2.8 Scrum Pros.................................................................................................................15 2.9 Scrum Cons................................................................................................................15 2.10 Existing Model............................................................................................................16 2.11 Suggestions...............................................................................................................17 References.............................................................................................................................18
IV
List of Figures
Figure 1 Evolutionary Map of Agile Methodologies................................................................2 Figure 2 Scrum Overview.......................................................................................................4 Figure 3 Scrum Flow..............................................................................................................7 Figure 4 Burndown Chart.......................................................................................................9 Figure 5 SDLC Support........................................................................................................12 Figure 6 Scrum Life Cycle....................................................................................................16
List of Tables
Table 1 General Features....................................................................................................14
Chapter 1
Introduction
1.1 Agile Software Development
Agile software development refers to a group of software development methodologies that include: Extreme Programming (XP) Scrum Crystal Feature Driven Development (FDD) Lean Development Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) [2]
Agile software development methodologies follow the principle of rapid delivery of high quality software with process of frequent adaptability, inspection, teamwork, self organization, accountability and customer-developer partnership throughout the life cycle of the project. Agile practices are often considered favorable for most of the businesses because it reduces cost and time which reduces the overall effort involved in developing a reliable software product. The best fact is that even if the effort is reduced the quality of the product is not compromised. It requires less planning and less documentation which keeps the overall team in high spirits. Each agile software development methodology carries iterative approach. Each iteration is re-evaluated and goes through the complete SDLC (Planning, Analysis, Implementation and Maintenance) which keeps the project adaptable. Some agile methods emphasize on face-to-face communication or short meetings rather than over written documents to get the overall progress of the project. It also resolves any problem that is hindering in the way which may be overlooked in the documents. Team members are assigned tasks and they each develop in their own way, which are then integrated. Customers are kept involved during the development to highlight the overall project progress or any ambiguity or any priorities that are to be set. There are two kinds of techniques involved during agile software development: Test Driven Development (TDD) Behavior Driven Development (BDD)
In test driven development tests are written prior to coding and in the behavior driven development collaboration is maintained between developers, quality assurance and customers (non-technical) in order for each one to talk in their own language. TDD focuses on code that must be written in order to pass the test and BDD focuses on why the code should be written.
1.2 History
Figure 1. Evolutionary Map of Agile Methodologies
[5]
1.3
Agile Manifesto [8]
Better ways of developing software are being uncovered by doing it and helping others do it. Agile manifesto 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
That is, while there is value in the items on the right, we value the items on the left more.
1.3.1 Principles Behind the Agile Manifesto

Highest priority is to satisfy the customer through early and continuous delivery of valuable software. Adoption of frequently changing requirements, even late in development. Changes for the customer's competitive advantage are harnessed. Requires a couple of weeks to a couple of months for delivery of working software, frequently, with a preference to the shorter timescale. Business people and software developers must work together daily throughout the project. Projects are built around motivated individuals. Environment and support that they need must be given, and trust them to get the job done. Face-to-face conversation is the most efficient and effective method of conveying information to and within a development team. The primary measure of progress is working software. Agile processes promote sustainable development. To maintain a constant pace indefinitely sponsors, developers, and users should be able. To enhance agility continuous attention to technical excellence and good design is needed. Simplicity is the art of maximizing the amount of work not done and is essential. Self organizing teams produces the best architectures, requirements and designs. The team reflects on how to become more effective, then tunes and adjusts its behavior accordingly at regular intervals.
1.4
Scrum
Scrum is a team-based process to develop complex systems and products. [1] It is an iterative, incremental process that focuses on managing practices of software development. It allows teams to deliver a potentially shippable product at the end of each iteration, which caters the agility needed to respond to frequently changing requirements. The Scrum process adapts any change in the requirements which keeps the user focus on improvement and this is why Scrum is becoming the most popular method in the world of agile software development. The term Scrum comes from a 1986 study by Takeuchi and Nonaka that was published in the Harvard Business review.[3] In that study, they both note that projects using small, crossfunctional teams significantly produce the best results. They get the word Scrum because of formation of Scrum team in Rugby which produces great results. Jeff Sutherland developed the Scrum process at Easel Corporation in 1993, while studying the basis for team formation and adopted the analogy as the name of the process as a whole. Ken Schwaber formalized the process for the software industry in the first published paper on Scrum at OOPSLA 1995.
Figure 2. Scrum Overview [ref]
1.4.1 Roles
Since Scrum focuses on management practices roles are clearly defined. The organization should maintain the differences between roles in order to achieve goals. Scrum consists of three roles i.e Product Owner, Scrum Master, and the Team (of developers). Scrum team members are called pigs and rest are called chicken. Chickens does not control pigs in order to make them work. The concept of Chickens and pigs come from the following story: A chicken and a pig are together when the chicken says, Lets start a restaurant! The pig thinks it over and says, What would we call this restaurant? The chicken says, Ham n Eggs! The pig says, No thanks, youd only be involved but for me it would be a real commitment![1] There are three main roles in Scrum:
1.4.1.1
Product Owner
Product owner is the person who manages and controls the Product Backlog (requirements) and its prioritization. He / She is usually involved with the stakeholders and the one who takes all the input for the product from the customers or end users. The whole decision about the project is in the hands of the product owner and it is his/her responsibility to give vision to the overall team. Product owner can either be from the side of the customers or the developers and guides the whole Scrum team about the priorities and makes sure that the product backlog is visible to everyone. Product owner is selected by Scrum master, customer and management.
1.4.1.2 1
Scrum Master
Instead of having a project manager in Scrum, a Scrum master is appointed.[6] The role of the Scrum master is not similar to a project manager. Scrum master leads the Scrum team and guides them but he/she does not control them. Scrum master is neither the developer nor helps the Scrum team in development but his/her responsibility is to get involved with the stakeholders and carry out meetings with stakeholders and top management. Scrum master also helps the product owner in the product backlog and helps development team in making important decisions. Scrum master usually act as a firewall between the team and the rest of the world.[6] It is the duty of Scrum master to make sure that Scrum practices and values are being followed and help development team, stakeholders, product owner and top management to understand and create motivation among them.
1.4.1.3
Scrum Team
Scrum team is the developers who turn product backlog into increments of potentially shippable functionality every sprint (iteration or cycle).[1] Scrum teams are cross functional and organize themselves to carry out the tasks assigned to them. Scrum team is composed of five to nine members. Each team member has equal authority having no roles among the team. Each member can share
ideas with product owner to make the product better. After each sprint team composition may be changed but frequent changes lose the productivity of self organization. If team members are less than five there will be less flexibility in the knowledge, on the other hand if it exceeds nine members communication gap will increase so it is better to divide teams regularly so they can work in parallel. The meeting of more than one team is called Scrum of Scrums.[6]
1.4.2 Pre-Game Phase

1.4.2.1 Product Backlog
Product backlog contains the requirements that need to be implemented according to the product specification. Product owner maintains the entire product backlog. Specifications in the product backlog can be added, modified, removed or prioritized. Product backlog can contain features, bugs, fixes, defects and changes and is the master list of all the functionalities to be implemented.Product Backlog items have the attributes such as description, priority and estimate. Priority is driven by risk, value and necessity (nonfunctional requirements).[1] Higher priority items are developed urgently and are well understood, fine grained and are given more time in order produce better results for the overall product. It is the responsibility of the product owner to make the product backlog visible to everyone otherwise miscommunication can lead to delays and unnecessary functionalities.
1.4.2.2
Architecture/High Level Design
Architecture/Design is planned based on the current items in the product backlog which gives a broader view of how the architecture/design should be. Change in the product backlog also has a effect on the architecture/design.
1.4.3 Development Phase
Figure 3. Scrum Flow
[ref]
1.4.3.1
Sprint
Sprint is an iteration or cycle which is around two to four weeks long. Each sprint goes through the complete software development life cycle. It is considered to be the heartbeat of the Scrum process because if the sprint is not planned well then customers may be disappointed as there is commitment in the beginning of each sprint that at the end of a sprint they would get a shippable deliverable.
1.4.3.2
Sprint Planning Meeting
Two four hours sprint planning meeting is held at beginning of each sprint. First four hours is discussed what functionality should be implemented in the next sprint. Scrum master, Scrum team, management, possible stakeholders and product owner usually attend the first meeting in which they negotiate on tasks to be completed in the upcoming sprint. The second meeting is held between product owner, Scrum master and Scrum team to negotiate features to be completed in the upcoming sprint. When the team chooses the top priority features from the product backlog then the Scrum master and the team breakdowns the product backlog features into sprint tasks and when the sprint backlog is complete estimation and comparison is done against the product backlog. Team negotiates the number of tasks that must taken for the sprint or sprint backlog if there is a significant difference.
Sprint goal must be clearly defined to the developers, that what product we would achieve after the implementation of the sprint backlog and what client wants.
1.4.3.3
Sprint Backlog
Sprint backlog contains those requirements or features that must be implemented during a sprint. Features that are selected in a sprint depend on the team size and their skills so that they produce what they committed. Product owner, Scrum master and the team negotiate on the sprint backlog in the sprint planning meeting. If tasks are too few for the sprint more are added and if tasks seem to be more for the sprint goes into the next sprint. The sprint backlog changes throughout the sprint as they get into individual tasks. Bug fixes and testing also include in the sprint backlog list which are implemented during that sprint only.
1.4.3.4
Daily Scrum Meeting
Scrum master conducts a daily 15 minutes meeting at the earliest (morning) which is called daily scrum meeting. During the meeting, each team member explains: 1. What he or she has accomplished yesterday (since the last meeting)? 2. What he or she is going to do today (before next meeting)? 3. What difficulties are in his or her way? All impediments are considered by the Scrum master in which some are solved within teams and some are organizational or personal issues. In this way the whole progress is being monitored and managed and gives a good control over the schedule. All the obstacles are prioritized and a remediation plan is implemented.
1.4.3.5
Sprint Review Meeting
At the end of each sprint a sprint review meeting is held. It is a four hour meeting for a thirty days sprint. It should not be more than 5% of the time of the sprint. Whatever has been done in the sprint is presented and what to do in the next sprint is discussed. Anyone can be invited in this meeting as it is informal. The team also presents that what were the obstacles during the entire development in the sprint and how did they solved it. The product backlog is reprioritized and velocity estimates are given. Goal for the next sprint is set.
1.4.3.6
Sprint Retrospective
After the Scrum review meeting a three hour sprint retrospective meeting is held. In this meeting the Scrum team (product owner, scrum master, team) discusses what is working and what is not. Everyone answers two questions that are: 1. What went fine during the last Sprint? 2. What could be enhanced in the next Sprint? The underlying causes of things that did not work out are identified and are resolved in the next sprint.
1.4.3.7
Burndown Chart
Figure 4. Burndown Chart [3]
Burndown chart shows the overall progress of the project. It is not in terms of time but in terms of goal, that how much the team is nearer to their goal, which is the implementation of all the features present in sprint backlog. Graph goes down as the team progresses towards their goal. This way can help the team to pace up if they are going slower or if the graph is going up. The total of all sprint backlog estimates of work remaining to be completed is the cumulative backlog. [3] As the sprint proceeds and tasks are completed, Scrum master recalculates the remaining work to be done and the list of sprint backlog decreases or burns down over time. If the sprint backlog is emptied or zero at the end of the sprint, the sprint is successful.
1.4.4 Post-Game Phase

A release sprint is dedicated for the final release of the product.
1.4.4.1
Integration
All the code is integrated and any bugs and fixes are reported for testing. Integration may introduce bugs that are never been identified because each of the module is tested by its own tests and not for the whole project. There may be an addition to the problem if no proper versions of the code and test are maintained. A configuration management tool can be used as a repository which even handles the locking making developers able to work concurrently.
1.4.4.2
Testing
Unit test frameworks may be used to create test suites. Unit test frameworks are helpful in creating automated unit test suites, thus saving time. Unit tests are also updated with the code in the repository. Code without tests neither is integrated nor released. Unit tests are also helpful in re-factoring. Changed code is tested with the test suite to identify any bugs introduced. When a bug is reported, a test is created for that bug. An acceptance test is written to protect the source from that bug. Developers create unit tests from those acceptance tests to target a specific code. When the unit tests have been passed, the code is passed through the acceptance (functional) test to check if the bug is fixed.
1.4.4.3
Release Planning
Product owner decides when the product is ready for release and the whole product goes through the last sprint called Release Sprint. During this sprint a final integration and testing is performed for the product to be launched. Sometimes certain features need to be implemented for the product to be called complete. Many releases are also made in versions. Interim releases give the customer a good feeling about the benefits he/she is going to have.
1.4.5 Scrum Values

- The team is willing to achieve the goal. - Each team member should have focus on his own work. - Everything related to project is visible to everyone. - Each member of the team should respect other team members. - Members must have the courage to act in the right direction and be open. - Everybody must abide by the rules that are agreed by the whole team. - Team must avoid wastes related to the project: resources, time, money, etc.
10
Chapter 2
Scrum and Agile Methodologies
2.1 Scrum VS. XP
Scrum and XP practices overlap each other. Scrum focuses on management processes while XP emphasizes on engineering practices. Scrum is used where better business engagements and collaboration are required, while XP is used where the productivity must be high maintaining software quality.
2.2 Scrum VS. Crystal

Crystal family includes number of different methodologies (Crystal Clear, Crystal Orange and Crystal Orange Web). [4] The methods are tailored in order to get the best out of its family. Each method is marked with a color indicating its heaviness. Dark color methods are considered to be heavy. Each method is differentiated by the projects size and its criticality. Crystal uses incremental approach with several iterations within an increment that is of 4 months usually where as Scrum uses iterative approach. Milestones are set for delivery while Scrum uses release planning and sprint planning. Scrum uses daily scrum meetings where as Crystal progress is monitored and measured by milestones.
2.3 Scrum VS. FDD

FDDs main focus is on the design and building phases. Iteration in FDD emphasize on the features while in Scrum product backlog is used. In FDD iteration usually requires 1 to 3 weeks and in Scrum 2 to 4 weeks. Scrum focus on the management practices where as FDD employ both management and engineering practices. FDD is the model driven short iteration software development process.
2.4 Scrum VS. ASD

ASD is used where systems are large and complex. Scrum can handle small projects to large projects. ASD uses a three phase cycle and focuses on components to be implemented rather than tasks in Scrum. Unlike Scrum, ASD recognizes that building a complex system may require the expertise of several specialized teams. It also does not support co-located teams.
2.5
Scrum VS. DSDM
DSDM calls iterations as timeboxes and duration is of few days to few weeks. Prototypes are developed in DSDM and goes through heavy documentation. Technical coordinator is responsible for defining the system architecture and helps as a technical lead. Each team should at least have a developer and user. Scrum calls iterations as sprints which is two to four weeks long.
11
2.6 Software Development Life Cycle Support
Figure 5. SDLC Support
[4]
12
2.7 General Features
13
Table 1. General Features
[4]
14
2.8 Scrum Pros

Clearly defined roles increases teamwork. Self organizing and cross functional teams increases productivity. Product Backlog reduces heavy documentation. Sprint Backlog breakdowns further clarifies requirements. Sprint goal moves the team in one right direction. Daily scrum meeting resolves any obstacles. Sprint review meeting highlights what went wrong. A deliverable is ready at the end of each sprint which satisfies the customer.
2.9 Scrum Cons

Frequent changes in team composition effects productivity by self organizing adversely. Suitable for the development of new products and not for enrichment of an existing product. If development team is immature and undeveloped, scrum is risky. Requirements are managed by only one person (product owner). Sprint planning, sprint review and sprint retrospective meetings are too long to concentrate. A potentially shippable product should be delivered at the end of the sprint. Acceptance (functional) tests are not detailed. As focus is on management practices, engineering practices are ignored.
15
2.10 Existing Model
Figure 6. Scrum Life Cycle
[4]
16
2.11 Suggestions
Changes in the team composition should be controlled. Immature developers should assist experienced ones. Product owner should discuss requirements with the technical person to remove any ambiguities. Meetings should be shortened as possible. Tasks in sprint backlog should be completed before the time so that proper integration and testing can be performed. Engineering practices should be tailored in order for the product to be successful. Some of the XP engineering practices that may be helpful are unit tests framework, refactoring, on site customer, coding standards and spike solutions.
17
References
[1] http://www.scrumalliance.org [2] Lowell Lindstrom, Extreme Programming and Agile Software Development Methodologies, 2003. [3] Jeff Sutherland, Ken Schwaber, The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process, 2007. [4] Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, Agile Software Development Methods, 2002. [5] Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen, New Directions on Agile Methods: A Comparative Analysis, 2003. [6] Lior Azouri and Marcus Olsson, Benefiting of improvements in Scrum project regarding web application, 2005. [7] Jorge Edison Lascano, Extreme Programming Embedded Inside Scrum, 2008 [8] Agile Manifesto, http://agilemanifesto.org
Websites:
http://www.agile-software-development.com/2008/04/extreme-programming-versusscrum.html http://www.ferolen.com/blog/xp-vs-scrum/ http://www.approximity.com/cgi-bin/blogtariAgile/index.rb/XP_agile/XPvsXCRUM.txt
18

Scrum and Agile Methods

Uploaded by

Document Information

Original Title

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Scrum and Agile Methods

Uploaded by

Copyright:

Scrum and Agile Methods

Independent Study Report