An Agile Implementation of SeRUM

Michele Gannon John Hopkins University Applied Physics Laboratory

11101 Johns Hopkins Road Laurel, MD 20723

443-778-5345 Micbele.Gannon@jhuapl.edu

Abstract-Is Agile a way to cut corners? To some, the use of an Agile Software Development Methodology has a negative

connotation - "Oh, you're just not producing any documentation". So can a team with no experience in Agile successfully implement and use SCRUM?

This paper explores the fundamentals of SCRUM as well as

how this Agile development methodology has been implemented on a project at the Johns Hopkins University Applied Physics Laboratory. It will review the deviations made from the traditional SCRUM framework, the management of the project using standard SCRUM artifacts such as the Product Backlog, Sprint Planning, Daily Serum meetings,

Sprint Reviews, Sprint Retrospectives, metrics and documentation as well as integrating the use of a Kanban board and pair programming methods from Extreme Programming (XP).

In addition to explaining the "what's" and "how's" of the project implementation, it will examine the many challenges and successes encountered.

TABLE OF CONTENTS

1. INTRODUCTION ••••••••••••••••••••••••••••••••••••••••••••••••• 1 2. THE SCRUM PROCESS •••••••••••••••••••••••••••••••••••• 1 3. IMPLEMENTATION •••••••••••••••••••••••••••••••••••••••••••• 2 4. CHALLENGES •••••••••••••••••••••••••••••••••••••••••••••••••••• 5 5. RESULTS ............................................................ 6 6. SUMMARY ... . . . . ... . . .. .... . .. . .. ..... . .. .... . . .... . . . . . .......... 7 REFERENCES •••••••••••••••••••••••••••••••••••••••••••••• ••••••••••• 7 BIOGRAPHY ••••••• ••••••••••••••••••••••••••••••••••••••••••••••••••• 7

1. INTRODUCTION

It is inevitable that there will be change on any software project, so why not plan for it?

seRUM is an iterative software development methodology that utilizes an "inspect and adapt" framework. There is a

standard set of roles and artifacts as well as an official SeRUM Guide. But as we all know, no two software development projects ever seem to be the same. So why not be agile in the implementation of an agile software development methodology? With the guidance of a project manager dedicated to the success of the project as well as the use of an agile methodology and a team having never used SeRUM before, is it possible to succeed? Yes!

978-1-4673-1813-61131$31.00 «J2013 IEEE

2. THE SCRUM PROCESS

seRUM is a framework for developing and sustallllllg complex products and consists of the following artifacts, roles, and events. [1] SeRUM Teams deliver products iteratively and incrementally, maximizing opportunities for

feedback. [1]

Wri.i"G inOW'T'Wtnt of the .oftw ...

Figure 1 - The SeRUM Process [2]

SCRUM Artifacts

SeRUM has two artifacts: a Product Backlog and a Sprint Backlog. The Product Backlog is a prioritized list of requirements for a system. The list can include functional

and non-functional customer requirements as wen as technical requirements. The Sprint Backlog is the set of items from the Product Backlog that the team has committed to complete during a single iteration or Sprint.

seRUM Roles

seRUM has three roles: Product Owner, Team Member, and SeRUM Master. The Product Owner is a single person who represents the interest of the stakeholders. It is the sole responsibility of the Product Owner to prioritize the Product Backlog. The team members include a cross functional group of people responsible for delivering an end to end product at the end of each iteration or Sprint. The SeRUM Master coaches the team in following the SeRUM process.

SCR UM Events

Sprint Planning Meeting-The goal of sprint plal1l1ing is to identify the goal of the Sprint, what will be done in the Sprint, and how that work will get done. [1] The Product Backlog is reviewed to determine which items will be addressed in this Sprint. The goal of the Sprint identifies why the Sprint is being conducted. The Spring Backlog is then created based on the items pulled from the Product Backlog to be completed in this Sprint. The Sprint Backlog

has tasks broken down into units of one day or less and the team self-organizes to determine how these tasks will get done. [1]

Daily Scrum-A time-boxed Daily Scrum (or stand up meeting) is conducted or held every day in which each member of the team answers three questions:

• What did you accomplish yesterday?

• What will you commit to complete today?

• Do you have any impediments?

Any identified impediments are resolved immediately within the team or escalated by the SCRUM master for resolution as soon as possible.

