Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Practical Scrum - one day training

•
•
A
Anat (Alon) Salhov

Here are the estimated story points for the items using Planning Poker: Spain - 13 China - 13 Luxembourg - 5 Denmark - 8 South Africa - 8 (reference point) Belize - 3

1 of 137
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

Practical Scrum - one day training
Practical Scrum - one day training
BEING AGILE IS OUR FAVORITE THING
Some Working Agreement If you want to be here - act like you want to be here
Some Working Agreement
EXERCISE Let’s Form Teams
Respect the sticky note One item per sticky, use a sharpie
What are we going 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?
“It ain’t what you 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
What we thought vs. What we know
Requirements Design Implement Test Acceptance Analysis Deliver
WINSTON W. ROYCE 1970 "I believe in this concept, but the implementation described above is risky and invites failure"
“It ain’t what you 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
01 WHAT WE KNOW The harder we plan and analyze in the beginning, the less there’s change in the project and the more successful the project WHAT WE THOUGHT
WHAT WE THOUGHT 01 WHAT WE KNOW There is change always and responding to it is vital. Uncertainty is best reduced by learning from actual implementation
02 WHAT WE KNOW It is possible to “collect” or even “know” all the requirements up-front WHAT WE THOUGHT
02 WHAT WE KNOW Requirements evolve as customers and our knowledge increases – based on experience WHAT WE THOUGHT
03 WHAT WE KNOW Division of work to specialized teams (specification, design and testing) is efficient WHAT WE THOUGHT
WHAT WE THOUGHT 03 WHAT WE KNOW Cross-functional teams reduce the amount of handovers and are more productive
04 WHAT WE KNOW Multiple parallel programs speed up the development WHAT WE THOUGHT
EXERCISE Exercise: The Name Factory • • • •
Round 1 Context Switch
Round 2 No Context Switch
WHAT WE THOUGHT 04 WHAT WE KNOW Multiple programs create big management overhead and risk of overloading the pipeline, R&D works most efficiently in continuous mode
05 WHAT WE KNOW Resource usage and cost optimization is the key to increased productivity WHAT WE THOUGHT
Continues Improvement Respect for People Waste Value Opportunity for improvement Traditional improvement Lean Thinking
Kaizen - Reduce Waste 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
Detect and Eliminate Waste 1. Overproduction of features 2. Waiting and delay 3. Handoff 4. Extra process 5. Partially done work
Detect and Eliminate Waste 6. Task Switching 7. Defects 8. Under-realizing people’s potential 9. Knowledge scatter 10.Wishful thinking
WHAT WE THOUGHT 05 WHAT WE KNOW Concentrating on value stream optimization, removing waste and sustainable flow increases productivity
06 WHAT WE KNOW It’s possible to transfer information effectively on written documents without much of human contact. WHAT WE THOUGHT
WHAT WE THOUGHT 06 WHAT WE KNOW Essential knowledge is lost in every handover and human interaction is needed to overcome it.
07 WHAT WE KNOW You can save time by “good-enough” development. WHAT WE THOUGHT
Technical Debt Time Work left 20 10 12 14 16 18 Low Quality
WHAT WE THOUGHT 07 WHAT WE KNOW Any technical debt will slow development down and thus we don’t allow technical debt to accumulate.
08 WHAT WE KNOW Product development process can be defined as a predictable and repeatable process WHAT WE THOUGHT
WHAT WE THOUGHT 08 WHAT WE KNOW Product development is an evolving and adaptive process
THE ORIGIN • Toyota lean concept
 • The new, new software development game [Takeuchi & Nonaka, 1986] • Iterative & incremental development
WHAT IS AGILE?
EXERCISE Rewrite Each Agile Principle With 3 Words
Agile Principle 1-4 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
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
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
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
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
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
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
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
Agile Principle 9-12 9. Continuous attention to technical excellence and good design enhances agility
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
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
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
EXERCISE Command and Control Vs. Self Manage
Where Scrum Fits?
• In our industry 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!!!
WHAT IS SCRUM? "Scrum is 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."
THE ORIGIN OF 
 SCRUM • Toyota lean concept
 • The new, new software development game [Takeuchi & Nonaka, 1986] • Iterative & incremental development • Jeff Sutherland • Ken Schwaber
• Understanding that we cannot predict the future
 • One size does not fit all
 • Constant improvement
 • Transparency & Visibility • Team work SCRUM PRINCIPLES
