Like me, you may have read about the growing popularity of kanban in the agile software development community. Perhaps its mysterious allure and intriguing pronunciation (kahn-bahn not kayun-bayun) have piqued your curiosity, yet you struggle with finding a pragmatic way to apply it to your current software development process?
Interestingly enough, the beauty of kanban is that you can apply it to your two week iterations… right now if you like without that much disruption. In fact, you may even find it so useful that you’ll find other ways to work the kanban mojo.
Let me explain.
About a year ago an agile team walked into our iteration retrospective a bit down trodden. They felt as though their energy was being sucked from them at the beginning of every iteration due to the length of the tasking and design sessions. In addition to this, they would open all of the stories within the two week iteration at once and would jump around from story to story at will. They had also realized about half way through the iteration they had forgotten the conversations around the original tasking sessions. All of this added up to a great deal of frustration about the way they worked.
A couple suggestions were made within the iteration retrospective:
1. Apply a work in progress limit on how many stories are tasked in one sitting.
2. Apply a work in progress limit on the number of open stories within the iteration.
The team decided on a work in progress, or WIP, limit of 5 for tasking, and a WIP of 3 for open stories. These numbers were rather arbitrary, but we had to start somewhere.
Over the next few iterations, something almost magical happened.
Tasking and design sessions had a renewed energy
Tasking sessions no longer felt like a marathon to the team, with people routinely checking Twitter (ahem) and checking out mentally. We noticed that 6 days into the iteration, team members could remember why we had tasked a user story in such and such manner.
Now the downside of this was that we had more interruptions within the iteration as we would task in bunches on 2 or 3 separate occasions. At first the team felt a slight annoyance with this, but eventually adjusted and embraced the approach as the pros greatly outweighed the cons.
Team members had more focus with regards to the open stories
We found that the number of mistakes, errors and defects on our stories were drastically decreased. No longer were team members shifting from one story to another and back, but rather exhibiting a laser focus on the 3 open stories. There was a sense of urgency in the team room that was lacking beforehand. We knew that in order to open another story we had to finish one of the existing 3, and it helped foster collaboration. Team members would help each other to wrap things up, rather than jump around like they had in past iterations.
Now the downside of this was that at times the urgency turned into anxiety and we exceeded the WIP limit. When this occurred, we would address it in the iteration retrospective to see if we could uncover the root cause of exceeding our WIP. Those conversations generally lead to process improvement that may not have been discussed otherwise.
It doesn’t replace your current SDLC
Kanban is applied to what you do now. Purists may argue that applying it to 2 week iterations is not enough, and that you need to break out of the time box. Eventually, I can envision this as it seems like the natural progression, but it happens on your time schedule, when your team is ready.
So go ahead, dip your toes in and see if you like it.