Introducing Agile in Government - part 2: Implementing Kanban

In my previous post Introducing Agile in Government – part 1: Assessing current state, I introduced that I’ve been helping a government development team improve their capability. In that post I spoke about how I assessed the team’s current state and what I found. In this article I continue discussing the experiences during the work with a focus on implementing Kanban within the team.

First steps - choosing the Kanban methodology

So having assessed the current state, we concluded that the problems that needed the most urgent attention were those affecting quality and predictability. However, to be able to address these with any confidence the team needed to be able see what their quality and predictability were like in the first place, which meant some kind of work tracking and reporting mechanism.

I chose Kanban as a methodology for a number of reasons but initially and primarily because it required very little change to their existing work processes yet gave them a mechanism to start highlighting problems with their process as well as numerical means to judge their own performance.

Value Stream Mapping

My first practical step was putting together a Value Stream Map (VSM) of the work that the team did. Preparing the VSM required more discussion and iteration with the team over a diagram, which ended being relatively complex because of the variety of the work that the team did. Here is the VSM that we came up with:

View larger Value Stream Map image.

For those of you that are already familiar with VSM you'll notice that some of the key components (such as value times and waste) are not on this. That's because collectively we had no real idea of what these values were and therefore where to concentrate efforts. It was precisely this problem I was hoping to solve first with the introduction of Kanban. The workflow was sufficient to put together a visual board and a tracking system. There are also a couple of other additions or departures on this example when compared with a typical VSM, which I personally found useful:

1. The inclusion of cut-offs (labelled "control point") defining the parts of the process over which we believed the team had control; effectively the boundaries of the team's sphere of influence at the time.
2. The defining of the VSM more like a flow diagram, as this was easier for the team to understand and disagree with, leading to the surfacing of flows and other work that might otherwise have been lost.

Getting from Value Stream Map to Kanban board

I had originally feared that the team wouldn't like having their work up on a public visual board but thankfully they were open to the idea. I'd like to believe that this was because I'd built sufficient desire at that point and some subtle suggestions about how the board would also show problems elsewhere in the department was enough to swing the vote, but I'll never know for sure!

Of course the physical board isn't necessary if an electronic equivalent exists but I think there are a number of advantages to the former given the increased transparency and the tactile nature of this approach. The physical board we started with looked like the following:

Some aspects worth pointing out:

• There are a few different types of work that go through the team and these were identified separately with different colour post-it notes and different service classes.
• Despite there being different flows in the VSM we opted for a single representation of flow on this board. This was something we actually changed at a later date.
• Some parts of the existing workflow, around Test for example, were circular and dependent upon change request lead-times for the test environment. There was no inherently obvious way to model this, which actually highlighted a problem in itself around context switching that I'll get to in a later blog post. We started by showing this as a linear flow but this didn't work very well for the team and didn't really represent truth, so we changed the Test column to have two swim lanes which the ticket then iterated between before continuing. A check-list on the card covered off the aspects that needed to be complete before transitioning on from the Test column.
• There were no WIP limits to start off with. This was intentional because of the current state and variety of the work that the team was engaged in. I was hoping to introduce WIP limits pretty soon after getting the board up and running, once the team was used to the board, however, for various reasons which I'll get in to in a later post, it was actually quite a while before this happened. Of all the lessons I learnt while helping this team, this I believe was one of the most significant. Getting WIP limits in sooner rather than later is worth the pain it causes. Without them, unsurprisingly, Kanban as a methodology just doesn't work, despite people's best intentions!

In part 3 of this series Introducing Agile in Government - part 3: Getting the Kanban board right I continue to look at the Kanban board and how I helped the team to get the board right for their needs. Thanks for reading and I'll get this next instalment up shortly.

Ray Cooke is a Lean and Agile business transformation coach, based in Equinox IT’s Wellington, New Zealand office.