Defect management using kanban
Download as PPTX, PDF3 likes4,568 views
The document outlines a defect management process using Kanban, emphasizing its scheduling system and how it contrasts with Scrum by not being time-boxed. It introduces concepts such as work-in-progress (WIP) limits and service classes to prioritize defect handling based on business value. Metrics for measuring team velocity are also discussed, along with the idea of continuous improvement through Kaizen.
Defect management using kanban
- 1. Defect Management using Kanban Presented by Carl Bruiners
- 2. What is Kanban? • Created by Taiichi Ohno of Toyota • Japanese for signboard or billboard • A scheduling system that helps determine what to produce, when to produce it, and how much to produce • Pull instead of push system Spare Parts Supply Demand Point Supplier Pull • Backlog can take on any shape or form • Unlike Scrum Kanban is not a time-boxed Agile methodology • Kanban reveals bottlenecks dynamically (TOC) 2
- 3. Kanban Task Wall 4
- 4. W.I.P (Work-In-Progress) limits • The purpose of W.I.P limits is to ensure that no swim lane is a bottle-neck • W.I.P limits are set against each lane on the Task Wall • W.I.P limits are used to ensure that the team is not attempting to work on too many Stories at any given time and that each Story is completed before a new one is worked on. • W.I.P limits should be reviewed regularly and changed accordingly to avoid bottlenecks – This cannot be done my any individual, this must be a team exercise and agreement. 5
- 5. Service Class model „Each Class of Service will have its own policy to reflect prioritisation based on the different risks and business value. Classes of service and knowledge of the policies associated with them empower the team to self-organize the flow of work to optimize business value. Used effectively this will result in improved customer satisfaction, elevated employee engagement, and increased trust.‟ David Anderson • There will be two Service Classes; Standard and Expedited. • A set of Service types (between 3-6) needs to be generated for the Standard class (this needs to be determined by the team; i.e. letters or numeric). Each Type needs to be inline with Defect Teams SLA‟s and should be based on business impact. • Story requests in the Standard class are assigned one of the Standard Service type‟s. • The prioritisation of the Stories is driven by the Service Class model 6
- 6. Standard Service Class • Various class types should be created under the standard service class. For example; • A – Under £100000 impact if delayed • B – Under £50000 impact if delayed • C – Under £10000 impact if delayed • D – Under £1000 impact if delayed • E – BAU • The prioritisation of the Stories is driven by the Standard Service Class Types • A Story will change service types as it gets closer to its delivery date; i.e. a C type after 5 days would be escalated to a B type and therefore more further up the priority stack. Impact delay would be determined at the point of a story being added to the Task Wall, this will help Stories move up the priority stack as it gets closer to its delivery date. 7
- 7. Expedited Service Class Handling the JDI / 11th hour requests • A Story flagged as expedited must be reviewed by the Defect Manager before it can be added to the task wall. • All other items in the W.I.P lanes is paused and full attention is given to the expedited Story. • There can only be 1 expedited item on the task wall at any given time. • Each Manager is limited to the amount of expedited items they can raise within a calendar year. The amount needs to be negotiated between the Defect Manager and the Managers. 8
- 8. Example Defect request workflow Defect gets raised Team receives Team reviews Team adds defect to creates a defect email notification defect and assigns the Task Wall. review request that a new defect an Service Class Prioritisation of needs to be Stories in backlog is reviewed amended if needed Expedited defect? Defect manager reviews defect and determines if it should be expedited 9
- 9. Measuring team velocity Unlike Scrum we will not be assigning a estimated measurement against each defect. • The team will track two metrics; • Cycle time of each Story – Whilst in the W.I.P zone and between Taskboard states • Amount of Stories completed over a time period of x • A team retrospective should occur each month and part of the discussion should focus on how long each type of defect took to complete. • At the monthly retrospective the team should assign a ideal lead time figure to each Service class, which can be tracked and reviewed. This will be determined by the cycle time metric from the previous month. • A chart should be put onto the Task Wall and in a shared location (information radiators) with the delivery teams with a number of hours / days each defect is taking them to complete. This will help manage the expectation of how long it takes to resolve a defect. 10
- 10. Improving your model - Kaizens • Japanese for "improvement” or “change for the better” • Used to improve standardised activities and processes, kaizen aims to eliminate waste Using 5 Whys • The vehicle will not start. (the problem). • Why? - The battery is dead. (first why) • Why? - The alternator is not functioning. (second why) • Why? - The alternator belt has broken. (third why) • Why? - The alternator belt was well beyond its useful service life and not replaced. (fourth why) • Why? - The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause) • Why? - Replacement parts are not available because of the extreme age of the vehicle. (sixth why, optional footnote) • Reviewed by the team and determine which Kaizens should be played when there is either a free space of and prioritised by the Product Owner / team 11
- 11. Further reading… http://www.agilemanagement.net - David Anderson (Kanban) http://www.clarkeching.com - Clarke Ching (Agile, TOC, Scrum) http://www.carlbruiners.com - Carl Bruiners (Agile, Scrum, Kanban, BDD) http://theagilepirate.net - Simon Cromarty (Agile, Scrum, Kanban, BDD) http://blogs.ripple-rock.com/danbrown/default.aspx - Dan Brown (Agile, Scrum, Kanban) 12
Editor's Notes
- #10: One major change is that the requestor schedules the request, NOT the defect team. The class of service rules apply which stops the requestor from abusing the process by creating 11th hour requests.