Kanban for Shared Services Teams - Using data to deliver predictably

Many organizations have departments within IT where teams or individuals are specialized to do work to support product teams. These teams are often considered shared services, with team members having specific skill sets or working in an area which has traditionally been maintained by a small team. These teams often have their own initiatives to keep up with advancing technology as well as handle requests from teams throughout the organization. 

The Problem to Solve

One of the challenges shared services teams and the organizations in which they operate have is when the demand of needs from product teams is high, competing with the work needed to support critical initiatives and day-to-day work. Having a single point of contact or shared services team who needs to complete work for many other teams can cause a bottleneck, resulting in delays in product initiatives as well as delays with initiatives within the shared services team. While some needs may be cross-skilled into teams, there may be other skills that are highly specialized and may not be needed often enough to embed a dedicated team member in each product. This is where Kanban can help, both at a team level, as well as scaled. 

Chaos and Delays 

From the shared services standpoint, it can often feel like work is coming from every direction, all with a high priority set by the person requesting it. Work may come in through a ticketing system, email, chat, phone, etc. Without a single location, it is challenging to get a clear picture of all that is being requested, or how to prioritize and manage work. 

From the product team’s point of view, it can feel like work requested to shared services teams can get lost. Rather than being able to see work in a queue or backlog, it is often unclear how much is ahead of the work.

Visualize and Manage work with Kanban

Using Kanban, teams can help redirect incoming work into a Kanban board which becomes the single source the team pulls work from. The team starts by defining and visualizing their workflow. Starting with a Definition of Workflow, the team defines start and finish points, types of work items, one or more workflow states, sets WIP (Work in Progress) Limits, identifies their SLE (Service Level Expectation) and agrees on explicit policies of how work flows through the system. By doing this, the team builds a shared understanding of how they do the work. 

Once this is established, the team can begin to manage their work by monitoring work item age and limiting WIP. As they continue to work, the team gathers data that can help them continue to refine their process. By using Cycle Time and Throughput the team may decide to experiment in modifying their process. For instance, using Cycle Time, the team may find work takes longer than they realized. The team may further review and decide to experiment with reducing their Work in Progress (WIP) limits. By continuing to monitor their Cycle Time, the team can see the impact the change had. This is just one way Cycle Time can be used to help the team. Both Cycle Time and Throughput can also be used in forecasting future work. 

Benefits of Using Kanban

By visualizing all of their work, the team gets data to support how long items take to move through their workflow. Benefits to this include but are not limited to: having data inform improvements, improved flow of value to the customer, better ability to forecast, leading toward predictability, and ability to communicate realistic expectations to other teams who are dependent on their work, and ability to further identify where bottlenecks may occur. Additionally, by limiting Work in Progress, the team may have better focus, improved quality, as well as increased employee satisfaction, to name a few. 

Improvements beyond the team

Additionally, when the Kanban System is scaled, either to a higher level view of the work (example Epics to Stories) or to expand further upstream or downstream, the organization may begin to see where they need further improvements. In the case of a single point of contact or even a shared services team, members in the scaled Kanban System may identify areas to swarm or cross-skill certain activities. Or they may find an opportunity to automate a number of steps that help reduce the workload on a strained point in the system. When it comes to scaling Kanban, the same practices and measures in the Kanban Guide that apply at a team level can be used to optimize value at a scaled level as well. 

Informed Decisions and Predictability

In conclusion, both team level and scaled Kanban can help inform members of where to experiment with improvements and use data to gauge success. By having a predictable system, teams are able to share with those who they interface with how long it will take to complete an item or items. When changes occur, the team can use updated data to reforecast as needed and communicate so that product teams can adjust if needed. This is a win-win for both the Shared Services teams and the product teams they work with. 

Reference - The Kanban Guide