technical debt | Scrum Agile Project Management Expert

Resources for Code and Database Refactoring

scrumexpert — Wed, 25 Feb 2026 17:49:12 +0000

Martin Fowler defined refactoring as a ” disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”. In the days of Agile development where code is delivered after one or two-week cycles, you start quickly to deal with “legacy” code, what was known as “maintenance” for projects that had longer delivery time frames. To limit your technical debt, code refactoring should be an ongoing activity in Agile teams. Even if refactoring is mostly linked to code, the term is also widely used for every restructuring effort: database definition code, testing scripts, software architecture or development process. In the core principles and best practices of refactoring, you will have to keep behavior unchanged as you verify with tests before and after refactoring. You work in small, incremental steps: make tiny, reversible changes and run tests frequently. It is important to automate tests and CI. A solid test suite and continuous integration are prerequisites to code refactoring. In addition, you need to improve readability of your code first with prefer clear names, single-responsibility functions, and consistent style. Finally, you need to refactor for intent: you have to change the structure so the code expresses why it exists, not just how. I am sure to forget some precious resources in this overview, so do not hesitate to add some pointer in the comments (no commercial tools, thank you). Some of these resources are language specific (Java, Ruby, .Net, Python, PHP and even Fortran) but you [...]

The post Resources for Code and Database Refactoring first appeared on Scrum Agile Project Management Expert.

How to Sell a Big Refactoring or Rewrite to the Business?

scrumexpert — Wed, 03 Dec 2025 15:50:43 +0000

In the world of software development, dealing with legacy code is often a necessary evil, especially for successful, fast-growing companies. But how do Agile teams tackle this challenge smartly and sell the idea of refactoring to the business? This presentation discusses the often-misunderstood realm of large-scale refactoring and rewrites, presenting a nuanced approach that contrasts with the traditional ‘never rewrite’ dogma. It presents real-world case studies where companies have successfully navigated their technical debt, uncovering crucial insights. Specifically, the video identifies two key properties of these successful rewrites that can make or break your efforts. Understanding these properties enables Scrum teams to strategically manage technical debt without losing your competitive edge. This session is not just a theoretical discussion but a practical guide, concluding with a systematic approach for your team’s refactoring or rewrite projects. Video producer: https://ndcoslo.com/

The post How to Sell a Big Refactoring or Rewrite to the Business? first appeared on Scrum Agile Project Management Expert.

Agile Tools to Measure and Manage Technical Debt

scrumexpert — Tue, 24 Jun 2025 09:00:42 +0000

Technical debt is a metaphor coined by Ward Cunningham in 1992. This concept refers to the work that needs to be done so that a software development project could be considered as “complete”. Could you try to measure your amount of technical debt? Could you use some tools to do this? These are some of the questions that this article explores. In a brief informal survey of Agile practitioners, the idea of putting some number on the amount of technical debt was mostly considered as strange. Somebody even answered that if you had a good definition of “done”, your project should never create any technical debt. For those who live in a less perfect world, technical debt could be created in all the software development activities: architecture, design, coding, testing and configuration management. You don’t have to be an evil programmer to create some debt, especially in large projects. You just duplicate some code because you don’t know that the same feature is also implemented elsewhere in the system. You rely mostly on manual testing to verify an urgent change needed for a bug in production. Sometimes, it is the requirements or the concept that changes. Then you should refactor some to make variables names more meaningful. Tools to detect some of the technical debt issues have existed for a long time. There are plenty of them available for code analysis or test coverage. Some might provide “absolute” information, like the violation of a coding standard. Others will just produce [...]

The post Agile Tools to Measure and Manage Technical Debt first appeared on Scrum Agile Project Management Expert.

A Framework for Managing Technical Debt

scrumexpert — Wed, 05 Apr 2023 16:00:37 +0000

Technical debt is inevitable in Agile software development and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn’t have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions – it all sounds great on paper, but it often fails in practice: to-dos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against technical debt. In the past three years, the presenter has explored different strategies and processes for refactoring code. This talk describes the key components of a framework for tackling refactoring and reducing technical debt. It shares some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases. Video producer: https://techleadconf.com/

The post A Framework for Managing Technical Debt first appeared on Scrum Agile Project Management Expert.

How to Get Out of Technical Debt

scrumexpert — Mon, 30 Jan 2023 16:28:52 +0000

This presentation discusses what technical debt looks like, and how easy it is to get into debt in the first place. Then the presenter proposes to put a plan into action to get out of it, understanding that you should consider technical debt as a business problem, not as a tech problem. This plan to get out of technical debt includes: * Facing up to all the debt you are in * Deciding How Much You Can Pay Back Each Month * Getting help when you need it * Being Diligent Moving Forward Video producer: https://www.agileonthebeach.co.uk/

The post How to Get Out of Technical Debt first appeared on Scrum Agile Project Management Expert.

Technical Debt: Fixing Highest ROI Issues

scrumexpert — Mon, 28 Feb 2022 16:15:41 +0000

