When you keep people busy …you get busy people. Join our Lean-agile coach Thorbjørn in this second instalment of a two-part story about a team that despite working long hours, wasn’t getting much done.
(If you haven’t already, read part 1 here)
INTERLUDE
Ever visited the Imperial gardens in Tokyo? When you enter they hand you a laminated card, to be returned upon exit. There is a limited number of cards: When they’re all handed out, new visitors have to wait for cards to become available before they can enter. On busy days, this ensures that the park isn’t too crowded. It’s a beautiful idea, simple and effective.
Reading about this in David Anderson’s book back in 2010, was the first time I encountered a CONWIP system. Patrick Steyaert also had a great post called Customer Kanban last fall. I haven’t found many other stories about CONWIP based processes, so this case study is my contribution.
BACK TO OUR STORY
When we left off in part 1, I considered implementing a process based on CONWIP (Constant Work In Progress). My idea was to give each key account manager a limited number of “tickets”. Each ticket would represent a reserved space in the Todo column of the new Kanban board. The ticket would then be stuck to the task, until it had travelled all the way to the Done column. Only then would it be released back to the owner. Instead of a WIP limit per column, CONWIP enforces a system wide WIP limit. This concept limits the total number of tasks in the board.
As in the illustration above, we wanted to maintain the column WIP limits that were already in place. On top of that we’d introduce the system wide CONWIP limit.
I decided to explain the idea to the team first, who were positive to trying it out. Next came the key account managers. I introduced the concept and suggested that each account manager would get two tickets each. I got a mixed response, and many worried that an even distribution of tickets wouldn’t work. The number of customers per account manager varied, and they also worried about what would happen during peak periods. And what if they had urgent issues? After a couple of meetings, we agreed on the following guidelines:
- Each key account manager would get two tickets each. These could be used for any task type, with any class of service.
- In addition, each account manager would get an extra (third) ticket. This could only be used for tasks that were small, urgent and had a known solution.
- Bugs / problems would not require a ticket, to ensure priority for this task type.
In conclusion: The total WIP limit for the entire system would be 21: Seven key account managers who could have at most three tasks in the board.
This allowed for far less tasks than before. We previously allowed 10 in Todo, 20 in In progress and 10 in Acceptance (40 total). Now the 14 team members got a total of 21 tasks to work on, across all columns. Re-work like bugs and reported problems would come on top of that.
THEN WHAT HAPPENED?
After implementing CONWIP, the number of tasks in progress quickly decreased. “Stop starting and start finishing” became second nature. The guidelines encouraged the account managers to slice their tasks in smaller chunks. They were also more eager to help out with blocked tasks. How else to get their tickets back, so that they could submit the next task? Since the customer had to accept a task as complete before the ticket was released, quality stayed high.
Execution wasn’t perfect all the time, but the effect was still dramatic. As in the Imperial gardens, simple yet effective. Talking to the team, they couldn’t remember a period with less to do, and lower levels of stress. The reduced WIP and reduced task switching increased flow.
Despite delivering more, it felt like doing less.
How were the team able to deliver more with less effort? CONWIP ensured fewer tasks in flight at the same time, so the team spent less time task switching and trashing. In addition, they no longer started tasks with poor specifications, or tasks that would shortly be blocked due to known dependencies. Finally, they spent less time on rework due to higher built-in quality in the process.
RESULTS
We’re now approaching the end of April 2017.
- The number of tasks in Backlog is a comfortable 34.
- The number of tasks in Todo is 4 (Limit: 10).
- The number of tasks in In progress is 14 (Limit: 20)
- The number of tasks in Acceptance is 3 (Limit: 10)
Since there are some seasonal changes in the workload, it made most sense to compare with the same period from the year before.When comparing March 2016 against March 2017:
- The median cycle time was reduced from 10 to 4 days.
- The median lead time was reduced from 4 weeks to 1 week.
After implemeting first column based WIP Limits, and then CONWIP, both the tasks in the backlog and the tasks in progress started dropping. Soon the work in progress stabilised at a new level (about 30% of the original number), while the number of tasks in the backlog kept dropping.
New baseline: Less than 1/3 of the tasks in progress compared to when we started. Significantly lower stress levels both with the team and the key account managers. The team keeps reducing the backlog, as opposed to before, when the backlog had been stable at best.
It’s safe to say that the result of this implementation exceeded my expectations. Initially we discussed to give out an uneven number of tickets to the account managers. In the end the flow was so high that it just worked, despite variations in workloads and priorities.
As we remember from Part 1, the team was responsible for setting up new and existing customers on a SaaS platform. They were not developers. It was fun to work with a team where the flow wasn’t as coupled to technical issues as with a traditional development team.
CONCLUSION
CONWIP isn’t a mechanism for every team and every situation — But when the situation calls for it, it can be a powerful way of controlling flow.
Say you have several people requesting changes from the team, like in our story. It’s important to give fair treatment to all stakeholders, so that they get their share of the capacity. CONWIP is an elegant and automatic solution to this problem. No need for lengthy discussions and HIPPO interventions
.There are a number of other situations where a system wide constraint might make more sense than setting limits per workflow state. Experiment! Feel free to reach out if you want to discuss how to try it in your team!
This article is syndicated from the author’s Medium blog.