Pushed To The Limit
The Importance of In Progress Limits in Software Development
Life is full of limits. Whether they be imposed by societal pressures; government legislation; or even a byproduct of unfortunate events; they are indeed present. Breaking the smaller rules is exhilarating. However, generally we abide, even with those that seem less sensible.
Restraints also apply on the amount of work we can undertake. For humans and computers alike, multitasking is a fallacy. Rather than exhibiting true parallelism, we context switch between operations. If we believe that we are truly good at multitasking, it is more the case that we think our context switching overhead is minimal. In reality, it contributes to wider productivity issues.
Recent events have highlighted the challenges multitasking imposes on software delivery. Here I reflect on programmer parallel processing, and the importance of establishing work in progress thresholds.
Working on a Dream
Before delving into my personal experiences, it is important to reflect on the origins of Work In Progress. WIP is a fundamental principle of Kanban. The aim of the game is to match the velocity of developers to establish a consistent effort cadence.
Adoption of a constant pace allows us to develop software in a dependable manner. Our clients think it’s great that they have a regular release cycle. Engineers are happy that their work rate is constant. Previously we had significant up rates as they scrambled to finalise features for the next release.
Despite experiencing these established benefits, we have seen bad habits emerge. Management pressure occasionally results in programmers working on both new enhancements and bug fixes concurrently. I find myself asking, is this the right approach?
Parallel Minds
Context switching may feel like we’re being more productive. We do have several engineers that will commonly work on two tasks at once. I understand the appeal. Humans do like variation in their tasks. Working on several items provides a level of satisfaction. Nevertheless, it has side effects.
Lack of dedicated time may affect the quality of the final implementation. Splitting your attention will also split your attention to the details. Programmers may miss edge cases that would have otherwise been detected.
For me as a lead, tracking what items are going to be available for a given release becomes an impossible feat. Keeping clients abridged of upcoming features is challenging enough. Ideally, developers would focus on a subset of stories and complete the features at a regular pace. With multitasking, we run the danger of no features being available if an unfortunate events arise. Even in an opportunistic world, individual stories will take longer to ship.
Take it to The Limit
It was becoming clear that key individuals were task thrashing. Subtasks were not being distributed among the team. This lack of distribution is partly a side effect of engineers wanting to own their own feature. It’s one of the key reasons we have struggled with feature toggle aversion in the past. Senior developers can fall into the trap of completing common tasks because they can complete it more rapidly than less enlightened colleagues.
Brent is a bottleneck in The Phoenix Project by Gene Kim et al. For those unfamiliar, Brent is an experienced engineer that is found to be a process bottleneck due to his superior knowledge. I recently faced the terrifying realisation that I have more than one Brent in my team.
With reliability of delivery starting to slip, action was needed to reduce the number of concurrent items on which individuals were working. At this point, it was imperative to introduce limits. Ideally, I would have preferred no more than one task assigned to any given developer at any one time. As our tools prevented this, I resorted to a simple task count on the development state. The team had concerns of such a low ceiling impacting release management items. So a compromise of two points was reached, and evaluated over several weeks.
Invisible Limits
Applying an upper bound to the development state on our board initially proved effective. The first week saw programmers progress work items through the states without breaching. Regardless, all good things must come to an end. Far from being a warning, after a while it became an everyday event. It seemed like for a significant period of time we were always infringing on our limit.
Originally, I feared we were becoming desensitised to the red. My inaugural mindset of stopping developers pushing the boundary needed to evolve. It’s more important that engineers adopt the habit of clearing items when they do infringe, rather than continue to take on work items.
The squad must also become comfortable with reassessing any established workflow restrictions. Like any part of our process, experimenting with thresholds will allow the team to improve their development practices. Just like people, every collective has their limits.
Thanks for reading. Claps and comments are always appreciated!
