Kanban board exprience
I was last week working with system verification team that had problems using scrum. No wonder they had problems because scrum is meant for managing product development and not to map parts of sequential life cycle model to scrum. The solution to distribute the system verification team to development teams and do the end testing as part of sprint (iteration) work was not an option at this stage (hopefully in future).
Team’s biggest problem was that they were not able to plan even for one weeks of work. This was due to interruptions and problems they found that prevented them to continue on work that they had planned. So we decided to try kanban board as work management practice. For more information about kanban development you can read free minibook provided by infoq.
The idea of kanban board seemed to fit this situation nicely but then we started to discuss about work in progress (wip) limits n and ran into problems. As this was system verification team they were concerned that wip limits are not feasible because they tend to have blockers in their normal work and development teams are needed to remove the blockers. So we decided to start with big wip limits and meanwhile try to speed-up responses from development teams so blockers wont shut down the whole teams work when using wip limits.
The team was happy to abandon sprints but decided to keep retrospectives with steady intervals. Daily stand-ups they also found useful and decided to keep them to manage their work. The planning cycle was changed so that work items were planned pretty much as in past but instead of using iteration cycle to use the release cycle to create the cadence for planning. The planned work was then only managed using the board to visualise the progress to team and stakeholders.
Team also wanted to keep the scrum master even they were not using any more scrum by the book which I found interesting. When I will visit the team in future I will try to dig out what the scrum master is doing in this new setup.
To me this exercise was useful. I realized that kanban development works best if you are able to map enough of your value stream to kanban board so wip limits can be used to remove bottlenecks. The challenge with kanban seems to be the same as with scrum if you only use it in development and not with whole value stream the benefits that you gain are modest.
There are 1 Comments to "Kanban board exprience"
Interesting case study, thanks.
I think the desire to keep the retrospectives, scrum-master and stand-ups is maybe a demonstration that these practices are more ‘fundamental’ to some of the others in Scrum, like sprints etc.
With regards to WIP limits, I think the idea is that when the limit is reached, the whole team contributes to delivering what needs to be delivered. Ie if you’re waiting for a developer to finish a task, and you can’t pull anything more into your ‘plate’ then you go help the developer.
Also, you might deliver quicker if you don’t start something new until the developer is finished the work he needs to be performed. This is due to the overhead involved in multi-tasking. (This is counter-intuitive and something I am thinking about myself).