kanban kanban
play

Kanban Kanban Creating a Kaizen Culture and evolving Creating a - PowerPoint PPT Presentation

Kanban Kanban Creating a Kaizen Culture and evolving Creating a Kaizen Culture and evolving Lean Software Engineering Solutions Lean Software Engineering Solutions David J. Anderson President, Modus Cooperandi, Performance Through


  1. Kanban Kanban Creating a Kaizen Culture and evolving Creating a Kaizen Culture and evolving Lean Software Engineering Solutions Lean Software Engineering Solutions David J. Anderson President, Modus Cooperandi, Performance Through Collaboration

  2. What is a kanban system?

  3. Kanban allows us to implement my recipe for success � Focus on Quality � Reduce (or limit) Work-in-Progress � Balance Demand against Throughput � Prioritize � Prioritize

  4. Case Study Microsoft 2004/2005 � XIT one of Microsoft’s 8 IT departments � XIT Sustained Engineering � Small team � Change requests � Supports over 80 applications (and growing) � Supports over 80 applications (and growing) � Engineering responsibilities moved from Redmond (Washington, USA) to Hyderabad (India) in 2004 � Hyderabad vendor is CMMI Level 5 and uses TSP/PSP � Initial quality is very high

  5. Dark Days in July 2004 Sustained Engineering Supply v Demand 90 PM PM Dev Mgr Dev Mgr Test Mgr Test Mgr 80 Change Change 70 Requests Requests 60 50 Change Requests 40 30 20 10 Manager resigns end June � 0 Jan-04 2004 – open position Q3 2004 – open position Q3 Apr-04 Supply Supply Jul-04 Jul-04 2004 Quarters Backlog is 80+ and � User Acceptance Test User Acceptance Test Supply Demand growing about 20 per quarter �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� �������������������������������������� Lead time is 155 days ���������������� ���������������� ���������������� ���������������� ���������������� ���������������� ���������������� ���������������� � ���������������� ���������������� ���������������� ���������������� ���������������� ���������������� ���������������� ���������������� Product Product Backlog Backlog 155 Days 155 Days Managers Managers Customer satisfaction – � lowest in IT department

  6. Estimation (ROM) was Top Priority Open and Read � Source Code PM PM Dev Mgr Dev Mgr Test Mgr Test Mgr 3 Developers, 3 Developers, Change Change Read Application � Requests Requests Guide 3 Testers 3 Testers Whole process about � But… But… ROM ROM 1 day per developer ROM ROM and tester 80 Applications 80 Applications Estimation was using Estimation was using 33%-40% 33%-40% 33% 33% 40% 40% SLA – 48 hours to of available capacity!!! of available capacity!!! � return a rough order What What User Acceptance Test User Acceptance Test of magnitude happens?... happens?... estimate (ROM) All change requests � Product Product Backlog Backlog 155 Days 155 Days are ROM estimated Managers Managers ROMs are expedited � as top priority due to SLA

  7. Actual effort was miniscule compared to lead time of 155 days PM PM Dev Mgr Dev Mgr Test Mgr Test Mgr Change Change Requests Requests 25 ROM ROM 20 ROM ROM e q u e s ts 15 Historical data gathered over Historical data gathered over C h a n g e R e q � 9 months showed that a 10 typical change request took User Acceptance Test User Acceptance Test 5 approx 5 business days to process through 0 development 1 to 2 3 to 5 6 to 10 Dev Test Product Product 11 to Backlog Backlog 155 Days 155 Days > 15 Low end was 1 day Managers Managers � 15 Effort in Days High end 15 days �

  8. Are Estimates muda? Only 52% of requests � were actually ever completed Other 48% PM PM Dev Mgr Dev Mgr Test Mgr Test Mgr � Change Change Too big � Requests Requests (bigger than 15 days) Too expensive (low � value versus cost) ROM ROM ROM ROM Overtaken by events, � application decommissioned decommissioned before request is processed User Acceptance Test User Acceptance Test ROMs are taking 40% of capacity but 48% of ROMs represent analysis � that is never used beyond estimate, schedule and go/no go decision! Knowledge work is perishable. ROM analysis is done months before work � Product Product Backlog Backlog 155 Days 155 Days Managers Managers is conducted and there is no guarantee that ROM is conducted by same engineer who will code or test. Conclusion – all ROMs are muda �

  9. Could it get worse? Expediting PTC PTC Non-code Fix Non code Fix PM PM Dev Mgr Dev Mgr Test Mgr Test Mgr Change Change Requests Requests ROM ROM ROM ROM User Acceptance Test User Acceptance Test Production Text Change � E.g. graphical changes, data changes, Product Product � Backlog Backlog 155 Days 155 Days Managers Managers anything that didn’t require a developer Must be expedited � Need to make formal QA pass �

  10. State Model ������������������ ��� ��� ��������� �������� �������� ������� ��������� ���������� ��� ��� ����� ������� ������� ���� ���� �������� �������� ��� ���� ������ ��������� ������ ������������������������ �������� Virtual Kanban Virtual Kanban ��������� ��������� ������"��#�#���������� +������ limit initially $%�&���"� �)�������, 8 = WIP + 7 days &#������� ������� buffer '��(����) �������� ��� ������� ������ !��"�� ������ Virtual Kanban limit initially �*������� ��� 8 = WIP + 7 days buffer ������� �������� ����� ��� ������������

  11. Intervention 1 Pace the Line from Development PTC PTC Expedite Expedite Local Mgr Local Mgr PM PM Change Change Requests Requests Kanban Kanban Kanban Kanban 8 cards 8 cards 8 cards 8 cards (3 WIP (3 WIP 5 Buffer) 5 Buffer) Development Kanban � � Typically enough for WIP + 7 days Test Kanban � User Acceptance Test User Acceptance Test � Typically enough for WIP + 7 days Pace line at rate of consumption � At times of high expediting levels, kanban insures that line is paced � Product Product from Test not Dev Backlog Backlog 25 Days 25 Days Managers Managers Reduces lead time by insuring single-tasking � Focuses customer acutely on selection of highest priority (urgency) � requests for insertion into empty buffer slots

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend