Integrating gsix Sigma THINKING into Scrum-Based. Darian Rashid Agile Trainer and Coach

Transcription

1 Integrating gsix Sigma THINKING into Scrum-Based Development Environments Darian Rashid Agile Trainer and Coach

2 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

3 Symptoms

4 Lean Six Sigma is a Method to Solve complex problems by: Establishing a measurable gap Digging i deep Finding root causes

5 Root Causes Hidden Usually multiple Usually interacting Find the vital few

6 Lean Six Sigma Thinking is Systems thinking

7

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 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

12 The ScrumMaster Owns the process of Scrum SM Have impediments removed Agent of change!

13 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

14 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

15 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

16 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

17 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

18 Possible Factors Causing Gaps Problem / Gap Knowledge Others Lacking the right tools Incorrect process Environment 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 Symptom Problem / Gap Symptom Symptom Root Cause Root Cause

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 ih 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 ed until 4 weeks prior Development group was blamed Working hours since

24 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

25 Establish a Gap Why is the release late? Outstanding features No time to work on features. Fixing defects during most of the iteration

26 Establish a Gap How many defects are 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!

27 Define Gaps Short term Launch date projected to be missed by 5 months Number of defects at 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 Analyze Improve Control Root cause analysis to reveal why Confirm main factors Create improvements May be phased Validate improvements Create controls against regression

29 Defects Submitted Each Day tted Each Day cts submit Defec Day Defect detection rate is stable over time

30 Defects Fixed Each Day ay efects Fixed Each Da De Day Fixing less defects everyday

31 Open Defects Per Day 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 Spent Per Defect Each Day Day ect Each D rs Per Defe Hour 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 Improve Control Create improvements May be phased Validate improvements Create controls against regression

35 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

36 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

37 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

38 Symptom 1 Gap between find and verify fix was increasing 4 Cause More defects + Less feature progress = more status meeting and written reports

39 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

40 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*

41 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

42 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*

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 ypractice 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 Analyze Improve Control Root cause analysis to reveal why Confirm main factors Create improvements May be phased Validate improvements 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 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

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 o Integration and automated tests infrastructure was built Internal Scrum team dedicated to infrastructure Took more than 1 year

50 Results Current maximum m 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 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

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