Sprint Review-At the end of each sprint there is a Sprint Review meeting where the team has a chance to present to the stakeholders what was done in the Sprint. During this

meeting the attendees collaborate on what was done and what to do next. [1] Feedback is collected and the product backlog is updated to include items to be completed in

future Sprints.

Sprint Retrospective-The Sprint Retrospective is held after the Sprint Review and prior to the next Sprint Planning Session. This is the opportunity for the SCRUM Team to

identify things that went well and not so well during the Sprint. The meeting results in one or more identified improvements that can then be incorporated into the future

Sprints. This encourages and ensures continuous improvement throughout the process.

3. IMPLEMENTATION

Following the above SCRUM rules the team set out to

develop complex software.

Software Pwpose

The purpose of the software this team was developing was

to remotely monitor and control equipment that builds a

connection from a manned workstation to a satellite to a remote site which houses various components. There is a

COTS product which provides the core functionality.

Team Composition

The team consisted of 1 Product Owner, 6 software developers, 5 network engineers, 4 testers, 2 IA representatives, I Project Manager, and 1 SCRUM Master. Team members ranged in allocation to the project of 50% -100%. Because there were team members with less than 100% allocation, Sprints were scheduled to last greater than 30 days. In addition one team member was not co-located with the rest of the team.

2

DailyScrum

Daily Serums were held every day at 9am in the team lab. Initially the Daily Serums included just the software engineers. These meetings typically resulted in illlanswered questions which would require follow up with the other teams. It became beneficial to have each of the other teams

represented at the Daily Serum. Because of the larger team size, the Daily Serums were time-boxed to 30 minutes versus 15 minutes.

Originally the team made one pass around the table to answer the 3 questions in the Daily Serum. There were typically additional, beneficial discussions held at the Serum. This would result in a longer meeting or team members following the discussion being rushed through

their 3 questions. After several sprints the team realized it was necessary to have two passes; one for the 3 questions and a second for any further discussion or questions. This actually resulted in the meetings being shorter.

Product Backlog

The Product Backlog was written with the Product Owner and other stakeholders in the form of user stories. A user story is a description of a feature of the software written from the perspective of an end user. [3] The format for user stories is "As a [name of end user or role] I want [simple description offunctionality] so that I have [business value]." The user stories reflect the requirements for the software. Each user story is assigned Story Points by the development

team. Story Points are simply a number used to express the complexity of a user story. Story Points are used during Sprint Planning to assist in determining the number of user stories that can be completed in a Sprint, as well as for

capturing metrics on the SCRUM Teams velocity. The Product Backlog for this project started with 53 user stories

and 2200 story points.

Sprint Planning

After completing the Product Backlog or immediately following the Sprint Retrospective for a Sprint, planning for the next Sprint was started. Sprint Planning typically lasted between six and eight hours, broken up over two to four meetings.

Spring Planning started with a set of user stories that had a similar theme and that when grouped together could result in a demo-able product. Each selected user story was reviewed to identify the list of detailed tasks to complete the

story. Each of the tasks was written on a sticky note, which would ultimately be added to the Kanban board as a "To Do" task. After all tasks for the Sprint had been defined a second pass across all of the tasks was made. During this pass hour estimates and a priority were assigned to each task.

Estimating-Estimating always seems to be a difficult process with any software development methodology. This starts with the decomposition of tasks to an appropriate

level. In the first Sprint tasks were decomposed to a very

low level . As multiple tasks could be completed within a

piece of code, multiple tasks were worked by a single team member in parallel. In Sprint 2 tasks were not decomposed to the same low level, which resulted in the need to decompose tasks even further before they could be started.

In Sprints 3 and 4, decomposition of tasks became easier for the team as they had seen the result of poor task decomposition. The goal of decomposition and estimation was to keep each task under 20 hours , as a task great than 20 hours should be broken down further.

SPRINT BURN DOWN CHART

f

400

350

300

250

; 200 ::c

150

100

50

3 4 5 6 7 9 10 11 12 13 1 4 15 16 17 18 19 20 21 22 23 24 25 26

Days in Sprint

Figure 3 - Sprint Burndown Chart

3

Prioritization of Tasks-To ensure that the most critical tasks were addressed first, the team began to prioritize tasks as part of sprint planning. Tasks were given a priority of one to three. Priority 1 tasks were critical to the success of

