Technical Debt Scenario #2: Feature factory
Your stakeholder wants to see features at an impossible speed. Your team's velocity is dropping due to technical debt, so sometimes the product owner or another stakeholder says, "I do not understand why it's taking so long to add a new feature." What do you say then?
Let us examine the second scenario "Feature factory" of how technical debt can cause in a product team. If you're an engineer, I'm sure you already have experienced this scenario.
If you are interested in the first scenario click on the link below 👇
Patrick Roos
Table of Contents
The scenario
🕑 Planning Sprint 5:
👩💻 🧑💻 👨💻 Developers: Hey Product Owner, we should schedule some technical tasks. For example, our build pipeline on the development branch takes over 45 minutes. And yes, test coverage on existing features is very poor. It would be good to get a task to optimize these things. We should do this as soon as possible.
🧑💼 Product Owner: You know. We will be killed by the sponsor if we do not work on story x and story y. We do not have time to do those technical tasks.
👩💻 🧑💻 👨💻 Developers: But...
🧑💼 Product Owner: No but...! Let's start the sprint.
🕑 Sprint Review 5:
🧑💼 Product Owner: Hey folks. We've done the story x and the story y. We will present them today. Developers, let's start with the presentation.
👩💻 🧑💻 👨💻 Developers are presenting the business story. The stakeholders are happy.
🕑 ... Sprint 5...10...
🕑 Planning Sprint 10:
🧑💼 Product Owner: So I have presented to you the story z. Can you estimate it (in hours)?
👩💻 🧑💻 👨💻 The developers estimated: 40h for story z.
🧑💼 Product Owner: W-T-F! 40 hours for this screen? It's just a bunch of input fields and some buttons! It can not be. I do not understand why it takes so long to add this screen. I am not satisfied with your performance. We will have to discuss this with the sponsor.
What's the problem?
There are stakeholders who simply expect to see features at an impossible speed. They have no knowledge (or only pseudo-knowledge) and no ear for technical issues.
In greenfield product development, this can probably go well for a few sprints, as you see in the scenario above. But if you don't actively address the technical issues, the technical debt will build up from sprint to sprint. Your team velocity will decrease and so sometimes it happens that the product owner or another stakeholder asks you during a Scrum event, "I don't understand why it takes so long to add a new feature. This feature should be easy, right?" What do you say then?
Engineers are often confronted with non-technically (or pseudo-technically) aware people. Especially on the sponsor and/or business side, there is no awareness of technical excellence. What happens is that the development team is literally forced into a feature factory. The engineers are expected to be 10x and high performers and just deliver. And there is "no time" and no awareness of technical excellence.
How can you prevent this problem?
There are several points that lead to the problem described above:
- Communicating technical debt to non-technically aware stakeholders
- Active management of technical debt
There is no simple solution to solve the problem described above. I will give you some approaches to mitigate the risk of getting the problem described.
Take on technical debt but explicitly and make it transparent
Technical debt is like paying with a credit card. Or you buy a house and owe money to a bank. With debt comes interest, which you have to pay all the time. You have to make sure that the amount of interest is affordable and does not get too high.
The problem is that technical debt is often hidden and creeps up slowly. I.e. the build time of the frontend gets higher and higher or the libraries used contain more and more critical vulnerabilities or an important release of a 3rd party dependency used is missed. So the interest you pay on these debts (time, money, risks) also increases.
As a first bold step, I suggest that you make the current technical debt explicit and visible.
How can you make technical debt explicit? First, create a common list of technical debt. The list only needs to have a small number of attributes:
- Id
Id of the entry of the technical debt - Date of report
Date of the report - Reported by
The person who has documented the technical debt - Name
A short title for the reported technical debt - Description
The description of the technical debt - Causes, Risks, and Costs of delay
The description of the causes and costs of the delay, what are the interest costs if this debt is not repaid? - Possible resolution strategies
Describe some possible resolution strategies to minimize, mitigate, or avoid this debt. - Date of the last review
When did the product team last review this debt?
Let's give you a real-world example of technical debt:
- Debt Id: 1
- Date of report: 28.08.2021
- Reported by: Patrick
- Name: "Slow Frontend build"
- Description:
The build of a (monolithic) frontend takes approx. 45 minutes on a develop branch. - Causes, Risks, and Costs of delay
❗️ Slows down build feedback to developer in build pipeline, must wait at least 45 minutes each time.
❗️ Interferes with local testing of build artefact; detection of errors only on test systems.
❗️ Slows down the delivery of a hotfix ( 45 minutes) - Possible resolution strategies
💡 A preliminary analysis has shown that the build system can be optimised to at least 10 minutes with various measures (cost 10 PD).
💡 A quick solution would be to remove a time-consuming build option, reducing the build time to 20 minutes. This would increase the web application load time by just under a second. (2 PD) - Last verified date: not yet
Continuous reporting of new debt is the responsibility of the entire team
Keeping the list is the responsibility of the entire team. That is if a developer discovers technical debt. She or he must add it to the list of technical debt described above. A good event to discuss new technical debt is the sprint retrospective. The scrum master should bring them to the table. The Scrum Master could add it as a fixed agenda item of the retrospective.
Prioritize technical debt by urgency, based on the resulting debt weight
Once you have created your list of technical debts, you have a basis for prioritization. But how can you prioritize them?
A good approach for prioritizing technical debt entries is to use the "Weighted Shortest Job First" formula. This formula contains the following factors:
User business value
- What is the relative value to the customer or business?
- Do our users prefer this over that?
- What is the impact on our company's revenue?
- Is there a potential penalty or another negative impact if we delay?
Time criticality
- How does the user/business value behave over time?
- Is there a fixed deadline?
- Will people wait or move to another solution?
- Are there employees who will look for another job if we do not address this technical debt in a timely manner?
- Are there milestones on the critical path that will be impacted?
- What is the current impact on customer satisfaction?
Risk mitigation/opportunity enablement
- What does this mean for our business?
- Does it reduce the risk of this or a future delivery?
- Does the information we receive have value?
- Does this feature enable new business opportunities?
Duration:
- How long will it take, relatively speaking, to pay back this technical debt?
All of the above factors are evaluated relatively. That is, you can use the Fibonacci sequence.
After the calculation, you have a prioritized list of your technical debt and can start planning to pay off the highest prioritized technical debt in the next sprint.
Continuous assessment and planning of the identified technical debt
The list needs to be continuously evaluated by the entire team. I would suggest that you schedule one fixed meeting per month. At this event, go through all the listed debts and review the business value to the user, time criticality, and risk mitigation/opportunity enablement factor. This way, the debts can be reprioritized according to the current business.
For each high priority debt listed, you can decide as a team:
- Should we continue to pay the interest on the technical debt? Keep the debt on the list.
- Should we pay off the debt? Schedule the debt to be paid off in one of the next sprints.
- Do we need to reschedule the debt? Schedule a workaround in one of the next sprints, create another debt on the list.
IMHO a good rule of thumb is to hold 10 - 20% of the sprint backlog to handle technical debts.
This decision schema above helps you to be transparent about the technical issues. The resulting decisions are also suitable for communicating to stakeholders.
Summary
Debt is not bad per se. But excessive debt and excessive interest are problematic. Technical debt can be compared to financial debt. Make your debts explicit, communicate their causes, continually evaluate them in the current context, pay them off from time to time.
I have heard the term "factory" used many times in the context of a software development team. When you develop software, the problems you need to solve are often complex and complicated (see Cynefin-Framework). In a factory, you can only solve simple problems. Therefore, this factory metaphor is out of place in software development. When you hear it, think of it as an opportunity to change the feature factory mentality in the company to a true product team mentality. It has potential and could be really empowering from different perspectives.
Btw: Have you ever seen a passionate factory employee?
Comments ()