Managing Product Adaptability

Overview

Creating reliable and adaptable software is not straightforward even if the team embraces Agile practices. In most cases, however, it’s not lack of technical capability or poor performance that prevents the team from achieving this goal. My experience says that the teams are aware that constant refactoring, automated tests, design spikes, etc. are required to keep the system reliable and adaptable – it’s senior stakeholders that usually fail to understand it.

Market is very demanding nowadays. Industry after industry demands for continuous innovation. Pressure for frequent releases and responsiveness to constant changes grows. And Agile seems a good solution for software teams to deliver valuable, high-quality products quickly. However, they need to be quick but should not cross the line and make mistakes. They “need to be quick but should not hurry“.

And unfortunately senior stakeholders far too often adds to this pressure and sacrifice long-term gain for short-term wins. Unreasonable deadlines are set and all the features are requested to be delivered. And in most cases the team manages to do that – velocity accelerates and the team delivers what they were asked for. But it’s a false acceleration, because corners are cut. And adaptability is the first thing that suffers from such an approach. Technical debt grows quickly and accumulates.

Technical debt

Technical debt is invisible, especially at first sight and in short-term. Software is being delivered, features get implemented so why to bother about it at all, right? What really suffers, however, is system long-term reliability and, most of all, adaptability, but it usually doesn’t come to light quickly. But it’s a real problem that in long-term results in dropping velocity, increased cost and time to delivery, growing number of defects, and above all decreasing customer satisfaction. The company is no longer ready and able to deliver valuable software and adapt to tomorrow’s client needs.

It’s especially frustrating from team’s perspective, because – if you ask them – chances are that they will directly mention parts of the code that need urgent refactoring and that contribute to technical debt the most.

Product Quality Assessment

This being said I suggest that one of the measures you can use to monitor if system’s adaptability is not deteriorating [too fast] is Product Quality Assessment performed by the team:

This measure depicts team’s sense of the project’s “feel” (“smell” as called in XP). It can be supported by a chart that plots growth of the test code compared to executable code over iterations (both should be growing proportionally).

Why, in my opinion, this measurement is so important when there are dozens of other KPIs available? It’s not to say that it’s the most important KPI you should use, but it’s a canary in a coal mine that gives you an advanced warning of system adaptability potentially going down before other measures notice it. It gives you a chance to have a closer look into the problem before velocity drops, number of defects grows and the cost of getting rid of technical debt becomes [too] high.

Managing technical debt

Please be reminded that technical debt, like financial debt, has to be managed. It’s important to realise that there is no debt-free product, but you should be aiming at keeping technical debt low so that it doesn’t affect future product development. There are several possible ways of paying technical debt back, but the most important thing to remember is that it should be done regularly and incrementally. You need to avoid large balloon payments as a means of servicing technical debt when it’s far too costly, frustrating and time-consuming. By using some simple measures you can make technical debt visible – both to the business level and technical level. And hopefully convince everyone that technical quality is critical to achieve long-term goals and it shouldn’t be short-changed for current needs. Continuous value generation should be viewed from a whole product life cycle perspective after all.

To be fair, it has to be noticed that technical debt is not bad by definition – it just has to be acknowledged and managed properly. There are situations when technical debt doesn’t need to be paid back, i.e.: product nearing end of life, throwaway prototype or product built for short-life.

Please bear also in mind that technical debt can be intentional, i.e. when a fixed deadline has to be met. However, rather than being hidden it should be well-thought-out decision. The decision that not only allows for technical debt, but most of all acknowledges the consequences of introducing it and involves a concrete plan for getting it paid back in future. Otherwise it would be living a lie and asking for trouble.