the Sprint. A priority 3 task could be deferred from the Sprint should the amount of work in the Sprint exceed the capacity of the team.

Assigning Tasks-The process of task assignment changed as the team became more experienced in using this methodology. Following Spring Planning for Sprint I all tasks were assigned to a team member. In subsequent sprints just an initial set of tasks were assigned as tasks were often reassigned multiple times throughout the first Sprint.

Process Improvements-With the use of an inspect and adapt framework, as well as the Sprint Retrospective, there was always continuous improvements being made. In addition to other improvements noted, during Sprint Planning for Sprint 2 the team identified certain tasks that would need to happen with every user story, thus a base set of tasks for each user story was created. Examples of these tasks included "create detailed use case," "create design documentation," and "create test case".

Sprint Burndown Chart

The SCRUM Master created and maintained the Sprint Backlog and a Sprint Bumdown Chart. The Sprint Backlog, as illustrated in Figure 2, includes all tasks to be completed in the Sprint as well as the total hour estimates and hours remaining on each task. With this information one can graph the completed and remaining hours in the Sprint in a

Bumdown Chart, as illustrated in Figure 3. The Sprint Backlog and Bumdown Chart are reviewed and updated every day. The red line in the chart, incorporated as a

process improvement, conveys the "ideal" bum line. This allows the team to easily gauge whether they are behind or

ahead of schedule.

Kanban

The team used a Kanban chart, illustrated in Figure 4, to

track the progress of each task throughout the Sprint. This provided a visual representation of where the team was at any point in time and was displayed prominently in the lab.

The team continually refined the use of the Kanban Board for ease of use and effectiveness for the team.

4

�\I'.sCIU8E TD

