Introduction:
In this case study, we examine the journey of identifying the cause of the team demotivation and release delays by applying scenario-based development in a fintech company for one of their teams. The team was created to modify one of the company’s products to allow for deployment and customizations for different countries and legislations.
Growth Trajectory and Expansion: The initial product was implemented to be used in a specific country based on specific requirements. At the time, nobody thought about the potential expansion into other markets. And as it usually happens, some of the implemented code as well as various tools were tied to legislation particular to the initial market. When the opportunity to expand into other markets arose, the company employed a specific team to deal with various refactoring needs, replatforming and customizations, while the original team focused on the original market’s new requirements.
In this case study we will focus on the improvement of the development process of the new team by implementing a scenario-based development framework to address their challenges.
Key Challenges:
The team encountered several challenges during their tenure. These challenges included:
- unclear, unorganized, outdated and repetitive technical debt items
- miscommunications between the original and new team
- extended project timelines due to unnecessary rework during development
- team dissatisfaction due to the small or inexistent gains compared to the amount of work from tacking items in the technical debt log
All these things happen in most products because most of us focus on delivering new functionalities to keep up with the market demands. And tacking technical debt is one of the efforts we admire and we are happy to support those embarking on this journey. The gains long term are difficult to quantify but they well exceed the effort.
Solution identified:
We started by analysing the technical debt backlog and the strategy of the team while observing each individual team member’s skills and interests. We involved the team as well as product and scrum teams to identify priorities and pains.
We soon discovered that the majority of the issues were due to improper prioritization and analysis of the items in the backlog. The effort was tackled from the product functionality perspective instead of the product architecture and coding practices and needs. The logic made sense, in theory, because any development effort usually concerns the quality of the product. But considering the majority of the items in the technical debt, they required a different logical grouping and prioritizations.
The point was to address as much technical debt as possible while avoiding duplication of effort and keeping the product functional in this process.
To tackle these challenges, we recognized the need for improved communication of requirements and proper prioritisation in line with the actual expectations.
Based on the team’s skills, interests and preferences we implemented a scenario-based framework. Looking at the technical debt backlog, analysing the product’s needs and a logical grouping of the items, and discussing with team members and product owners and stakeholders, we created the following:
- a new organized and prioritized technical debt backlog
- dependencies added between various item groups
- prioritized based on the bigger gains for a group of items
- assigned them per sprints according to the skills and interests of each individual team member
- we refined the framework based on the team feedback
This approach enhanced their understanding, encouraged active participation, and facilitated a comprehensive review of the requirements.
Additionally, the team felt empowered as they were contributing to the overall increase in quality of the product. Their efforts also supported the original team in gaining more confidence in the code while adding new functionalities. The practices created by addressing the technical debt were adopted by the original team as well.
But the most important gain we noticed was the improved team satisfaction. They didn’t only address the technical as a chore but they did improve the software development practices for the entire product and they improved the quality and stability and reliability of the product.
The implementation of a scenario-based framework for addressing technical debt transformed the team’s approach to managing and improving the product. By reorganizing the backlog, prioritizing tasks for maximum impact, and fostering collaboration, the team not only enhanced product quality but also set a precedent for effective software development practices.
Key Lessons Learned and Future Recommendations:
This experience taught us lessons we added to our current scenario-based development approach:
- tackling technical debt without proper grouping or prioritization can result in duplication of effort and a lack of measurable progress
- prioritizing items based on product architecture and coding needs rather than immediate functionality proved more effective for long-term gains
- assigning tasks based on individual skills and interests increased motivation and ownership
- active participation in decision-making improved team morale and resulted in better quality output
- scenario-based frameworks help address complex challenges – a structured approach to tackling technical debt enabled the team to identify dependencies and logical groupings of tasks.
It is imperative to create and maintain an updated technical debt backlog organized by architecture needs and logical groupings, rather than functionality alone.
It is important to celebrate and communicate the value of addressing technical debt:
- Regularly measure and communicate the impact of resolved technical debt (e.g., improved performance, reduced bugs).
- Share success stories across the organization to foster a culture of quality and continuous improvement.
Conclusion:
This case study underscores the value of empowering teams to tackle technical debt with a structured, feedback-driven process. Beyond resolving existing issues, the initiative fostered higher team morale, stronger cross-team collaboration, and better long-term stability and reliability for the product. These lessons provide a blueprint for effectively managing technical debt and improving development processes in similar contexts.
Finding a scenario-based development framework that suits both your organization, teams and users is fun and challenging and so worth it.
