One thing that I teach during a Kanban implementation is that the entire team should clap when they make a work item go through their entire workflow. This helps the team understand and internalize that their work has value only when it reaches the final step of their workflow, which for software teams its usually a deployment in a production environment.
There was a team, in particular, that was struggling to complete their work items and no one could understand where the problem was. After I helped them implement Kanban, the two main problems appeared on day ONE:
- The acceptance step was taking too long, accumulating many work items. Everytime this happened, the team started new work, which was causing a lot of context switching when they had to fix bugs or deploy the accepted work to production.
- New work items were arriving very poorly defined and with many pre-requisites missing, which caused a lot of work items to halt in the middle of the workflow, causing high traffic on their wall board and many context switching between work items.
To solve the first problem, the team stopped accepting new work if the work already at the acceptance step didn’t get approved (WIP limits!), which forced the business guys to focus on accepting the work already done before asking for new work. To solve the second problem, the team started to refuse work that was poorly defined or with pre-requisites missing (explicit transition rules!), which drastically diminished the halting problem.
At the beginning, this team seldom clapped, at most once each 15 days. Today, this team claps every single day, and I’m not kidding! Today we can say that the work is flowing!
People really want to deliver and improve the way they work, sometimes they just don’t know how. Kanban, with its visualization, flow and explicit rules, helps any team find their bottlenecks and solve it, starting at day one!