• Deliver business value fast (max. 30 days) • Prioritizing • Empirical approach • Fun !!! SCRUM PRINCIPLES
THE HIGH MOON STUDIO
SCRUM PROCESS OVERVIEW 3 Roles: Product owner Scrum Master Team 4 Ceremonies : Sprint Planning Daily Sprint review Retrospective 3 Artifacts: Product Backlog Sprint Backlog Burndown Charts
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)
What does it means 
 “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
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
WHAT IS THE MANAGER 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
SCRUM TEAM • Self organizing • 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
CONCEPT CHANGE • Decides what 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
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
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
Manage the product Backlog 1. Clear 2. Ranked 3. Optimize the value 4. Visible transparent 5. Ensure understanding
Traditionally throws content “over the fence”
The PO takes an active role throughout the development lifespan Traditionally throws content “over the fence” NO MORE! CONCEPT CHANGE
How? • Talk directly and 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
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
Practical Scrum - one day training
Sizing Requirements
KEN SCHWABBER, “SCRUM ET AL”
What is Definition of 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”
This is just one example Expending the Definition of Done over time Designed Coded analyzed Unit tested Perf. tested Code coverage Live Deployable Acc. tested
This is just one 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
Agile Effort Estimations
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
“IT IS BETTER BE ROUGHLY RIGHT THAN PRECISELY WRONG” John Maynard Keynes
Persistence of Time
34.4 Relative Estimations
• 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?
Story Points: They reflect the “bigness” of a user story How hard it is ?
 How risky it is ?
 How much of it there is ? 5 ? 3
1. Each person gets 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:
EXERCISE Estimate The Following Based On Size Using Planning Poker • Spain • China • Luxembourg • Denmark • South Africa - 8 (Reference point) • Belize
• Those who do 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?
One page spec Group A 7 Pages spec Group B 173 hours 117 hours Specification Length
Group A Customer thinks 500 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
WHY USE PLANNING POKER? IT IS QUICK! IT IS FUN!
Spain 3 China Too big 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
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
SP 8 priority 5 priority 4 SP 8 priority 3 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
SP 8 priority 5 priority 4 SP 8 priority 3 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
SP 5 priority 8 What will happen 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
Planning For Support: Alternating team each sprint
 Alternating person each sprint
 Limiting the hours per team
 Use velocity - Ignoring it completely
Agile Planning With Scrum Daily Iteration Release Product Portfolio Strategy
Release Planning#Story points Time Velocity
Calculating Release Time Given that: The items for the release are estimated The velocity is known (or predicted) We know the scope or deadline #Story points Time Velocity
Calculating Release Time We can 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
Scrum Ceremonies
Sprint Planning The first meeting of the sprint
 Length: 2-8 hours
 Participants: PO, Team, Scrum Master
 Preconditions: Product backlog should be in good shape
 Divided into two parts
Sprint Planning Goal
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
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
Sprint Backlog
The sprint Backlog Belongs to 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
To do In progress Done PBI # 1 PBI # 2 Task Board
To do In progress Done PBI # 1 PBI # 2 Task Board
To do In progress Done PBI # 1 PBI # 2 Task Board
To do In progress Done PBI # 1 PBI # 2 Task Board
To do In progress Done PBI # 1 PBI # 2 Task Board
Burndown Chart A simple visual way of tracking progress Used in different levels: Sprint Release Product Shows the amount of work left to reach target
Effortremaining 0 25 50 75 100 Sprint 1 2 3 4 5 6 7 8 Sprint Burndown Chart
Daily Scrum
Every day, Same time, Same place
 No longer than 15 minutes
 Stand up
 All the team must attend
 Only team members are allowed to speak Daily
Daily 3 Questions: 1. What have we accomplished since the last daily 2. What will we accomplish until the next daily 3. What are my/our impediments
EXERCISE Daily Scrum From Hell
Sprint Review Show & Tell Bazaar Review
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
EXERCISE Ball Point Game
EXERCISE Ball Point Game ‣ ‣ ‣ ‣
Practical Scrum - one day training
Practical Scrum - one day training
Sprint Retrospective ‘The greatest enemy of great is good enough’
Goal: Inspect and create 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
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)
THE WRONG WAY TO DO RETROSPECTIVE
Parking lot
Practical Scrum - one day training
“THE VALUE OF AN IDEA LIES IN THE USING OF IT” Thomas Edison
THE EXPERT SOLUTION
Reading List 1. Clean Code 2. Scrum Guide 3. Delivering happiness 4. Peopleware *RECOURSE