J(q,1Lb ... .-TOIJl

AUI A8M

HANM-'

&ET �M£ .HJ£KY

IIOTf!l -

Figure 4 - Kanban Board Example

The original categories of tasks on the Kanban Board included To Do, In Progress, and Completed. Additional categories were added to better track where tasks were in their lifecycle, such as Awaiting Code Review, Ready for

Test, & Tested.

Originally there was just one big In Progress section on the Kanban board. The team decided to split this area up so each team member had their own section of the board. This

way everyone could easily see the task load on each team member.

Sprint Review

The Sprint Review meeting was scheduled at the beginning of each Sprint and was open to any team member or

stakeholder. A dry run of the review demonstration was typically scheduled about a week prior to the Sprint Review meeting.

The demonstration of the Sprint accomplishments was conducted by the team members, each presenting the features or functions they developed. Participants were encouraged to ask questions and make comments at any point during the meeting.

Following the demonstration the completion of the user

stories identified for the Sprint were assessed. If a user story was not fully complete a new user story was created to capture the remaining or missing functionality and the Product Backlog was updated. A team member would capture all comments and discussion points so it could ultimately be determined if addi tional tasks, defects or user

stories were required.

Sprint Retrospectives

The Sprint Retrospective was a one hour time-boxed meeting to discuss how the Sprint went, similar to the identification of lessons learned.

During the Sprint Retrospective there is a period of time allotted for everyone to write down things that they felt went well or not so well during the Sprint. After the time was reached, there was a round robin discussion to go through each item that was written down. At the end of the

meeting, after every item was discussed, the team would

collectively identify process improvements to be implemented immediately at the start of the next Sprint.

The Sprint Retrospectives were highly effective for this team. The team was open, honest, and professional when identifying and discussing the topics that came up at the meeting . Many process improvements were implemented

throughout the project. Examples of the items captured

during the Sprint Retrospective include:

• The team was flexible in the assignment of tasks and "rolled with the punches"

• The team established trust and a feeling of collective success

• Poor communication with network and test teams

(resulted in process improvement)

• Need to streamline code reviews, as they were cumbersome (resulted in process improvement)

• Some Definition of Done tasks are being overlooked (resulted in process improvement)

Metrics

Metrics are necessary to assist with Sprint Planning and to ensure the result of the process is a successful Sprint. The two essential metrics for this process were Capacity and Velocity.

Capacity-Capacity is the total number of hours available for work between the start and end of a Sprint . The equation used to create a person's capacity for this implementation was:

(Workdays in sprint - Plalmed out of office) *

Allocation to the project * .75

This metric takes into account that some team members are

not allocated 100% to the project and scheduled time out of the office. In addition, it assumes that each team member spend 75% of their allocated time on the project on the tasks in the Sprint Backlog. This allows time for breaks, training ,

an unplanned out of office, or corporate meeting and events.

The total team capacity was the sum of each individual team member's capacity.

5

Esti mates Person A Person B Person C Person D Pers on E Person F

Remainin Total: 1344

118 39 23 69 89 110 645

1093

Figure 5 - Team Capacity Metric

Velocity-Velocity is the total effort a team is capable of in a sprint based on historical data. Velocity can be measured in user stories or story points. Velocity can only be measured after there is historical data and becomes a more reliable metric over time.

Story Point$ Completed by Sprint

.�tir "�l

Figure 6 - Team Velocity Metric

Documentation

Most documentation was created on a Just-in-Time basis

and there were few formal templates. Checklists were created and used for ensuring completed tasks met the teams Definition of Done. The documentation repository included a folder structure under each Sprint for documentation to be captured. This included code review documentation, Daily Serum minutes, demo scripts, design documents, use cases, and checklists. A user guide, style guide, and installation

procedures were updated with each Sprint.

4. CHALLENGES

Challenges will occur on any software development project. The benefit of using an Agile Development Methodology is

that with the continuous inspecting and adapting, process improvements can be made as needed and are planned for within each Sprint.

Team

Only one of the six team members was allocated 100% to the project. The other team members were allocated 50%,

60%, or 70% to the project. Each team member managed their own time across their projects. At the beginning of the project it was decided that a team members' other project could not be stated as an impediment. As the team met every day for the Daily Scrum it was acceptable to say that they had completed only a few hours of work or that they were unable to work on the project for that day. If there were critical tasks to be completed that day, tasks were

reassigned.

There were times when team members stated that they were

working more hours on the project than they were allocated. This was addressed as a part of Sprint Planning. The entire

team participated in Sprint Planning and made a collective commitment to meet the Sprint goal by the Sprint Review

date. Through this commitment and with the assistance of the Daily Serum meetings team members had to become good with their own time management.

Another challenge for the team was changes in team composition from Sprint to Sprint. This is not desirable, but

project assignments would change for varying reasons and occurred frequently throughout the fIrst few Sprints. This made identifying the team velocity metric diffIcult. This was addressed by ensuring the total hours for tasks assigned to a Sprint were less than the team capacity and by Sprint Backlog task prioritization. Priority 3 tasks were identifIed as tasks that could be deferred to a future Sprint if needed.

A third challenge for the team was that one team member was not co-located with the rest of the team. He was involved in every meeting and many discussions via the phone; however body language and emotion are not easily conveyed via a phone conversation. The seRUM Master would convey some of this information over the phone in meetings and through follow up conversations, but this is not a challenge to easily overcome.

A fourth team challenge was each team member's amenability to change. Some software developers are set in their ways and have diffIculty adapting to the multiple improvements being made. Each team member must be honest with the team and open to frequent change. Also, as new tasks were created the team members needed to accept that although these tasks are being identifIed they may not

fall within the goal of the current Sprint. These tasks would be fIled under a new or existing user story and be reviewed and possibly implemented in a future Sprint.

Daily Scrum

Software developers are not typically fans of meetings. This was evident in some of the earlier Daily Serum meetings, as the team was learning the process. After completing a Sprint and starting a second Sprint, the purpose and benefIts of this meeting became apparent to the team. In addition, through experience the team learned how to quickly address the 3 questions, what warranted additional discussion during the SeRUM and what topics should be deferred to a smaller discussion immediately

6

following the seRUM or a follow up meeting later in the day.

Sprints

The length of the Sprints was a challenge. With the team members being allocated less than 100% to the project Sprints were typically longer than 30 days and their durations varied from Sprint to Sprint. It is diffIcult to ensure that a Sprint is not too long or too short. Longer Sprints can result in diffIculty with motivation and staying focused; as well as a larger set of tasks, which could be potentially overwhelming. Shorter Sprints resulted in more

attention being paid to schedule and tasks that had yet to be started.

Tool Setup and Configuration

Tasks in the Product Backlog and ultimately tlle Sprint Backlog did not include tool set up and confIguration or product installation. In the initial Sprints this was a challenge, because automated builds and unit testing was desirable. For the second Sprint a new user story was created to address Release Engineering. This user story was broken down into tasks that included product installations and configuration, as well as infrastructure tasks and test harness creation. Portions of this user story were executed over several Sprints, so as not to impact the quality or

diminish the number of end user requirements in a given

Sprint.

"/n Sprint" Testing

It was a challenge to conduct testing of a Sprint within the Sprint. A development environment was maintained where the software developers created and compiled code. A test environment was maintained which had the content of the last Sprint . Testers could not reliably test in the

development environment due to the instability and continuous changing of the environment. Thus, testing was always a Sprint behind development.

Procurement Delays

As the purpose of the software being developed was to monitor various pieces of equipment, delays in the procurement and receipt of the equipment presented a challenge to the team. Because of this some user stories were broken in what the team called "vertical slices". A vertical slice was defmed as an implementation of a feature across a single piece of equipment or a subset of the total pieces of equipment to be monitored.

S.RESULTS

The ultimate success, of course, is a fInal working product that meets the end user requirements. Each Sprint however was a success in that it resulted in functionality that could be demonstrated to the stakeholders.

There were also successes in the implementation of SCRUM.

Working a s a Team

Daily meetings, collaboration, team commitment, paired or team programming, honest discussion, and various other team building activities resulted in a tightly knit team environment. Through this strong sense of team and shared commitment the agile processes seemed to happen

automatically. Tasks could easily shift from one team member to another, unit and integration testing became easier, bugs were identified and resolved by anyone and

everyone, potential problems or pitfalls were discussed and resolved collectively, code reviews were a positive experience, Sprint Planning and estimation improved throughout the duration of the proj ect and collaborative work between development team and test team are just a small set of the result of a strong agile SCR UM team.

Sprint Planning

Sprint Planning improved throughout the duration of the

project. As the team became comfortable with the process and each other, as well as their collective goal, Sprint Planning discussions were more honest and thorough. This resulted in better estimates, properly decomposed tasks, and a realistic set of achievable user stories.

Sprint Review

The execution of the Sprint Review meeting was a team success. Each member of the team presented the portion of the product they developed. This allowed for everyone on the team to participate and take pride in each incremental delivery .

Sprint Retrospectives

There is always room to improve. Effective communication i s essential to a team ' s success. This, along with professionalism, self evaluation, honesty, and openness allowed the teams Sprint Retrospective to be highly beneficial to the success of the team. The goal of each retrospective was to identify 3 process improvements . This was an easy goal for the team. Process improvements were

easily identified and implemented. And if a process improvement did not meet the desired goal, it was amended as needed. Due to these retrospectives the team was able to

inlprove quality, capability, and productivity.

Improved Productivity

As any identified impediments are removed on a daily basis, the team is able to focus their efforts on productive tasks resulting in increased productivity.

Improved Quality

With a documented Definition of Done on a task, user story, and sprint level, there is always a focus on what it meant to state that something was "Done" . This ensured that throughout the process standards were being followed,

7

documentation was being updated, unit tests were being created and executed, and code reviews were being conducted. The checklist was posted in the lab and the team would ensure that all items were incorporated resulting in

higher quality code as well as supporting materials .

6. SUMMARY

Is it possible to introduce and succeed using a new Agile Software Development Methodology? Of course it is. Will there be challenges along the way? Of course there will. Will there be changes and improvements that must be made

along the way? Yes. Is i t better to understand this from project inception and plan for these things along the way? Absolutely.

Three key requirements for a successful implementation of an Agile Development Methodology include:

• A well defined baseline set of rules or a framework, such as SCRUM

• Supportive management and stakeholders educated

in agile methods

• Team members that are open minded and amenable

to change.

The only constant in most software development is change. It is inevitable that there will be change on any software proj ect, so why not plan for it? There is no "right" way to implement an Agile Development Methodology. Pay attention to what works and what does not work and make adjustments as needed - Inspect and Adapt. Be Agile.

REFERENCES

[ 1 ] The official Scrum Guide: www. scrum. orWScrumGuides.aspx

[2] http://commons. wikinledia. org/wikilF ile: Scrum process.s

yg

[3] http://www. agilemodeling. comlartifacts/userStory.htm

BIOGRAPHY

Michele Gannon received a B.S. in

Computer Science from Towson State University, in 1 99 7. She has worked at the Johns Hopkins University Applied Physics lab for two years and with Agile

Software Development Methodologies for over nine years.