Dipping Your Toes Into Kanban

Planbox is glad to present David J. Bland from Scrumology.netour first guest blogger of 2011.

dipping your toes into kanban

David is an Agile and ScrumMaster with 10 years experience in the technology industry who strives to find balance between Agile theory and Agile reality. He recently developed a keen interest for Kanban and we invited him to discuss it on our blog. And without further ado…

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.

Share this post!
  • Twitter
  • Facebook
  • Reddit
  • Digg
  • del.icio.us
  • Add to favorites
  • RSS
  • Google Bookmarks
David Bland

Tags: agile, kanban, scrum, ScrumMaster

6 Responses to “Dipping Your Toes Into Kanban”

  1. Agile Scout says:

    Nice! Glad to see some guest bloggers stepping up!

  2. [...] This post was mentioned on Twitter by Nick Oostvogels, Planbox Inc. Planbox Inc said: New Blog Post: Dipping Your Toes Into Kanban – Planbox is glad to present David J. Bland from Scrumology.net, our fi… http://ow.ly/1aYntU [...]

  3. bonder says:

    Great article. We’re doing a weird mashup of Scrum, Kanban, and BDD. Stories are moved from my product backlog into a “ready” queue. But in order to get that far, the story must consist of at least one BDD specification. It can be more, but usually we have 2-6 per story to describe the behavior that story represents.

    We’re also using Gerrit code review so everyone on the team has a chance to see what everyone else is doing.

    Pretty soon, we’ll have our Continuous Integration system (Hudson) acting as the code verifier inside Gerrit.

    After that, we’ll work on getting stories smaller so they can be code, verified, reviewed, and merged faster.

    –Bruce

  4. Debro Silk says:

    Great post! Keep updating your blog regularly, you’ve gained one reader in me today. Keep up the super work.

  5. [...] talk will be similar in content to what I’ve written previously over at Planbox and [...]

  6. [...] the pair was ready to work on it.  This we determined was what many call “scrumban,” a blend of the timeboxed ritual of scrum with the flow management of kanban.  This meant we maintained the iteration barriers, biweekly demos, standups, and retrospectives [...]

Leave a Reply