Continuing our series on thirteen technical debt categories, we’ll dive into Process Debt today.
What Is People Debt?
The authors of the Towards an Ontology of Terms on Technical Debt paper define process debt as
inefficient processes, e.g. what the process was designed to handle may be no longer appropriate
The paper itself doesn’t provide more explanation or examples, so I went into the paper they referenced, Managing Technical Debt: An Industrial Case Study by Zadia Codabux and Byron Williams. And in fact, I can’t find a clear reference to a thing called Process Debt. So we’re left to wonder a bit ourselves what Process Debt could be in the context of Technical Debt.
If Process Debt is “inefficient processes” that are “no longer appropriate”, and technical debt is a suboptimal way to deliver something faster, then maybe we can think of these examples of Process Debt:
- “for now, we’re not pair programming or code reviewing, because we need to get something out there, even if it is buggy”
- “we’re a team of 3 working closely together, so there’s no real process and we just talk to each other about what needs to be implemented”
- “we work in iterations of 2 months which worked fine for our desktop application, but after shifting to a SaaS model, we notice customers no longer find this acceptable”
In each case, things may have worked for a while or the organization may not have really thought things through initially. But over time, the process can become a hindering factor, slowing the team down rather than making them more efficient.
Causes Of Process Debt
While I have little data in the research papers to back me up here, my own experience teaches me there are several possible causes of Process Debt.
The first is an obvious one: it used to work well a certain way, but it no longer does. The software development process for a small company working on a small customer-facing product will be different than what a large company with a complex and government-regulated product needs.
Although it must be said, that large companies often add inefficiencies that serve little purpose but come from a desire to control and a lack of trust. Very often, procedures are put in place to avoid errors but none are put in place to fix the errors swiftly. Or when a rare mistake occurs (the type that will not easily happen again), procedures are modified that make teams more inefficient. Sometimes, in my opinion, people only focus on avoid another error instead of weighing costs and benefits.
Finally, a cause of process debt can be a deliberate choice to do away with (certain pieces of) the process in order to move faster. This of course makes us more efficient, but after a while, the resulting chaos makes us slower again. This is when we must repay our debt and reinstate the correct, efficient processes.
Solving Process Debt
Making teams and organizations efficient is difficult. The theory is simple, because it’s something that has already been solved. The Agile Manifesto was signed in 2001. DevOps was born in 2009. But the Agile and DevOps ideas and concerns date back much further.
The solutions many researchers and practitioners have always been proposing were more collaboration and communication, more autonomy and responsibility, more adaptation to the context.
It was never rigidly following a certain process framework. It was never imposing a process on all teams in the organization. It was definitely never buying and using some vendor tools.
But while the theory may be simple, implementing it is not. It is definitely easier in smaller organizations. But each team, each organization must find a way to give team members the necessary responsibilities (and tools, yes we do need them) to deliver the necessary business value. Managers must understand what it takes to develop software and why the long-known industry best practices should be followed.
And developers should take these responsibilities and honor them. They must keep educating themselves, be prepared to change the way they work, follow those best practices and teach others about them.
Again, the solution is better communication and collaboration. Not just between developers, but also between developers and operations teams, between IT staff and end users, and between IT practitioners and management.
If everyone works together, teams should be able to find an efficient way to organize their work, within the boundaries that the organization set. And organizations can find a way to enable those efficient processes within teams, while setting up more efficient company-wide procedures.
The important thing is to regularly evaluate if processes are still adequate for the current state of the organization.
The Business Case For Reducing Process Debt
This should probably not need much explaining, but companies (should) hate inefficiency. Be careful not to confuse this with speed of delivery. If a team is delivering fast, but it can’t sustain that pace year after year, the process is fast and maybe effective, but probably not very efficient.
Efficient processes ensure an organization can continue the pace and over time, by finetuning the process, increase the pace of delivery. Efficient processes reduce the risk of errors, because it’s clear to everyone who needs to perform which task. And if we add automation to our processes, our efficiency can increase substantially.
These steps allow organizations to delivery a more stable product faster, meaning happier customers and a more steady or even growing income stream. It also enables them to change as the market and customer expectations change.