Moin.
Advertisement
(Bild:
)
Stefan Mintert works with his customers to improve the corporate culture in software development. He currently sees the greatest potential in leadership; regardless of a hierarchy level. He gave himself the task of leveraging this potential after a career path with a few changes of course. Originally coming from a computer science background with several years of consulting experience, he initially founded his own software development company. He discovered that leadership has to be learned and good role models are rare. It became apparent that the greatest need for support from his customers in software development was not in producing code, but in leadership. So it was clear to him where his company Kutura was headed: improve leadership so that the people who develop the products can develop and grow themselves. Stefan has been writing for Heise as a long-time freelancer for iX since 1994.
The term “technical debt” is now used to cover up one of the biggest idiocies in contemporary software development. The causes are multi-layered. They range from a simple misunderstanding of the term to a lack of responsibility to cargo cult agility.
In this post, I’ll start with the misconception: What is technical debt in agile software development?
With my customers, I mostly come across the following understanding of the term: Technical debt is voluntarily accepted deficits in software that are not visible to the outside world or are only visible to a very limited extent. This primarily includes deficits at the code level that are corrected later (repaying debts). Developers who enjoy developing clean code don’t want technical debt in their source code. You take on technical debt in order to be able to implement a large new feature in one sprint, for example, whereas it would take longer if it were implemented cleanly. Just quick & dirty.
But this explanation does not agree with the original meaning. In a 2009 video, Ward Cunningham, who coined the term, explains what it originally meant and how it came about. Anyone listening to his remarks will notice that Cunningham chose the word debt in a project in which the team was developing financial software. Cunningham spoke of debt to use a term with which the client was familiar and because he believed it was a good metaphor in the financial context. In fact, from today’s perspective, I think the metaphor is completely inappropriate because it is now contributing to serious problems. Cunningham believes that the idea of consciously writing source code worse than you can at any point is completely absurd. I agree with him. But if he didn’t mean that, what did he actually mean?
In agile development, you write the software (as best you can!) based on your current understanding of the problem and task. Both can change quickly with an agile approach – for example after just one iteration. Maybe because the customer changed his mind. Maybe because the market has changed. Maybe because stakeholders gave surprising feedback.
Whatever the reason, the software from the previous iteration may no longer be an optimal solution for the new situation. Cunningham called the delta between the current state of the software and the new understanding of the problem debt. However, these debts are by no means of a technical nature, but rather have everything to do with the incomplete understanding of the problem that is inherent in complex tasks in agile development. It is also not a debt that you consciously enter into. The moment you start programming, you assume that you are developing the software properly. What else? Otherwise, ideas like continuous delivery would be complete nonsense. Who wants to publish regular product increments that contain technical deficiencies? Anyone who deliberately produces poor quality is definitely not acting in an agile sense.
Worse still: If the understanding of the problem changes (e.g. after a sprint), it is absolutely necessary that the source code is as “clean” as possible; i.e. free of what we now call technical debt. Once I have developed software worse than I am actually capable of, after a sprint I not only have to struggle with the new understanding of the problem, but my legacy problems also get in the way.
In this way, technical debt becomes a burden on agility and, if not careful, leads to technical bankruptcy; a state in which it is cheaper to develop the next iteration from scratch than to rebuild the debt-laden software. Demolition and new construction.
For what Cunningham originally meant, I suggest the term Agile Course Correction. This makes me think of navigation on sailboats. Without going into details: There are various factors that influence the course of a boat. Wind, current, deviation of the compass can play a role. By determining your location, you can determine any deviations and make a course correction. I think this is a very good metaphor for agile development.
What can the development team do to prevent technical debt?
This question deserves more space than I can give in just one blog post. That’s why the topic will come up here again and again in the future. Nevertheless, I would like to briefly address the question.
First of all, it should be noted that dominant stakeholders or patriarchal product owners, team leaders or similar who force the team to quickly develop new features, take on new technical debt or leave existing legacy issues behind are an excellent prerequisite for turning technical debt into technical bankruptcy close. The development team is responsible here, because no one knows the extent of the technical legacy better.
In my opinion, anyone who works in a team that is described as agile by their boss can claim to have a say and bear responsibility. An important way to exercise this right and responsibility can be summed up in one word: no. This means: If I as a developer or team recognize that someone is asking me/us to do nonsense, no is the right answer.
And what if the story is really too big for a sprint?
I’ve seen teams unashamedly have tickets of the following types in their backlog: “Big Feature Part 1”, “Big Feature Part 2”, “Big Feature Part 3”, “Big Feature Part 4″, ” Big feature, part 5″ and so on. Each ticket corresponded to a specific developer’s volume of work in a sprint. When I asked how many parts the feature consists of, I got the answer: “We don’t know that beforehand, we work agilely.” It should be mentioned that all of these tickets went through refinement and planning.
Anyone who has read this far will agree that such an approach has nothing to do with either a proper agile way of working or a proper plan-driven approach.
What was missing here is at least an attempt at expert story splitting. I consider story splitting to be an art that extremely few teams practice. They give up way too early and rattle off beliefs like “There’s no other way”, “You can’t make it smaller”, “The feature is just so big” and “It’s no longer of any value if it’s smaller”.
My advice at this point is very clear: If the ticket doesn’t fit into the sprint,
Clarify what “Delivering Value” means to you, practice story splitting and avoid incurring technical debt.
Finally: The term “technical debt” has one thing in common with “financial debt”: In most cases it is good to reduce it quickly.
In contrast to financial debt, I doubt that technical debt has any significant benefit in agile development. If you do them regularly, it is a sign of a deficiency elsewhere.
Bye. Stefan
(rme)
To home page