Why Scrum Why Now

Why Scrum? Why Now?
Michael Toppa
University of Pennsylvania
School of Medicine
Information Services
March 22, 2010

Why Scrum? Why Now?
Projects are born, they rarely die
Our staffing is not increasing

SOMIS Workflow
Our workflow is half-agile, half-waterfall
We don't do lengthy, detailed requirements documentation
Instead, we communicate frequently with clients
We expect and allow change
But when we code we still try to anticipate all possibilities and model perfectly
Then we feel frustrated when things shift
When we refactor we feel like we failed to get it right the first time

SOMIS Workflow
Our workflow is not transparent to us or to our clients
Hard to control scope of new work
Hard to commit to schedule for delivering new work
Hard to estimate our resources/availability for new work requests from ”occasional” clients
We've struggled with finding standards for our documentation

SOMIS Staffing
Our funding model has resulted in one developer only for most clients/projects
Increases risk: no coverage
Removes flexibility: hard to allocate needed resources to important projects
Waves of inequitable workloads
Technical debt accumulates
Limits benefits of teamwork:
More and better ideas for solving problems
Sharing of solutions across projects
Fewer weaknesses, reinforced strengths
More fun!

What Are Others Doing?
Many possibilities, but most common are:
Waterfall: a ”heavy”, command-and-control methodology
Any programmer over 30 will know it
Used to be commonly viewed as the ”right” way
” Roll with the punches” & overtime: an opaque process
Scrum: a ”light”, agile methodology
An overview
Now used by Google, Yahoo!, IBM, Lexis-Nexis, Fidelity, and many others

The Project Management Triangle

Why Scrum?
Scrum complements our strengths
Get better at what we already do: expect change
Will help us address weaknesses
Not feel frustrated when things change
Reap the benefits of teamwork
Plan for future projects and allocate resources
Mike ♥ Efficiency, Improving Workflow
Scrum provides a coherent framework for addressing goals I outlined previously

6 Essentials of Scrum
Cross-Functional Teamwork
” An Activity-Specific Sprint is as bad an idea as it would be an acronym” - Mike Cohn
Continuously deliver functional, useful features
Priority features get done first
Enables continuous feedback and refinement
Maintains momentum
YAGNI – ”you ain't gonna need it”

Change happens – plan on it!
It's ”..like driving at night in the fog. You can only see as far as your headlights, but you can make the whole trip that way.” - E.L. Doctorow
But it's still ok to pull out the map when you need it
Maximize productivity over time
Multi-tasking reduces productivity
Work on only one project at a time
No scope change within sprints, but ok between sprints

Continuous improvement: inspect and adapt
Recommended to start with ”textbook” scrum
Use sprint retrospective meetings to guide refinement of the process
Transparency: for us and for our clients
Provides predictability, builds confidence, establishes trust
Helps maintain sanity of workload
Improves quality

What's Next?
Developers' Meetings:
April 5: the product backlog and user stories
April 12: sprints and techniques for estimating
April 19: roles and teamwork in Scrum
Future: technical practices
April 7: 1 st sprint for pilot Research Billing project ends
Start a sprint for another pilot project with a different team soon
Mike will discuss with our clients

http://www.toppa.com	62
http://www.slideshare.net	6
http://feeds.feedburner.com	1

Why Scrum Why Now

by mtoppa on Mar 28, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 69

Statistics

Why Scrum Why Now — Presentation Transcript