Forensic Kanban - Identifying Hidden Shared Services

Posted on October 22, 2013 by David Anderson

In this 5th post on Kanban and service-orientation, I want to demonstrate how we can see services on a kanban board design. This is the first in what may become a series of posts on what I refer to as "Forensic Kanban" - the ability to understand the organizational design in situ by interpreting the board design the organization has developed to facilitate its current workflow. Often the people involved will not be thinking in a service oriented fashion or about service delivery. They may even view some people simply as "team members" and not appreciate that they provide a service to the wider group and as part of the overall workflow. Hence, the shared service is "hidden". By helping to hold up a mirror and show the team the services that actually exist, hiding in plain sight, it can help them think about the choices they are making and how they might improve the performance of their workflow. By showing it to others, it may encourage them to move towards a shared services model.

Take a look again at the board I've used to illustrate other shared services these past two days. If you look carefully you will see a WIP limit of 5 above the testing column (tagged as "resolved" on the board as the team were using Team Foundation Server and "resolved" is Microsoft-speak for "in test".)

The WIP limit at the top of the column tells us that testing is a shared service on this project. The testing team span all 5 rows of the board and therefore provide a testing service to the 5 development teams who service the work displayed on each row. The testers are not shown as avatars (orange tickets), in fact they are invisible in this board. In this example, the testers were an offshore team in Chennai, India when the project team was in Seattle, Washington. It would have been reasonable for the test team to have their own kanban board in Chennai and to treat the 5 dev teams as different customers - different sources of demand - and therefore the work from each source as a different work item type. They could echo the board design in Seattle and have 5 lanes on their board, or choose to use 5 different colors of tickets to represent the "customer" development teams.

In this second board, taken from a product development team at a smaller firm in San Francisco in 2009, again if you look closely you will see a WIP limit of 3 at the top of the QA column. In this case, the QA team were doing scientific clinical validation of the software as their products had a medical application. While the clinical validation testers actually sat with the development team and would have been considered team members, we can see from the board design that they, in fact, provided a shared service to the 3 development teams. [The board design has 4 lanes. The bottom lane is a expedite lane without a dedicated team. Expedite requests were serviced by team members from the 3 teams represented on the first 3 lanes.]

This board design shows us that the testers were not embedded in each development team, as would typically be recommended by proponents of Agile software development. It is, in fact, quite likely that this organization inherently understood that testers would be better utilized and risk would be managed better by working as a shared service to the 3 teams working on each lane.

If testing became a bottleneck, and it did in the early stages of the story associated with this picture, it may have been desirable to specifically call out testing as a shared service and to give the testers a small kanban board of their own and to make the relationship with 3 development teams - and the occasional expedite "tiger" team - much more explicit. In this specific case, that was never necessary. The entire group were colocated and all sitting where they could see this board. The one board with a WIP limit on the column was enough to help them manage their situation and make improvements to their way of working.

As a general rule, when you see a column WIP limit spanning a set of rows, it indicates a shared service is present. If it wasn't a shared service and the function was embedded within teams associated with rows on the board then you would either see no WIP limit at all, or WIP limits on individual boxes on the board.

If you are interested in how Kanban helps with improved service delivery in creative knowledge work organizations, and how it helps to switch managers to understanding the true business they are in, then I will be talking about this at the Modern Management Methods conference in London on 31st October. Register now!