Does your technical debt backlog look endless? Are you thinking about pausing feature development to resolve technical debt? Stop. What if you were told that a good chunk of your backlog can simply wait? Technical debt can seem overwhelming when we look at it as a loosely organized list. This can lead to several anti-patterns in how we deal with them. This session shares strategies that have been used to identify high priority technical debt items to make sure we are able to continue feature development while improving code health. Problem Statement: Technical debt often accumulates until productivity takes a serious hit and then as a knee-jerk reaction we try to clean it up all at once. At this point, there is just one large list of issues with a loose sense of priority. This gives the impression that you have a huge backlog. This can lead to many anti-patterns:* Chicken and Egg Problem – Too much Tech-Debt, so feature development is slow. Since feature development is slow, we cannot set aside time to fix issues. Fixing the wrong issues – In the larger scheme of things, it may be counter-productive to fix low priority issues just because they are easy. Pausing Feature Development – Approaches such as “”Technical Debt Sprints”” where we pause features to resolve tech-debt are not sustainable even if they offer some short term benefits. Local Optima – Patchy cleanups which lead to uneven code health across the code base. Solution: Understand the impact of each [...]

The post Technical Debt: Fixing Highest ROI Issues first appeared on Scrum Agile Project Management Expert.

Prioritizing Technical Debt

scrumexpert — Tue, 21 Sep 2021 20:56:06 +0000

This presentation explains how easily obtained version-control data lets you uncover the behavior and patterns of the development organization and manage technical debt. This language-neutral approach lets you prioritize the parts of your system that benefit the most from improvements so that you can balance short- and long-term goals guided by data. The specific examples are from real-world codebases like Android, the Linux Kernel, .Net Core Runtime and more. This new perspective on software development will change how you view code. Prioritizing technical debt is a difficult issue as modern systems have millions of lines of code and multiple development teams — no one has a holistic overview. In addition, there is always a trade-off between improving existing code versus adding new features, so we need to use our time wisely. What if we could mine the collective intelligence of all contributing programmers and start making decisions based on information from how the organization actually works with the code? Video producer: https://www.jfokus.com

The post Prioritizing Technical Debt first appeared on Scrum Agile Project Management Expert.

Technical Debt is not Technical

scrumexpert — Mon, 20 Nov 2017 16:29:28 +0000

Technical debt is not primarily caused by incompetent developers, architecture astronauts, unrealistic UX people or even stupid project managers. Rather, it is a third-order effect of poor communication. It is a symptom of an underlying lack of appropriate abstractions, which in turn stems from insufficient modeling of the problem domain. In order to avoid technical bankrupcy, therefore, we must improve the way we build our understanding of the problem we are trying to solve. Video producer: https://www.boosterconf.no/

The post Technical Debt is not Technical first appeared on Scrum Agile Project Management Expert.

Technical Debt Management Future

scrumexpert — Mon, 24 Oct 2016 14:39:55 +0000

Technical Debt is defined as the eventual consequences of poor or evolving software architecture and software development within a codebase. In a blog post published for the Software Engineering Institute (SEI), Robert Nord has provided the keys points discussed in a seminar Managing Technical Debt in Software Engineering, an event that discussed both the past and the future of managing technical debt. The International Workshop on Managing Technical Debt is organized every year since 2010. Robert Nord starts by describing the landscape of the technical debt issue, the visible and the invisible parts. The event tried to get a better definition of the core concepts of technical debt, producing a conceptual model. It produced also a vision on how to manage technical debt across different perspectives, like software economics or education. The conclusion of the author is that “The convergence of efforts on these multiple fronts is necessary to make software development technically and economically sustainable. Otherwise, the friction that slows down the machinery of software evolution will threaten the discipline’s ability to maintain the code base on which society depends.” Read the full blog post on https://insights.sei.cmu.edu/sei_blog/2016/08/the-future-of-managing-technical-debt.html

The post Technical Debt Management Future first appeared on Scrum Agile Project Management Expert.

Organizational Debt

scrumexpert — Thu, 14 Jan 2016 17:00:14 +0000

Technical debt is a well-known concept in Agile software development. Technical Debt is defined as the eventual consequences of poor or evolving software architecture and software development within a codebase. In this blog post, Steve Blank discusses the concept of organizational debt. He defines organizational debt as “all the people/culture compromises made to “just get it done” in the early stages of a startup.” He explains how companies need to recognize and refactor organizational debt. He gives the example of a growing startup that had no plans to retain early employees and train new one when it was facing a thought scaling challenge. Scaling the organization also imply that there could be a change in the current communication modes. The blog post proposes seven way to refactor the organizational debt of this company. His conclusion is that “failing to refactor organizational debt can kill a growing company”. The same problems happen for software development projects and organizations that try to scale. The initial developers and testers have accumulated some essential knowledge about the software architecture and features, a knowledge that is often located only in their brain as many Agile teams have minimal documentation requirements. The addition of new members to the project also requires some training time. A training effort that is often mainly done by current member of the project team. Read the complete blog post on http://steveblank.com/2015/05/19/organizational-debt-is-like-technical-debt-but-worse/

The post Organizational Debt first appeared on Scrum Agile Project Management Expert.