Date post: | 13-Jan-2015 |
Category: |
Technology |
Upload: | mtoppa |
View: | 890 times |
Download: | 0 times |
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