Lesson learned: do not clog your workstream
Learning this lesson cost us two weeks of throughput. Here is what happened.
We started work on a feature that was dependent on external resources for completion. In anticipation of a quick completion (based on past experience with other providers), we filled our “Analysis Compete” queue with work that depended on the completion of the work in development.
Of course, completion was delayed and it involved a lot of waiting and very little work. So the bottleneck resource, me, was under utilized. As the delays dragged from day to day we tagged the work with an issue and thought of pushing some other work instead. But all the work in our stream was dependent on the resolution of the issue. I did not want to break WIP limits so we could not simply start a new work item. So I kept myself busy with some refactoring.
There are two bad things that stemmed from this. First we lost throughput. Second I did work that will not be verified as a story would have. The good thing to come out is that we reflected on how to improve.
The first improvement is obviously to limit dependencies between work items that are in process. In particular those for which we do not fully control the completion. The second improvement is to try to avoid saturating our queues, in other words avoid a one hundred percent utilization of them. The third improvement is that we are now comfortable dropping work in process when we find out that either it cannot be completed in a reasonable amount of time or it does not have the value we anticipated.
What do you think ? Are there other lessons that we should learn ? Do you have any advice on how to anticipate these issues ?
