Download as PDF, PPTX
![THE ORIGIN
• Toyota lean concept
• The new, new software
development game
[Takeuchi & Nonaka, 1986]
• Iterative & incremental
development](https://image.slidesharecdn.com/worldmate-170509121320/75/Practical-Scrum-one-day-training-39-2048.jpg)
![THE ORIGIN OF
SCRUM
• Toyota lean concept
• The new, new software
development game
[Takeuchi & Nonaka, 1986]
• Iterative & incremental
development
• Jeff Sutherland
• Ken Schwaber](https://image.slidesharecdn.com/worldmate-170509121320/75/Practical-Scrum-one-day-training-58-2048.jpg)
![EXERCISE
Estimate The Following Based On Weight In
Kilograms [No Google Please!!!]
• Chihuahua
• Great Dane
• Staffordshire bull terrier
• Appalachian mountain dog
• Border Collie
• American Cocker spaniel](https://image.slidesharecdn.com/worldmate-170509121320/75/Practical-Scrum-one-day-training-83-2048.jpg)
More Related Content
Similar to Practical Scrum - one day training
Practical Scrum - one day training
- 1. PRACTICAL SCRUM Like us: Visit: Follow me: Tweet: CONSTANT HIGHER MORE LEARNING QUALITY FUN Day 1 www.facebook.com/PracticalAgile www.practical-agile.com @Linkedin @PracticalAgile1
- 4. BEING AGILE ISOUR FAVORITE THING
- 5. Some Working Agreement Ifyou want to be here - act like you want to be here
- 6.
- 7.
- 8. Respect the stickynote One item per sticky, use a sharpie
- 9. What are wegoing to cover today? TABLE OF CONTENTS What is Agile? What is scrum? What are the roles in scrum? What is the manager role within agile environment? How to estimate stories? How do we do long term planning? What is the meaning of each ceremony in scrum?
- 10. “It ain’t whatyou don’t know that gets you into troubles. It’s what you know for sure that just ain’t so” Mark Twain WHAT WE THOUGHT VS. WHAT WE KNOW
- 11. What we thoughtvs. What we know
- 12.
- 13. WINSTON W. ROYCE1970 "I believe in this concept, but the implementation described above is risky and invites failure"
- 14. “It ain’t whatyou don’t know that gets you into troubles. It’s what you know for sure that just ain’t so” Mark Twain WHAT WE THOUGHT VS. WHAT WE KNOW
- 15. 01 WHAT WE KNOW The harderwe plan and analyze in the beginning, the less there’s change in the project and the more successful the project WHAT WE THOUGHT
- 16. WHAT WE THOUGHT 01 WHAT WE KNOW Thereis change always and responding to it is vital. Uncertainty is best reduced by learning from actual implementation
- 17. 02 WHAT WE KNOW It ispossible to “collect” or even “know” all the requirements up-front WHAT WE THOUGHT
- 18. 02 WHAT WE KNOW Requirements evolve ascustomers and our knowledge increases – based on experience WHAT WE THOUGHT
- 19. 03 WHAT WE KNOW Division ofwork to specialized teams (specification, design and testing) is efficient WHAT WE THOUGHT
- 20. WHAT WE THOUGHT 03 WHAT WE KNOW Cross-functionalteams reduce the amount of handovers and are more productive
- 21. 04 WHAT WE KNOW Multiple parallelprograms speed up the development WHAT WE THOUGHT
- 22. EXERCISE Exercise: The NameFactory • • • •
- 23.
- 24. Round 2 No ContextSwitch
- 25. WHAT WE THOUGHT 04 WHAT WE KNOW Multipleprograms create big management overhead and risk of overloading the pipeline, R&D works most efficiently in continuous mode
- 26. 05 WHAT WE KNOW Resource usageand cost optimization is the key to increased productivity WHAT WE THOUGHT
- 27. Continues Improvement Respect forPeople Waste Value Opportunity for improvement Traditional improvement Lean Thinking
- 28. Kaizen - ReduceWaste Value: The moments of actions or thoughts creating the product that the customer is willing to pay for Total value time Total cycle time = Value ratio____________ Waste: All other moments or actions that do not add value but consume resources
- 29. Detect and EliminateWaste 1. Overproduction of features 2. Waiting and delay 3. Handoff 4. Extra process 5. Partially done work
- 30. Detect and EliminateWaste 6. Task Switching 7. Defects 8. Under-realizing people’s potential 9. Knowledge scatter 10.Wishful thinking
- 31. WHAT WE THOUGHT 05 WHAT WE KNOW Concentratingon value stream optimization, removing waste and sustainable flow increases productivity
- 32. 06 WHAT WE KNOW It’s possibleto transfer information effectively on written documents without much of human contact. WHAT WE THOUGHT
- 33. WHAT WE THOUGHT 06 WHAT WE KNOW Essentialknowledge is lost in every handover and human interaction is needed to overcome it.
- 34. 07 WHAT WE KNOW You cansave time by “good-enough” development. WHAT WE THOUGHT
- 35. Technical Debt Time Work left 20 10 1214 16 18 Low Quality
- 36. WHAT WE THOUGHT 07 WHAT WE KNOW Anytechnical debt will slow development down and thus we don’t allow technical debt to accumulate.
- 37. 08 WHAT WE KNOW Product development processcan be defined as a predictable and repeatable process WHAT WE THOUGHT
- 38. WHAT WE THOUGHT 08 WHAT WE KNOW Productdevelopment is an evolving and adaptive process
- 39. THE ORIGIN • Toyotalean concept • The new, new software development game [Takeuchi & Nonaka, 1986] • Iterative & incremental development
- 40.
- 41. EXERCISE Rewrite Each AgilePrinciple With 3 Words
- 42. Agile Principle 1-4 1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
- 43. Agile Principle 1-4 1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 2.Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
- 44. Agile Principle 1-4 1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale
- 45. Agile Principle 1-4 1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale 4. Business people and developers must work together daily throughout the project
- 46. Agile Principle 5-8 5.Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done
- 47. Agile Principle 5-8 5.Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done 6. The most efficient and effective method of conveying information to and within development team is face-to-face conversation
- 48. Agile Principle 5-8 5.Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done 6. The most efficient and effective method of conveying information to and within development team is face-to-face conversation 7. Working software is the primary measure for progress
- 49. Agile Principle 5-8 5.Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done 6. The most efficient and effective method of conveying information to and within development team is face-to-face conversation 7. Working software is the primary measure for progress 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
- 50. Agile Principle 9-12 9.Continuous attention to technical excellence and good design enhances agility
- 51. Agile Principle 9-12 9.Continuous attention to technical excellence and good design enhances agility 10.Simplicity – the art of maximizing the amount of work not done – is essential
- 52. Agile Principle 9-12 9.Continuous attention to technical excellence and good design enhances agility 10.Simplicity – the art of maximizing the amount of work not done – is essential 11.The best architectures, requirements, and designs emerge from self-organizing teams
- 53. Agile Principle 9-12 9.Continuous attention to technical excellence and good design enhances agility 10.Simplicity – the art of maximizing the amount of work not done – is essential 11.The best architectures, requirements, and designs emerge from self-organizing teams 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
- 54.
- 55.
- 56. • In ourindustry people got used to create and use META solutions to problems. • The problems we are facing have nothing to do with technology, it is a people issue. • In this land the basic assumption is that there is no META solution, just an empirical framework to allow inspect & adapt cycles. • This experience is frustrating for those who are looking for predefined processes and final answers. • ENTER AT YOUR OWN RISK!!!
- 57. WHAT IS SCRUM? "Scrumis a team of eight individuals in Rugby. Everyone in the pack acts together with everyone else to move the ball down the field in small incremental steps. Teams work as tight, integrated units with whole team focusing on a single goal."
- 58. THE ORIGIN OF SCRUM • Toyota lean concept • The new, new software development game [Takeuchi & Nonaka, 1986] • Iterative & incremental development • Jeff Sutherland • Ken Schwaber
- 59. • Understanding thatwe cannot predict the future • One size does not fit all • Constant improvement • Transparency & Visibility • Team work SCRUM PRINCIPLES
- 60. • Deliver businessvalue fast (max. 30 days) • Prioritizing • Empirical approach • Fun !!! SCRUM PRINCIPLES
- 61. THE HIGH MOONSTUDIO
- 62. SCRUM PROCESS OVERVIEW 3Roles: Product owner Scrum Master Team 4 Ceremonies : Sprint Planning Daily Sprint review Retrospective 3 Artifacts: Product Backlog Sprint Backlog Burndown Charts
- 63. SCRUM MASTER (SM) •Scrum - A framework for managing the development lifecycle of software products • Master - A skilled practitioner of a particular art or activity • A Scrum master - the leader of the Scrum process (& team)
- 64. What does itmeans “The leader of the scrum process”? • Coach the team with Scrum • Coach the PO with Scrum • Help Facilitate effective ceremonies • Helps removing impediments • Help the team grow • He is standing at the nexus between: The product management that believes that any amount of work can be done Developer’s that have the willingness to cut quality to support the managements belief
- 65. The English verb“to manage” was originally derived from the Italian maneggiare, meaning to handle and train horses The SM has no authority over the team or the PO
- 66. WHAT IS THEMANAGER ROLE WITHIN AGILE ENVIRONMENT? A change in Manager’s role Stop: • Assign task and verify completion • Micro manage to have the “illusion of control” • Makes decisions for the team • Limit the information & resources available to the team Start: • Trust the team to get the job done • Gather data • Coach - observe and ask questions • Challenge • Give feedback
- 67. SCRUM TEAM • Selforganizing • Typically 5-9 people • Cross functional (Preferably a feature team) • Provide estimate for the tasks • Decides how much it can do • Decides how to reach the sprint goal (within the project’s boundaries) • The team is responsible for the outcome
- 68. CONCEPT CHANGE • Decideswhat it can do • Decides how to do it • Responsible for the quality • If the job is successful the team gets the credit • If the job is not DONE the team is responsible ALL OF US ARE SMARTER THAN ANY OF US
- 69. THE TEAM IS WRONG? •Let the team fail • Create an environment where it is ok to fail • Failure amplifies learning • Where failure is allowed, innovation and experiments are encouraged • Increases trust THERE IS NO FAILURE ONLY FEEDBACK
- 70. PRODUCT OWNER (PO) •Defines the features of the product • Defines release dates and content • Responsible for ROI • Prioritizes feature according to value • Can change features and priority once every predefined interval • Decides what will be worked on in each iteration • Accepts or rejects results
- 71. Manage the productBacklog 1. Clear 2. Ranked 3. Optimize the value 4. Visible transparent 5. Ensure understanding
- 72. Traditionally throws content“over the fence”
- 73. The PO takesan active role throughout the development lifespan Traditionally throws content “over the fence” NO MORE! CONCEPT CHANGE
- 74. How? • Talk directlyand frequently with your customers • Talk directly and frequently with your development teams • Engage the development teams in creating value for your customers • Maintain your product’s quality and agility – do not let technical debt accumulate
- 75. Product Backlog Refinement= Grooming The team and the PO together review the backlog in order to make it ready for the next 2-3 sprints How? Grooming = Clarifying, Estimating, and Splitting Recommended to allocate ~5% of the sprint time
- 77.
- 78. KEN SCHWABBER, “SCRUMET AL”
- 79. What is Definitionof Done (DoD) Terms of satisfaction of the product owner Defined by the PO with the team reflecting the technical abilities of the team Items that are not Done “do not count”
- 80. This is justone example Expending the Definition of Done over time Designed Coded analyzed Unit tested Perf. tested Code coverage Live Deployable Acc. tested
- 81. This is justone example Expending the Definition of Done over time Undone Undone Undone Undone Stabilization sprint(s) Sprint 1 Sprint 2 Sprint 3 Sprint 4 Undone = risk Undone = no visibility Can we release ? Unfinished Unfinished Unfinished
- 82.
- 83. EXERCISE Estimate The FollowingBased On Weight In Kilograms [No Google Please!!!] • Chihuahua • Great Dane • Staffordshire bull terrier • Appalachian mountain dog • Border Collie • American Cocker spaniel
- 84. “IT IS BETTERBE ROUGHLY RIGHT THAN PRECISELY WRONG” John Maynard Keynes
- 85.
- 86.
- 87. • We are: - Not good in measuring absolute values - Good in comparing things • We have the basic math skills (or a calculator) • High accuracy has a high toll • Estimates become commitments • Time is not persistent Why Relative?
- 88. Story Points: They reflectthe “bigness” of a user story How hard it is ? How risky it is ? How much of it there is ? 5 ? 3
- 89. 1. Each persongets a deck of cards (Fibonacci) 2. The item to be estimated is read to all 3. Attendants ask clarifications for the item 4. Each person selects a card and puts it on the table facing down 5. When everyone is done, cards are exposed 6. If the estimations do not match a short discussion is done: Highest and Lowest estimators speak first -> return to step 4 7. Handle next item Planning Poker:
- 90. EXERCISE Estimate The FollowingBased On Size Using Planning Poker • Spain • China • Luxembourg • Denmark • South Africa - 8 (Reference point) • Belize
- 91. • Those whodo the work estimate it • Emphasizes relative estimation • Estimates are within one order of magnitude • Modeled for open discussion – forces thinking • Reduces anchoring - Everyone's opinion is heard WHY USE PLANNING POKER?
- 92. One page spec GroupA 7 Pages spec Group B 173 hours 117 hours Specification Length
- 93. Group A Customer thinks500 customer has no technical knowledge Don’t let the customer influence you Group B 555 hours 456 hours Same as B customer thinks 50 Group C 99 hours Anchoring
- 94. WHY USE PLANNING POKER? IT ISQUICK! IT IS FUN!
- 95. Spain 3 China Toobig Luxembourg 0 Denmark 1 South Africa 8 Belize 1 Chihuahua 3 Great Dane 90 Staffordshire bull terrier. 17 Appalachian mountain dog. ??? Border Collie 23 American Cocker spaniel 13 The Results
- 96. Velocity = Speed+ Direction How many points can the team complete in one iteration Easy to measure Fixes estimation errors Easily reflects the project status Primary parameter in planning
- 97. SP 8 priority 5 priority 4 SP 8 priority3 Planning Iteration Planning As Anat, scrum Master, I would like to calculate team velocity so that I will be able to estimate how much work I can do in the following iteration SP 5 priority 2 Planning SP 2 Iteration 1: SP Done = 5+8+2 = 15 velocity = 15
- 98. SP 8 priority 5 priority 4 SP 8 priority3 Planning Iteration Planning As Anat, scrum Master, I would like to calculate team velocity so that I will be able to estimate how much work I can do in the following iteration SP 5 priority 2 Planning SP 2 Iteration 1: SP Done = 5+8+2 = 15 velocity = 15 priority 7 SP 5 priority 6 Planning As Elad, product owner, I would like to calculate team velocity so that I will be able to estimate how much work we are going to complete in two months SP 8 priority 5 Planning SP 2 Iteration 2: SP Done = 8+5 = 13 velocity = (15+13)/2 = 14
- 99. SP 5 priority 8 What willhappen if support is needed? SP 2 priority 7 Long Term Crisis: Planning Iteration 3: SP Done = 2+5 = 7 velocity = (15+13+7)/3 = 12~ SP Done: Iteration 4 = 5 Iteration 5 = 7 Iteration 6 = 6 Velocity = (13+7+5) = 8 Velocity = (7+5+7) = 6 Velocity = (5+7+6) = 6
- 100. Planning For Support: Alternatingteam each sprint Alternating person each sprint Limiting the hours per team Use velocity - Ignoring it completely
- 101.
- 102.
- 103. Calculating Release Time Giventhat: The items for the release are estimated The velocity is known (or predicted) We know the scope or deadline #Story points Time Velocity
- 104. Calculating Release Time Wecan estimate: How much content can we do until the deadline How many sprints it will take to complete the content # Sprints X Velocity = # Story Points # Story Points Velocity = # Sprints____________ #Story points Time Velocity
- 105.
- 106. Sprint Planning The firstmeeting of the sprint Length: 2-8 hours Participants: PO, Team, Scrum Master Preconditions: Product backlog should be in good shape Divided into two parts
- 107.
- 108. Sprint Planning -Part I Decide what the team takes to part II 1. PO Explains the top items from the backlog 2. Team decides what takes to part II in order to commit for sprint content 3. Team and PO selects the sprint goal
- 109. Sprint Planning -Part II Generate the sprint backlog & commit on the sprint’s content How? Splitting each of the stories into smaller tasks Estimating each task (maximum length 8 hours) Design decisions Verify that the goal is achievable Commit
- 110.
- 111. The sprint Backlog Belongsto the team Assists the team in tracking the sprint’s progress Maximum task length should not exceed 16h (2 days) for a 2 week sprint Updated throughout the sprint • Every team member can add, remove or change the sprint backlog • Status of tasks & remaining work is updated daily • Sprint content emerges
- 112. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 113. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 114. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 115. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 116. To do Inprogress Done PBI # 1 PBI # 2 Task Board
- 117. Burndown Chart A simplevisual way of tracking progress Used in different levels: Sprint Release Product Shows the amount of work left to reach target
- 118. Effortremaining 0 25 50 75 100 Sprint 1 2 34 5 6 7 8 Sprint Burndown Chart
- 119.
- 120. Every day, Sametime, Same place No longer than 15 minutes Stand up All the team must attend Only team members are allowed to speak Daily
- 121. Daily 3 Questions: 1. Whathave we accomplished since the last daily 2. What will we accomplish until the next daily 3. What are my/our impediments
- 122.
- 123. Sprint Review Show &Tell Bazaar Review
- 124. Close the sprint Participants: The team, PO, everyone (managers, customers..) Inspect & adapt, focus on feedback - this is NOT a Demo Focus on shard learning - not reporting Only Done Working Software allowed Avoid power point presentation Sprint Review
- 125.
- 126.
- 129. Sprint Retrospective ‘The greatestenemy of great is good enough’
- 130. Goal: Inspect andcreate plan for improvements Team time tune & adjust After sprint review - Before sprint planning Length: 1-2 hours Participates: Scrum Master and the team (others are optional) Generate AI (experiments) to execute the following sprint Sprint Retrospective Things to Stop doing Things to start doing Things to Keep doing
- 131. Retrospective Model Example Opening(2-5 minutes) Data collection (15-25 minutes) Generate insights (15-25 minutes) Decide what do do (15-25 minutes) Closing (2-5 minutes)
- 132. THE WRONG WAYTO DO RETROSPECTIVE
- 133.
- 135. “THE VALUE OF ANIDEA LIES IN THE USING OF IT” Thomas Edison
- 136.
- 137. Reading List 1. CleanCode 2. Scrum Guide 3. Delivering happiness 4. Peopleware *RECOURSE