MARTYHAUGHT

In my exploration of lean processes, I have recently focused on Kanban, Japanese for ‘visual board’. This is the pull system developed by Toyota for their just-in-time manufacturing system. It has been applied to software development and more specifically it has been listed as a core principle in Lean Start-ups. Just last week I attended an Agile Denver meeting where Frank Vega and Brad Swanson presented on Kanban and their experiences with it.

Though I have yet to use it on my software team, I was struck by how many issues that I’ve seen recently in classic timeboxed iterations that Kanban solves. I’m only going to reflect on these issues and not talk at length what Kanban is. Please visit here and here to learn more or check out this page that contains links to all sorts of resources on Kanban applied to software development.

Troubled Stories

Stories see a fair amount of trouble at the hands of timeboxes. My experience is limited to two-week iterations so I can’t speak to iterations of different lengths but I’ll assume they’d be similar.

The first trouble comes trying to get a story to fit inside an iteration. If you look back in the archives in January 2009 I wrote about my take on large stories in iterations. Stories don’t always fit nicely into a timebox. Sometimes they’re too big. So they get dragged over or you’re forced to break down stories artificially to fit. This is bad as you have compromised your stories to fit your time box and lost sight of what’s most important delivering the requested feature wholely completed. Are you doing the 3 iteration story? One iteration to get the story ready, one to develop and one to discover bugs/test and fix? In some form or another I’ve seen this as a common pattern in the last five years of doing agile development.

Kanban thinks about this differently. First, your stories should really be a MMF, minimal marketable feature. This means you make it as small as you can and still make it something you’d announce in a release. The nice thing here is that you’re not making concessions based on an artificial timebox. As a team you work on this MMF until it’s really done. No trying to rush its delivery a day or two early to get it in before the iteration is over.

The second story trouble is the stale factor. If you have a sizable backlog then you may recognize this one. On my last large agile project this was a real problem. We had stories in the backlog that had been there for over a year. How relevant do you think those stories were? I know we had at least two people comb over a 100+ story backlog to see if all stories were still valid and where they really fit into the future of the product. What a waste!

With Kanban your backlog should be limited. This keeps all MMFs there fresh and relevant. Let the product owner keep other future ideas stew somewhere else until there’s room for them.

Wasted time

Time gets wasted in spades around the beginning and ends of iterations. We had nearly two days geared towards the iteration turnover. There was the final check-in that the team waited for before stamping the release in version control. There was always one story that folks wanted in that was just wrapping up. What were the other team members doing? Well, they couldn’t start on a new story since the iteration was done. Usually this was nice downtime for the team and it was nice to catch our breath. However, I felt that I was a bit too idle wishing I could start on the next thing. Deployment started here and these wasn’t that bad as we’re dealing with a Rails app but we had a few environments all the code was pushed to. We did have a manual checking process that the engineers did so several of us waited for this to be ready. Finally there was release note writing and possibly prepping for the next day’s IPM (iteration planning meeting). This whole process usually took the entire day, sad to say and almost every iteration wasted time here.

The following day was the IPM and unfortunately this meeting wasn’t punctual so again more waste. Even when everything was scheduled just right we had long IPMs trying to cover all the stories for an 8 person team. We discussed each story, got estimates on them and then there would be the necessary pruning. We always talked about way too many stories which also pushed the meeting longer than needed. Finally we divvied up the stories and got started. But usually most of the day was shot. Again, it was a two day procession of agile ceremony that while necessary felt bloated more often than not.

In Kanban it would not be this way. There would be a constrained number of MMFs that we could possibly consider and then you’re only doing one at a time, once the slot for them opens up in the board. It’s just in time as its best. The team discusses the fresh MMF right then and there and gets started once it’s ready. The meeting only needs to be as long as this one MMF needs it to be. Perfect. The team then tag teams the MMFs to get it done and off the board as quickly as the team can possibly do. No need to time things with the end and beginning of a timebox.

Hidden Bottlenecks

In our iterations we had a common pattern of roadblocks or other issues pop up that kept the team from completing stories efficiently. It happened so much that it was just considered part of the way we do business and not an issue to try and work out. Furthermore, some bottlenecks were never noticed as we had this large selection of stories to choose from over the two weeks. A bottleneck? Just grab the next story and we’ll deal with it later.

With Kanban you have less work in progress and bottlenecks are more obvious. Furthermore the process is geared towards noticing these things quickly by anyone looking at the board. ‘Why is the dev team sitting idle while we wait for testing to catch up?’. Kanban helps you notice these bottlenecks as you have stages that work goes through and thus you can see all the work as it flows through your team in one look. This bottleneck would most certainly be hidden in the traditional iteration process.

Over commitment

It was fairly often that we overcommitted in our iterations. It was impossible to get it just right and the business would rather try too much than not have enough. It wasn’t the end of the world if a story got pushed to the next iteration or if we had to grab an extra story or two if we finished early. However, it made things a bit uncomfortable when the business was expecting a feature in the iteration and it didn’t make it. Waiting another two weeks was not a pleasant thing for them and in reality this only existed because you didn’t compromise your timebox or do partial releases.

In Kanban this isn’t an issue at all. When the team finishes the MMF, it gets deployed. End of story. There is also no need for velocity calculations or even the need to estimate MMFs. Instead you track cycle time, how long MMFs usually take to complete. You can, of course, still do estimates and track cycle time scoped by size but that’s up to you.

Best Fit?

Now, since I haven’t been using Kanban in a larger team I can’t really promise that it will work so seamlessly but I’m excited by the possibilities as this process addresses several of the pain points that I’ve experienced in my agile teams. With Kanban you can still do all the other things you do in XP. You can even take some sort of hybrid approach that includes some sort of timebox rhythm if it makes your team more comfortable.

As I think about where Kanban fits best a couple business model come to mind even if you aren’t experiencing these issues. First, a product that is in maintenance mode can streamline addressing bugs and adding new features with Kanban with ease. No weird ‘wait for the end of iteration’ delays to deploy bug fixes.

If you are in a volatile situation like a start-up that is moving super fast with changing requirements Kanban feels much, much better. If you’re not planning out large releases but instead gauging your product direction by customer development then the efficiency of Kanban will serve you best.

I’d say if you have releases that are set in stone that you’ve planned out for several months then classic timeboxed iterations may be a more natural fit. I still think Kanban would be a better approach but it could really be the ‘shiny new process’ effect that is coloring my views. I guess only time will tell.

blog comments powered by Disqus