Scrum at SOMIS

Michael Toppa

University of Pennsylvania

School of Medicine

Information Services

November 2, 2010

Overview

The SOMIS Web Applications Group our staff – our teams – our challenge

3 different approaches to software development waterfall - no formal process - agile

Scrum 3 roles - 3 artifacts - 3 meetings

Requirements user stories – epics - conditions of satisfaction

Planning and Estimating release planning – estimating - velocity - sprint planning

Technical practices OOD - TDD – refactoring – pair programming

Web Group: Old Setup

ITMATFAPD PM OHR Genetics DSS

BGS

FAPD

Admissions Registrar

Other

DesignerDesigner ITMAT Designer

Design PMPM

Problems with the old setup

Each programmer worked in a “silo” Inadequate sharing of skills and knowledge Not enough common solutions to common problems Support problems if someone is out or leaves Difficult to swarm on a big project Difficult to find support for clients we work with only

occasionally Unclear responsibilities for project managers Often difficult to plan

Web Group: New Setup

PO

Admissions, BGS, Registrar, Others

SM PO

FAPD, Genetics, DSS, Others

SM

PO

Design Team: ITMAT, Others

SMPO

ITMAT, OHR, Vice Dean of Research, Others

SM

Our Current Challenges

Getting better at doing Scrum Getting more staff – we especially need another Product

Owner Getting our backlog under control

Currently supporting and developing 109 applications for 22 different clients

That does not include the design team, which supports roughly 200 static web sites

Our recent planning effort indicates we would need to triple our staff to do the work our clients desire over the next six months

We're working on establishing an Advisory Board to help us prioritize our work

3 Approaches to Software Development

Waterfall – focus on “anticipation” Highly detailed, big plans

No formal process – focus on “adaption” Every day is an adventure

Agile – balance anticipation and adaption Has a formal process, but is geared towards

adapting to change

Waterfall

Traditional software development models are based upon a defined methodology which attempts to: Define all requirements up front Logically break down the work Estimate the effort / durations Plan out all the work And only then begin the development…while trying to

limit/control any change that will threaten the plan.

Document System Concept

System Requirements

Architectural Design

Detailed Design

Code, Debug, Unit Test

System Test

Deploy & Operate

“Waterfall” Development Methodology

Sequential

Waterfall: Results

According to industry surveys, the waterfall model results in overproduction of features: Almost half of all features are never used One-fifth of features are rarely used

Business value is not delivered reliably: One-fifth of all projects are considered failures by

their clients Half of all projects are considered ”challenged”

The Agile Alternative

ConstraintsConstraints

EstimatesEstimates

FeaturesFeatures

ScheduleScheduleCostCost

PlanPlan

DrivenDriven

The Plan createscost/schedule estimates

WaterfallThe Vision createsfeature estimates

ScheduleScheduleCostCost

FeaturesFeatures

Value / VisionValue / VisionDrivenDriven

Agile

Source: Michelle Sliger in “Relating PMBOK Practices to Agile Practices”

The Agile Umbrella

Scrum

XPCrystal

Lean

DSDM

FDD

AGILE

Scrum Is...

3 Roles 3 Artifacts 3 Meetings That's it!

But there are also several best practices commonly used with Scrum, for requirements gathering and for writing code

Roles: The Product Owner

Manages the relationship with the clients Gathers and writes up business requirements Sets the priorities for the team Responsible for what the team will work on, but not

how the work is done: Does not have authority over technical design decisions Cannot tell an individual team member what to do

A good Product Owner is: available, business-savvy, communicative, decisive, empowered

Roles: The Scrum Master

A “servant-leader” for the team Analogous to a physical trainer: can set goals and provide

encouragement, but cannot specifically tell you what to do

But does have authority over the Scrum process For example, if daily scrums are getting long and unproductive, the

Scrum Master can limit the scope of conversation and control the length of the meeting

Removes obstacles for the team, such as: Helping a product owner to improve poorly defined requirements Helping to solve technical problems

A good Scrum Master is: responsible, humble, collaborative, committed, influential, and knowledgeable

Roles: The Team

The team takes collective responsibility for doing the work, and doing it in priority order

This means more interaction with co-workers than some programmers are used to

It can also mean more interaction with clients Team members can still have a technical

specialty (e.g. database design), or a project specialty, but will often need to do work outside their specialties

Artifacts: Product Backlogs

Every project has a set of desired features The “backlog” for the project is where the features are listed in

priority order The priorities are determined by the clients' business needs

But negotiation is allowed for reasons of technical efficiency

The Product Owner is responsible for the Product Backlog Each of our clients has a number of projects Each of our teams support a number of clients

A Team's Product Backlog

ProjectBacklog

ProjectBacklog

Client Backlog

ProjectBacklog

ProjectBacklog

Client Backlog

ProjectBacklog

ProjectBacklog

Client Backlog

Team Backlog

DEEP

Product Backlogs should be: Detailed appropriately Estimated Emergent Prioritized

Artifacts: The Sprint Backlog

A sprint is a repeating time interval – we start a new sprint every 2 weeks

At the start of each sprint, the team estimates the top priority items in their product backlog, to determine how many they think they can finish in the sprint

The product backlog items the team feels they can commit to finishing are put in the sprint backlog

Any unfinished items from one sprint roll over to the next sprint Because we work in priority order, any unfinished work is the least

