I will now discuss a concrete case (...I actually found it in several organizations) in which one of the main risks for a software development company is the high level of technical debt for the product and its documentation.
The final effects are the followings:
- Components difficult to modify and fix
- Economic inefficiency in developing and maintaining several product variants, as required by the market
- High risk when technologies need to be changed: components need to be completely rewritten, documentation does not reflect current functionality, but only a long series of change requests, time and cost high now, and impossible to bear in the future.
- The risk for the future, given that technologies change very often (even if you keep the same technology, it will change at a rapid rate) is infinite.
How did they get here?
They somehow complied with the basic recommendations for technical debt and flow optimization:
- Technical debt was not a major impediment… until it became so
- Flow delays were not a big problem… until they became so
For a while, at any time, they could have told you “Our flow is good, we have no major delays and technical debt does not cause us much trouble"
Important - the technical debt accumulates, it's like in the metaphor with the Boiled Frog. You also need to consider measurements trends and future implications, not just current ones.
My advice about Technical Debt: measure the trends and act preventively.
Likewise, to avoid waste: it is not enough to measure the delays in the flow, this being only the final effect of many sources of waste. Find the various sources of waste, calculate the trend, and take preventive action.
We have more strategies to deal with the waste (read more here):
- correct
- correct early
- avoid
