Neglected Work

When I was with Corbis, we relied on an ERP application called JD Edwards (JDE). It was an old, customized version and quite fragile. Taking JDE offline to do backups or database restores impacted the accounts payable and accounts receivable functions, and applying a new JDE upgrade from the vendor broke the customized database tables. So, we did what many IT shops surprisingly do—thought short term and continued using the ten-year-old unsupported version. What could possibly go wrong? Well, the manual JDE build-and- deploy process routinely overwrote configuration files during deployments, causing new orders to disappear. Eventually, everyone became afraid to touch the JDE server, and as a result, it was left alone for the better part of ten years, until we replaced it with SAP. In some ways, aging software is much like an older car that needs regular oil changes and tune-ups to keep it functioning correctly. Old software in itself is not a problem. Old software that is not maintained and is not part of an automated build, test, and deploy process is a problem.

Maintenance of legacy systems is one of the most neglected types of work. Old, fragile systems decay, making them unpredictable as the technical debt adds up. The entropy of an isolated system always increases over time. If not repaired or replaced, the system eventually bombs, blocking or delaying something important. This consumes time and energy, taking people away from other important work. “If it hurts, do it more often,” as the saying goes. Frequency reduces difficulty. Until that principle is applied to system maintenance, the neglected work will remain a problem. When new requests continuously jump over or bypass important maintenance work, neglected work sits alone, sadly, like a rejected child at a lunch table in the school cafeteria.

Thief Neglected Work often plants invisible technical debt in the system, knowing that short-term thinking sways prioritization in favor of new features over protecting valuable assets. Like financial debt, technical debt incurs interest payments, which come in the form of extra effort required to fix software bugs and develop new features. Conflicting priorities and neglected work are also close cousins. (I imagine you’re sensing a pattern here.) Neglected work doesn’t get the attention, the budget, or the resources needed to be successful, like that ten-year-old JDE configuration that was still using a customized version of a no longer supported version. The impact of this aged and neglected system on our Corbis team was failure demand that occurred when the configuration files incorrectly pointed to the wrong instance. This was a high maintenance problem and cause for many a troubleshooting ticket.

If I had to identify what kind of work is most neglected, it would be the work related to improving quality, including deferred maintenance, bugs, technical debt, and code without tests (legacy software, as defined by Michael Feathers).1 Time and cost often win when it comes to getting product out the door (“Just skip those tests. We need to get this delivered. We’ll come back to it later.”). The current corporate culture that focuses on people being “busy” all the time is absurd. Work is neglected when people are “busy.” Busy people, however, do not signal productivity—delivered value does.

Two significant areas where work stalls include work waiting on feedback and work deemed important but not urgent. A third factor is what Donald Reinertsen termed “zombie projects.”2 Zombie projects are low-value projects that are barely alive. They lurk around looking for handouts, but they get no love. They are starving for money, resources, and people.

Nevertheless, they persist, and in doing so, these starving projects subtly siphon people’s time and energy away from higher value projects. When you discover a zombie project, kill it. Kill it so the more important work will be delivered sooner and with fewer interruptions.

Some people have difficulty killing projects that have started because of a desire to avoid losing whatever time and money have already been sunk into the project. The more people invest in a project, the harder it becomes to abandon it, even when a more rational decision based off of future value would be better. This is known as sunk cost fallacy. In The Principles of Product Development Flow, Donald Reinertsen suggests we should only consider the incremental investment needed to finish the project in comparison to its economic return.3 Purging low-value jobs from the work queue makes sense whenever a surplus of high-value jobs is in progress. In other words, it’s okay to kill zombie projects. If they are really needed, zombie projects can return from the dead. The things that matter most must not be sidetracked by the things that matter least.

However, zombie projects are not the only cause of neglected work. Businesses frequently prioritize new feature releases over fixing technical debt. They choose to work on revenue-generating work instead of revenue-protection work.

This rarely works out as the business hopes, particularly as problems discovered during the final stages of uncompleted projects drag engineers away from the newer projects. Because new work is started at a faster rate than partially completed work already in the pipeline is finished, the work piles up and takes longer to do (Thief Too Much WIP sneaking its way in again). Flow time metrics start to increase. It’s like rush hour traffic. When more cars are entering the freeway than are leaving the freeway, drivers are greeted with a longer commute. And like the traffic jam on the freeway, the ensuing barrage of constant interruptions can bring workflow to a grinding halt.

Important work sits waiting until it eventually becomes an emergency or it causes distractions and interruptions. Neglected work is perishable. It ages. And like rotten fruit, it’s wasteful. Fruit is expensive, consumes space on the countertop, and gets old and moldy and smells bad. And who wants that?

You know Thief Neglected Work is stealing time from you when you delay important tasks that will eventually become emergencies. It’s like planning to take your better half out for your anniversary dinner, then deciding to skip going out this year in favor of batching it up with next year’s anniversary. How do you think that would go over? If your partner would give you an earful about it, your neglected work will give you two.

Shining a light on how long work sits neglected is a useful exercise to undergo in order to understand the relationship between old work (think zombie projects) and newer, competing projects. Similar to all the other thieves, Thief Neglected Work is cheered on by Thief Too Much WIP.

KEY TAKEAWAYS

If not dealt with, important neglected work eventually becomes an emergency.
Beware of invisible technical debt accruing while teams are sidetracked by short-term priorities.
Acknowledge zombie projects. Consider the impact they have on completing high-value projects. Either give them the attention they need or kill them.