Integrating Six Sigma Thinking Into Scrum Based Development Environments
- 1. Integrating Six Sigma THINKING into Scrum-Based Development Environments Darian Rashid Agile Trainer and Coach darian@agileethos.com
- 2. 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
- 3. Symptoms
- 4. Lean Six Sigma is a Method to… Solve complex problems by: – Establishing a measurable gap – Digging deep – Finding root causes
- 5. Root Causes • Hidden • Usually multiple • Usually interacting • Find the “vital few”
- 6. Lean Six Sigma Thinking is… Systems thinking
- 8. Lean Six Sigma Thinking Requires You To… • Scale with the problem • Compare before and after
- 9. Perceptions in S/W Dev. Environment • Tool blamed for misuse • Misconceptions – Is for manufacturing – Requires a degree in Statistics • No cross-realm expertise
- 10. 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
- 11. The Foundation Walter Shewhart 1924 • Control charts • Statistical Process Control • Continuous Improvement
- 12. The ScrumMaster • Owns the process of Scrum • Have impediments SM removed • Agent of change!
- 13. Many Tools in Change Arsenal Work Design Thinking Transparency Job Modes Analysis Time Issue Structural Duration Resolution KAIZEN 5S Analysis vs Attitudinal Accountable Ergo & Hierarchies Differentiati Waste Safety on & Levels of Problem Integration & Universal Learning Solving Root Cause Process Gap Analysis Value Structure Analysis Contain, Value Waste Correct, & Prevent Stream Analysis Programmat Sources of Change ic Power Six Sigma Mapping Levels of Process Change Maps Organizational Analysis Avoidance Analysis Trends Value Add Analysis Analysis Change, Size, Balanced Awareness Bureaucracy Leadership Metrics & Fear & Life Cycles Structural Culture Data Open vs Management Attitudinal Systems Levels of Model Analysis Metrics Culture Workflow Analysis PFQT Sustain Mistake Proofing Flow & Process Spaghetti Visual Types Motion Diagrams Transparency Mgmt Cellular Structure Pull vs ABC vs RRR Push Balance & Value Add Structure Job Trend Analysis Resource Leveling Characterist Types ic Model
- 14. Revise Transformation Backlog Gap Analysis Validate Filter Gains Define Measure Analyze Improve Control Take corrective action using the right method
- 15. The Roadmap Mechanic Doctor Barrier-Buster Define Car trouble Describe illness or injury Establish a gap Create hypotheses for Diagnostics, Temperature, blood Measure memory, codes pressure, history causes, Collect data Flight test Blood test, x-ray, scan, Root cause analysis Analyze Sensor exploratory Confirm factors Stimulator Repair, tune, Surgery, medication, Improve rework, replace exercise, splint Create improvements Verify, Follow-up visit, ongoing Control maintain, and treatment, maintenance Validate improvements record drug
- 16. Identifying the Right Problems • Systemic issues • Issues that were fixed that reappeared • Issues where the root cause is unknown
- 17. Exploring Gaps in Software Environments Quality level Consistently too low miss iteration goals Miss release targets Most builds fail Builds too slow • Easy to blame people
- 18. Possible Factors Causing Gaps Problem / Gap Knowledge Others… Lacking the Environment Incorrect right tools process How can we be sure?
- 19. 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
- 20. Get to Root Causes - Ask “Why?” Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Symptom Why? Why? Problem / Symptom Why? Gap Why? Why? Why? Symptom Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Why? Root Root Cause Cause Why?
- 21. 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
- 22. 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
- 23. Case Study • Slip wasn’t realized until 4 weeks prior • Development group was blamed • Working 60-80 hours since
- 24. The Roadmap Define Establish a gap Create hypotheses for causes Measure Collect data to reveal what Root cause analysis to reveal why Analyze Confirm main factors Create improvements Improve May be phased Validate improvements Control Create controls against regression
- 25. Establish a Gap Why is the Outstanding release late? features Why? No time to work on features. Fixing defects during most of the iteration
- 26. Establish a Gap How many defects are 1200+ currently open? severity 1 & 2 Why don’t you stop and “No time for that” burn down defects? “Value is in features, not defects” Is this the first No, last 3 releases release like this? were worse!
- 27. 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
- 28. The Roadmap Define Establish a gap Measure Collect data to reveal what the factors are Root cause analysis to reveal why Analyze Confirm main factors Create improvements Improve May be phased Validate improvements Control Create controls against regression
- 29. Defects submitted Each Day Defects Submitted Each Day 3 6 9 12 15 18 21 24 27 Day Defect detection rate is stable over time
- 30. Defects Fixed Each Day Defects Fixed Each Day 3 6 9 12 15 18 21 24 Day Fixing less defects everyday
- 31. Open Defects Per Day 2 4 6 8 10 12 14 16 18 20 22 24 Number of open defects was increasing
- 32. Median of 7 weeks from ‘find’ to ‘verify fix’ …and increasing Defect Found Fix Verified Weeks
- 33. Hours Per Defect Each Day Hours Spent Per Defect Each Day 2 4 6 8 10 12 14 16 18 20 22 Day Hours per defect were going up
- 34. The Roadmap Define Establish a gap Measure Collect data to reveal what the factors are Analyze Root cause analysis to reveal why Create improvements Improve May be phased Validate improvements Control Create controls against regression
- 35. Symptom 1 Gap between ‘find’ and ‘verify fix’ was increasing • Still working on new features • Q/A’s priority was to always test new Cause 1 features • A fixed defect could wait on backlog to verify
- 36. Symptom 1 Gap between ‘find’ and ‘verify fix’ was increasing More pressure to get new features out – Sustained overtime Cause 2 – 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
- 37. Symptom 1 Gap between ‘find’ and ‘verify fix’ was increasing • Fixing less defects over time Cause 3 • Still working on new features • New features were full of defects • Defect find rate > defect fix rate increasing gap
- 38. Symptom 1 Gap between ‘find’ and ‘verify fix’ was increasing Cause 4 More defects + Less feature progress = more status meeting and written reports
- 39. Symptom 1 Gap between ‘find’ and ‘verify fix’ was increasing • Only development was ‘doing Scrum’ Cause 5 • Q/A was not considered ‘eligible’ • Product Owners valued getting the product out over quality
- 40. Symptom 2 Rate of defects corrected is decreasing The data showed the complexity of the defects were getting higher? Why? We were cherry- picking the easy ones Why? To increase velocity. Defects count toward it Why? u se Velocity is used to Ca compare teams*
- 41. Symptom 3 No visibility into release delay until too late Velocity used to compare teams – Defects, meetings and more counted toward Cause 1 velocity – Measured tasks, not forward progress or efficiency
- 42. Symptom 3 No visibility into release getting delayed until later stages Product Owners were disengaged from each iteration Why? Did not track progress toward release plan Why? Did not have a release plan e2 us ScrumMasters were not Why? Ca allowed to work with them*
- 43. 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
- 44. 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’
- 45. The Roadmap Define Establish a gap Measure Collect data to reveal what the factors are Root cause analysis to reveal why Analyze Confirm main factors Create improvements Improve May be phased Validate improvements Control Create controls against regression
- 46. First Iteration: Triage • ‘Stopped the line’! • Reprioritized defects and features together with POs • Q/A worked intimately with developers – Temporarily moved to same location
- 47. Results • 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
- 48. 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
- 49. Phase 2: Longer Term • Continuous Integration and automated tests infrastructure was built • Internal Scrum team dedicated to infrastructure • Took more than 1 year
- 50. Results Current maximum number of open defects: 125 COMBINED Down from over 1200
- 51. 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
- 52. Larger Gap: Release Dates Constantly Missed Managemen No No time Iteration t did not automated goals not want feature testing met teams Horizontal Scrum Separate teams Q/A group Not defined Understood Too many well own defects competencies Horizontal Stories No defined Worried about backlog to advancement Very late work from integration No Missed Features not completed Too many features continuous integration Deadline No infrastructure System not No formal stable release plan Not enough time Defects were Set of loose Every goals ignored feature is sufficed No budget Priority 1 Team not for servers Not involved in Not planning important to important to developers PO Patches make heros! Incentives based on new Estimates features are done for Didn’t trust team REWARDS CURRENT team’s MISALLIGNED CULTURE estimates
- 53. 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
- 54. 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
- 55. 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