Date: March 22, 2010 An overview of the web team at U Penn's School of Medicine Information Services adoption of scrum

1. Scrum at SOMIS
Michael Toppa
University of Pennsylvania
School of Medicine
Information Services
November 2, 2010

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

3. Web Group: Old Setup
PM Design PM
Admissions BGS Registrar Designer Designer ITMAT Designer
FAPD FAPD PM ITMAT OHR Genetics DSS Other

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

5. Web Group: New Setup
Admissions, BGS, Registrar, Others FAPD, Genetics, DSS, Others
SM PO SM PO
ITMAT, OHR, Vice Dean of Research, Others Design Team: ITMAT, Others
SM PO SM PO

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

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

8. Waterfall
 Traditionalsoftware 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.
“Waterfall” Development Methodology
Document System Concept
l
tia
System Requirements
Architectural Design
u en
eq
Detailed Design
Code, Debug, Unit Test
System Test
S
Deploy & Operate

9. Waterfall: Results
 Accordingto 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”

10. The Agile Alternative
Waterfall Agile
The Plan creates The Vision creates
cost/schedule estimates feature estimates
Constraints Features Cost Schedule
Value / Vision
Driven
Plan
Driven
Estimates Cost Schedule Features
Source: Michelle Sliger in “Relating PMBOK Practices to Agile Practices”

11. The Agile Umbrella
AGILE
Crystal XP
DSDM
Scrum
Lean FDD

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

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

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

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

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

17. A Team's Product Backlog
Project Project Project Project Project Project
Backlog Backlog Backlog Backlog Backlog Backlog
Client Backlog Client Backlog Client Backlog
Team Backlog

18. DEEP
 Product Backlogs should be:
 Detailed appropriately
 Estimated
 Emergent
 Prioritized

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

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

21. Start Date: 5/24
Research Billing - Sprint 2
 Percent Effort
Still To Go Burndown Chart
End Date: 6/4
User Stories: 20
Estimated Hours: 81
100
90
5/25
80
5/28
70
60
50
6/2
40
30
20
6/4
10
0
0 1 2 3 4 5 6 7 8 9
Days
Percent Ideal Line

22. 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?

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

24. 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
 Scrumcalls 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

25. Scrum Summary

26. Requirements

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

28. 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.”

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

30. Sample Application Prototype

31. Derived User Stories

32. Good stories: INVEST
 Independent
 Negotiable
 Valuable to users or customers
 Estimatable
 Small
 Testable

33. 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)

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

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

36. Planning and Estimating

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

38. Story Points

39. Planning Poker

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

41. Using Velocity to Predict

42. 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…”

43. Example of Tasks for a Story

44. Putting It All Together

45. When you need something
more…
 It’sperfectly 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

46. Technical Practices

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

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