Techrospective: A New Sprint Event for Technical Debt Management

What is technical debt and why does it exist?
Technical Debt can be summarized as preferring simple but much faster results, instead of the methods that we think are ideal but will take serious effort/time while developing software.

Nowadays, keeping the time from understanding customer needs and demands to completing their developments and making them available in the production environment as short as possible is critical in the life cycle of products. In this sense, if progressing with the most ideal design and method while developing a new feature will delay the production environment for example 2 weeks, a path that can be completed in 3–4 days may be preferred instead.

The issue here is almost entirely linked to the trade-off concept. We cannot say, “Let’s make and apply the most ideal design and complete the developments as soon as possible”. We have to compromise one way or another. This is a phenomenon that is inherent in our software development business and we encounter almost every stage and we need to manage and solve it well.

As far as I see, there has been no common opinion on exactly what can be called “Technical Debt” and which subjects fall under this scope, although long discussions have been made about it. One segment tends to categorize technical debts by saying “A deficiency in the user interface is not a technical debt, this is an Interface Debt”, while another group makes inferences that “debts left unknowingly due to lack of competence or knowledge cannot be called a technical debt”.

While I do not intend to engage in these long discussions, it is my conviction that in the software development lifecycle, all debts left deliberately or unintentionally should be considered technical debt. I am of the opinion that looking at technical debts from a holistic perspective would be much more accurate in deciding which technical debt can be settled under what conditions and when.

Difficulties in Technical Debt Management
It is not very easy to determine and manage all of the technical debts. Probably not a very high percentage of software development teams today have internalized the concept of technical debt and are trying to manage it. An estimated majority of the teams trying to manage these also suffer because there is no specific standard or specific event.

Apart from identifying, detailing, categorizing, and constantly monitoring technical debts, it is the real problem to decide which of these debts will be resolved and at what stage.

New Sprint Event: Techrospective
In order to address all these problems and to make better technical debt management, we started to organize an event called Techrospective at SabancıDx.

Techrospective (we call it Techro for short) is an event that takes place once in each sprint and lasts about one and a half hours, specifically for two-week sprints.

If you ask where the name “Techrospective” came from, it developed spontaneously as “We should make a technical retrospective, let’s call it Techrospective”. When we searched for the name “Techrospective”, we have not seen it used as a sprint event name. This name was used before, but it was organized as an event where technological developments of the past period were discussed. We decided to use this name, which is easy, catchy, and describes its purpose.

What are we doing in Techro’s?
Techro’s creation purpose was to manage our technical debts, but we saw that we could address more of our needs with this event, and we gathered Techro’s possible agenda items under 6 topics.

1. Technical Debts: Techro’s most important agenda item is technical debts. Within the scope of this topic, if not exists, we start by creating a “Technical Debt Board”. On this board, we write our debts as detailed as possible and determine their priorities. In order to take the top priority debts to the next Sprint Backlog, with a mutual decision in a way that does not violate our product time plan, we move it to the Product Backlog by obtaining the approval of the Product Owner.

In principle, technical debts should be in constant motion on the technical debt board. New technical debts should be added to the board as they arrive, and old debts should be completed over time. A board with little movement or no new debts is an indication that something is wrong.

2. Software Quality: “Software Quality” is a very broad subject and requires specific expertise. It is critical that this expertise should be extended to the entire development team, and even to every role involved in the software development lifecycle. With this awareness, we take advantage of Techro’s to evaluate two main software quality issues, and we reserve a time slot to discuss.

• We measure Unit/Integration Test sufficiency, if there is a lack of information in the team, we try to complete it, and if there are obstacles, we try to eliminate them. If necessary, we devote an entire activity to this topic, write tests with the “Mob Programming” approach, and develop the test writing infrastructure.
• We evaluate the “Static Code Analysis” outputs that are made regularly. We decide which of these outputs can be “false positives” according to the relevant project dynamics, we remove them and enter the rest on the Technical Debt Board. After this stage, taking into account the ones with high importance, we move them to the Product Backlog, with the approval of the Product Owner. So we can include them in the upcoming Sprint Backlogs with a joint decision, just like technical debts.

Specific to this item, we have seen that the participation of professionals who are experts in software quality specific to the department, even if they are in other teams, adds great value to us. It is very important to spread know-how and practice on this subject, and we can progress much faster and more efficiently with expert professionals.

3. Process Improvement: We, the software developers, can sometimes put up with the problems we experience while developing, or even worse, form a habit, and continue our lives like this, even if it seriously affects our productivity. With this agenda item, we are trying to break this blindness, improve our software development processes and remove obstacles.

Within the scope of this subject, we can talk about the following topics as an example:

