Sunday, August 22, 2010
Supporting Delivery with a three tier Kanban
After a full day session creating a Kanban with my client we ended up with not one, not two, but a 3 tier Kanban. (I warned my clients this was a really complex option, but they are willing to give it a go and throw out a tier if it warranted)
The three tiers consisted of:
1 - MMFs, a release with a common theme, with business value, or some measure of delivery progress
2 - Testing Packages - a cohesive collection of delivery stories that are teased as a unit as part of package testing
3 - Delivery Stories - classic agile units of work that go through analysis, development and developer testing
As soon as we completed our first standup my mind started turning towards a better structure to manage the flow and multiple level WIP limits that my client wanted.
It was certainly a struggle to come up with a Kanban design that reflects this relatively complex value stream. I hope I have done it justice. I do have a couple of concerns.
1 - complexity, this board may become hard to manage and it's complexity may make it hard to walk, I also hope visibility os not obscured.
2 - it feels like this board is holding a lot of WIP, if necessary I'll start removing buffers and collapsing states between analysis and development if they aren't adding any value.
3 - I'm new to using WIP at different tiers acting as control points for each other, in this board user stories can be blocked by a lack of movement from testing packages and testing packages can get blocked by a lack of progress with MMF related activities. It will be interesting to see how this works.
4 - I'm unsure how defects will affect the board. Both MMFs and testing packages have dedicated slots, if there is a bug do I create a new dedicated slot for a testing package containing a defect, do I move the whole testing package back, or maybe I should just have dedicated lane for defects