important work

Artifacts: Burndown Charts

A burndown chart provides a high-level snapshot of the team's progress during a sprint

The Y axis indicates the work remaining to do Work is estimated at the start of the sprint

The X axis shows the days remaining in the sprint

0 1 2 3 4 5 6 7 8 9

0

10

20

30

40

50

60

70

80

90

100

Research Billing - Sprint 2

6/4

Percent Ideal Line

Days

Percent EffortStill To Go Burndown Chart

Start Date: 5/24End Date: 6/4

User Stories: 20Estimated Hours: 81

5/25

5/28

6/2

Scrum Meetings

Release Planning Team estimates new product backlog items

Held as needed

Run by the Product Owner

Sprint Planning First day of sprint

Decide on work for the sprint

Run by the Scrum Master

Daily Scrum Daily check-in meeting: 15 minutes maximum

Run by the Scrum Master

What did you do yesterday?

What are you doing today?

Do you need help with anything?

Scrum Meetings

Sprint Review Product Owner reviews finished work

Held at the end of the sprint

Run by the Scrum Master

Sprint Retrospective Held at the end of the sprint

Team review - highlight what went well, what didn't, discuss goals for next sprint

Run by the Scrum Master

Product Owner typically not included

Scrum of Scrums Retrospective for all teams together

Held as desired

SOMIS Sprint Compromises

Scrum calls for focus on a single project Our sprints typically entail work on a few projects, as we

simply have too many

Scrum calls for not making any changes to the work planned in a sprint We stick to our planned work, but we reserve time in

each sprint for unplanned work and urgent bugs For many of our clients we are involved in day-to-day

operational support needs We will work towards reducing unplanned work – it is a

big culture change for us and our clients

Scrum Summary

Requirements

Requirements Gathering

In Scrum, we don't define a complete, highly detailed plan at the start of a project. Why?

Time is scarce Don't treat all requirements as equal Do priority features first Learn the details about a requirement as it gets closer to the

time you'll work on it

Things will change New requirements will emerge as the project progresses Others may fall away

User Stories

Requirements are gathered in the form of User Stories

As a [role] I want to [do something] so that [goal]

Provides a quick understanding of who, what, and why

“As a theater patron, I want to reserve a ticket online, so I am sure I can go to the play.”

Gathering User Stories

Often a good way to start is with a low fidelity visual prototype of the application flow

Using a white board is good for this A Product Owner's responsibility, but the team

can help Provides a basis for deriving user stories Makes it easier to understand how the user

stories will fit together to shape the overall user experience

Sample Application Prototype

Derived User Stories

Good stories: INVEST

Independent Negotiable Valuable to users or customers Estimatable Small Testable

Conditions of Satisfaction

By the time the story is ready to be coded, all the details need to be added, in the form of high level acceptance tests (conditions of satisfaction)

The tests let the developers know how to measure when they are done, and they facilitate estimating

They can be added as they are discovered (over the course of planning meetings with product owners, even while developers are estimating)

Example Conditions of Satisfaction

As a theater patron, I want to reserve a ticket online, so I am sure I can go to the play.

Conditions of Satisfaction Customer can choose from seats not already

reserved Customer can pay with a valid Visa, MasterCard, or

American Express Customer will receive an email notification

summarizing the reservation

Epics

Epics are very large stories for work that will be done further in the future

They will need to be broken down into multiple user stories before they can be worked on

“As a job seeker, I want to post my resume online, so potential employers can find me”

Useful for initial scoping of the features areas in a large project

Planning and Estimating

Release Planning

In release planning meetings, the team reviews new stories

After the team has a general understanding of a story, they estimate the size of the work involved

Estimating is done in story points

Story Points

Planning Poker

Velocity

The story points completed in a sprint is the team's velocity for that sprint

The goal is to measure how quickly a team moves through the product backlog, so we can plan

A team's historical record can be used to determine the likely range of future velocities

Important not to use one team's velocity to predict the velocity of other teams, especially early on Perspectives on story point numbers may vary Different teams may have different tempos

Using Velocity to Predict

Going from Stories to Tasks

When it’s time for the team to estimate stories for a sprint, break the story down into tasks

Estimate the work in hours at this point, not story points We can do away with time estimates once we establish a

velocity for the team

The next slide is a task breakdown for the story: “A user can search for a hotel on various fields…”

Example of Tasks for a Story

Putting It All Together

When you need something more…

It’s perfectly fine to supplement conditions of satisfaction with other documents: The Research Billing project has a spreadsheet

indicating the availability of various functions by user role. This is easier to understand and reference than multiple lists of conditions

Specification by example is also a useful technique for understanding and documenting complex rules

Technical Practices

Clean Code

Projects do not start with a big design plan in Scrum This means code must be designed with future

refactoring in mind: Object oriented design Small classes and methods – the single responsibility

principle (SRP) Meaningful names – self-documenting code Automated tests – gives you confidence to make changes

without fear of breaking downstream dependencies

New Practices for SOMIS

We are just starting to explore the technical practices recommended for use with scrum

Object oriented design Several of our projects use OOD extensively, but we don't have a

common set of practices yet

Test driven development One team so far has experimented with TDD I have found it to be a powerful technique

Pair programming One team has also experimented with this Studies indicate the quality improvements far outweigh the time

spent by two people working on the same task