Monday, April 29, 2013

Kanban in Practice

In this posting I talk about my experience using Kanban, why it worked and what is required to make the use of Kanban successful in software development companies. A few things motivated me to write this long overdue posting (sorry @amazonv), specifically a discussion that I had at a recent Meetup group and also that we are thinking about adopting Kanban at DealerOn.

This experience goes back to my tenure at Apprenda, where we had successfully adopted and utilized classic Agile development practices. We adhered to a two week iteration cycle, and produced fully tested, releasable packages every iteration though we didn't necessarily release every package to the public. While at Apprenda I served as the Test / Release Manager and so some thoughts are from that perspective as well.

Why we tried Kanban

I first heard about Kanban at a conference, and around the same time my colleagues Bryan and Dan begun to advocate for it, and finally we gave it a try at the beginning of a major release cycle. There were a couple of reasons why we liked Kanban even though nothing was really "broken" with the Agile cycle:
  • Too much work tracking metrics for too little benefit
  • The two week cycle was jarring, providing an inconsistent workload throughout the cycle
With Agile we spent a lot of time tracking velocity and attempting to produce accurate and reliable forecasts for the business. We never were particularly good at producing forecasts for the business owner despite all of the time spent trying to do so, but no one noticed anyway because the forecasts were disregarded since we were a startup and change our mind all the time. We ended up manipulating the numbers to make ourselves look productive, and it worked fine for the most part. But one thing was always true: no matter what the velocity, we'd work on the highest priority items and try to release it as soon as possible. The forecasts, quite frankly, were not that useful for any sort of long term planning.

In Kanban, everyone works on the next highest priority item as determined by the business. When the release date comes, the highest priority items that could successfully be completed by the team during the release cycle are done. In otherwords the business got what the team was capable of producing at the time.

Another issue we had with our classic Agile approach was due to our strict two week iteration cycle. This was rather jarring for the team. The burden was on development at the beginning of the iteration, and it transfered to the testing team near the end of the cycle. I can remember basically blocking every other Wednesday and Thursday evening to stay late to "test stuff" and rush for basically what amounts to be a false-deadline since we would not actually release every Friday.

In Kanban, the cycle goes away. The work load is evenly distributed all throughout because there is no start and finish officially defined. There are work limiters for each phase which help prevent the sub-teams from being overburdened.

What about the ceremonies?

Rather than have one of the many "agile ceremonies" for the sake of having it on a schedule, you have them when you need them. If you have a cool new feature to show, schedule a showcase. If you need to plan out a feature implementation, gather the team and conduct a planning meeting. The benefit is the meetings are shorter and more focused. Gone are the 5-minute showcases with nothing but a half-finished feature and bug fixes.

What enables Kanban to work?

A major risk to a Kanban team is producing unstable software. Since there is no end to an iteration where the software is tested and stabilized, this has to be enforced in a different way. As a part of the adoption of Kanban at Apprenda, we implemented a policy of requiring a 100% stable trunk. Features were tested and stablized on independent branches (we used Mecurial as a DVCS) and we made the appropriate investment in our testing infrastructure to be able to automatically deploy and run regression tests on all feature branches. This was no small effort, but was absolutely necessary to keep quality high and make Kanban work for us.

Another key to enable Kanban is discipline. While it is easy to pan the agile ceremonies as artificial and wasteful in a Kanban setting it is necessary to conduct each of the meetings when it is appropriate to do so. Planning meetings are important to ellicit a full understanding of the requirements and get feedback from the business before setting out on a work assignment. The daily standup meeting is important to "walk the board" and make sure all development and testing is progressing. The retrospective is still important to the team's self-improvement. You'll find yourself having less meetings overall but if you are suddenly having no meetings after introducing Kanban that is a problem.

The final item that is important to Kanban's success is adhearing to work limiters. This forces the team to confront bottlenecks. For example, at one point the testing team had a bit too much on its plate and the development team as a result made improvements to the testing framework and infrastructure that typically would be done by the testing team. At the same time, members of the testing team assist development with advanced debugging, bug fixes, and other development that typically is done by the development team when they reached their work limit.

In this posting I talked a little bit about how Kanban contrasts with Agile and some of the items that I feel make Kanban work well for software companies. If you have any feedback or questions please feel free to comment or contact me!

No comments: