This is the second installment of the series devoted to WIP (Work in Progress). As explained in the first installment of this series, each open task leads to some additional work and to a number of problems. Let’s have a look at them.
Context switching
With many tasks pursued in parallel, we are forced to switch between them. Every time we do this, we are losing time. That’s just the way we operate – “entering” a new topic fully can take as much as 15 minutes. In addition, we have to record (in memory or in writing) where we interrupted the previous task.
Every now and then we will be making mistakes: we might think that we have already done some things (when in fact we were just thinking about them), or that some things have only been planned (while we have actually done them). In both cases, our work will lack a steady rhythm.
Re-discovering knowledge
Each time we are returning to an open task, we must understand its nuances again. Depending on how complex the task is, and the time that has passed since we last worked on it, this could take a moment, or much longer. The real problems begin when we are continuing a task that was started by another person…
… because that’s where we are hitting the
Knowledge transfer problem
Experience shows that some things are not transferable, and no type of documentation can really help with that. If we are lucky we might get a chance to talk to our predecessor, but even that will not allow us to get all the knowledge. And we will have to reinvent something that has already been invented.
The more tasks being done in parallel, the more delayed their completion will be. And we will deliver them to the client later. And this results in:
Delayed feedback
The later we present a demo or deploy to production, the later we will learn what the client thinks about a given fragment of the system under construction. And, in the case the client is not fully satisfied, we will pay a higher penalty than we would have to pay if we had allowed the client to review our work earlier. There will be more to change, redo, and rethink.
Reduced value
As the development time increases, the risk increases that changing business requirements will reduce the importance of the task for the client (vs. earlier delivery). In extreme cases — when a deadline is exceeded — the task may lose all its value altogether.
P.S You will find much more Kanban goodness in my book — “Kanban for your team” 🙂