Integrating gsix Sigma THINKING into Scrum-Based Development Environments Darian Rashid Agile Trainer and Coach darian@agileethos.com
Lean Six Sigma THINKING in Software Development What is Six Sigma Thinking Six Sigma Myths and Misconceptions A Common Ancestry and Values Review e 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 i 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 Foundation Objectives Make a change Walter Shewhart h Plan Do Analyze root causes for difference Act Check For a measurable gap 1924 Control charts Statistical Process Control Continuous Improvement
The ScrumMaster Owns the process of Scrum SM Have impediments removed Agent of change!
Many Tools in Change Arsenal Transparency Structural vs Attitudinal Process Types Value Stream Mapping Work Design 5S Value Add Analysis Workflow Pull vs Push Waste & Value Process Maps Change, Awareness & Fear Flow & Motion Resource Types Job Analysis Ergo & Safety Waste Analysis Balance & Leveling Size, Bureaucracy & Life Cycles Spaghetti Diagrams Open Systems Model Accountable Hierarchies Leadership Structure Time Duration Analysis Differentiatio n & Integration Levels of Analysis Organizational Analysis Levels of Analysis Culture Culture Analysis Universal Process Change Gap Analysis Trends Analysis Programmat ic Change Avoidance Data Management PFQT Levels of Learning Balanced Metrics Transparency Issue Resolution Contain, Correct, & Prevent Metrics Visual Mgmt Value Add Analysis Thinking Modes Problem Solving Sources of Power ABC vs RRR Sustain KAIZEN Root Cause Analysis Six Sigma Cellular Structure Job Characteristi c Model Structural vs Attitudinal Mistake Proofing Structure Trend
Revise Transformation Backlog Gap Analysis Barrier Barrier Validate Gains Define Measure Analyze Improve Control Take corrective action using the right method Just Do It Filter Need stronger tools/concepts Need Root Cause Analysis Barrier
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 Analyze Flight 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 Control Verify, maintain, and record Follow-up visit, ongoing treatment, maintenance drug Validate improvements
Identifying the Right Problems Systemic issues Issues that were fixed that reappeared Issues where the root cause is Issues where the root cause is unknown
Exploring Gaps in Software Environments Consistently miss iteration goals Quality level too low Most builds fail Builds too slow Miss release targetst Easy to blame people
Possible Factors Causing Gaps Problem / Gap Knowledge Others Lacking the right tools Incorrect process Environment How can we be sure?
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 Symptom Problem / Gap Symptom Symptom Root Cause Root Cause
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 ih Current product 2 months from launch Release date was going to be missed Projected delay of 5 months
Case Study Slip wasn t realized ed until 4 weeks prior Development group was blamed Working 60-80 hours since
The Roadmap Define Establish a gap Measure Create hypotheses for causes Collect data to reveal what Analyze Improve Control Root cause analysis to reveal why Confirm main factors Create improvements May be phased Validate improvements Create controls against regression
Establish a Gap Why is the release late? Outstanding features No time to work on features. Fixing defects during most of the iteration
Establish a Gap How many defects are 1200+ currently open? severity 1 & 2 Why don t you stop and burn down defects? No time for that Value is in features, not defects 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 Analyze Improve Control Root cause analysis to reveal why Confirm main factors Create improvements May be phased Validate improvements Create controls against regression
Defects Submitted Each Day tted Each Day cts submit Defec 3 6 9 12 15 Day 18 21 24 27 Defect detection rate is stable over time
Defects Fixed Each Day ay efects Fixed Each Da De 3 6 9 12 Day 15 18 21 24 Fixing less defects everyday
Open Defects Per Day 2 4 6 8 10 12 14 16 18 20 22 24 Number of open defects was increasing
Median of 7 weeks from find to verify fix and increasing Defect Found Fix Verified Weeks
Hours Spent Per Defect Each Day Day ect Each D rs Per Defe Hour 2 4 6 8 10 12 Day 14 16 18 20 22 Hours per defect were going up
The Roadmap Define Establish a gap Measure Collect data to reveal what the factors are Analyze Root cause analysis to reveal why Improve Control Create improvements May be phased Validate improvements Create controls against regression
Symptom 1 Gap between find and verify fix was increasing 1 Cause Still working on new features Q/A s priority was to always test new features A fixed defect could wait on backlog to verify
Symptom 1 Gap between find and verify fix was increasing 2 Cause 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
Symptom 1 Gap between find and verify fix was increasing 3 Cause Fixing less defects over time Still working on new features New features were full of defects Defect find rate > defect fix rate increasing gap
Symptom 1 Gap between find and verify fix was increasing 4 Cause More defects + Less feature progress = more status meeting and written reports
Symptom 1 Gap between find and verify fix was increasing 5 Cause Only development was doing Scrum Q/A was not considered eligible Product Owners valued getting the product out over quality
Symptom 2 Rate of defects corrected is decreasing The data showed the complexity of the defects were getting higher? We were cherry-picking the easy ones To increase velocity. Defects count toward it Velocity is used to compare teams*
Symptom 3 No visibility into release delay until too late 1 Cause Velocity used to compare teams Defects, meetings and more counted toward velocity Measured tasks, not forward progress or efficiency i
Symptom 3 No visibility into release getting delayed until later stages Product Owners were disengaged from each iteration Did not track progress toward release plan Did not have a release plan ScrumMasters were not allowed to work with them*
Dig Deeper: Root Causes 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
Root Causes 4. Iterations were a developer-only ypractice 5. Product Owner incentives based solely on number of features 6. Post-release patches made heros
The Roadmap Define Establish a gap Measure Collect data to reveal what the factors are Analyze Improve Control Root cause analysis to reveal why Confirm main factors Create improvements May be phased Validate improvements Create controls against regression
First Iteration: Triage Stopped the line! Reprioritized defects and features together with POs Q/A worked intimately with developers Temporarily moved to same location
Results Reprioritized ed 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
Second Iteration: Longer Term 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
Phase 2: Longer Term Continuous o Integration and automated tests infrastructure was built Internal Scrum team dedicated to infrastructure Took more than 1 year
Results Current maximum m number of open defects: 125 COMBINED Down from over 1200
Third Iteration: Currently In the Journey 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
Larger Gap: Release Dates Constantly Missed Management did not want feature teams Understood own competencies Horizontal Scrum teams Horizontal Stories Separate Q/A group No automated testing Too many defects No time Iteration goals not met Not defined well Worried about advancement No infrastructure No continuous integration Very late integration System not stable Missed Deadline Features not completed Too many features No defined backlog to work from No formal release plan No budget for servers Not enough time Patches make heros! REWARDS MISALLIGNED Not important to developers Defects were ignored Incentives based on new features Not important to PO CURRENT CULTURE Every feature is Priority 1 Didn t trust team s estimates Set of loose goals sufficed Estimates t are done for team Team not involved in planning
Key Points 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