Agile & SCRUM


Published on

Published in: Technology

Agile & SCRUM

  1. 1. Agile & SCRUM<br />Created by, 6 Nov 2009<br />Why, What & How.<br />Presented to project team members. Pictures are copied from Internet and not my copyright. Some slides are also taken from Internet.<br />
  2. 2. AGILE Methodology<br />
  3. 3. Why Agile Software Development…?<br />
  4. 4. What is Agile?<br />The agile process is based on the empirical approach, accepting the complexity of the problem and addressing it through frequent inspection and constant adaptation<br />– Ken Schwaber<br />
  5. 5. Agile, basic <br />Adaptive and responsive to change<br />Increase productivity and identifying and prioritizing high value features<br />Positive emergent culture that allows for continuous improvement<br />Avoid the pitfalls of waterfall<br />
  6. 6. More on characteristics<br />Empirical (relies on observation and experience)<br />Lightweight<br />Adaptive<br />Fast – but never hurried<br />Exposes wastefulness<br />Customer-centric<br />Pushes decision making to lower levels<br />Fosters trust, honesty and courage<br />Encourages self-organization<br />
  7. 7. Agile manifesto<br />Individuals & Interactions over Process & Tools<br />Working Software over Comprehensive Documents<br />Customer Collaboration over Contract Negotiation<br />Responding to Change over Following a Plan<br />Things on the right are important.<br />Things on the left are more important!!<br />
  8. 8. Agile methodologies<br />Feature Driven Development (FDD)<br />Extreme programming (XP)<br />Crystal<br />Lean Development<br />SCRUM<br />Rational Unified Process (RUP)<br />Adaptive Software Development (ASD)<br />Dynamic System Development Method (DSDM)<br />
  9. 9. Agile SW development practices<br />Essential Practices<br />Regular refactoring (many times daily)<br />This produces well-componentized designs, clear APIs and clean code without duplications<br />Frequent check-ins (many times daily)<br />Unit Testing <br />Leading to Test Driven Development (TDD)<br />Continuous Build and Integration<br />Running automated tests on each build<br />Just-in-time code reviews (e.g. pair programming)<br />Example methodologies: XP, Agile Modeling<br />
  10. 10. Agile SW Testing<br />Early involvement<br />An Agile project begins when testers convert high-level requirements into testable specifications.<br />Work as part of the development team<br />The 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.<br />Automate everything<br />(wherever possible)<br />Test early, test often<br />Never leave the testing until the end<br />
  11. 11. The Agile Customer<br />“Customer’ is a role, not a person<br />Also known as Product Manager, Product Owner<br />Proxy for the entire customer group<br />Responsible for the Release Plan<br />Responsible for managing the Product Backlog<br />Determines business value & priority on a regular basis<br />Provides information to development team for estimation purposes<br />Works with testers to produce clear, testable user stories for each iteration<br />Inspects software regularly (e.g. runs acceptance tests) and provides feedback to the development team<br />
  12. 12. SCRUM<br />
  13. 13.
  14. 14. SCRUM is…<br />Scrum is an agile, lightweight processthat can be used to manage and control software and product development using iterative, incremental practices<br />Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation<br />It is adaptive, quick, self-organizing and have few rests<br />..process framework, not methodology<br />
  15. 15. Why SCRUM<br />It is HOT!<br />It’s work and simple.<br />More practical (practical process model). <br />A rule of thumb or best practices for process inspection and continue adaptation.<br />
  16. 16. SCRUM Characteristics<br />Self-organizing teams<br />Product progresses in a series of month-long “sprints”<br />Requirements are captured in a list of “product backlog”<br />No specific engineering practices prescribed<br />SCRUM doesn’t tell how to develop Software.<br />Find XP, TDD, etc<br />
  17. 17. Roles and Responsibilities<br />Product Owner<br /><ul><li>Defines the features of the product, decides on release date and content
  18. 18. Is responsible for the profitability of the product (ROI)
  19. 19. Prioritizes features according to market value
  20. 20. Can change features and priority every 30 days
  21. 21. Accepts or rejects work results</li></ul>Scrum Master<br /><ul><li>Ensures that the team is fully functional and productive
  22. 22. Enables close cooperation across all roles and functions and removes barriers
  23. 23. Shields the team from external interferences
  24. 24. Ensures that the process is followed. Invites to daily scrum, iteration review and planning meetings</li></li></ul><li>Team<br /><ul><li>Cross-functional, seven plus/minus two members
  25. 25. Selects the iteration goal and specifies work results
  26. 26. Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal
  27. 27. Organizes itself and its work
  28. 28. Demos work results to the Product Owner</li></li></ul><li>Key Artifacts<br />Product backlog<br /><ul><li>List of requirements & issues
  29. 29. Owned by Product Owner
  30. 30. Anybody can add to it
  31. 31. Only Product Owner prioritizes</li></ul>Sprint Goal<br /><ul><li>A short “theme” for the sprint, typically one line summary:
  32. 32. For example, “Make the application run on Oracle in addition to SQL Server”
  33. 33. Declared by Product Owner
  34. 34. Accepted by team</li></li></ul><li>From Sprint Goal to Sprint Backlog …<br /><ul><li>Scrum team takes the Sprint Goal and decides what tasks are necessary
  35. 35. Team self organizes around how they’ll meet the Sprint Goal
  36. 36. Manager doesn’t assign tasks to individuals
  37. 37. Managers don’t make decisions for the team
  38. 38. Sprint Backlog is created</li></ul>Sprint backlog<br /><ul><li>List of tasks
  39. 39. Owned by team
  40. 40. Only team modifies it</li></ul>Blocks list<br /><ul><li>List of blocks & unmade decisions
  41. 41. Owned by Scrum Master
  42. 42. Updated daily</li></li></ul><li>Product Backlog<br />
  43. 43. Sprint Backlog<br />
  44. 44. Sprint Backlog (after 5th days)<br />
  45. 45. Key Meetings<br />Sprint Planning Meeting<br /><ul><li>Hosted by Scrum Master; ½-1 day
  46. 46. In: Product Backlog, existing product, business & technology conditions
  47. 47. Select highest priority items in Product Backlog; declare Sprint Goal
  48. 48. Team turns selected items into Sprint Backlog
  49. 49. Output Sprint Goal, Sprint Backlog</li></li></ul><li>Sprint Planning Meeting<br />Product Owner<br />Scrum Team<br />Management<br />Customers<br />Product Backlog<br />Sprint Planning<br />Meeting<br />Team Capabilities<br />Sprint Goal<br />Business Conditions<br />Sprint Backlog<br />Technology<br />Current Product<br />
  50. 50. Key Meetings (Cont’d)<br />Daily Scrum<br /><ul><li>Hosted by Scrum Master
  51. 51. 15 – 30 minutes stand-up meeting
  52. 52. Attended by all: pigs (scrum team) and chickens (others), but only pigs can talk
  53. 53. Same time every day; three questions:
  54. 54. What did you do yesterday?
  55. 55. What will you do today?
  56. 56. What obstacles are in your way?
  57. 57. Team updates Sprint Backlog; Scrum Master updates Blocks List</li></ul>The team should reflect on how to make them most effective.<br />Sit or stand, up to you!<br />
  58. 58. SCRUM Process<br />Burndown Chart<br />Daily Scrum<br />Meeting<br />24 hours<br />Sprint<br />Backlog tasks<br />expanded<br />by team<br />30days<br />Sprint Backlog<br />Potentially Shippable<br />Product Increment<br />Product Backlog<br />As prioritized by Product Owner<br />
  59. 59. Key Meetings (cont’d)<br />Sprint Review Meeting<br />Hosted by Scrum Master, attended by<br />Customers<br />Management<br />Product Owner<br />Team<br />Team presents what it accomplished during the sprint<br />Team demos Increment<br />2-hour<br />Hold retrospective<br />Announce next Sprint Planning Meeting <br />
  60. 60. Tools: Burn-down chart<br />For monitoring progress during a sprint. <br />Remaining work is plotted on the Y axis, <br />Time proceeds along the X axis. <br />As tasks are completed, the line slopes down. <br />Burndown Chart…the velocity of turning requirements into potentially shippable increments of functionality. <br />
  61. 61. Burndown chart<br />
  62. 62. Scrum of Scrum<br />
  63. 63. Summary<br />Roles : <br />Product Owner, ScrumMaster, Team <br />Artifacts : <br />Product Backlog, Sprint Backlog, Block List and Burndown Chart <br />Ceremonies : <br />Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting<br />
  64. 64. Concept & Process (PM & SM)<br /><ul><li>Scrum Masters say
  65. 65. Sprint
  66. 66. Sprint Backlog
  67. 67. Task Breakdown
  68. 68. Velocity
  69. 69. Burndown Chart
  70. 70. Project Managers say
  71. 71. Schedule
  72. 72. Scope
  73. 73. Work Breakdown Structure
  74. 74. Productivity
  75. 75. Estimate to Complete
  76. 76. Scrum Masters say
  77. 77. Define Backlog, Plan Sprint
  78. 78. Develop and Test
  79. 79. Move Stickies, have Daily Scrums
  80. 80. Demo, Release, have Retrospective
  81. 81. Project Managers say
  82. 82. Plan
  83. 83. Execute
  84. 84. Monitor & Control
  85. 85. Close</li></li></ul><li>Risks & Challenges<br />Educating the team – Dev, QA, Business<br />Estimations to get work ‘done’ – not just engineering<br />Changing the mindset of all stakeholders – PM, team, management, client and users<br />Reduced importance to signoffs and approvals, increased value to collaboration and transparency<br />Either budget or scope should be flexible<br />
  86. 86. SCRUM IN MY PROJECT<br />
  87. 87. Case study: Our project<br />We haven’t done a SCRUM yet<br />We planning it<br /><ul><li>We need to adapt not adopt
  88. 88. No “big bang” adoption</li></ul>Start by a simple but working, NOT complete but not working<br />
  89. 89. The Goal is Success<br />Success factor as seen by customer<br />On time <br />No bugs, right features, good performance<br />Successful deployment/release<br />Success factor as seen by my employer<br />On time to get money<br />Maximum revenue<br />The client is happy<br />
  90. 90. The Challenges are…<br />It’s kind like SCM rather than PM <br />Developer tends to<br />Hard to estimate working effort (time)<br />Don’t want to commit to timeline<br />Complaining<br />Our work culture:<br />I only doing as you requested<br />I don’t care about documentation<br />As long as it is run (passed the test), it’s done<br />Working time is not effective<br />The CR is not iterative as seen by customer<br />
  91. 91. How?<br />We will commit to any task that we can do<br />We will use tools that works for us<br />We will share each other<br />Document first & document as simple as possible<br />We start development early<br />It seems “scrum of scrum” will work rather than scrum<br />Minimize testing iteration whenever possible<br />Characterize each CR then reduce work if possible<br />We will not do scrum for small (effort) CR (team less than 3)<br />Detail plan will be discussed after this presentation!<br />
  92. 92. SCRUM TEAM MEMBER?<br />What you should keep in mind <br />
  93. 93. …<br />SCRUM team, keep asking these questions:<br />What is the simplest thing that can move the project forward?<br />Does what I am doing right now move the project forward at all?<br />Are there any impediments that are preventing progress?<br />Escalate impediment even thought they don’t really care about it.<br />Sprint is belong to the team and is a team’s goal<br />“Don’t procrastinate, do something, no matter how small…” – Ken Schwaber, Vienna, April 2004<br />
  94. 94. END<br />