An Agile Implementation of SeRUM

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 e

x

amine 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 ite

r

a

tiv

e

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

g

ui

dance

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

de

velo

p

i

ng 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 S

p

r

in

t

Backlog. The Product

Backlog is

a prioritized list of requirements

for

a

system.

The

list

can

i

nc

lu

de 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

s

ole

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 sp

rin

t 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 P

r

oduc

t

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 c

om

p

l

eted in this Sprint. The Sprint Backlog

has

tasks

broken down into un

it

s 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

meeti

ng

) is conducted

or

h

eld

every

day in which each mem

ber 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

resolve

d

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 S

print Planning

Session.

This is the opportunity for

the SCRUM

Team to

identify

things that w

en

t 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 c

o

mp

le

x

software.

Software Pwpose

The purpose

of the software

this team was developing was

to

remotely monito

r

and control equipment that

b

ui

l

ds 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 networ

k

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, Spri

n

ts were scheduled

to

last greater

than

30 days. In add

ition one team

member

was not co-located

with

the rest of the team.

DailyScrum

Daily Serums were held

every day at 9am

in the team lab. Initially the

Daily

Serums included

just

the software engineers.

These

meetin

g

s typically resulted

in illlanswered

qu

e

s

ti

o

n

s which

would require

fo

l

l

ow

up

with the other teams. It became beneficial to have eac

h of the other teams

represented at the Daily Serum.

Because

of the larger

team

size,

the Daily Serums were time-boxed to

30

min

u

t

e

s 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

f

ollowing

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

q

u

e

st

ion

s

and a

second for

any

further

discussion or questions. This actually res

u

lted 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 so

ft

ware 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

u

s

ed

to express

the

complexity of a user story. Story Points are

u

s

e

d during Sprint Planning to assist in determining the

number

of user stories that can be completed

in

a Sp

r

int, 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 Sp

r

int 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

P

l

a_nnin

_{g started with}

_{a set of user}

_stories

_that

_{had a}

s

i

mil

ar theme

and

that

when grouped together could result in a

d

emo-able product. Each selecte

d

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,

w

hic

h 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

t

his pass hour estimates and

a

priority

were

assigned to each task.

Estimating-Estimating

always seems to be

a

d

i

f

fi

cult process with

any s

o

ftw

a

re

develo

p

ment methodology. This starts with the decomposition of tasks

to

an appropriate

level.

In the first Sprint

tasks

were decomposed to a very low leve

l

. As multiple tasks could be completed within a

piece of code, mu

l

tiple t

a

sk

s

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 shou

l

d 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 14 15 16 17 18 19 20 21 22 23 24 25 26 Days in Sprint

Prioritization

of

Tasks-To ensu

r

e

that

the most critical tasks

were

addresse

d 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

S

print 2

the

team identified certa

i

n tasks that

would need

to happen with every user story, thus a base

set

of tasks for

each user story was create

d

. Examples of these

tasks

include

d

"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 Figu

r

e 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.

�\I

'

.s

CIU8E

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 K

a

nban Board included To Do, In Progress, and Comple

t

ed. 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 sec

t

ion 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 b

e

ginning of each Sprint and was open to any

team

memb

e

r or stakeholder. A dry run of the review demonstration was

typically sche

d

uled 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 point

s

so it could ultimately be determined

if

additional

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 thing

s

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

i

mm

ediately

at the start

of t

h

e

next Sprint. The

S

p

r

i

n

t

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:

•

Th

_e

team

was flexible

in the

assignment of tasks

and

"rolled with

the

punches"

• The team established trust an

d

a feeling

of

collective

success

• _{Poor communication with network}

and

_{test teams}

(res

u

lted 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

so

m

e

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,

t

ra

in

ing

, an unplanned out of office, or corporate meeting

and events.

The total team

capacity

was

the

sum of each individual team

member's capacity.

Est

i

mates

Person A

Person B

Person C

Person D

Pers

on E

Person F

Remainin

T

o

ta

l

:

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

c

an

be m

easu

red

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,

de

m

o scripts, design documents, use cases, and

checklists.

A user guide,

s

t

y

le guide, and installation procedures

were

updated

with

each Sprint.

4. CHALLENGES

Challenges

w

il

l

occur on any software development project. The

benefit of

using an Agile Development Methodology is

that with

the continuous inspecting and a

d

a

p

t

ing

, process

improvements

can

be made as

needed and are planned for within each Sprint.

Team

Only

one

of

the six team members was a

l

l

o

ca

t

e

d 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 pro

j

ect 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 te

a

m

members

had to become

good

with their own time management.

Another

challenge fo

r

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 mad

e

identifying the team velocity metric diffIcult. This was addressed

by ensuring the

total hours

for

tas

k

s assigned to a Sprint were less than the team capacity and by Spr

i

nt

Backlog

task prioritization.

Priority 3 tasks

were

identifIed

as tasks

that could

be

deferred to a future Sprint if needed. A third cha

l

lenge 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 m

ul

t

i

p

l

e

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 w

i

thin

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

ear

l

ier 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

addit

i

on, 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 sm

a

lle

r discussion immediately

following the seRUM or a follow up meeting

la

ter in the day.

Sprints

The

length

of the

S

prints was a challenge. With

the

team

members being

a

l

located less than

100%

to

the

project

Sprints

were

typically lo

n

ger

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

i

nclu

d

e

tool

set up and confIguration

or

product installation. In the initial Sprints this was a challenge, because automated builds and unit testing

was

d

e

si

r

a

ble.

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

use

r

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

wi

t

hin the Sprint. A

development

environment was maintained

where

the software

developers created

and compiled code. A

test

environment was maintained

which

had th

e

content of the last

S

print.

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

d

e

velo

ped

was to

monitor

various pieces

of equipment, del

a

ys 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 sl

i

ce was defmed

as an

implementation of a feature

across

a single

pi

e

c

e 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 tea

m

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

t

h

e result

of

a strong agile SCR UM team.

Sprint Planning

Sprint Planning

improved

throughout the duration of the project. As

the

team

became c

omfortable with the process

and each

other, as

well as

their collective goal, Sprint

Planning

discussions were more honest and thorough. This res

u

lted 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 membe

r of the

team presented the po

r

t

i

on

of

the product

they

developed. This allowed

for everyone

on the team to participate and take pride in each incremental

d

elivery.

Sprint Retrospectives

There is

always room to improve. Effective communication

is

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 incre

a

sed 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 somet

h

ing was "Done" . This ensured that throughout the process standards were being followed,

documentation was

being

updated, unit tests were

being

created and

executed, and code reviews were

b

ein

g

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

a

n

d

improvements

that must

be

made along the way? Yes. Is

it

better to understand this from

project

in

ception

and

plan for these things alon

g

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.

wikinled

i

a

.

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.