Like the great economists have mentioned "with every activity there comes a debt", same applies to IT projects and projects in other disciplines as well. With every project activity a certian kind of debt is always associated.
I personally compare technical debt analogous to the interest payment over a borrowed or spent capital. Its a debt realized due to poor project and engineering practices which sometimes can accumulate and turn out to be very hazardous for the project. It might also lead to project bankruptcy.
In this article I will try to explain you the kinds of technical debt, what causes a technical debt and steps required to minimize or resolve these kind of debts in your projects.
Technical debt can be classified into following categories:
Another kind of debt in known as Unavoidable debt, for example if a project being built uses a third party building block or component and later on if the vendor releases an update for the component which disrupts the usual flow of the project, such situations are very common and these kind of technical debt are unavoidable and can be foreseen upfront.
The third kind of debt is the Strategic debt, such kind of debts are usually time sensitive. For example a capital constrained organization might ask the project team to cut project and engineering practices to achieve timely go to market or if the project is running out of capital then it might downgrade the project to meet cost constraints. More specific example would be, suppose a project is running out of money and the organization decides to skip performance and load testing for a piece of software to save time and money. This might benefit the project short term but it comes with its own consequences later in the operations cycle of the project.
Consequence of a Technical Debt:
Technical debt comes with serious consequences impacting all aspects of the project from its performance to customer satisfaction and project economics. Some common consequences can be summarized like:
Atrophy is another very common consequence of high technical debt. If the product is delivered to the customer with high technical debt then it might loose its significance due to overspending and defects. This might force the customer to look out for new products or substitutes as soon as an opportunity hits them.
Now I would like to share you some common observed reasons that account to high technical debt in projects. Most common and frequently observed reason for different kinds of debt is the pressure to meet deadlines. Its very usual that during Agile projects the teams velocity might not remain consistent across sprint cycles. Their velocity might decrease due to unavoidable reasons and with decrease in velocity comes the fear of not meeting the deadlines. During such situations teams usually try to falsely accelerate the velocity to meet deadlines by cutting down the scope or engineering practices. For example if a team skips regression testing or performance quality compliance checks then such reductions are accounted as technical debt which might come to attention late in the life cycle.
I wonder few project teams intentionally cut down testing activities of their products to increase velocity but eventually land into a more compromising situation due to high technical debt. SCRUM encourages Test and behavior driven development TDD/BDD, which makes the development and testing to run parallel before the deliverable meets its definition of done. A strong definition of done reduces the technical debt rising due to engineering practices and recklessness.
Every project team should proactively manage technical debt in their projects. Any kind of technical debt can be managed by following these processes right from the beginning of the implementation phase.
Assume
1) Cost of development per month = 100K $ for a ten month project cycle
2) Project is running behind schedule and budget
3) No option for any scope cut as all features are minimum marketable requirements (MMR)
Now if the project was to be delivered on time then the actual cost of the project would come out to be 100k$ x 10 = 1 million dollar
But due to delays in the project the expected time for completion is say 13 moths. So the expected project cost turns out to be 13 * 10k$ = 1.3 million dollar.
Under this situation the management feel that a three month delay would lead to 300K $ loss in sales and decides not to overshoot the budget by another 0.3 million so they ask the team to cut the practices and testing to meet 10 month deadline. So in order to save 300K $ and 0.3 million they increase the technical debt.
Now suppose after three months of the release the technical debt incurred starts causing disruptions in the operations of the product and now the management decides to repay the technical debt and asks the team to estimate for the removal of potential disruptions in the product. Team estimates around 500K $ for removing the disruptions. Now if the management executes this repair cycle the total project cost might go above 1.5 million $ + Interest value + Other factors which might be way above if the technical debt was taken care right before release which could come out to be 1.3 million $ + 300K $ (Cost of sales).
So under economic analysis scenarios it becomes very important for teams to properly identify the cost and time value of the technical debt and decide on accepting the debt early or ignoring it for future. It becomes the core responsibility of the Product Owner and the Development team to account for technical debt at the right time with high priority to avoid an extra interest payment later.
I personally compare technical debt analogous to the interest payment over a borrowed or spent capital. Its a debt realized due to poor project and engineering practices which sometimes can accumulate and turn out to be very hazardous for the project. It might also lead to project bankruptcy.
In this article I will try to explain you the kinds of technical debt, what causes a technical debt and steps required to minimize or resolve these kind of debts in your projects.
Technical debt can be classified into following categories:
- Naive or Reckless debt
- Unavoidable debt
- Strategic debt
Another kind of debt in known as Unavoidable debt, for example if a project being built uses a third party building block or component and later on if the vendor releases an update for the component which disrupts the usual flow of the project, such situations are very common and these kind of technical debt are unavoidable and can be foreseen upfront.
The third kind of debt is the Strategic debt, such kind of debts are usually time sensitive. For example a capital constrained organization might ask the project team to cut project and engineering practices to achieve timely go to market or if the project is running out of capital then it might downgrade the project to meet cost constraints. More specific example would be, suppose a project is running out of money and the organization decides to skip performance and load testing for a piece of software to save time and money. This might benefit the project short term but it comes with its own consequences later in the operations cycle of the project.
Consequence of a Technical Debt:
Technical debt comes with serious consequences impacting all aspects of the project from its performance to customer satisfaction and project economics. Some common consequences can be summarized like:
- Increased time to delivery
- Significant known defects
- Rising development and support costs
- Decreased predictability
- Under performance
- Atrophy
- Frustration and decreased customer satisfaction
Atrophy is another very common consequence of high technical debt. If the product is delivered to the customer with high technical debt then it might loose its significance due to overspending and defects. This might force the customer to look out for new products or substitutes as soon as an opportunity hits them.
Now I would like to share you some common observed reasons that account to high technical debt in projects. Most common and frequently observed reason for different kinds of debt is the pressure to meet deadlines. Its very usual that during Agile projects the teams velocity might not remain consistent across sprint cycles. Their velocity might decrease due to unavoidable reasons and with decrease in velocity comes the fear of not meeting the deadlines. During such situations teams usually try to falsely accelerate the velocity to meet deadlines by cutting down the scope or engineering practices. For example if a team skips regression testing or performance quality compliance checks then such reductions are accounted as technical debt which might come to attention late in the life cycle.
I wonder few project teams intentionally cut down testing activities of their products to increase velocity but eventually land into a more compromising situation due to high technical debt. SCRUM encourages Test and behavior driven development TDD/BDD, which makes the development and testing to run parallel before the deliverable meets its definition of done. A strong definition of done reduces the technical debt rising due to engineering practices and recklessness.
Every project team should proactively manage technical debt in their projects. Any kind of technical debt can be managed by following these processes right from the beginning of the implementation phase.
- Managing the accruals of the debt
- Making the debt visible
- Repaying the debt
Assume
1) Cost of development per month = 100K $ for a ten month project cycle
2) Project is running behind schedule and budget
3) No option for any scope cut as all features are minimum marketable requirements (MMR)
Now if the project was to be delivered on time then the actual cost of the project would come out to be 100k$ x 10 = 1 million dollar
But due to delays in the project the expected time for completion is say 13 moths. So the expected project cost turns out to be 13 * 10k$ = 1.3 million dollar.
Under this situation the management feel that a three month delay would lead to 300K $ loss in sales and decides not to overshoot the budget by another 0.3 million so they ask the team to cut the practices and testing to meet 10 month deadline. So in order to save 300K $ and 0.3 million they increase the technical debt.
Now suppose after three months of the release the technical debt incurred starts causing disruptions in the operations of the product and now the management decides to repay the technical debt and asks the team to estimate for the removal of potential disruptions in the product. Team estimates around 500K $ for removing the disruptions. Now if the management executes this repair cycle the total project cost might go above 1.5 million $ + Interest value + Other factors which might be way above if the technical debt was taken care right before release which could come out to be 1.3 million $ + 300K $ (Cost of sales).
So under economic analysis scenarios it becomes very important for teams to properly identify the cost and time value of the technical debt and decide on accepting the debt early or ignoring it for future. It becomes the core responsibility of the Product Owner and the Development team to account for technical debt at the right time with high priority to avoid an extra interest payment later.
No comments:
Post a Comment