Here at @flexpay_io, we are working to reduce our firefighting ( aka unplanned work ) on a daily basis. We understand that it is hurting us and that it will always be a constant battle no matter how we organize our work load.
I wrote a little while ago a post about firefighting ( link here : ) that describe the importance of managing unplanned work.
I didn’t realize at that time what was the root cause of our unplanned work . I did understand, however, what to do when it did happen, but was not sure where it was coming from.
Every morning, I spend an hour or so reading about a topic that I care about. Time to time, I fall onto articles that describes exactly what is torturing me at the moment . This morning the magic has happened again.
Technical debt is often the root cause of unplanned work whether it’s a system performance issue or failure that has demanded attention to fix away from resource that had been assigned to work on a new feature, or refactoring of code that is outside of the project’s original time and budget constraints.
The first step to understanding the impact of technical debt on an organisation is to measure the unplanned work (metrics being a fundamental DevOps concept) – many organisations don’t do this today, but it’s not difficult to do.
It’s arguable whether it’s ever possible to fully eliminate technical debt, particularly when we’re doing Agile, we often work towards models where the developed code is ‘Just Good Enough‘.
We might want code that is excellent, or perfect, but time and budget are constraints too – as is the need to get innovation to market fast enough to win or compete.
We speak with a lot of organisations who are concerned about the volume of defects they are experiencing and jump to a conclusion that they would benefit from automated testing. Often we find, upon closer inspection of the processes involved, that there are issues around requirements elicitation and that by making improvements here, the volume of defects reduces; the root cause of the defect is poorly defined requirements.
Could our salvation be in measuring our unplanned work and making improvement on better requirements?
Here my takeaways:
- Unplanned work will always happen no matter how you organize your work load.
- Our ability to handle properly unplanned work is the key of our success. ( see how )
- The source of unplanned work is directly related to our technical debt.
- Understand that technical debt grows because of issues around requirements elicitation.
- Accept that code will be sometime ‘Just Good Enough‘ but when this happens the debt needs to be managed accordingly within the backlog.
- Technical debt needs to be managed properly. ( Measure, classify and a plan to reduce your backlog. That plan should be part of your ALM ).
- Maintain your technical debt in a single list.
- Technical debt item should all be describes in the same way. Make sure that they are clear and they highlight the effect they have on your product.
- Continually evaluate the priority and effort of your technical debt list.
- Spread awareness about the cost of technical debt.