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.