How we started to address technical debt on a concrete case
The first step was to start identifying the technical debt initial state.
The approach we took was to create the first list of items to check per technical debt category.
For each item, we then collected and consolidated the associated KPIs to get a big picture.
Identify your business drivers to clarify the business goals and pain-points
It is important to start with business goals first. Our technical debt management is here to support and enable business drivers.
It is easy to fall into a siloed technical optimization focusing on a technological value over a business one.
A pragmatic approach was to interview the key stakeholders: business owner, product owner, and business analyst.
We complemented the analysis with the business roadmap sharing ambition, goals, and priorities.
Then, balance the business drivers with your technical ones
Having business drivers, we incorporate technical drivers from our perspective.
In our case, we confirmed the architecture principles and constraints complemented by the technical radar possibilities.
Then we performed brainstormed with the team, focusing on specific aspects of the application we had to evolve.
As with a traditional brainstorming exercise, we grouped similar post-its and identified other topics based on the team’s input.
Combine the various inputs in a matrix to identify priorities
At this point, we were able to map out the topics to address.
A useful representation for prioritization is to evaluate each item in business value versus its implementation effort.
Then, identify if there are any real dependencies on specific items. Challenge them once identified to discover ways to decouple potentially them.
If you have too many dependencies, this could indicate problems of granularity, implementation, or design.
Translate your priorities into a concrete action plan based on your resources
The last step before leading implementation is to meet the timing expectations.
The resources available were the main constraints. In our case, we clarify the allocation of one person to this task over-time.
Then based on the effort estimated in the previous step, the planning starts to emerge.
Traditional project management implementation techniques secured the delivery with automation and testing, among others.
A trimestral retrospective was also excellent practice to adapt our plan to reality.
What is working for us to address technical debt?
Based on our experience, we find concrete actions that led to results.
A traditional yet powerful one involved the whole team in the brainstorming process, helping to find better approaches.
An effective mechanism for ensuring time allocation was to focus on the activity instead of the results, such as 4 hours per week.
Lastly, applying the same quality mechanisms for standard developments is common sense: code review, peer review, and testing.
What are we planning to improve in our technical debt management?
Our journey in technical debt management is starting. We still have a lot to learn while expanding.
Many of them are related to organizational matters such as systematic review, better design of incremental and modular approaches, and resource allocation disciplines.
It is easy to go back to old habits, responding to urgent requests or another type of pressure.
Sticking to the mid-term vision backed up by your KPIs is vital and would make a difference to your overall performance.
We hope this sharing of experience was helpful to you. Feel free to share and contact us.
Stay tuned via our newsletters!