Présentation scrum


Published on

Overview of the Scrum project delivery approach.

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

  • Be the first to like this

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

No notes for slide

Présentation scrum

  1. 1. Scrum<br />AnAgileProject Delivery Approach<br />
  2. 2. Discover what Scrum is and what it is not. <br />Understand how Scrum can be used<br />Prepare yourselves to start with Scrum, knowing that this is only the beginning…<br />
  3. 3. Overview of Scrum<br />Is used to conduct complex projects since 1990 <br />Delivers business value every 30 days according to priorities determined by the customer<br />Based on distributed intelligence <br />Fits long, large and distributed projects <br />Meets CMMI Level 3 and ISO 9001 <br />Outlines the issues but gives no answer <br />Is very simple to describe but very difficultto implement<br />
  4. 4. What Scrum proposes<br />
  5. 5. Scrumis not a methodology and does not give the recipe for software development.<br />
  6. 6. Scrum is an Approach, which implies a road, a direction, a frame of mind, perhaps a philosophy, but not a formula of proven rules to be followed. <br />
  7. 7. The product is incrementally developed in blocks of time<br />A prioritized product backlog<br />The empirical process<br />A self-managed team<br />
  8. 8. An Empirical Approach<br />Means that the information is collected by observing, experience or experimenting.<br />
  9. 9. Adding details over time<br />Detailed<br />Elements<br />High-Level<br />Elements<br />Tasks<br />Ideas<br />Sprints 1-2<br />Delivery<br />Current Sprint<br />Product<br />6 Months<br />2-3 Months<br />1 Month<br />Horizon of predictability<br />
  10. 10. The Scrum process<br />Blocks of time (timebox)<br />3 roles<br />Some rules <br />3 points of inspection and adaptation<br />5 artifacts: <br />The product book(product backlog)<br />Delivery progress chart (Release burndown chart)<br />Sprint backlog tasks (sprint backlog)<br />Sprint Progress Chart(sprint burndown chart)<br />new functionality ready to be exploited (Potentially shippable product increment)<br />
  11. 11. Scrum implements an inspection and adaptation mechanism in order to maximize the output. <br />Without visibility, inspection is not possible. <br />Visibility requires transparency, and therefore courage and a suitable value system.<br />
  12. 12. Stages of a sprint<br />1 day meeting to review and debrief<br /> (4 h/ 4 h)<br />1 day meeting to plan sprint (4 h/ 4 h)<br />Development<br />30 day sprint at a sustainable pace<br />
  13. 13. A Scrum team includes only the following people:<br />a multi-disciplinary development team a <br />product manager and a ScrumMaster<br />
  14. 14. Development team’s characteristics<br />Manages itself<br />Is multidisciplinary and has no predetermined roles<br />Has 7 members (+/- 2)<br />Is responsible for his commitment<br />Has the authority to act to meet its commitments<br />Works in close contact<br />Solves its own conflicts<br />Observes basic rules of operation and conduct<br />
  15. 15. What the project manager did which is now done by the development team<br />Making commitments on behalf of the team on what it can accomplish by a given date<br />Convincing the team that commitments are realistic<br />Directs the work of the team so it can meet its commitments<br />Monitor the progress in weekly meetings<br />Reporting back to management on progress<br />Deciding what to do when the team is experiencing difficulties or is delayed<br />“Motivate" the team and encourage them to redouble their efforts<br />Assign tasks and track progress to ensure that the work is done<br />Being responsible for the team doing the right thing at the right time and the right way<br />
  16. 16. The roles of Scrum are difficult to play. <br />
  17. 17. Roles and responsibilities<br />The product manager (product owner) ensures the return on investment when setting the priorities in the product backlog. <br /> <br />Members of the team are responsible for the management of development activities and quality of the software. The team is self-directed and multidisciplinary. <br /> <br />The ScrumMaster ensures the Scrum is efficient without direct authority.<br />
  18. 18. Product Manager (product owner)<br />Defines the characteristics of the product and fixes the delivery date <br />Manages the content of the product to ensure the best possible returns <br />Determines the hierarchy of elements of the product backlog based on business value <br />Can change priorities every 30 days  <br />Accepts or rejects the results<br />
  19. 19. Execution Team<br />Includes seven members (plus or minus two) who form a multidisciplinary team<br />Determines its own commitment and work to be done to achieve the objectives it sets <br />Has the flexibility, based on overall project directives , to do what is necessary to achieve the sprint goal<br />Organizes and manages its activities autonomously<br />Works closely with the product manager to maximize the value produced <br />Presents the achievedresults to the product manager<br />
  20. 20. The ScrumMaster <br />"The ScrumMaster is like a sheep dog who does everything he can to protect his flock, and never allows himself to be distracted from the task.“<br />- Ken Schwaber <br />Ensures the implementation team is functional, productive and is constantly improving its productivity<br />Eliminate barriers and ensure close collaboration between different stakeholders <br />Protects the implementation team of any external interference Ensures the implementation process <br />Ensures that the product manager and team members understand and play their roles properly <br />
  21. 21. Are you a chicken or a pig?<br />
  22. 22. Key considerations<br />The implementation team must deliver software that works and meets the customer specifications sprint after sprint.<br />The implementation team must deliver the product features at a sustainable pace. <br />The Scrum team must learn throughout the project. <br />Knowing that the capacity of the development team is fixed (more or less), the product manager sets priorities to maximize the profitability of the product. <br />
  23. 23. Success FactorsThe product backlog<br />It’s a way to start implementing the vision; it represent all the expected work.<br />It is the common denominator between the product manager and members of the development team.<br />It’s a list of all the functional and non-functional elements to deliver as well as issues to settle.<br />All elements must have value for the product manager.<br />It must be evaluated, estimated and ordered. <br />It provides more details on the elements with high priority. <br />All stakeholders can contribute, however, it’s the product manager who establishes the priority of each element.<br />It is updated and well communicated.<br />
  24. 24. Success FactorsDefining "completed" <br /> The production team and the product manager together define what "completed" means. <br />The definition of "completed" captures the current technical capacity of the team. <br />Over time, the definition of "completed" should extend to all activities required for production delivery.          <br />Need to identify and bring to the product backlog the work that is not covered by the definition of "finished" (that is to say "Unfinished" work).               <br />Anything that does not meet the definition of "completed" is not presented to the product manager at the end sprint. <br />
  25. 25. Consequences of not defining "completed"<br />The velocity is unstable and does not help in planning. <br />The delivery progress graph does not reflect the remaining work to do. <br />The product manager does not know what the real progress is. <br />The product backlog is probably not well-organized. <br />The team does not know what it's committing to during the sprint planning. <br />The product manager does not know what to look at, at the end sprint. <br />
  26. 26. Consequences of "non-completed" work <br />Decision to deliver <br />Delivery<br />Revised<br />Plan<br />Revised<br />Plan<br />Revised<br />Plan<br />Plan<br />Revised<br />Plan<br />Revised<br />debt<br />debt<br />debt<br />debt<br />“Stabilization” Sprint<br /> Rapid and non-linear growth! <br />
  27. 27. Success FactorsMonitoring progress<br />The slope of the remaining work to be done to determine the probable date of delivery.<br />120<br />100<br />80<br />Products remaining to be delivered<br />60<br />40<br />20<br />0<br />Sprint 1 <br />Sprint 2 <br />Sprint 3 <br />Sprint 4 <br />Sprint 5 <br />Sprint 6 <br />Delivery<br />
  28. 28. A scrum team has to struggle against <br />The tyranny of the waterfall process<br />Belief in magic<br />The era of darkness<br />
  29. 29.
  30. 30. Credits<br />Pyxis-Technology (<br />Agile certified trainers<br />Garr Reynolds (<br />