On my first Agile project we have an hybrid model of Agile methodologies. We are part SCRUMish and part Kanbanish if I could say.Its very clear that the methodologies dont matter as long as you focus on these two aspects:
- How much of value is being added to the customer every iteration.
- Is the team focussing on improving itself.
The focus of this post is to highlight on the second point – “Is the team focussing on improving itself?”
With so much happening on the Kanban front, I wasn’t particularly convinced on the WIP limit on the development front. Partly because we handle the one piece flow and ensure that there aren’t any cards on the wall for long. I would like to dedicate a separate post on this aspect, and focus on how we applied Kanban to our project.
Faced with recurring regression defects, we found out a very different approach to applying the WIP limit to our project.
There was a time in our project where the team was struggling to fix defects that were coming in their later phase of development. We tried to address them by first providing visual cues on the defects that are being opened. When this didn’t work, it was quite clear that the team wasn’t learning from its mistakes.
The team was handling defects like how traditional teams do – add the bugs to the backlog and address them based on their priority. Sometimes this could be a day or a full iteration. This lead to the defect lead getting cold and there wasn’t an opportunity for the team to learn and identify the pattern of these regression defects.
Enter Kanban & WIP. We agreed that we will stop work whenever the Bug count reaches 2 for critical or High defects on our story wall. The moment the bug count for Critical or High defects touches 2, we stop work understand the root cause, fix the issue before proceeding on the stories for that sprint. We also added sound alarms to indicate such an event.
Today we see a more stable code that is getting written and our bugs have stabilized to a larger extent.
My 2 key takeaways from this experiment;
- Jump in to address key critical issues so that the feedback is rapid. You dont have to wait till the Retrospective to arrive at an action item.
- Look for ways to continuously bubble up critical risks & priority items and fix them to learn and adapt.
Today Kanban philosophies helped me achieved this, tomorrow it could be something else.
Chronicles from the Agile World 