Introducing Agile in Government - part 3: Getting the Kanban board right

In my previous articles in this series I have spoken about my experiences helping a government development team improve their capability.

In the first article Introducing Agile in Government – part 1: Assessing current state I assessed current state and as a result decided on an initial course of action to implement Kanban, with the goal of:

• Improving the transparency and measurability of work
• Improving predictability
• Creating slack for process improvement
• Raising the quality of work done by the team.

In the second article Introducing Agile in Government - part 2: Implementing Kanban I helped the team implement Kanban by:

• Undertaking Value Stream Mapping (VSM)
• Defining the different work types
• Establishing a physical board for visualisation purposes, based on the VSM.

In this article I continue the series discussing my experiences during the work with a focus on getting the Kanban board right.

The learning curve

It took a surprisingly long time for the team to get used to using a physical Kanban board. Longer than I'd previously experienced with other teams. I think a number of factors contributed to this:

• Only one member of the team had ever used a physical board before
• Although the team was multi-disciplinary, some resources were “dedicated” from single-discipline teams elsewhere in the department. So, in reality their work management resided elsewhere in the department and work would often appear out of left-field from outside of the Kanban flow.
• Despite being multi-disciplinary (each discipline being represented in the team), the team wasn't cross-functional (individuals generally didn’t help across different functions such as support or development even though they had the right discipline skills). Generally speaking, the work broke down to a number of small projects and background support work of various flavours. The projects tended to be given to a single developer to deliver and the support work was in two very different types. This meant that people generally couldn't help each other out and work was very segregated in the team. This made it very difficult to navigate the board and determine what work someone could pick up.
• Workflows were often convoluted due to the silo-ing of work and the make up of the team.

Changing the Kanban board to help the transition

We made a number of physical Kanban board changes to address the problems encountered and to help the team adopt the approach faster.

Efficiency Improvements

I encouraged the team to make a number of efficiency improvements to the Kanban board to better reflect the value adding steps in the value stream. This consisted of removing the "triage" step in the flow since this was generally done in minutes and was never held up by anything so showing this added little value and took up space on the board. We also physically reduced the space on the board allocated to the Pre-Prod and Prod release columns since this was out of the team's control anyway.

Compressing workflow detail to simplify use

We concluded that the split in the test column between "Shared Test Release" and "Test" wasn't constructive (discussed in previous post Introducing Agile in Government - part 2: Implementing Kanban). As a result of the workflow requirements imposed by the Test Services team and the Change Control process for releases to Shared Test (ST), the tester was required to raise a Request for Change (RFC) 3 days prior to the release to ST. In addition to this the Test Services team then required the Tester to put together a Test Plan prior to the RFC being implemented.

Testing itself couldn't actually take place until after the release to Shared Test. The end result of these was that the Tester had to repeatedly switch contexts, and kept moving the ticket between states reflecting this, to ensure that RFCs were raised on time, Test Plans were written on time and Testing could actually take place.

This made Testing the most unpredictable part of the process. Some of this detail was only discovered a lot later though so at this point Testing was compressed down to a single column within which all tasks relevant to testing had to be done for a given piece of work.

In retrospect it is obvious that as a result of those process issues the Work In Progress (WIP) in Test was always going to be high. However, at the time I was hoping that by showing Test as a single step in the value chain it would highlight the WIP and serve as a mental nudge to keep the number of tasks down.

Dealing with team members that weren’t on the team

Having combined Test in to a single state, we then split it again into two swim lanes because it turned out that projects could either use the dedicated team's tester or more often sourced their own testers. We therefore settled on a Test state with two swim-lanes, one for the team's tester and the other for "Project Testers" as we had absolutely no control over those staff or processes. This effectively curtailed the Value Stream relevant to the team down to Analysis and Development for most project work.

Splitting into work type based swim lanes to improve ease of use

Since the project work was done by dedicated team members and the flow was typically very different to support work, we split the selection of Analysis and Development columns into two swim lanes, one for support and the other for project work. This served to make it easier for people to see what work was relevant to them but was also intended to highlight the relative priority of the work as well as increase the visibility of WIP of those two types of work separately.

Showing the "hidden" work

There was a lot of work still going on that wasn't being reflected on the board. We therefore also added an "Admin" stream on the board to try and highlight some of this.

The new board

The end result was a board that looked like the following:

The second iteration of the Kanban board

Thanks for reading, click on the 'Like', 'Share' or 'Tweet' icons above if you want to see more, and look out for part 4 coming soon!

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