One of the most common problems teams face is starting more work than they complete. The reasons this occurs are both myriad and legendary. The impacts of teams starting more work than they complete, range from quality problems to increased support costs. Maybe the most critical outcome is lost trust. All these problems stem from letting work sit around once started while you do something else. No one can work on two items at the same time. You have to put one down, change your mental model and then work on something else. Neglected WIP is the gap between all the work you say you are working on and the stuff you are actually doing. While all neglected WIP is a problem, all teams have a few items on hold. TaskTop, the company Mik Kersten author of Project to Product founded, suggests that up to 25% neglected WIP might be acceptable. While I feel that is a high hurdle, the natural vagaries of office life can cause an item to get stuck due to someone being out sick or because your co-worker hit the lottery – stuff happens. When neglected WIP passes that hurdle, real flow time will increase and velocity will slow. The combination of getting less work done and taking longer at it is a prescription for your stakeholders to start looking for torches and pitchforks.
Knowing how much WIP is right is a challenging discussion. Every role is biased. For example, product owners want more features done, architects want to retire more tech debt, and developers want to stay busy but go home on time. That tension is why work entry is such a difficult problem to solve. One approach to creating an overall WIP limit is to use Little’s Law to calculate the estimated amount of WIP a team should have based on their capabilities. Given that the equation is algebraic, if you know any two of the three variables, you can solve for the third. In this case, if we want to know WIP, Little’s Law can be expressed as:
Average Work in Progress = Average Cycle Time * Average Throughput
A real-life example:
A team of three stalwart process improvement coaches provides a broad portfolio of services including Jira implementation and administration, team and executive-level coaching, and more. Over the past five months, their flow metrics for stories, debt items, and defects show:
Average Cycle Time 4 days per item
Average Throughput 1 item per day
Predicted Average WIP (via Little’s Law) 4 (4*1)
The data shows that the actual average WIP is 4. HOWEVER, there have been several times when WIP skyrocketed to 8 or 10 for a brief period. Knowing the level where the excess WIP can cause problems (the predicted WIP) provides the team with a tool to facilitate a discussion about why WIP spikes are occurring.
One quick note, Little’s Law assumes that the system is under control (or at least close enough). If the process is effectively a random walk, determining the level of neglected WIP is the least of your challenges.
Let’s explore an example of using neglected WIP to support establishing an overall work entry limit for a team:
Context: An eleven-person team deals with production defects, administrative support, upgrading, and delivering enhancements to a classic large ERP package. Everyone on the team runs around like their hair is on fire. The scuttlebutt in the organization is that the team never delivers on promises. No one is happy but the manager and new team leader privately state this is our corporate culture and “it is not going to change.” The new team leader has to stop the 20%’ish turnover rate the team has had for the last two years.
Flow Metrics:
Average Cycle Time 32 Days (including defects)
Average Throughput 4 Items per day (3 out 4 are defects and admin tasks)
Predicted Average WIP 128 (32*4)
Average WIP for the past two months 150 items
The average WIP includes several items that are “active and have been more than 2 years. When asked about the items the team had to look them up in the system before remembering what was going on with them. Active? One telling comment when discussing the items currently in WIP was that several of the ancient items were over two years old and actually represented the fix for defects that continually occur on a daily and weekly basis. One person on the team started a couple of hours early every day to find and fix recurring problems before anyone noticed them in production. They were so used to the situation that no one thought much about it. The bottom line was no one had time to fix the root cause but they did have time to fix the defects that regularly popped up. Clearly saying yes and starting every piece of work presented to the team serves no one.
The use of the neglected WIP calculation led to the impetus for a facilitated discussion with the key stakeholders and management. The outcome was that the team took a 2-week hiatus from most new work. They still had to deal with priority one issues (impact on human life or system down). The remainder of the time focused on paying back some of the more crucial technical debt items they had not had time for. At the end of the timeframe, everyone agreed to reduce daily WIP to 40 items at any point in time. While not a perfect, solution, the combination of WIP and tech debt reduction led to a ⅓ reduction in the defects they saw on daily basis. The team was so happy with the impact on their lives (the early person was ecstatic) that they pitched doing the 2-week debt clean-up every quarter. A year later, they have continued to ratchet down their overall WIP limit and the TL’s goal of reducing turnover has come to pass. Maybe saying yes to everything wasn’t the culture when people stopped doing it.
The team in the second example might not really have been under control, violating the assumption we noted earlier. The technique still was a good conversation starter. In the next installment, we will review all of the assumptions of Little’s Law and the calculation of neglected WIP make (and might have been ignored in the second example).
