Most of us involved in software development are familiar with the term “technical debt”.
As a quick reminder, it was introduced by Ward Cunningham to describe the phenomenon that occurs when we use code that is easy to implement in the short run instead of applying the best overall solution we have identified.
It is by definition a conscious decision to take a shortcut for short term gratification (like taking out a new credit card for a holiday) that in thew long term will cost us to spend extra time in development when improving the system (like paying interest on the credit card debt).
Until the capital is repaid in full we will always pay interest when adding features to the system as the debt creates obstacle to adding new code efficiently.
Ward suggests that when we are in a situation of rushing something out we need to be conscious that we will have to pay the capital in the future or the interests will cripple us.
Ward suggests refactoring as a solution to paying off technical debt.
I really like Ward’s vision and I want to expand the metaphor one level up.
Now if we change the word “software” in my description of technical debt above with “processe” we can define Process Debt.
Replacing we get:
Process Debt is the phenomenon that occurs when we use a processes that is easy to implement in the short run instead of applying the best overall solution we have identified.
Let’s look at one example
You notice that lately the system seems to be more unstable than usual. You know this because there are more calls from customer care and more defects get raised.
Option 1: You want to get to the bottom of the situation and believe that a root cause analysis with 5 whys could get you there. If you use this approach you will probably identify a change in your process to help you prevent some defects in the future.
Option 2: You implement a better policy for developers to select the defects to work on reducing the time the defects are in the unresolved queue while maintaining new features creation throughput relatively stable.
You know Option 1 is better in the long run because it will generate a change in the process to reduce the amount of rework. This will mean less time spent fixing and more time spent on new features that as a consequence means higher throughput and lower lead time for new features.
Option 1 requires some investment. You need to hold one or more root cause analysis sessions, identify the problem(s) experiment with solutions until you find a solution that mitigates your problem.
If you are under pressure, because the new product needs shipping and the old defects need fixing, you are likely to choose option 2.
By doing this you have introduced process debt
The capital of this debt is the lack of change in the process you could have identified if using Option 1.
Oh, yes, I forgot, change is difficult.
The worst part of it is the interest on the debt you will pay forever until you pay the capital. This interest will appear in the form of.
1. bugs keep on coming, we seem to be fixing bugs all the time
2. new features get delayed because now the queue is in the new features to be delivered
3. the lead time of any new feature is expanded by a factor X
4. the customers continue on complaining because of your defects in production
5. your product owner starts being annoyed at the amount of work spent by the development team on defects
6. developers are tired of always fixing defects
7. …
n. need I say more?
This interest will be paid for the rest of your life if you don’t fix the problem.
Months after you are covered in defects, are stressed by your customers and change job.
Is this healthy? Certainly not.
Is there a cure? Oh yes, indeed.
Continuous improvement has the same effect on process that refactoring has on software. It repays the capital of your process debt.
With small changes in the form of experiments you will be able to clearly discuss the problem that the team is having and make small tweaks continuously.
My esteemed colleague and fervid innovator Claudio Perrone presents his continuous improvement model called PopcornFlow saying
If change is hard, make it continuous
I could not agree more.
By making process change a continuous activity, we enable behaviours that will stay with teams forever and we unleash the power of people’s creativity in improving their own way of working.
| Published on Java Code Geeks with permission by Augusto Evangelisti, partner at our JCG program. See the original article here: The hidden dangers of Process Debt Opinions expressed by Java Code Geeks contributors are their own. |