• If we are not satisfied with the performance or a feature of a development tool we use, we are discussing whether we can improve it with plugins or switch to a new development tool.
• We discuss the problems of the computers we use for development, if there is a general problem, we can go to the relevant departments to solve them.
• One person in the team reports that he/she works more efficiently with a new tool, he/she presents this to the teammates and we evaluate it together.

These are just a few examples, the main purpose is to try to solve the problems that slow us down and we constantly experience during the day.

4. Personal Improvement: Self-improvement is important in almost every profession, but this is a necessity in software development. We can see that what we think is right today is wrong after a while, we realize that a method we know today loses its meaning over time, and we need to move forward with new, more efficient methods. In this respect, the professional survival of a software developer is directly related to his/her self-improvement.

In this agenda item, each participant answers the questions of “What did I learn new in the last sprint, in what ways did I improve myself”. As a basic principle, we expect the developer to be self-taught on new technology, method, tool, etc. in every sprint. If a sprint is spent without learning a new subject and without spending time on self-improvement, we consider it as a “Personal Technical Debt”.

It should not be forgotten that the self-improvement of software developers is both an investment in themselves and their future, and it will return as a direct contribution to the organization, product, and team they work for. In this sense, if there are situations that prevent people from improving themselves, we talk about these issues and try to solve them.

5. Documentation: One of the common concerns of almost all software developers is to prepare documents for their work. As an approach, we do not like to write static, very detailed documents that are written once and then not looked at for a long time. However, we agree that to a certain scope, living and constantly updated information should also be written. In this sense, we create and edit “Wiki” pages for each project. In this agenda item, the importance of Wiki is re-emphasized, its up-to-dateness is checked and awareness is increased. We aim to provide input, with the goal of software developers using the Wiki actively, making it feel like a bedside book and being the first point of reference when they get stuck or have trouble remembering a topic. In this sense, we can summarize the sample titles on the Wiki as follows:

• What You Need to Get Started with Project Development: This is a critical topic for the quick adaptation of newcomers to the team.
• Basic Diagrams: Product/process flow/sequence/block diagrams, topology, network etc.
• Coding Standards: Naming standards, preferred methods in coding, etc. a non-detailed section that aims to set standards across the team.
• Product/Project Specific Procedures: For example “New microservice adding procedure”, “Module authorization system”, “New scheduled task adding procedure” etc.
• Basic Architectural Decisions (Lightweight Architecture Decision Records): The section where the architectural decisions taken for the project are kept in a short and simple language. It may be more accurate to manage these decisions together with the source code instead of the Wiki in terms of history and development/change tracking. For those who do this, just linking to the relevant resource on the Wiki is sufficient.

It may be all of these and even more, but it may be preferable to have only certain titles on the Wiki. Some headings can also be filled by simply linking to the relevant documents and resources. The main purpose here is not to overwhelm the team with boring work such as filling out documents, but to create a common library of knowledge, to share the notes that each individual keeps privately, and — I am writing at the end, but one of the most important — to enable the adaptation of the new team members to be done much faster.

6. Detailed Discussion on a Special Topic: Apart from the agenda items discussed so far, in this topic, we are discussing a problem or method that the team wanted to discuss and could not find a clear solution to or could not agree on a common point about, at Techro. We try to find the most appropriate technical solution by examining the issue from every angle, aiming to reach a common solution that everyone can accept.

The question “How do you stick to the timetable with so many agenda items?” immediately comes to mind. We may not be able to discuss every agenda item at every event. We always look at the Technical Debt Board at every event and make the relevant evaluations. Afterward, we discuss if there is a special topic that is desired to be discussed specifically for that event, otherwise we continue with other items. We do the time and agenda item planning together in that event. If Techro time seems to be running out and there are critical issues to be discussed, we plan new and topic-specific sessions.

Another important point of Techro’s is to ensure that every participant has a say and an active role. It is also very valuable to hear the voice of each participant in the events, to learn their ideas and to increase cooperation and interaction, to encourage polyphony, to hear different ideas, and to develop intra-team communication.

Techro’s are attended by the entire development team and relevant people from other teams who are experts in their fields. If your organization is eligible, I find it important to have a role that participates in the Techros of all teams. The person with this role is aware of the internal dynamics of each team, the problems they experience, the solutions they develop, and plays a critical role in the spreading of information among teams. The comments and feedbacks that this person will make as an outside eye at the events he attends are also very valuable for the teams.

We have been having Techro events at SabancıDx for a considerable amount of time. At least one person (usually two) having the role of Architect and one person having the role of Software Quality Team Leader attend all events. I can say that with this solution, discovering the potential issues where we can improve in our own organization, and producing solutions have contributed a lot to us.

Thank you for reading this article, which I shared in the hope that it will be useful to those who have similar problems.