David J Anderson’s book on Kanban shows us that a way to handle ticket issues is by attaching a color tag to a ticket to make it visible. An issue is a ticket-related event that becomes an impediment to its value flow, such as a defect, insufficient definition, unresolved dependency, etc. What I encounter often is, people have a natural tendency to move the ticket to where the dependency lies.
Although Kanban does not stop us from doing so, this might not be the best of actions. If, for example, in the images here the dependency is on Patient Checking it might be tempting to move the ticket to the Checkin column.
Doing this brings some difficulties.
- We lose track of where the issue occurred (Treatment)
- Quantification becomes tricky. Cycle time measurement for the ticket becomes unreliable. It is better to leave the ticket under Treatment so that we know the issue occurred during Treatment and the red ticked affixed to the yellow ticked
indicate the dependency with Check-in. This is better because we don’t lose track of where things are at and quantification remains unaffected.
- WIP handling becomes very tricky. What would happen if Checkin is at maximum capacity and we tried to move the ticket from Treatment to Check-In? We either violate WIP or keep the ticked under Treatment on some sort of stale state until Check-In has capacity (ugly).
- Root cause analysis becomes harder also. It is better to keep log of the activities under Treatment, where the issue actually occurred to make root cause analysis easier, otherwise it becomes a bit harder to understand the space-time-event relationship
There is another solution by Duane Bradbury, Alex Hui and Taimur Mohammad, which I like. I’m posting this with permission (thanks Duane!).
This is how we treat defects and the parent standard card.
Step 1: Card is in progress in QA.
Step 2: When a defect is discovered it is created in the Fix QA cell.
Step 3: If QA is unable to continue the Card is moved down to Fix QA as well. (if not the card remains in progress until they are unable to continue, maybe the defect will be fixed before they are stuck)
Step 4: The defect lives in this location until it is addressed/assigned, basically if someone is working on it, then it goes to where that is. For this example it is the developer looking into it. So the defect moves to the Build in progress…at this stage it is known that these cards are related (due to naming conventions) and it also shows the status.
Step 5: Once the defect is addressed and resolved it is moved into completed, flagging the QA to pick up the defect and see if it resolved, retesting, once the QA is able to pick it up both cards move into in progress QA, showing retest is happening.
Although this solution requires extra real state for the Fix swim lane it makes visibility and tracking much easier.
