New words pop up all the time, sometimes to describe a new phenomenon, or to capture the essence of a previously poorly investigated area. One such word is technical debt, first used by Ward Cunningham to show the later cost involved in delivering a quick solution now.
Also new management models are constantly being developed, such as SAFe (Scaled agile framework). SAFe is intended to govern multiple agile development teams, but is basically a bureaucratic approach. That might sounds a bit weird. Why would managers consider a rigid model for an agile development business? I think technical debt and the need for bureaucratic solutions like SAFe are related.
Is technical debt a new phenomenon?
Technical debt, according to Wikipedia, describes the cost of additional rework caused by choosing an easy solution that can be delivered now instead of developing a better design that would take longer. Technical debt is a concept mainly used in agile software development.
However, the idea could in theory also apply to hardware products that after launch will require maintenance, support, and model upgrades. Just as delivering of a piece of software functionality which code later needs to be refactored, launching a product or building a production system that later needs a lot of maintenance, or creates a lot of down-time for the customer will decrease margins as well as require a lot of attention from the engineers.
Over the past 20 years, I have implemented agile management methods for product development in more than 50 companies operating in a wide range of areas, from equipment for mining, pulp and manufacturing industries, to medical devices, chemistry and advanced built in software. Overall these companies initially spend a lot of time on product maintenance. But when the management team receives tools that create transparency and enable them to prioritize, they can focus the resources on long-term, strategically important and profitable projects. The previous huge need to maintain existing products seems to partly evaporate and ends up around 20 % of the resources. So the explanation was not a lot of serious quality issues caused by a technical debt, but rather a lack of priority.
Recently however, I have started to encounter technical debt as a potential problem mentioned again and again by managers in software development. And that made me curious. Why do companies that use agile software development principles, such as scrum, suddenly talk about technical debt? Is scrum in itself maybe creating a technical debt? And why would managers consider a rigid model such as SAFe for managing an agile development business? Let me dig deeper into the concept of technical debt to find the answers.
Agility is to keep on moving
Martin Fowler distinguishes between deliberate and inadvertent technical debt, but I think the line in the real world is often blurred. It will be a question of whether the strategic decision-makers actually understand the long term technical consequences of their decisions, as well as whether the technicians understand the long term consequences on the business. I think that both parties often will fail to fully grasp the options, because when doing cutting-edge product development the uncertainty is very high and a majority of all the answers are unknown. Your success will rest on your ability to find the answers fast and make decisions that will keep up the momentum, which can be summarized in the concept of agility.
There is no way that you can make all the right decisions. Product development doesn’t work that way. It is all about trial and error, with many failures along the way that step by step will be combined to build new knowledge and eventually be merged into the new product and the business model.
Speed in decision-making
However, speed in decision-making is absolutely crucial for success. The business must be able to make decisions in the same pace as new information arrives. Information only becomes valuable when it is used in defining the product and process design, thus creating boundaries that will channel the energy. When you speed up the operational work in the projects by introducing agile methods, more information, problems and options becomes available. You then have to speed up the strategic decision-making even more to meet the increasing demand. And as you move forward, the system begins to expand, creating ever more information (read more in The Principles of Agile Management).
It is fairly easy to expand the operational work; you just add on more engineers and start another project, but it’s really challenging to expand the strategic decision-making capacity. At some point, there is a real risk that the business can’t keep up. If decision-making becomes too slow, then a lot of information, that doesn’t create any meaning, is circulating in the system. That information is not creating any value; instead it will create confusion and hesitation. At that point the business is starting to build up a decision debt that will slow down progress and increase cost.
A technical debt can be a consequence of deliberate strategic considerations and risk assessment. But in my work I see many situations where management does not make strategic decisions, at least not quickly enough. And that creates stress. Unclear long term visions and patchy major steps towards that goal will ripple down through the organization, making it increasingly hard to make the right decisions. How do I then know what actions are needed today to come closer to the overall goal, and what ideas and options should be left untouched? The consequences will later be seen as cumbersome product architecture, an increasing amount of product maintenance, quality issues and conflicts.
Leave the old behind?
Technical debt per se is neither good nor bad; it will always depend on the situation and what consequences it will have in the long term. And you can never develop any product without also creating a need for improvements. The question is how to manage your product portfolio so that your business can continue to expand. There are several strategies that can be applied.
One way is to never look back. This will require fast development of the next generation that will replace the existing one. This strategy is in practice hard to apply on expensive hardware products. The customer will expect some support on products that doesn’t work and the cost of just scraping and replacing is too high. However, there are parts of this strategy that can be useful also here. Instead of thinking that the existing design is so precious because it took so long to develop; think that it was a first good attempt, but this time we can do the design so much better and much faster.
Another approach is to do incremental improvements in each project, which will be possible with a modular design.
Elon Musk tells us to start with a blank canvas when thinking about how to solve a problem and to use all the creativity and experience of the diverse team to come up with bold new ideas. When a better solution is found, the old one has to go.
Is scrum creating technical debt?
Let us go back to the initial questions. Firstly, is scrum in itself maybe creating a technical debt?
My answer is yes, scrum creates technical debt and the reason is weak strategic management. Scrum and the Agile Manifesto were created to deal with slow operational progress in projects. The methods have always lacked a well-built connection to the strategic decision-making. As long as scrum is used in start-up companies or initially in developing just one product, it will work as the complexity is still fairly low and the number of strategic choices quite few. But as the system starts to expand with an increasing number of actors and numerous technical components that interact, the management team loses control. Not only will they fail to make the right strategic decisions, the technicians will also fail to make the right operational decisions. The technical debt has become a consequence of a decision debt.
So why are companies today adding a bureaucratic management model like SAFe to their software development? The simple answer is that increased bureaucracy will slow down the progress of projects by adding on a lot of restrictions. The management team will then be able to catch up.
Business agility – avoid creating technical debt from a decision debt
I think it’s a much better solution to increase the speed in strategic decision-making instead. And that is what we do with Parmatur Pulse. The business can then continue to execute projects at a fast pace and launch products with conscious design and risks. When the business can avoid creating a decision debt, the need for the concept of “technical debt” disappears. This is true business agility, both strategically and operationally, giving the company a strong competitive edge.
Ulla Sebestyén has written three books on agile management, most recently The Principles of Agile Management and Parmatur Pulse.
Parmatur Pulse 