Why Scrum Why Now


Published on

Date: March 22, 2010

An overview of the web team at U Penn's School of Medicine Information Services adoption of scrum

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Old projects are like geological layers. They build up over time, and always require some degree of ongoing maintenance and feature enhancements. New projects are continuously piled on top, but our staffing does not increase. Eventually we will reach a point of unsustainability, unless we find a way to increase our productivity.
  • Typically for our projects, resources are fixed, scope often changes, and deadlines are sometimes flexible. With Scrum, deadlines and resources are fixed, and scope is what shifts. Priority features are worked on first in a sprint, and developed to be fully functional. If the work was underestimated, then lower priority features are skipped, and roll over to the next sprint. The point is that we are always delivering fully functional features on a regular schedule, and priority features are done first.
  • Why Scrum Why Now

    1. 1. Why Scrum? Why Now? <ul><li>Michael Toppa </li></ul><ul><li>University of Pennsylvania </li></ul><ul><li>School of Medicine </li></ul><ul><li>Information Services </li></ul><ul><li>March 22, 2010 </li></ul>
    2. 2. Why Scrum? Why Now? <ul><li>Projects are born, they rarely die </li></ul><ul><li>Our staffing is not increasing </li></ul>
    3. 3. SOMIS Workflow <ul><li>Our workflow is half-agile, half-waterfall </li></ul><ul><ul><li>We don't do lengthy, detailed requirements documentation </li></ul></ul><ul><ul><li>Instead, we communicate frequently with clients </li></ul></ul><ul><ul><li>We expect and allow change </li></ul></ul><ul><ul><li>But when we code we still try to anticipate all possibilities and model perfectly </li></ul></ul><ul><ul><li>Then we feel frustrated when things shift </li></ul></ul><ul><ul><li>When we refactor we feel like we failed to get it right the first time </li></ul></ul>
    4. 4. SOMIS Workflow <ul><li>Our workflow is not transparent to us or to our clients </li></ul><ul><ul><li>Hard to control scope of new work </li></ul></ul><ul><ul><li>Hard to commit to schedule for delivering new work </li></ul></ul><ul><ul><li>Hard to estimate our resources/availability for new work requests from ”occasional” clients </li></ul></ul><ul><ul><li>We've struggled with finding standards for our documentation </li></ul></ul>
    5. 5. SOMIS Staffing <ul><li>Our funding model has resulted in one developer only for most clients/projects </li></ul><ul><ul><li>Increases risk: no coverage </li></ul></ul><ul><ul><li>Removes flexibility: hard to allocate needed resources to important projects </li></ul></ul><ul><ul><ul><li>Waves of inequitable workloads </li></ul></ul></ul><ul><ul><ul><li>Technical debt accumulates </li></ul></ul></ul><ul><ul><li>Limits benefits of teamwork: </li></ul></ul><ul><ul><ul><li>More and better ideas for solving problems </li></ul></ul></ul><ul><ul><ul><li>Sharing of solutions across projects </li></ul></ul></ul><ul><ul><ul><li>Fewer weaknesses, reinforced strengths </li></ul></ul></ul><ul><ul><ul><li>More fun! </li></ul></ul></ul>
    6. 6. What Are Others Doing? <ul><li>Many possibilities, but most common are: </li></ul><ul><ul><li>Waterfall: a ”heavy”, command-and-control methodology </li></ul></ul><ul><ul><ul><li>Any programmer over 30 will know it </li></ul></ul></ul><ul><ul><ul><li>Used to be commonly viewed as the ”right” way </li></ul></ul></ul><ul><ul><li>” Roll with the punches” & overtime: an opaque process </li></ul></ul><ul><ul><li>Scrum: a ”light”, agile methodology </li></ul></ul><ul><ul><ul><li>An overview </li></ul></ul></ul><ul><ul><ul><li>Now used by Google, Yahoo!, IBM, Lexis-Nexis, Fidelity, and many others </li></ul></ul></ul>
    7. 7. The Project Management Triangle
    8. 8. Why Scrum? <ul><li>Scrum complements our strengths </li></ul><ul><ul><li>Get better at what we already do: expect change </li></ul></ul><ul><li>Will help us address weaknesses </li></ul><ul><ul><li>Not feel frustrated when things change </li></ul></ul><ul><ul><li>Reap the benefits of teamwork </li></ul></ul><ul><ul><li>Plan for future projects and allocate resources </li></ul></ul><ul><li>Mike ♥ Efficiency, Improving Workflow </li></ul><ul><ul><li>Scrum provides a coherent framework for addressing goals I outlined previously </li></ul></ul>
    9. 9. 6 Essentials of Scrum <ul><li>Cross-Functional Teamwork </li></ul><ul><ul><li>” An Activity-Specific Sprint is as bad an idea as it would be an acronym” - Mike Cohn </li></ul></ul><ul><li>Continuously deliver functional, useful features </li></ul><ul><ul><li>Priority features get done first </li></ul></ul><ul><ul><li>Enables continuous feedback and refinement </li></ul></ul><ul><ul><li>Maintains momentum </li></ul></ul><ul><ul><li>YAGNI – ”you ain't gonna need it” </li></ul></ul>
    10. 10. 6 Essentials of Scrum <ul><li>Change happens – plan on it! </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>But it's still ok to pull out the map when you need it </li></ul></ul><ul><li>Maximize productivity over time </li></ul><ul><ul><li>Multi-tasking reduces productivity </li></ul></ul><ul><ul><li>Work on only one project at a time </li></ul></ul><ul><ul><li>No scope change within sprints, but ok between sprints </li></ul></ul>
    11. 11. 6 Essentials of Scrum <ul><li>Continuous improvement: inspect and adapt </li></ul><ul><ul><li>Recommended to start with ”textbook” scrum </li></ul></ul><ul><ul><li>Use sprint retrospective meetings to guide refinement of the process </li></ul></ul><ul><li>Transparency: for us and for our clients </li></ul><ul><ul><li>Provides predictability, builds confidence, establishes trust </li></ul></ul><ul><ul><li>Helps maintain sanity of workload </li></ul></ul><ul><ul><li>Improves quality </li></ul></ul>
    12. 12. What's Next? <ul><li>Developers' Meetings: </li></ul><ul><ul><li>April 5: the product backlog and user stories </li></ul></ul><ul><ul><li>April 12: sprints and techniques for estimating </li></ul></ul><ul><ul><li>April 19: roles and teamwork in Scrum </li></ul></ul><ul><ul><li>Future: technical practices </li></ul></ul><ul><li>April 7: 1 st sprint for pilot Research Billing project ends </li></ul><ul><li>Start a sprint for another pilot project with a different team soon </li></ul><ul><li>Mike will discuss with our clients </li></ul>