Agile & SCRUM
Download as PPTX, PDF18 likes7,046 views
This document provides an overview of Agile methodology and SCRUM. It discusses the principles of Agile, including its emphasis on collaboration, adaptability, and delivering working software frequently. It then describes SCRUM in more detail, covering the roles of Product Owner, Scrum Master, and Team. The key SCRUM artifacts like Product Backlog, Sprint Backlog, and Burn Down Chart are explained. It also outlines the core SCRUM ceremonies of Sprint Planning, Daily Scrum, Sprint Review, and Retrospective. The document concludes by discussing challenges of adopting SCRUM and provides tips for SCRUM Team members.
Agile & SCRUM
- 1. Agile & SCRUMCreated by ejlp12@gmail.com, 6 Nov 2009Why, What & How.Presented to project team members. Pictures are copied from Internet and not my copyright. Some slides are also taken from Internet.
- 3. Why Agile Software Development…?
- 4. What is Agile?The agile process is based on the empirical approach, accepting the complexity of the problem and addressing it through frequent inspection and constant adaptation– Ken Schwaber
- 5. Agile, basic Adaptive and responsive to changeIncrease productivity and identifying and prioritizing high value featuresPositive emergent culture that allows for continuous improvementAvoid the pitfalls of waterfall
- 6. More on characteristicsEmpirical (relies on observation and experience)LightweightAdaptiveFast – but never hurriedExposes wastefulnessCustomer-centricPushes decision making to lower levelsFosters trust, honesty and courageEncourages self-organization
- 7. Agile manifestoIndividuals & Interactions over Process & ToolsWorking Software over Comprehensive DocumentsCustomer Collaboration over Contract NegotiationResponding to Change over Following a PlanThings on the right are important.Things on the left are more important!!
- 8. Agile methodologiesFeature Driven Development (FDD)Extreme programming (XP)CrystalLean DevelopmentSCRUMRational Unified Process (RUP)Adaptive Software Development (ASD)Dynamic System Development Method (DSDM)
- 9. Agile SW development practicesEssential PracticesRegular refactoring (many times daily)This produces well-componentized designs, clear APIs and clean code without duplicationsFrequent check-ins (many times daily)Unit Testing Leading to Test Driven Development (TDD)Continuous Build and IntegrationRunning automated tests on each buildJust-in-time code reviews (e.g. pair programming)Example methodologies: XP, Agile Modeling
- 10. Agile SW TestingEarly involvementAn Agile project begins when testers convert high-level requirements into testable specifications.Work as part of the development teamThe testers work with the developers to pick unit test and acceptance test frameworks, and to test the software in parallel with development. This requires a shift in thinking.Automate everything(wherever possible)Test early, test oftenNever leave the testing until the end
- 11. The Agile Customer“Customer’ is a role, not a personAlso known as Product Manager, Product OwnerProxy for the entire customer groupResponsible for the Release PlanResponsible for managing the Product BacklogDetermines business value & priority on a regular basisProvides information to development team for estimation purposesWorks with testers to produce clear, testable user stories for each iterationInspects software regularly (e.g. runs acceptance tests) and provides feedback to the development team
- 12. SCRUM
- 14. SCRUM is…Scrum is an agile, lightweight processthat can be used to manage and control software and product development using iterative, incremental practicesWrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementationIt is adaptive, quick, self-organizing and have few rests..process framework, not methodology
- 15. Why SCRUMIt is HOT!It’s work and simple.More practical (practical process model). A rule of thumb or best practices for process inspection and continue adaptation.
- 16. SCRUM CharacteristicsSelf-organizing teamsProduct progresses in a series of month-long “sprints”Requirements are captured in a list of “product backlog”No specific engineering practices prescribedSCRUM doesn’t tell how to develop Software.Find XP, TDD, etc
- 17. Roles and ResponsibilitiesProduct OwnerDefines the features of the product, decides on release date and content
- 18. Is responsible for the profitability of the product (ROI)
- 19. Prioritizes features according to market value
- 20. Can change features and priority every 30 days
- 21. Accepts or rejects work resultsScrum MasterEnsures that the team is fully functional and productive
- 22. Enables close cooperation across all roles and functions and removes barriers
- 23. Shields the team from external interferences
- 24. Ensures that the process is followed. Invites to daily scrum, iteration review and planning meetingsTeamCross-functional, seven plus/minus two members
- 25. Selects the iteration goal and specifies work results
- 26. Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal
- 27. Organizes itself and its work
- 28. Demos work results to the Product OwnerKey ArtifactsProduct backlogList of requirements & issues
- 29. Owned by Product Owner
- 30. Anybody can add to it
- 31. Only Product Owner prioritizesSprint GoalA short “theme” for the sprint, typically one line summary:
- 32. For example, “Make the application run on Oracle in addition to SQL Server”
- 33. Declared by Product Owner
- 34. Accepted by teamFrom Sprint Goal to Sprint Backlog …Scrum team takes the Sprint Goal and decides what tasks are necessary
- 35. Team self organizes around how they’ll meet the Sprint Goal
- 36. Manager doesn’t assign tasks to individuals
- 37. Managers don’t make decisions for the team
- 38. Sprint Backlog is createdSprint backlogList of tasks
- 39. Owned by team
- 40. Only team modifies itBlocks listList of blocks & unmade decisions
- 41. Owned by Scrum Master
- 43. Sprint Backlog
- 44. Sprint Backlog (after 5th days)
- 45. Key MeetingsSprint Planning MeetingHosted by Scrum Master; ½-1 day
- 46. In: Product Backlog, existing product, business & technology conditions
- 47. Select highest priority items in Product Backlog; declare Sprint Goal
- 48. Team turns selected items into Sprint Backlog
- 49. Output Sprint Goal, Sprint BacklogSprint Planning MeetingProduct OwnerScrum TeamManagementCustomersProduct BacklogSprint PlanningMeetingTeam CapabilitiesSprint GoalBusiness ConditionsSprint BacklogTechnologyCurrent Product
- 50. Key Meetings (Cont’d)Daily ScrumHosted by Scrum Master
- 51. 15 – 30 minutes stand-up meeting
- 52. Attended by all: pigs (scrum team) and chickens (others), but only pigs can talk
- 53. Same time every day; three questions:
- 54. What did you do yesterday?
- 55. What will you do today?
- 56. What obstacles are in your way?
- 57. Team updates Sprint Backlog; Scrum Master updates Blocks ListThe team should reflect on how to make them most effective.Sit or stand, up to you!
- 58. SCRUM ProcessBurndown ChartDaily ScrumMeeting24 hoursSprintBacklog tasksexpandedby team30daysSprint BacklogPotentially ShippableProduct IncrementProduct BacklogAs prioritized by Product Owner
- 59. Key Meetings (cont’d)Sprint Review MeetingHosted by Scrum Master, attended byCustomersManagementProduct OwnerTeamTeam presents what it accomplished during the sprintTeam demos Increment2-hourHold retrospectiveAnnounce next Sprint Planning Meeting
- 60. Tools: Burn-down chartFor monitoring progress during a sprint. Remaining work is plotted on the Y axis, Time proceeds along the X axis. As tasks are completed, the line slopes down. Burndown Chart…the velocity of turning requirements into potentially shippable increments of functionality.
- 61. Burndown chart
- 62. Scrum of Scrum
- 63. SummaryRoles : Product Owner, ScrumMaster, Team Artifacts : Product Backlog, Sprint Backlog, Block List and Burndown Chart Ceremonies : Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting
- 64. Concept & Process (PM & SM)Scrum Masters say
- 65. Sprint
- 66. Sprint Backlog
- 67. Task Breakdown
- 68. Velocity
- 69. Burndown Chart
- 71. Schedule
- 72. Scope
- 74. Productivity
- 77. Define Backlog, Plan Sprint
- 78. Develop and Test
- 79. Move Stickies, have Daily Scrums
- 80. Demo, Release, have Retrospective
- 82. Plan
- 83. Execute
- 85. CloseRisks & ChallengesEducating the team – Dev, QA, BusinessEstimations to get work ‘done’ – not just engineeringChanging the mindset of all stakeholders – PM, team, management, client and usersReduced importance to signoffs and approvals, increased value to collaboration and transparencyEither budget or scope should be flexible
- 86. SCRUM IN MY PROJECT
- 87. Case study: Our projectWe haven’t done a SCRUM yetWe planning itWe need to adapt not adopt
- 88. No “big bang” adoptionStart by a simple but working, NOT complete but not working
- 89. The Goal is SuccessSuccess factor as seen by customerOn time No bugs, right features, good performanceSuccessful deployment/releaseSuccess factor as seen by my employerOn time to get moneyMaximum revenueThe client is happy
- 90. The Challenges are…It’s kind like SCM rather than PM Developer tends toHard to estimate working effort (time)Don’t want to commit to timelineComplainingOur work culture:I only doing as you requestedI don’t care about documentationAs long as it is run (passed the test), it’s doneWorking time is not effectiveThe CR is not iterative as seen by customer
- 91. How?We will commit to any task that we can doWe will use tools that works for usWe will share each otherDocument first & document as simple as possibleWe start development earlyIt seems “scrum of scrum” will work rather than scrumMinimize testing iteration whenever possibleCharacterize each CR then reduce work if possibleWe will not do scrum for small (effort) CR (team less than 3)Detail plan will be discussed after this presentation!
- 92. SCRUM TEAM MEMBER?What you should keep in mind
- 93. …SCRUM team, keep asking these questions:What is the simplest thing that can move the project forward?Does what I am doing right now move the project forward at all?Are there any impediments that are preventing progress?Escalate impediment even thought they don’t really care about it.Sprint is belong to the team and is a team’s goal“Don’t procrastinate, do something, no matter how small…” – Ken Schwaber, Vienna, April 2004
- 94. END