In this short extract from a longer article, Gojko Adzic discusses a tricky issue that often comes up - how to manage tech debt and 'technical stories' and how to create time for this work in agile user-centred deliveries.
How to prioritise technical debt against business features? How do we convince them that refactoring is important? How can anyone estimate the value of technical stories?
Lots of teams today struggle with scheduling something usually called technical work: system improvements that the team finds important, but nobody actually asked for them. Do too little technical work, and you’re actively damaging the product by slowly turning it into an unmaintainable mess. Do too much of it, and you’re actively damaging the product by delaying important business features. It’s very difficult to get this just right. Some teams blame micro-management caused by task management systems. Others claim that close customer collaboration turned the delivery team into a feature factory, taking orders from people who do not understand the importance of technical infrastructure. Of course, it’s easy to blame someone else, be it tools or ignorant stakeholders, but the cause of this problem is more fundamental. On the other hand, this is not a particularly new problem, and good solutions have existed for a long time.
Modern software delivery relies on close customer collaboration and transparency. Teams with remote members need digital work tracking tools. None of those factors cause problems with planning technical work, they just expose them more clearly. This is even more drastic with outcome-driven planning and measurable customer experiments from lean methods. With a laser-focus on a business goal, tech work will apparently always get postponed in favour of the stuff that actually brings in the money. This is a naive argument, of course, but after hearing it so many times following conference talks on impact mapping, it’s something I feel needs to be addressed.
Splitting work into technical and business is a wrong on many levels, but let’s disregard that for the moment. The core of the problem is the fact that a lot of work looks important to people working on software delivery, but it doesn’t seem that important to those paying for the whole process. Folks controlling the budget are also in charge of prioritisation, which is quite justified, so the prioritisation game is often dominated by tasks that easily to translate to money. As a result, teams look for ways to visualise, sell, explain, and convince stakeholders that technical stuff is important, usually bundled under the mystical spell of quality. This is a completely wrong approach, so no wonder it rarely brings results.
Read the rest of this article at gojko.net - https://gojko.net/2018/08/30/sprints-marathons-root-canals.html
