Driving a Kaizen Culture

Size: px

Start display at page:

Download "Driving a Kaizen Culture"

Lorraine Norris
5 years ago
Views:

1 David J. Anderson GOTO Copenhagen May 2011 Driving a Kaizen Culture using regular Operations Reviews

2 Agile Management Book What brought us to Kanban is described in this first book

3 And New Kanban Book Detail information about Kanban can be found in this new book

http://leankanbanuniversity.com http://www.

4 Yahoo! Groups: kanbandev Yahoo! Groups: kanbanops

5 Like this Want to see more? European Lean & Kanban Events October 2011

6 Kanban Training With David J. Anderson May, 2011

7 Product Strategy Simplified enterprise org structure for a telecom-like technology business Customers Shared Services Support Demand App Dev 1 App Dev 2 UI Design DBA Demand Demand Service Platform Development Infrastructure Architecture

8 Feedback Loops

10 Daily standup meeting becomes a central enabler of a Kaizen culture In this example more than 40 people attend a standup for a large project with 6 concurrent development teams. The meeting is usually completed in approximately 10 minutes. Never more than 15.

Spontaneous Quality Circles form after the standup to focus on immediate process issues Kanban board gives visibility into process issues ragged flow, transaction costs of releases or transfers

11 Spontaneous Quality Circles form after the standup to focus on immediate process issues Kanban board gives visibility into process issues ragged flow, transaction costs of releases or transfers through stages in process, bottlenecks Daily standup provides forum for spontaneous association to attack process issues affecting productivity and lead time For example, 3 day freeze on test environment was a transaction cost on release that caused a bottleneck at build state. This was reduced to 24 hours after a 3 person quality circle formed to investigate the policies behind the freeze. Result was improved smoother flow resulting in higher throughput and shorter lead time

12 Monthly Operations Review is used to reflect on quantitative objective performance measures

13 Why monthly? More often is too much overhead Preparing data Expensive meeting (lots of people) 2.5 hours is a lot of time Need enough time & data to show trends Quarterly is not frequent enough No one can remember events from 3 months ago Learning value is undermined Too much data

14 Lead off with finances you are running a business

15 Guest speaker from another business unit worked well

16 Managers & team leads present department demand & capability

17 Discussion items scribed on a flip chart

18 Improvement opportunities assigned to managers as last agenda item

19 Managers are held accountable for kaizen opportunities. Team learns how managers can add value for them

20 Ops Review & Metrics

21 Metrics to start off with Report Capability Quality (defect/rate) WIP (work-in-progress) Cycle Time (day deployed day ready = cycle time) Throughput (velocity) Issues & Blocked Work Across these: Trend Variation

22 Issue Management Cumulative Flow

23 Executive Dashboard

24 Days Mean Lead Time Trend SLA 30.0 CRs Bugs Combo Dec Jan Feb Mar Apr May

25 CRs & Bugs # CRs Due Date Performance Detail Lead Time Distribution MARCH Days Lead Time Distribution Majority of CRs range 30 -> 55 Outliers Days APRIL

26 Control Charts supported natively in Silver Catalyst

27 And also in LeanKit Kanban

28 BBC Worldwide Bug Rates

29 BBC Worldwide Days Blocked

30 90 DBA Team Velocity Total Velocity Small support tasks (not included in total velocity) 10 0 Mattias Skarin

31 Completion Velocity Velocity Control Charts 40 Completion Velocity Chart 30 UCL CL Completion Velocity UCL +2 Sigma +1 Sigma LCL Date

32 Completion Velocity Range Velocity Range Chart Completion Velocity Range 30 RUCL CL 8.3 Range UCL +2 Sigma +1 Sigma #DIV/0! -1 Sigma -2 Sigma LCL Date

33 Iteration 1 Cumulative Flow

34 Automated reporting out of TFS

35 Builds don t take that long Outliers caused by design and code errors

36 Data center outage SQLServer services errors SAN disk failures

39 Configuration issue in web.config

40 Throughput example showing trend of releases Delivered monthly. Sept sustainment release stuck waiting on major release. Code branching strategy prevented check-ins.

41 Automated testing was seen as too expensive Demonstrate vs. rant

42 Continuous Integration reporting

45 So why is hardly anyone doing Operations Reviews?

46 Let s make a list

47 Here is one I prepared earlier Requires management support Spans across teams and requires middlemanagement participation Some middle-managers fear transparency Fear of showing bad results / lack of capability Requires management discipline to collect data Expensive meeting

48 Thank you!

49 About David Anderson is a thought leader in managing effective software teams. He leads a consulting firm dedicated to improving economic performance of knowledge worker businesses improving agility, reducing cycle times, improving productivity and efficiency in technology development. He has 25+ years experience in the software industry starting with computer games in the early 1980 s. He has led software teams delivering superior productivity and quality using innovative agile methods. He developed MSF for CMMI Process Improvement for Microsoft. He is a co-author of the SEI Technical Note, CMMI and Agile: Why not embrace both! David is the author of 2 books, Agile Management for Software Engineering Applying the Theory of Constraints for Business Results, and Kanban Successful Evolutionary Change for your Technology Business. David is Vice President of the Lean Software & Systems Consortium, a not for profit dedicated to promoting greater professionalism and better economic outcomes in our industry. dja@djandersonassociates.com

MTAT Software Engineering Management

MTAT Software Engineering Management MTAT.03.243 Software Engineering Management Lecture 11: Flow-based (KANBAN) Principles and Processes Dietmar Pfahl Spring 2014 email: dietmar.pfahl@ut.ee Structure of Lecture 11 Flow-based agile development