> But you mentioned a systematic way of tracking tech debt and the cost of each item per year. How is that different from a backlog after a while?
Backlogs I've seen have tended to evolve into a graveyard of wish list items. But there is rarely even an attempt at quantifying the organizational cost of putting off tackling the debt until it ties into some obvious, acute measure that usually is some capex, typically software licensing, or some really way off opex, like hundreds of operations staff manually addressing issues that could be automated.
I'm wondering with so many organizations now tracking software engineering effort at a relatively granular level now with various degrees of agile projects, whether or not I could leverage the mere fact that we're seeing the effort listed out now.
Example: my team has a bunch of servers all mounting an NFS file share. Neither the OS or NAS teams ensure the mounts stay up. For a few years before I arrived, the mounts across the landscape just deteriorate, handled by individual support tickets until the degradation becomes too large to ignore, and then a task is tacked onto the current sprint for some poor schmoe to log into each server and ensure the mount works.
A quick scan of the incident tickets and the historical tasks gave me a defensible estimate of an average of 50 man-hours per year spent on this issue alone, not even counting any meetings to discuss it with customers.
In the real world, I had to use my personal Emacs Org mode agenda to keep attempting (until I succeeded) to add a task to an upcoming sprint to put in requests to automate monitoring, mounting, and alerting the OS and NAS teams when the mount fails. In "systematic technical debt management" world, when I see the incident pattern I would create a backlog task. The backlog item sinks to the graveyard/tech debt status, and every time a new incident or task comes up that would not if we resolve that debt, the time it takes to address the incident or task gets added to the debt.
The problem I'm wrestling with implementing such a mechanism is it relies upon people to remember and care about the debt in the first place, to associate it with a current work effort. That doesn't work in my experience; it's hard enough to get people to share what they are working on in such ticketing systems in the first place.
Backlogs I've seen have tended to evolve into a graveyard of wish list items. But there is rarely even an attempt at quantifying the organizational cost of putting off tackling the debt until it ties into some obvious, acute measure that usually is some capex, typically software licensing, or some really way off opex, like hundreds of operations staff manually addressing issues that could be automated.
I'm wondering with so many organizations now tracking software engineering effort at a relatively granular level now with various degrees of agile projects, whether or not I could leverage the mere fact that we're seeing the effort listed out now.
Example: my team has a bunch of servers all mounting an NFS file share. Neither the OS or NAS teams ensure the mounts stay up. For a few years before I arrived, the mounts across the landscape just deteriorate, handled by individual support tickets until the degradation becomes too large to ignore, and then a task is tacked onto the current sprint for some poor schmoe to log into each server and ensure the mount works.
A quick scan of the incident tickets and the historical tasks gave me a defensible estimate of an average of 50 man-hours per year spent on this issue alone, not even counting any meetings to discuss it with customers.
In the real world, I had to use my personal Emacs Org mode agenda to keep attempting (until I succeeded) to add a task to an upcoming sprint to put in requests to automate monitoring, mounting, and alerting the OS and NAS teams when the mount fails. In "systematic technical debt management" world, when I see the incident pattern I would create a backlog task. The backlog item sinks to the graveyard/tech debt status, and every time a new incident or task comes up that would not if we resolve that debt, the time it takes to address the incident or task gets added to the debt.
The problem I'm wrestling with implementing such a mechanism is it relies upon people to remember and care about the debt in the first place, to associate it with a current work effort. That doesn't work in my experience; it's hard enough to get people to share what they are working on in such ticketing systems in the first place.