Lightweight approach to defect management using Kanban. Presentation was originally for a build team to manage build requests, please excuse any typos which still references the build process.

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