integrating six sigma thinking into scrum based development environments
DESCRIPTION
One of the most important parts of a ScrumMaster’s role is to remove barriers. Lean Six Sigma’s DMAIC methodology, used to solve difficult problems with unknown root causes, should be a powerful tool in the Scrum Master’s arsenal. Unfortunately, with all the blogs, articles, books, lectures and tweets on Scrum best practices, there are very few on utilizing Lean Six Sigma methods for solving barriers within a Scrum deployment and even fewer practitioners. This may be due to several factors, including misunderstandings in both worlds, resentment from legacy “process” improvement methods, bad historical application of Six Sigma within software development, no cross-realm expertise, and more.This presentation will focus on debunking the myths and misconceptions and present intuitive ways on using Lean Six Sigma methods as a powerful barrier-busting tool in the ScrumMaster’s, management’s and the team’s arsenal. A case studies from industry will be presented as empirical evidence on the methods discussed.TRANSCRIPT
Integrating Six Sigma THINKING into Scrum-Based Development Environments
Darian RashidAgile Trainer and [email protected]
Lean Six Sigma THINKING in Software Development
• What is Six Sigma Thinking
• Six Sigma Myths and Misconceptions
• A Common Ancestry and Values
• Review role of the Scrum Master• Using Six Sigma Within a Development
Organization• Case Study
Symptoms
Lean Six Sigma is a Method to…
Solve complex problems by:– Establishing a measurable gap– Digging deep
– Finding root causes
Root Causes
• Hidden
• Usually multiple
• Usually interacting
• Find the “vital few”
Lean Six Sigma Thinking is…
Systems thinking
Lean Six Sigma Thinking Requires You To…
• Scale with the problem
• Compare before and after
Perceptions in S/W Dev. Environment
• Tool blamed for misuse
• Misconceptions– Is for manufacturing
– Requires a degree in Statistics
• No cross-realm expertise
Part of Continuous Improvement
• Lean methods have been evolving for the last several hundred years
• Lean Six Sigma is part of that evolution
• Common values – Continuous Improvement
The FoundationWalter Shewhart
1924• Control charts• Statistical Process Control• Continuous Improvement
The ScrumMaster
• Owns the process of Scrum
• Have impediments removed
• Agent of change!
SM
Waste &
ValueValue
Stream Mapping Process
Maps
5S
Time Duration Analysis
Trends Analysis
Job Characterist
icModel
Programmatic
Change Avoidance
Structural vs
Attitudinal
Levels of Analysis
Contain, Correct, &
PreventSources of
Power
Resource Types
Open Systems
Model
Balanced Metrics
PFQT
Thinking Modes
Process Types
Data Management
Structure Trend
Accountable Hierarchies Differentiati
on & Integration
Size, Bureaucracy
& Life Cycles
Six Sigma
Gap Analysis
Levels of Learning
Culture Analysis Sustain
Ergo & Safety
Mistake Proofing
VisualMgmt
Metrics
CellularStructure
Flow & Motion
Balance & Leveling
Pull vs Push
Workflow
Spaghetti Diagrams
Problem Solving Root Cause
Analysis
KAIZENIssue
Resolution
Organizational Analysis
Value Add Analysis
Transparency
ABC vs RRR
Change, Awareness
& Fear
Job Analysis
Work Design
Value Add Analysis
Transparency
UniversalProcess
Structural vs
Attitudinal
Waste Analysis
Leadership
Change
Culture
Structure
Levels of Analysis
Many Tools in Change Arsenal
ValidateGains
ReviseTransformation
Backlog
Gap Analysis
Take corrective actionusing the right method
Filter
Define Measure Analyze Improve Control
The Roadmap
Mechanic Doctor Barrier-Buster
Define Car trouble Describe illness or injury Establish a gap
Measure Diagnostics, memory, codes
Temperature, blood pressure, history
Create hypotheses for causes,
Collect data
AnalyzeFlight test
Sensor Stimulator
Blood test, x-ray, scan, exploratory
Root cause analysis
Confirm factors
Improve Repair, tune, rework, replace
Surgery, medication, exercise, splint
Create improvements
ControlVerify,
maintain, and record
Follow-up visit, ongoing treatment, maintenance
drugValidate improvements
Identifying the Right Problems
• Systemic issues
• Issues that were fixed that reappeared
• Issues where the root cause is unknown
Exploring Gaps in Software Environments
• Easy to blame people
Quality level too lowConsistently
miss iteration goals
Most builds fail
Builds too slow
Miss release targets
Possible Factors Causing Gaps
How can we be sure?
Others…
Problem / Gap
Knowledge
Lacking the right tools Incorrect
process
Environment
Use Data
• Use data as a tool to get insights
• Simple charts usually reveal a lot about what is happening
• Measure only as long as you need– Short-term for diagnostics
– Long-term for control over regression
Get to Root Causes - Ask “Why?”
SymptomProblem / Gap
Symptom
Root Cause
Symptom
Root Cause
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why? Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
Why?
The Journey
• Knowing the destination doesn’t mean the journey is mapped out
• If it were that easy, most would just do it
• Sometimes we need to prove we need to take the journey
Case Study
• Large B2B enterprise
• Methodology at best “Scrum-ish”
• Current product 2 months from launch
• Release date was going to be missed– Projected delay of 5 months
Case Study
• Slip wasn’t realized until 4 weeks prior
• Development group was blamed
• Working 60-80 hours since
The Roadmap
Define Establish a gap
MeasureCreate hypotheses for causes
Collect data to reveal what
AnalyzeRoot cause analysis to reveal why
Confirm main factors
ImproveCreate improvements
May be phased
ControlValidate improvements
Create controls against regression
Establish a Gap
Why is the release late?
Outstanding features
Why? No time to work on features. Fixing defects
during most of the iteration
Establish a Gap
Why don’t you stop and burn down defects? “No time for that”
“Value is in features, not defects”
How many defects are currently open?
1200+ severity 1 & 2
Is this the first release like this?
No, last 3 releases were worse!
Define Gaps
• Short term– Launch date projected to be missed by
5 months
– Number of defects at 1200+
• Longer term– No predictability of release
– Product integrity is below releasable standards
The Roadmap
Define Establish a gap
Measure Collect data to reveal what the factors are
AnalyzeRoot cause analysis to reveal why
Confirm main factors
ImproveCreate improvements
May be phased
ControlValidate improvements
Create controls against regression
Defect detection rate is stable over time
Day
Def
ects
sub
mit
ted
Each
Day
272421181512963
Defects Submitted Each Day
Fixing less defects everyday
Day
Def
ects
Fix
ed E
ach
Day
2421181512963
Defects Fixed Each Day
Number of open defects was increasing
24222018161412108642
Open Defects Per Day
Median of 7 weeks from ‘find’ to ‘verify fix’…and increasing
Weeks
Defect Found
Fix Verified
Hours per defect were going up
Day
Hou
rs P
er D
efec
t Ea
ch D
ay
222018161412108642
Hours Spent Per Defect Each Day
The Roadmap
Define Establish a gap
Measure Collect data to reveal what the factors are
Analyze Root cause analysis to reveal why
ImproveCreate improvements
May be phased
ControlValidate improvements
Create controls against regression
Symptom 1
• Still working on new features
• Q/A’s priority was to always test new features
• A fixed defect could wait on backlog to verify
Gap between ‘find’ and ‘verify fix’ was increasing
Cau
se 1
Symptom 1
More pressure to get new features out– Sustained overtime
– Quality of code was worse over time
– Defects that were assigned to the team were ‘bounced’ back to buy time
• Ye olde ‘can’t replicate’. Works every time
• Resulted in entire test suite being rerun
Gap between ‘find’ and ‘verify fix’ was increasing
Cau
se 2
Symptom 1
• Fixing less defects over time
• Still working on new features
• New features were full of defects
• Defect find rate > defect fix rate increasing gap
Gap between ‘find’ and ‘verify fix’ was increasing
Cau
se 3
Symptom 1
More defects + Less feature progress = more status meeting and written reports
Gap between ‘find’ and ‘verify fix’ was increasing
Cau
se 4
Symptom 1
• Only development was ‘doing Scrum’
• Q/A was not considered ‘eligible’
• Product Owners valued getting the product out over quality
Gap between ‘find’ and ‘verify fix’ was increasing
Cau
se 5
Symptom 2
Why? We were cherry-picking the easy ones
The data showed the complexity of the defects were getting higher?
Why? To increase velocity. Defects count toward it
Why? Velocity is used to compare teams*
Rate of defects corrected is decreasing
Cause
Symptom 3
Velocity used to compare teams– Defects, meetings and more counted toward
velocity
– Measured tasks, not forward progress or efficiency
No visibility into release delay until too late
Cau
se 1
Symptom 3
Why? Did not track progress toward release plan
Product Owners were disengaged from each iteration
Why? Did not have a release plan
Why?ScrumMasters were not
allowed to work with them*
No visibility into release getting delayed until later stages
Cause2
1. Development and Q/A seen as a separate function
– Even located in separate buildings
2. No universal definition of ‘Done’
3. No trust between managers and teams
Dig Deeper: Root Causes
4. Iterations were a developer-only practice
5. Product Owner incentives based solely on number of features
6. Post-release patches made ‘heros’
Root Causes
The Roadmap
Define Establish a gap
Measure Collect data to reveal what the factors are
AnalyzeRoot cause analysis to reveal why
Confirm main factors
ImproveCreate improvements
May be phased
ControlValidate improvements
Create controls against regression
• ‘Stopped the line’!
• Reprioritized defects and features together with POs
• Q/A worked intimately with developers– Temporarily moved to same location
First Iteration: Triage
• Reprioritized defects burned down in 4 weeks
• Productivity was higher on stable release
• Q/A continued to work along side dev.
• Release was only 1 month late
Results
• Started “10 then 10” initiative– Lower maximum outstanding defects
by a factor of ‘10’
• WIP-cap was put into place– ScrumMaster and team alerted PO if
WIP-cap was reached
– Stories were suspended
– Root-cause analyses were performed
Second Iteration: Longer Term
• Continuous Integration and automated tests infrastructure was built
• Internal Scrum team dedicated to infrastructure
• Took more than 1 year
Phase 2: Longer Term
Current maximum number of open defects: 125 COMBINED
Down from over 1200
Results
• Second 10x reduction
• Goal: no more than 15 open defects COMBINED
• Q/A mostly disbanded– Most working as part of team
– System strike force remains
Third Iteration: Currently In the Journey
Larger Gap: Release Dates Constantly Missed
Features not completedMissed
Deadline
Defects were
ignored
Very late integration
Horizontal Stories
Horizontal Scrum teams
Management did not
want feature teams
Understood own
competencies
Separate Q/A group
No budget for servers
No infrastructure
No continuous integration
Not enough time
Estimates are done for
team
Team not involved in planning
No formal release plan
Set of loose goals
sufficedEvery
feature is Priority 1
Too many features
Too many defects
No timeNo automated
testing
Incentives based on
new features
Worried about advancement
REWARDS MISALLIGNED
Patches make heros!
Not important to
PO
Not important to developers
System not stable
No defined backlog to work from
Not defined well
Iteration goals not
met
CURRENT CULTURE
Didn’t trust team’s
estimates
• Lean Six Sigma thinking means– Identify gaps
– Look past symptoms
– Use data to find causes
– Dig deeper to find root causes (and interactions)
• Agile and Lean Six Sigma have common ancestry and values
Key Points
• Don’t let misconceptions keep you from a powerful tool
• ScrumMasters and change agents need good tools in their arsenal– The thinking can always be used
– Can scale with the problem
Key Points
• Even if you know the final destination, using data-based decision-making and root cause analysis can help you find the best path
Key Points