Lean and agile in a chestnut
3 likes1,230 views
This document provides an overview of Lean, Agile and Scrum concepts and practices. It discusses Lean principles and how they were developed at Toyota to eliminate waste. It also covers the Agile manifesto and why Agile works by allowing for change and autonomy. The Scrum framework is summarized, including the roles of Product Owner, Scrum Master and Development Team. Key Scrum ceremonies like Sprint Planning, Review and Retrospective are outlined. Common Scrum artifacts such as the Product Backlog, Sprint Backlog and user stories are defined.
Lean and agile in a chestnut
- 1. Lean, Agile & Scrum in a chestnut
- 2. George Stamos Agile/Lean coach and trainer at Intracom Telecoms S.A Scrum.org/User Profile MsC in Electronics & Telecommunications Engineering graduate of Bath University . Specialties: Lean, Agile, Scrum, Kanban, Training & Coaching Scrum Teams, Mentoring Organization’s new Scrum Masters g_stam77 george.m.stamos@gmail.com http://www.slideshare.net/GeorgeStamos
- 3. Agenda • Lean Development – Why Lean? – What Lean is – History of Lean – Lean principles • Agile Development – Controlling chaos – Agile manifesto – Why Agile works – What makes us Agile? – Agile frameworks – Agile philosophy • Scrum framework – Roles – Ceremonies – Artifacts • Scrum Practices – Vision – User Stories – User story estimation – Definition of Ready
- 6. It is not necessary to change. Survival is not mandatory. W. Edwards Deming
- 8. Lean is an Operational Excellence Strategy that enable you to change for the better
- 10. TOYOTA PRODUCTION SYSTEM • The Toyota Production System historically has had four basic aims that are consistent with these values and objectives: • The four goals are as follows: – Provide world class quality and service to the customer. – Develop each employee’s potential, based on mutual respect, trust and cooperation. – Reduce cost through the elimination of waste and maximize profit – Develop flexible production standards based on market demand.
- 11. MURI (LOAD) Refers to the tendency to overload processes in the hope of achieving more. Lean thinking maximizes value creation over process utilization
- 12. MURA (FLOW) Inconsistent flow can disrupt a system, creating inefficiencies and waste. Lean decreases lead time by smoothing flow through a system
- 13. MUDA (WASTE) Refers to any non-value adding activity that a customer is unwilling to pay for.
- 14. Lean Principles • Eliminate waste • Build quality in – Think how to test before starting • Create knowledge – Amplify learning • Defer commitment – Decide as late as possible • Deliver as fast as possible – Learn as fast as possible • Respect people – Empower the team • Optimize the whole – Improve the entire system
- 15. Value Stream Map
- 16. KANBAN Visualize the flow Limit Work in Progress Optimize Lead Time
- 17. Lean Software Development: An Agile Toolkit (Agile Software Development Series) (Paperback) by Mary Poppendieck (Author), Tom Poppendieck (Author) This is Lean: Resolving the Efficiency Paradox Niklas Modig (Author), Pär Åhlström (Author)
- 18. The Principles of Product Development Flow by Donald Reinertsen
- 23. Agile Manifesto Individuals and interactions processes and tools Working software comprehensive documentation Customer collaboration contract negotiation Responding to change following a plan
- 24. WHY AGILE WORK?
- 25. Traditional WoW › Assumptions – The customer knows what he wants – The developers know how to build it – Nothing will change along the way
- 27. . . .
- 28. Result?
- 29. Agile Development › Assumptions – The customer discovers what he wants – The developers discover how to build it – Many things change along the way
- 30. Why Agile works › Autonomy – The desire to direct our own lives › Mastery – The urge to make progress and get better at something that matters › Purpose – The yearning to do what we do in the service of something larger than ourselves.
- 31. SCRUM FRAMEWORK A quick overview of Scrum, its roles and ceremonies
- 32. THREE SCRUM ROLES Product Owner Scrum Master Development Team
- 33. Product Owner PO
- 34. What does a product owner do? • Defines the Product Vision • Define the features of the product • Decide on release date and content • Helps the stakeholders understand – Product/Feature requirements – Product/Feature plans – Business and product/feature risks • Be responsible for the profitability of the product (ROI) • Creates and grooms the Product Backlog • Prioritize features according to market value • Adjust features and priority every iteration, as needed • Collaborates on the product • Accept or reject work results
- 36. What does a scrum master do? • Explain Scrum to the organization • Expert on the Scrum process • Understand that ScM has no product/feature authority • Represents management to the project • Responsible for enacting Scrum values and practices • Removes impediments • Ensure that the team is fully functional • Enable close cooperation across all roles and functions • Shield the team from external interferences • Support the team to be more productive in any way he/she can • Help team to improve the engineering practices • Works on his/her Scrum impediment list
- 38. Development Team A self-organized team that take collective ownership of the Sprint goal and sprint backlog. They fight impediment during the sprint and in retrospective
- 39. Development Team • Cross-functional • Seven plus or minus two members • Works with the Product Owner to select the sprint goal (what) and then specifies the work details (how) • Self-organizing • Team takes authority of the sprint • Team feels empowered • Team commits to work at sprint planning • All team members feel responsible for all tasks • Team constantly improve • Team works closely together • Responsible for product quality
- 40. Scrum Team Product Owner PO Scrum Master SM Development Team TM
- 41. SCRUM CEREMONIES Sprint planning Sprint Review Sprint Retrospective Daily Scrum
- 42. Sprint Planning • Occurs at the beginning of every Sprint – Day 1 – It is time-boxed to eight hours for a one month Sprint. For shorter Sprints, allocate approximately 5% of the total Sprint length to this meeting • Some preparation occurs before the Sprint Planning – Product owner prioritizes and refines the Product Backlog – The Product Owner may involve the team in preparation • Attended by the Product Owner, Scrum Master and Team • There are two parts to the Sprint Planning Meeting: the “What?” part and the “How?” part
- 43. Sprint Review • The team demonstrates working software (no powerpoint!) completed during the sprint. • Product owner accepts or rejects each backlog item - The Scrum team considers the whole product with respect to the release goal and product vision. - How does this affect what we do next? The Sprint Review provides valuable input to subsequent Sprint Planning meeting - The team should briefly prepare so the meeting will be effective
- 44. Sprint Retrospective At regular intervals, the Development Team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
- 45. Agile Retrospectives: Making Good Teams Great (Paperback) by Esther Derby (Author), Diana Larsen (Author), Ken Schwaber (Author)
- 46. Daily Scrum • Whole world is invited – Only team members, Scrum Master, Product Owner, can talk BUT • Only “committed” people are allowed to talk, others can only listen... so the Scrum Master and the Team Members are pigs, the others are chickens...
- 48. SCRUM ARTIFACTS Product Backlog Sprint Backlog Estimation Release Planning
- 49. Product Backlog • User stories that fulfill requirements • A list of all desired work on the project – A list of user stories prioritized – Stories in the Product Backlog include features that deliver the Product Vision • Ideally expressed such that each item has value to the users or customers of the product • Prioritized by the product owner • The highest prioritized items need to be better detailed and specified - the team needs to be able to estimate and test these items • The list of stories is constantly evolving, changing and updating – Reprioritized at the start of each sprint
- 50. Requirements Requirements are the needs that your product must satisfy. They must answer the questions What is the need? and Why? They are descriptions of a problem.
- 51. Discussion • A Stakeholder tells you she needs a bridge • What is her need? • A well formulated requirements described the problem, not the solution
- 52. SMART Requirements • Simple Can everybody understand this? • Measurable When is the Requirement fulfilled? • Achievable Do you have the resources? • Relevant Is it really a need for the customer? • Traceable Who is the stakeholder or origin?
- 53. Example Requirement • Support complains about new features Some guys at the support office are complaining that our product is not easy to use, and they spend too much time on the support hot-line to get our user to run the software. MS A R TMS A R T
- 54. Example Requirement Requirement Need to improve usability: There is the need to make the product UI more intuitive. There are too many support requests related to usage of the tool, often associated with very “simple” problems MS A R TMS A R T
- 55. Sprint Backlog • What we want – A sprint backlog created by the team, estimated by the team and owned by the team. – Progress in sprint is highly visible. – Sprint Goal • A short statement of what the work will be focused on during the sprint
- 56. Agile Estimation • Why do we estimate? – To plan a release consisting of multiple sprints – To help the product owner with prioritizing stories – To estimate how many stories will fit in an iteration • Relative Estimation: Instead of estimating absolute size of feature, we estimate their relative proportion, and then derive the absolute size: ?
- 57. Agile Estimating and Planning (Robert C. Martin Series) (Paperback) by Mike Cohn (Author)
- 58. Release Planning • Why? • Release Planning Approaches – Scope first – Date first
- 59. Succeeding with Agile: Software Development Using Scrum by Mike Cohn Agile Software Development with Scrum (Series in Agile Software Development) (Paperback) by Ken Schwaber (Author), Mike Beedle (Author)
- 60. SCRUM PRACTICES Product Vision Sprint Backlog Release Planning
- 61. Product Vision • Start with WHY first • What do we want to accomplish • Imagine what the product will be like when it is ‘finished.’ • Describe this finished state and publish it. • Use the elevator pitch template.
- 62. Helps you move from this.... “I’m glad we’re all agreed then.”
- 63. to this . . . “I’m glad we’re all agreed then.”
- 64. iPod Vision • “In your pocket” • The iPod will be a portable digital music player that will hold 5000 songs. It will have a battery life measured in days, not hours. You will navigate the thousands of songs with a single finger. You will sync all your music from your computer to the iPod in minutes automatically, so you can have all your music in your pocket.
- 65. The vision that inspired a nation "I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth." — Pres. Kennedy, May 25, 1961
- 66. Made to stick A good book to help you create a catchy vision is “Made to Stick” by Dan Heath & Chip Heath. What you want to describe is the bottom line, the core idea of what you want your product to do. Don’t fall in the trap of rehashing a generic marketing line that applies to your entire company - really think about what you are setting out to achieve with your product.
- 67. User Stories • Requirements are descriptions of needs of the product - describe the problem • Requirements are transformed into multiple User Stories, were each User Story is a proposal to fully or partially satisfy the Requirement • User Stories are proposed solutions from a user’s perspective • User Stories have Acceptance Criteria or Conditions of Satisfaction
- 69. As a <type of user> I want to <do something> so that <I can achieve some business value>. Example format
- 70. Acceptance Criteria • Answer the question: How will know when we are done? • High-level criteria from the perspective of the user or stakeholder • There are Positive and Negative criteria • Collaborate with testers to create good Acceptance Criteria Given <context> When <action> Then <expected result>
- 71. Sample User Story As a Returning Customer I want the system to remember my details so I can purchase goods more quickly. Acceptance criteria: Scenario: Review Details Before Purchase Given I’m on the Amazon website And I’m logged in as a returning customer When I click the “1-Click” button Then I should see my order details
- 72. INVEST model • Independent: – Stories are easiest to work with if they are independent • Negotiable – A good story is negotiable. It is not an explicit contract for features • Valuable – A story needs to be valuable to the customer • Estimable – A good story can be estimated • Small or Sized appropriately – Good stories tend to be small: at most a few person-weeks • Testable – "I understand what I want well enough that I could write a test for it"
- 73. User Stories Applied: For Agile Software Development by Mike Cohn (Author)
- 74. Definition of Ready • A Release is done when it satisfies all the criteria the Product Owner (representing all stakeholders) requires to ship software to production • A User Story is done when it meets the story acceptance criteria and the team’s quality standards for being potentially shippable