More Related Content

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 IS OUR FAVORITE THING
  • 5. Some Working Agreement If you want to be here - act like you want to be here
  • 8. Respect the sticky note One item per sticky, use a sharpie
  • 9. What are we going 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 what you 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 thought vs. What we know
  • 13. WINSTON W. ROYCE 1970 "I believe in this concept, but the implementation described above is risky and invites failure"
  • 14. “It ain’t what you 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 harder we 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 There is change always and responding to it is vital. Uncertainty is best reduced by learning from actual implementation
  • 17. 02 WHAT WE KNOW It is possible to “collect” or even “know” all the requirements up-front WHAT WE THOUGHT
  • 18. 02 WHAT WE KNOW Requirements evolve as customers and our knowledge increases – based on experience WHAT WE THOUGHT
  • 19. 03 WHAT WE KNOW Division of work to specialized teams (specification, design and testing) is efficient WHAT WE THOUGHT
  • 20. WHAT WE THOUGHT 03 WHAT WE KNOW Cross-functional teams reduce the amount of handovers and are more productive
  • 21. 04 WHAT WE KNOW Multiple parallel programs speed up the development WHAT WE THOUGHT
  • 22. EXERCISE Exercise: The Name Factory • • • •
  • 25. WHAT WE THOUGHT 04 WHAT WE KNOW Multiple programs create big management overhead and risk of overloading the pipeline, R&D works most efficiently in continuous mode
  • 26. 05 WHAT WE KNOW Resource usage and cost optimization is the key to increased productivity WHAT WE THOUGHT
  • 27. Continues Improvement Respect for People Waste Value Opportunity for improvement Traditional improvement Lean Thinking
  • 28. Kaizen - Reduce Waste 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 Eliminate Waste 1. Overproduction of features 2. Waiting and delay 3. Handoff 4. Extra process 5. Partially done work
  • 30. Detect and Eliminate Waste 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 Concentrating on value stream optimization, removing waste and sustainable flow increases productivity
  • 32. 06 WHAT WE KNOW It’s possible to transfer information effectively on written documents without much of human contact. WHAT WE THOUGHT
  • 33. WHAT WE THOUGHT 06 WHAT WE KNOW Essential knowledge is lost in every handover and human interaction is needed to overcome it.
  • 34. 07 WHAT WE KNOW You can save time by “good-enough” development. WHAT WE THOUGHT
  • 36. WHAT WE THOUGHT 07 WHAT WE KNOW Any technical debt will slow development down and thus we don’t allow technical debt to accumulate.
  • 37. 08 WHAT WE KNOW Product development process can be defined as a predictable and repeatable process WHAT WE THOUGHT
  • 38. WHAT WE THOUGHT 08 WHAT WE KNOW Product development is an evolving and adaptive process
  • 39. THE ORIGIN • Toyota lean concept
 • The new, new software development game [Takeuchi & Nonaka, 1986] • Iterative & incremental development
  • 41. EXERCISE Rewrite Each Agile Principle 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
  • 56. • In our industry 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? "Scrum is 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 that we cannot predict the future
 • One size does not fit all
 • Constant improvement
 • Transparency & Visibility • Team work SCRUM PRINCIPLES
  • 60. • Deliver business value fast (max. 30 days) • Prioritizing • Empirical approach • Fun !!! SCRUM PRINCIPLES
  • 61. THE HIGH MOON STUDIO
  • 62. SCRUM PROCESS OVERVIEW 3 Roles: 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 it means 
 “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 THE MANAGER 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 • Self organizing • 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 • Decides what 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 product Backlog 1. Clear 2. Ranked 3. Optimize the value 4. Visible transparent 5. Ensure understanding
  • 72. Traditionally throws content “over the fence”
  • 73. The PO takes an active role throughout the development lifespan Traditionally throws content “over the fence” NO MORE! CONCEPT CHANGE
  • 74. How? • Talk directly and 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
  • 79. What is Definition of 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 just one example Expending the Definition of Done over time Designed Coded analyzed Unit tested Perf. tested Code coverage Live Deployable Acc. tested
  • 81. This is just one 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
  • 83. 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
  • 84. “IT IS BETTER BE ROUGHLY RIGHT THAN PRECISELY WRONG” John Maynard Keynes
  • 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 reflect the “bigness” of a user story How hard it is ?
 How risky it is ?
 How much of it there is ? 5 ? 3
  • 89. 1. Each person gets 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 Following Based On Size Using Planning Poker • Spain • China • Luxembourg • Denmark • South Africa - 8 (Reference point) • Belize
  • 91. • Those who do 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 Group A 7 Pages spec Group B 173 hours 117 hours Specification Length
  • 93. Group A Customer thinks 500 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 IS QUICK! IT IS FUN!
  • 95. Spain 3 China Too big 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 priority 3 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 priority 3 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 will happen 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: Alternating team each sprint
 Alternating person each sprint
 Limiting the hours per team
 Use velocity - Ignoring it completely
  • 103. Calculating Release Time Given that: 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 We can 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
  • 106. Sprint Planning The first meeting of the sprint
 Length: 2-8 hours
 Participants: PO, Team, Scrum Master
 Preconditions: Product backlog should be in good shape
 Divided into two parts
  • 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
  • 111. The sprint Backlog Belongs to 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 In progress Done PBI # 1 PBI # 2 Task Board
  • 113. To do In progress Done PBI # 1 PBI # 2 Task Board
  • 114. To do In progress Done PBI # 1 PBI # 2 Task Board
  • 115. To do In progress Done PBI # 1 PBI # 2 Task Board
  • 116. To do In progress Done PBI # 1 PBI # 2 Task Board
  • 117. Burndown Chart A simple visual 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 3 4 5 6 7 8 Sprint Burndown Chart
  • 120. Every day, Same time, 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. What have we accomplished since the last daily 2. What will we accomplish until the next daily 3. What are my/our impediments
  • 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
  • 129. Sprint Retrospective ‘The greatest enemy of great is good enough’
  • 130. Goal: Inspect and create 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 WAY TO DO RETROSPECTIVE
  • 135. “THE VALUE OF AN IDEA LIES IN THE USING OF IT” Thomas Edison
  • 137. Reading List 1. Clean Code 2. Scrum Guide 3. Delivering happiness 4. Peopleware *RECOURSE