Scrum and the agile development process
- 1. Scrum and the Agile Development Process
- 2. AgendaIntroductionEmpirical vs. Defined ProcessAgile DevelopmentScrum 101Scrum OverviewRoles and responsibilitiesNew Operations Team
- 3. Defined ProcessRequires every piece of work be well understood. Given a well-defined set of inputs, the same outputs are generated every time.Yummy Donuts!Donut Mix
- 4. “Traditional” WaterfallJob Function EJob Function DJob Function CJob Function BJob Function ARequirements GatheringDesignDevelopmentDocumentation, Signoffs, HandoffDocumentation, Signoffs, HandoffDocumentation, Signoffs, HandoffDocumentation, Signoffs, HandoffTestingLaunch & MaintainAdvantage: Highly LogicalDisadvantage: Human Beings are involved
- 5. Empirical ProcessProvides and exercises control through frequent inspection and adaptationProcesses are imperfectly definedGenerate unpredictable and unrepeatable outputs.Yummy Donuts!Is it soup yet?Yummy Soup!Soup Fixin’s
- 6. Agile Software DevelopmentFeedbackFeedbackFeedbackv 1.0v 1.1v 1.2Short IterationsIncremental Releases
- 8. Test
- 9. Design
- 10. Build
- 11. Plan
- 12. Test
- 13. Design
- 14. Build
- 15. Plan
- 16. Test
- 17. Design
- 18. Build
- 19. Plan
- 20. Test
- 21. Design
- 22. BuildDo a little bit of everything every cycle
- 23. Empirical Processes“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.”Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992Translation into English: Inspect and Adapt
- 24. What are some other examples of processes suited to an empirical approach????
- 25. Roots in Lean: The Seven Wastes
- 26. Roots in Lean: The Seven Wasteswww.dbo2.com
- 27. Roots in Lean: The Seven Wastes
- 28. Agile ManifestoThat is, while there is value to the items on the right, we value the items on the left more.
- 29. What is Scrum?A flexible framework that is:CollaborativeIterative & IncrementalCommon SenseVery simple but very hardIt causes changeIt takes discipline
- 31. Scrum Roles
- 32. Product ManagerProduct visionaryMaximizes business valuePrioritizes and clarifies requirements
- 33. Product ManagerDoesProvide clear product directionWork with the team closely to clarify requirementsActively manages the product backlogRepresents the business and customer needs
- 34. Product ManagerDoes notAssign work to the team membersGive fixed date fixed scope projects without team consentChange priorities during a Sprint
- 35. Scrum TeamCross-functionalPossesses all the skills necessary to produce an increment of potentially shippable productTeam takes on tasks based on skills, not just official “role”Self-organizingTeam manages itself to achieve the Sprint commitment
- 36. Scrum MasterSimilar to a Project Manager… yet differentA facilitatorRemoves impediments
- 37. Scrum MasterThe Scrum Master does everything in their power to help the team achieve successServing the teamProtecting the teamGuiding the team’s use of Scrum
- 38. Scrum Process
- 39. Product BacklogA prioritized list of requirementsPrioritized by the Product ManagerProduct Backlog
- 40. User StoriesOne way to write a requirementDescribes a WHO, WHAT and WHY scenarioDescribes real business valueA “promise for a conversation”Has acceptance criteria to assert its behavior
- 41. User Story TemplateExpress user needs in terms of what the user wants to achieveExample:As a <type of user>, I want to <goal> so that <reason/value>Always includes acceptance criteria
- 42. Sprint PlanningPlanning at the start of a Sprint by the whole team and the Product ManagerTeam creates tasks, estimates, and volunteers for themSprint Planning
- 43. Sprints2 week timebox of work.During the Sprint:AnalysisDesignCodeTestA little bit of everythingSprint
- 44. Daily StandupA daily team meetingKeep up to dateHelp each other to resolve problemsDaily Stand-up
- 45. Sprint ReviewA demo by the team of:CompleteFully testedPotentially shippable featuresAnyone can attendSprint Review
- 46. Sprint RetrospectiveA meeting at the end of each Sprint so the team can inspect and adapt the process.Sprint Retrospective
- 48. Tracking ProgressHighly visibleTrack the work remainingDon’t care about actual time worked
- 49. Burndown Charts
- 50. Tracking ProgressUses inspection and subsequent adaptation to optimize realization of goals.Transparency is required for inspection and adaptationTransparency requires courage and change in reward system
- 51. FocusMy report doesn’t print right.DPR wants to change the Red Zone criteriaI didn’t get my scheduled report.I want to keep track of my old comments.Can’t I add contractors during an inspection?
- 52. Customer ServiceToday: “You can have that in the September release.”
- 53. Goal: “You can have that on Thursday.”New Operations TeamTwo Developers, One QABuilds to test up to dailyMini-releases up to weeklyNot Scrum, but it is Agile
- 55. New Operations TeamRespond to small/moderate customer requests quicklyCan focus on support issues when requiredCan focus on operations issues when requiredKeeps the other team focused on the release
Editor's Notes
- #13: 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)
- #16: 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
- #26: Promise for a conversationDifferent from traditional requirements documentation which seeks to ensure all details are present to form a “contract”
- #38: Delivering the highest quality, best customer service.. Every transaction, every time.