Notes on a Kanban software development experience

I’ve mentioned the Kanban software development method in this blog before. For those who don’t know its “the new kid on the block” in Agile circles - although the originator (David Anderson) would be quick to point out it is designed to be a Lean development method.

Last year I did some consulting with a large online travel agency. I was involved with helping five teams “get Agile.” This presented an opportunity to try out Kanban in the wild. What I found was: it works, and I feel it is a better models of my own approach to software development than other methods.

What made this engagement more interesting was that I was able to start one team using the Blue-White-Red Agile (BWR) development method I’ve described before and two teams using Kanban so making for an interesting comparison.

The BWR team had been tasked with a project for which a large functional specification had been written. The spec wasn’t perfect but the organization expected them to complete it. BWR allowed the team to break the spec down and attempt it piecemeal. Some upfront estimates were made and a burn-down chart created.

(It almost looked Scrum like, that is, if you ignored the Project Manager, Development Manager, Team Leader, Architect and second Project Manager who joined the project later - and lets not forget me as Agile Coach. Its hard for a team of five developers (and a Product Mmanager) to be self-organizing when there is an equal number of self-organizers.)

This worked well. In the first few weeks I took a lot of heat because I refused to let a completion date for the work be given. Simply we did not have enough date to go on. Once the data started to come through I could do that.

The two Kanban teams were in a different position. Although they had “projects” to do most of their work was sustaining work. There were systems in place and issues needed fixing. Many of the things the company called “projects” were really to small to be worthy of the name - but that’s another story.

As a result the teams had more diversity in their work and more variability. Work would just appear - and disappear. They would have been hard pressed to keep to an unchanged task list (backlog) for a one week iteration, let alone a four week sprint.

This is the first good point about Kanban: its easier to handle changing work loads.

The teams still did “iterations” but the planning meetings quickly changed. Some work would be planned out but this could be usurped at any time. The iteration became the basic unit of comparison, allowing two periods to be compared. This meant that the start/end of iterations meetings were rather more of a review and retrospective session than planning session.

In future I think I would nominally keep iterations for this reason. They are useful time periods to review work and provide a regular review/retrospective point.

Second good point about Kanban: its easier to pick up.

On the whole I found the two Kanban teams needed less training, instruction and coaching than the BWR team (some of whom had been on Scrum training courses.) However, there was some work needed to map out the correct process flow for the Kanban teams to have on their boards.

For anyone creating a Kanban board some advice: big boards a better, involve the team and use coloured tape - insulation tape works well. In the past I’ve just drawn lines on the white board, with Kanban there is more movement and the lines are lost so I used insulation tape to create hard barriers.

A Kanban board

I expected the work in progress (WIP) limits in Kanban to pose a problem. I was expecting managers and others to want to break the WIP limit. This didn’t happen but I found developers breaking the WIP limits.

Developers broke the limits not because they disagreed but because they were accustomed to starting new work when they hit a problem. For example, a developer is working on item X, they come to a block on X so start on Y. In the extreme they block on Y and start on Z. You now have three partially done pieces of work. Trying to instil a “resolve the block” approach was difficult - largely because this organization was overloaded with managers and developers had been “taught” not to resolve these type of issues themselves.

In this organization lots of things blocked. Blocked on other teams. Blocked on IT support. Blocked on administration, etc. etc. I didn’t like it but I added a “blocked” column to the Kanban board. I also added a tally sheet to identify the biggest reoccurring blocks. I then tried to have the managers feel responsible for resolving the blocks. This was only partially successful because managers were themselves blocked because there were so many other “managers” who wanted their time. (The organization used talk as a substitute for action.)

All the teams held daily stand-up (Scrum) meetings and I encouraged the team manager, product manager and BAs to have their own pre-meeting to ensure the prioritisation queue was full and correct. This worked well.

I had the teams tracking cards by making a note on the back of the date as it progressed across the board. The date when it entered the priority queue, the date when work started and stopped, the date when it went for sign-off or test and the date when it was “done.” This data (when complete) was fascinating and started to reveal issues and opportunities, and give an idea of flow. In fact there was so much date I was overwhelmed.

In conclusion I find myself remembering Karl Scotland’s comment from a few months back. Karl had a quote which was something like: “The emphasis in Scrum is on being Agile and improvement follows; the emphasis in Kanban is on improving and being Agile follows.”

In the past I’ve shied away from labelling a team as doing “Scrum” or “XP” because I was aware they were not going it completely and we weren’t seeing all the benefits. I don’t feel that about Kanban, I’m happy to call these teams Kanban. Yes they had problems but we were resolving them. The teams were on a journey.

As anyone who has read Changing Software Development will know, I’m an advocate for incremental improvement. While Scrum (and XP, etc.) hold out the promise of overnight Agile - one big bang and your there - I see Agile as a journey not a destination.