practical scrum - day 1
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
What are we going to cover today?
TABLE OF CONTENTS10
31
46
60
83
90
What we thought vs. What we know
What is Agile?
What is scrum?
What is the manager role within agile environment?
What is Lean Thinking?
How does scrum eliminate waste?
“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
WINSTON W. ROYCE 1970
"I believe in this concept, but the implementation described above is risky and invites failure"
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
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
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.
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
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
• 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
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
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
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
Ofer wants to know: Can your team build this skeletal system for him? The unions marketing division wants to set the press conference to one month, do you agree? What should he announce in this conference ?
Transparency Stop taking risks for our customers (without even letting them know)
Share the risk
Maximize the chances of success
Create a common interest
Know (not assume) the status of our projects - share it with the customer
How encourage transparency? Avoid the 90% done syndrome
Face hard facts - Early
Working Software - unfinished work is waste
Track progress with burn down charts
Core Code AKA infrastructure or legacy code
Most functionality depends on it
Usually fragile, does not have a test harness
only a few people really know it
Changes are time consuming
Becomes a bottleneck
“Once you put on a suit, no one tells you the truth anymore”
[Philip Crosby – 1995 – Reflections on quality]
Hierarchy
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
“THE TOYOTA STYLE IS NOT TO CREATE RESULTS BY WORKING HARD. IT IS A SYSTEM THAT SAYS THERE IS NO LIMIT TO PEOPLE’S CREATIVITY. PEOPLE DON'T GO TO TOYOTA TO 'WORK' THEY GO THERE TO ‘THINK'." Taiichi Ohno
Lean Thinking Continues Improvement Respect for People
[Mindset]My work is to do my work and to improve my work
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
Over Production of Features1. Features or services the
customer doesn’t want
2. Large engineering documents, more detailed designs than can be quickly implemented
3. Duplication of data
* THIS IS ONLY EXAMPLE
Wave
Waiting and Delay 1. For clarification
2. Documents
3. Approval
4. Components
5. Other groups to finish something
* THIS IS ONLY EXAMPLE
Handoff1. Giving a specification from an analyst to an engineer
2. Giving a component to another group for testing
* THIS IS ONLY EXAMPLE
Over Processing 1. Relearning, lose of information
2. Forced conformance to centralized process checklists
3. Recreating something made
* THIS IS ONLY EXAMPLE
Partially Done Work – WIP \ DIP 1. Designs documented but not built
2. Things built but not integrated or tested
3. Things tested but not delivered
* THIS IS ONLY EXAMPLE
Task Switching1. Interruption
2. Multitasking on 3 projects
3. Partial allocation of a person to many projects
* THIS IS ONLY EXAMPLE
Under-realizing People1. People only working to single speciality job
2. Do people have the chance to change what they see is waste
* THIS IS ONLY EXAMPLE
Information Scatter or Loss
1. Information spread across many separate documents
2. Communication barriers such as walls between people, or people in multiple locations
Wishful thinking 1. “We MUST follow the plan”
2. “The estimate cannot increase; The effort estimate is what we want it to be, not what it is now proposed”
3. “We’re behind schedule, but we’ll make it up later”
* THIS IS ONLY EXAMPLE