Scrum and the agile development process


Published on

A presentation that I did at work to explain to non-developers the Scrum process and Agile development philosophy.

Published in: Technology
  • Be the first to comment

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

No notes for slide
  • Partially Done Work (the “inventory” of a development process) Relearning (easy to find in documentation-centric development)Extra Features (develop only what customers want right now)Task Switching (everyone should do one thing at a time)Delays (for instructions, for information) Handoffs (tons of tacit knowledge gets lost) Defects (at least defects that are not quickly caught by a test)
  • Respect – teammates must respect each other, developers must respect QA, product management, etc.Commitment – team decides for itself what to take on, but the trade-off for that is commitmentFocus – Minimize task switching; minimize hand-offsOpenness – Requires team to be willing to share true status of thingsCourage – Courage to demand respect; courage to commit; courage to be open; courage to allow a team to focus
  • Promise for a conversationDifferent from traditional requirements documentation which seeks to ensure all details are present to form a “contract”
  • Delivering the highest quality, best customer service.. Every transaction, every time.
  • Scrum and the agile development process

    1. 1. Scrum and the Agile Development Process<br />
    2. 2. Agenda<br />Introduction<br />Empirical vs. Defined Process<br />Agile Development<br />Scrum 101<br />Scrum Overview<br />Roles and responsibilities<br />New Operations Team<br />
    3. 3. Defined Process<br />Requires every piece of work be well understood. <br />Given a well-defined set of inputs, the same outputs are generated every time.<br />Yummy Donuts!<br />Donut Mix<br />
    4. 4. “Traditional” Waterfall<br />Job Function E<br />Job Function D<br />Job Function C<br />Job Function B<br />Job Function A<br />Requirements Gathering<br />Design<br />Development<br />Documentation, Signoffs, Handoff<br />Documentation, Signoffs, Handoff<br />Documentation, Signoffs, Handoff<br />Documentation, Signoffs, Handoff<br />Testing<br />Launch & Maintain<br />Advantage: Highly Logical<br />Disadvantage: Human Beings are involved<br />
    5. 5. Empirical Process<br />Provides and exercises control through frequent inspection and adaptation<br />Processes are imperfectly defined<br />Generate unpredictable and unrepeatable outputs.<br />Yummy Donuts!<br />Is it soup yet?<br />Yummy Soup!<br />Soup Fixin’s<br />
    6. 6. Agile Software Development<br />Feedback<br />Feedback<br />Feedback<br />v 1.0<br />v 1.1<br />v 1.2<br />Short Iterations<br />Incremental Releases<br />
    7. 7. Agile Software Development<br />Feedback<br />Feedback<br />Feedback<br /><ul><li>Plan
    8. 8. Test
    9. 9. Design
    10. 10. Build
    11. 11. Plan
    12. 12. Test
    13. 13. Design
    14. 14. Build
    15. 15. Plan
    16. 16. Test
    17. 17. Design
    18. 18. Build
    19. 19. Plan
    20. 20. Test
    21. 21. Design
    22. 22. Build</li></ul>Do a little bit of everything every cycle<br />
    23. 23. Empirical Processes<br />“It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.”<br />Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992<br />Translation into English: <br />Inspect and Adapt<br />
    24. 24. What are some other examples of processes suited to an empirical approach?<br />???<br />
    25. 25. Roots in Lean: The Seven Wastes<br />
    26. 26. Roots in Lean: The Seven Wastes<br /><br />
    27. 27. Roots in Lean: The Seven Wastes<br />
    28. 28. Agile Manifesto<br />That is, while there is value to the items on the right, we value the items on the left more.<br />
    29. 29. What is Scrum?<br />A flexible framework that is:<br />Collaborative<br />Iterative & Incremental<br />Common Sense<br />Very simple but very hard<br />It causes change<br />It takes discipline<br />
    30. 30. Scrum Values<br />Respect<br />Commitment<br />Focus<br />Openness<br />Courage<br />
    31. 31. Scrum Roles<br />
    32. 32. Product Manager<br />Product visionary<br />Maximizes business value<br />Prioritizes and clarifies requirements<br />
    33. 33. Product Manager<br />Does<br />Provide clear product direction<br />Work with the team closely to clarify requirements<br />Actively manages the product backlog<br />Represents the business and customer needs<br />
    34. 34. Product Manager<br />Does not<br />Assign work to the team members<br />Give fixed date fixed scope projects without team consent<br />Change priorities during a Sprint<br />
    35. 35. Scrum Team<br />Cross-functional<br />Possesses all the skills necessary to produce an increment of potentially shippable product<br />Team takes on tasks based on skills, not just official “role”<br />Self-organizing<br />Team manages itself to achieve the Sprint commitment<br />
    36. 36. Scrum Master<br />Similar to a Project Manager… yet different<br />A facilitator<br />Removes impediments<br />
    37. 37. Scrum Master<br />The Scrum Master does everything in their power to help the team achieve success<br />Serving the team<br />Protecting the team<br />Guiding the team’s use of Scrum<br />
    38. 38. Scrum Process<br />
    39. 39. Product Backlog<br />A prioritized list of requirements<br />Prioritized by the Product Manager<br />Product Backlog<br />
    40. 40. User Stories<br />One way to write a requirement<br />Describes a WHO, WHAT and WHY scenario<br />Describes real business value<br />A “promise for a conversation”<br />Has acceptance criteria to assert its behavior<br />
    41. 41. User Story Template<br />Express user needs in terms of what the user wants to achieve<br />Example:<br />As a <type of user>, I want to <goal> so that <reason/value><br />Always includes acceptance criteria<br />
    42. 42. Sprint Planning<br />Planning at the start of a Sprint by the whole team and the Product Manager<br />Team creates tasks, estimates, and volunteers for them<br />Sprint Planning<br />
    43. 43. Sprints<br />2 week timebox of work.<br />During the Sprint:<br />Analysis<br />Design<br />Code<br />Test<br />A little bit of everything<br />Sprint<br />
    44. 44. Daily Standup<br />A daily team meeting<br />Keep up to date<br />Help each other to resolve problems<br />Daily Stand-up<br />
    45. 45. Sprint Review<br />A demo by the team of:<br />Complete<br />Fully tested<br />Potentially shippable features<br />Anyone can attend<br />Sprint Review<br />
    46. 46. Sprint Retrospective<br />A meeting at the end of each Sprint so the team can inspect and adapt the process.<br />Sprint Retrospective<br />
    47. 47. Tracking Progress<br />
    48. 48. Tracking Progress<br />Highly visible<br />Track the work remaining<br />Don’t care about actual time worked<br />
    49. 49. Burndown Charts<br />
    50. 50. Tracking Progress<br />Uses inspection and subsequent adaptation to optimize realization of goals.<br />Transparency is required for inspection and adaptation<br />Transparency requires courage and change in reward system<br />
    51. 51. Focus<br />My report doesn’t print right.<br />DPR wants to change the Red Zone criteria<br />I didn’t get my scheduled report.<br />I want to keep track of my old comments.<br />Can’t I add contractors during an inspection?<br />
    52. 52. Customer Service<br /><ul><li>Today: “You can have that in the September release.”
    53. 53. Goal: “You can have that on Thursday.”</li></li></ul><li>New Operations Team<br />Two Developers, One QA<br />Builds to test up to daily<br />Mini-releases up to weekly<br />Not Scrum, but it is Agile<br />
    54. 54. New Operations Team<br />
    55. 55. New Operations Team<br />Respond to small/moderate customer requests quickly<br />Can focus on support issues when required<br />Can focus on operations issues when required<br />Keeps the other team focused on the release<br />