practical scrum - one day training
TRANSCRIPT
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
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 noteOne 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
01WHAT 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
01WHAT WE KNOW
There is change always and responding to it is vital. Uncertainty is best reduced by learning from actual implementation
02WHAT WE KNOW
It is possible to “collect” or even “know” all the requirements up-front
WHAT WE THOUGHT
02WHAT WE KNOW
Requirements evolve as customers and our knowledge increases – based on experience
WHAT WE THOUGHT
03WHAT WE KNOW
Division of work to specialized teams (specification, design and testing) is efficient
WHAT WE THOUGHT
WHAT WE THOUGHT
03WHAT WE KNOW
Cross-functional teams reduce the amount of handovers and are more productive
04WHAT 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
04WHAT WE KNOW
Multiple programs create big management overhead and risk of overloading the pipeline, R&D works most efficiently in continuous mode
05WHAT 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 Waste1. Overproduction of features
2. Waiting and delay
3. Handoff
4. Extra process
5. Partially done work
Detect and Eliminate Waste6. Task Switching
7. Defects
8. Under-realizing people’s potential
9. Knowledge scatter
10. Wishful thinking
WHAT WE THOUGHT
05WHAT WE KNOW
Concentrating on value stream optimization, removing waste and sustainable flow increases productivity
06WHAT WE KNOW
It’s possible to transfer information effectively on written documents without much of human contact.
WHAT WE THOUGHT
WHAT WE THOUGHT
06WHAT WE KNOW
Essential knowledge is lost in every handover and human interaction is needed to overcome it.
07WHAT 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
07WHAT WE KNOW
Any technical debt will slow development down and thus we don’t allow technical debt to accumulate.
08WHAT WE KNOW
Product development process can be defined as a predictable and repeatable process
WHAT WE THOUGHT
WHAT WE THOUGHT
08WHAT 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-41. 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-41. 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-41. 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-85. Build project around motivated individuals. Give them the
environment and support they need, and trust them to get the job done
Agile Principle 5-85. 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-85. 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-85. 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-129. 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-129. 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-129. 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 roleStop:
• 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. Clear2. 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 = GroomingThe 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
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 UndoneUndone
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 storyHow 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 specGroup A
7 Pages specGroup B
173 hours
117 hours
Specification Length
Group A
Customer thinks 500 customer has no technical knowledgeDon’t let the customer influence you
Group B555 hours
456 hours
Same as B customer thinks 50
Group C99 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
3Planning
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
2Planning
SP 2Iteration 1:
SP Done = 5+8+2 = 15
velocity = 15
SP 8
priority
5
priority
4
SP 8
priority
3Planning
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
2Planning
SP 2Iteration 1:
SP Done = 5+8+2 = 15
velocity = 15
priority
7
SP 5
priority
6Planning
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
5Planning
SP 2Iteration 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 PlanningThe 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 IDecide 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 IIGenerate the sprint backlog & commit on the sprint’s content
How?Splitting each of the stories into smaller tasksEstimating each task (maximum length 8 hours)Design decisions Verify that the goal is achievableCommit
Sprint Backlog
The sprint Backlog Belongs to the teamAssists the team in tracking the sprint’s progressMaximum task length should not exceed 16h (2 days) for a 2 week sprintUpdated 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:SprintReleaseProduct
Shows the amount of work left to reach target
Effo
rt re
mai
ning
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
‣‣‣‣
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 planningLength: 1-2 hoursParticipates: 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
“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