Part of the review of ‣.
За двумя зайцами погонишься — ни одного не поймаешь.
Earl Beede suggests that having two tasks to work on is optimal for throughput because it provides for opportunities to do something when one task is naturally blocked (note: still, need to always look for ways to remove these "natural" blocks. They are often fundamentally unnecessary) or when an engineer "runs out of steam" working on one task.
Psychological effectiveness
Having three or more tasks at work in parallel is ineffective because it creates too much unnecessary context switching and reduces the engineer's working memory capacity dedicated to each task.
Effect on the length of the release cycle (and, hence, the feedback cycle)
The more there is work-in-progress, the later each feature will be released, which has an economic penalty explained in relation to the length of the release cycle in ‣.
In the development of products which allow for frequent releases (or continuous delivery), the release cycle should be as short as possible, i. e. just the time necessary to implement most changes that were chosen for development in the cycle (not even all changes, because if it turns out that some change takes longer than expected, it’s better to postpone integration of the change until the next release). This assumes that engineers focus primarily on just one change that goes into the release, rather than take up two changes and work on them one after another: in this case, the release cycle length would be almost two times longer than is minimally possible. An even worse version of this happens if a developer takes three or more tasks and tries to complete them in parallel. However, this particular negative effect of big personal work-in-progress stock doesn’t manifest on projects with release cycles significantly longer than implementation of a single change usually takes.
Sapped motivation and initiative
When people know that the release is far away because there are many work-in-progress tasks that the team completes slowly, they don’t have a sense of urgency to complete the work that is done independently faster. The low standard for performance propagates through the entire project.
The vicious circle of huge work-in-progress can lead to waste
When an engineer has many work-in-progress (or design-in-progress) items and delivers them at a slow rate, the chances are higher that they complete none of them between project re-prioritisation and planning sessions (or simply if there is new information coming from stakeholders that causes changes in the priorities of tasks, irrespective of the cadenced planning sessions). Then, it’s likely that they will be asked to take up yet another task, increasing the amount of their work-in-progress and slowing them even further. At some point, the engineer has to abandon some work items that they have started long ago and spent significant time on, but couldn’t prioritise any longer because the item has became too low-priority relative to many other tasks they were asked to work on since. This is a pure waste.
Status reporting takes longer and is harder to make sense of
When the work-in-progress of the single engineer as well as the whole team is huge, just going over can take a long time. On one project where I participated, at one moment, the work-in-progress was so huge that daily stand-ups were averaging 40 minutes. Furthermore, it’s harder if not impossible to gauge progress and to discuss all problems and roadblocks at any depth as well as make quality tactical decisions. Alternatively, if a particular area of the project is discussed at a proper depth, there will be no time left to discuss other areas at all, which may cause a latent project risk to build up.
Huge work-in-progress means an attempt to work at 100% capacity utilisation, which is a bad idea anyway
On the project which I referred to in the previous section, huge work-in-progress was a response to the fact that many tasks required coordination with external stakeholders which were typically very slow, routinely causing weeks-long interruptions. When engineers had already five tasks in progress and all of them blocked, their response was to take another task so that they do something and are not just idle.
In general, engineers usually try to fill 100% of their time with some work, perhaps, feeling that doing otherwise is a professional misconduct, or having an urge to do so when they look at their teammates who happen to be very busy with their work at the moment and a backlog of other work that no one else on the team could handle.
In the book, Reinertsen that this natural tendency is wrong. This creates is a project risk: any disturbance, such as a new extra-urgent project or any of the engineers falling ill or even simply going on a vacation, increases the cycle time dramatically when the team is working at nearly 100% capacity utilisation.