Illustration: Fast car

Image courtesy of macrorain

THE BACKDROP

This is the story about a large team (14 persons) in the pursuit of flow. When I first visited the team, it wasn’t unusual for a person to have between 5 and 10 different tasks or projects in progress at any time. The total number of tasks in progress for the team was around 60. Their backlog contained at least as many tasks waiting to be started. The level of throughput was low, the level of frustration was high.

Chart of backlog

Number of tasks in Backlog/Todo (orange) and In progress (blue), November 2016

Fighting for priority

The team was responsible for configuring new and existing customers on a SaaS based document distribution platform. Their tasks ranged from visual presentations, to writing customer specific business logic in Java. Tracking the progress of the around 60 active tasks was near impossible. Tasks often stalled due to internal or external blockers. Some were left alone for weeks or even months at the time, basically forgotten. The variation in task size was huge, from a couple of hours to several hundred. Adding to the chaos were seven key account managers, each responsible for many customers. Fighting each other for priority, these guys pummeled the team with tasks. It won’t surprise you to hear that they kept pushing harder for progress and status updates the slower the team got.

GETTING STARTED

After initial discussions in December 2016, I started working with the team in January 2017. The goal was to improve throughput and quality on the services delivered. We decided to implement a Kanban based improvement process. We started with the basics; Visualize the work, limit work in progress and pull instead of push.

Tasks were often stalled due to external dependencies from other teams or unresponsive customers. Despite that, there weren’t much inherent in the nature of the work that limited flow. Development teams often suffer from manual deployment processes and legacy systems with massive technical debt that add up to severe bottlenecks. In this team the work were less technical. I soon saw this team had the potential to witness the pure effect of doing less.

After going through the theory and discussing what changes to make with the team, we ended up with the following initial changes:

A new Kanban board:

  • We deprecated their old Kanban board (that had no working WIP limits), and started moving tasks to a new board.
  • The old board had a “Waiting” column reserved for blocked items, this was not included in the new one.
  • Previously the process was prone to lots of rework. Tasks were often assumed complete, then returned as incomplete or wrong. Based on this, we introduced a new “Acceptance” column.
  • We also added a “Backlog” column invisible on the main board, where tasks waiting to be qualified (or waiting for capacity) could live.
  • We reduced 12 (!) different classes of service down the following four: Normal, Fixed deadline, Urgent and Critical

In conclusion, the new board ended up with the following columns: Backlog, Todo(10), In progress(20), Acceptance(10), Done. The numbers represent the WIP limit in each column.

While moving to the new board, we decided to reject any new tasks until the total number of issues in progress went down from 60 to the new WIP limit of 20.

New Policies:

  • The new process were pull based. New tasks were selected by each individual based on priority, capacity and competence.
  • We encouraged everyone to unblock existing tasks or help other team members before pulling new tasks, especially when approaching WIP limits.
  • The team agreed to set stricter rules for what they accepted into the “Todo” column. Before pulling a task, the members had to ask themselves simple questions like “Do I have enough information to complete this task?” and “Can I complete this task without the help of others, or do I at least know who I need to turn to for help?” If the answer was no, they had to gather more information before starting the task.
  • We encouraged the key account managers to verify the quality of their task descriptions with the team before submitting them.
  • When a task was assumed complete and made available to the customer, we moved it to “Acceptance”. It was not moved to “Done” until the customer had approved that Yes, this does indeed solve my problem.

THEN WHAT HAPPENED?

It took some time to drain the issues in progress, and it was stressful for the team to reject new tasks during this period. Management grew anxious waiting for us to make progress, and made it clear to everyone involved that the new process was “just an experiment”. We had to show results, or they’d cancel the whole thing.

Ultimately we ended up closing some of the stalled tasks. The worst examples were over a year old. Not having heard from the customer in months, no one remembered what the real status was. After a few weeks we got close to the suggested WIP limit of 20, floating around 22–25 tasks in progress. Of the ~25 tasks in progress, a high number (50–70%) was blocked, and maintaining flow was still difficult. Sometimes the same person ended up with a second or even third blocked task in progress. Then it felt weird to simply stop working instead of pulling a fourth task, but the reduced WIP also meant reduced stress levels for the team members.

While we struggled with our process changes, the key account managers were still fighting for priority. I assured them that with the new WIP limits, speed would go up — without convincing anyone. Data showed reduction in lead time and cycle time, but the backlog was still large. After some reflection, I started playing with the idea of CONWIP, which is short for Constant Work In Progress. I was pretty convinced it would work, but what would management think of the somewhat controversial concept? Only one way to find out..

Read about implementing CONWIP and the results that followed in Part 2!

This article is syndicated from the author’s Medium blog.

Published 04/26/2017 by

Thorbjørn Sigberg