Managing in a Service-oriented Organization: For every service there should be a Kanban system

This is the third in my series of articles discussing the adaptation of your organization, leadership, and management to the new reality of a distributed, work from home (WFH) workforce.

This article discusses the concept that your organization is a network of interdependent services and that you can improve the effectiveness of your organization, and its management by encouraging the use of kanban systems to manage at every level from the individual at home, through to customer-oriented products, services, programs, and portfolios. For every service, there should be a kanban system! This article shows you how to see services and how you might design a kanban system to manage each service.

For every service there should be a kanban system!

If you haven’t read the first two articles in this series, you might like to start there: 1. Leading in a time of quarantine: create alignment through shared purpose; 2. Leading in a time of quarantine: the service-oriented organization.

In the modern world economy, some countries generate as much as 80% of GDP from the services sector. Yet, when talking with employees and managers in those businesses, they often fail to understand that they are in the services sector and that if their work product is largely invisible, if what they produce is “intangible goods”, then they are in “professional services”. For years, these businesses have persisted in using management methods developed for tangible goods and physical environments: they manage using paradigms from factories and civil engineering projects, using metrics, and incentives designed for manufacturing industries. The current crisis and the directive to work from home (WFH) has finally made it abundantly clear – if you can WFH, you aren’t dealing with a physical environment, and tangible goods, instead you are a professional services worker, and working independently and remotely, makes you are a “service of one.”

Since 2008, I’ve been teaching an approach to working, managing, leading change and organizational design that I developed and pioneered between 2002 and 2007 at Motorola, then Microsoft and another smaller Bill Gates company called Corbis. At its core, the Kanban Method as it came to be known, was always about improved service delivery, meeting customer expectations, shorter time-to-market, and greater predictability. Its primary mechanism is the use of virtual kanban systems (a counter-intuitive idea adapted from the manufacturing industry). Kanban systems in factories limit work-in-progress (WIP) and signal “just-in-time” replenishment, in the professional services firm, virtual kanban systems limit work-in-progress and prevent individuals, teams, departments, and larger organizational units from becoming overburdened. At its core, the Kanban Method recognizes that humans have a limited mental capacity – too much multi-tasking, too many things open and unresolved, leads to stress, anxiety, poor quality and long, unpredictable delivery times. Overburdened individuals, working in overburdened systems, perform poorly, and are viewed as untrustworthy by customers, disappointed by unpredictable lead times and deficient quality.

The board in the photograph shows the kanban system used to manage a project at Corbis in Seattle in 2007. This project had ~$11 million USD budget and employed around 55 people in total, roughly half of whom were software developers. The green tickets represent customer-requested features, described in the project scope and requirements, while the yellow tickets, averaging 22 per green ticket, represented a finer-grained breakdown producing units of work more readily consumed by programmers and testers. The work displayed on the board represents about 1/5th of the total scope of the project or about $2 million USD of WIP. Each green ticket represents around $100,000 of work on average and thus each yellow ticket around $4,500 of work on average.

The project is organized into 5 software development teams: each of these provide a feature development and testing service. Each team has a row in the middle of the board. The fine-grained work items represented by the yellow tickets are known as user stories. So these rows on the board represent a user story design, development and testing service. Shown in the column on the left, requirements are analyzed by a team of systems analysts who break the green tickets up into the smaller units of work represented by the yellow tickets. These analysts, offer a feature analysis service. To the far right, the column of the board barely visible in the photograph, there is a system integration testing service where the collected completed features are tested together for the harmonious functioning of the entire IT application.

Each row of the board, for each of the 5 development teams, represents in itself a kanban system. This one single board displays many kanban systems, some of them contained within others. The whole board visualizes a network of services. The whole board views the project as a service, flowing feature requests through analysis, development, testing and eventually deployment. Each development team row, views each of those teams as a service, within the project as a service. The analysis column views the analysis team as a service. And the system integration testing column views that also as a service. The project service is constructed as a chain of services and also invokes a whole host of other dependent shared services…

The column labeled “resolved” indicates a testing service at a vendor based in Chennai in India. These testers offer a user story testing service and they operate as a shared service. That is to say that the testers in Chennai are not assigned to teams in Seattle. Instead the whole pool of testers is available to test work that becomes available to them. This team in Chennai would treat the 5 development teams in Seattle as their customers. They, in turn, may have a team kanban board and use rows or colors of tickets to signify which “customer” the test request had come from.

If they only service this one project then they only have these 5 customers to worry about. If they also service other projects then they might need to use colors and rows on their board to separate out different projects and customer teams within projects to enable them to visually track the source of any specific request. A column on a project Kanban board in Seattle might be duplicated (or ghosted) as a whole team kanban board in Chennai.

The small orange tickets decorating the middle of the board, have names of individuals. On this project, these people were typically from specialists functions such as systems architecture, database administration, or user experience design. In traditional project management, these people might be assigned to the project using a technique called “matrix management”. This is widely excepted to be inefficient and often leaves the individuals underutilized for long periods of time. Operating specialist functions as shared services, where they serve this and other projects are much more efficient and keep the individuals busy with demand from a collection of different sources. Each of these individuals represented by an orange ticket, a shared service of one, can have their own personal kanban board. They can treat different projects, or teams within a project, as different customers. What is shown merely as an avatar decorating a ticket on the main project board, can manifest itself as a ticket on the individual’s personal Kanban board. This whole project board, actually visualizes a total of at least 12 enterprise services: some are shared at a project level; some shared at an enterprise level; some are dedicated to the project; and in the entirety, the whole project is a service. Each service, regardless of its level in the hierarchy or position in the network, has someone playing the role of service delivery manager – the person responsible and accountable for taking the customer’s order and ensuring it got delivered. At the level of an individual working from home, their “service of one” is owner-managed.

Personal and Team Kanban boards look very similar and are, as you might expect, far simpler. Regardless of the scale, the approach to developing kanban systems and the boards which visualize their invisible work and workflow is the same. Your organization is a network of services and for every service, there should be a kanban system!

Your organization is a network of services and for every service there should be a kanban system!

Finally, this article has used illustrations of physical Kanban boards. These have been wildly popular since 2007 as part of a general trend to collaborative team-centric working over the past 20 years. However, there is an irony to all of this, as the very first implementations of Kanban, with Microsoft in 2004, were done with geographically dispersed organizations, and the Kanban system was implemented with a software tracking tool. Suddenly, the true value of using kanban software tools is being recognized. When your whole workforce is distributed, you need virtual kanban tools not just physical boards.

To implement a service-oriented organization, where each service is managed with a kanban system, you need proper software designed for the task. I recommend only Swift Kanban or Kanbanize as tools that properly implement the necessary features. If you must use a legacy work tracking tool such as Jira, I recommend that you augment it with a metrics and reporting dashboard. For this we only recommend Nave.