Agile teams create business value by delivering working softwares at regular intervals. While doing so, they make design trade-offs in order to satisfy business reasons such as meeting a release schedule. Technical debt is the result of such decisions or trade-offs. When this happens, agile teams need to repay the accumulated debt by improving designs during subsequent iterations in order to improve maintainability. This must happen in a systematic way, so that technical debt does not swell up to cause damage to the project. Accomplishing this is one of the major challenges in distributed agile projects. Through the four-quadrant model discussed in this blog (see Fig.1) I wish to share my views on technical debt management in distributed agile.
Figure 1 – Distributed Agile Teams and Technical Debt: The Four-Quadrant Model
Distributed agile teams or distributed Scrum teams are ‘aware’ when
These teams recognize technical debt instantaneously or during reviews and retrospectives. Teams that are ‘unaware’ neither have a common understanding on the meaning of technical debt nor are mindful about technical debt.
Distributed teams are ‘aligned’ when
On the contrary, distributed teams are ‘not aligned’ when they do not have a common understanding on how to organize and manage technical debt. They become reactive in repaying technical debt and eventually fail to deliver business value.
Aware and Aligned: Teams those are aware and aligned ensure positive results in managing technical debt. They can differentiate between trivial code quality issues and technical debt. They take informed decisions while accumulating as well as reducing technical debt. Even if one or more team members trigger technical debt by accident, the team recognizes it during reviews and retrospectives.
Unaware and Aligned: Teams that are unaware of the context or meaning of the term ‘technical debt’ may consider trivial issues or technical tasks as part of technical debt. This is because these teams will not have the ability to distinguish between a messy code and a design flaw. In this case, design trade-offs need not be the only triggering points to make additions to the list of items that constitute technical debt. Also, these teams do not know how to prioritize technical debt. When team members improve their awareness on technical debt, they will start delivering value by repaying technical debt.
Aware and Not Aligned: When agile teams do not have an organized approach towards accumulating and managing technical debt it is highly likely that they deliver messy and rigid software that is difficult to maintain. These teams know how and when they accumulate technical debt. However, because of their unorganized approach they tend to claim ‘lack of time’ as an excuse for releasing a product with technical debt. This is because there is no guarantee that they minimize technical debt systematically. This approach does not deliver value to project sponsors. In distributed agile projects, this situation may result in finger pointing or blame game.
Unaware and Not Aligned: Teams in this quadrant pose high risks and the reasons are obvious!
I am sure you relate this discussion to your experience of working with distributed agile teams. In order to manage technical debt, distributed agile teams need to be aware and aligned. They need to keep track of technical debt and know the value generated by repaying debt. Also, they must include user stories related to repaying some of the technical debt in future iterations so that technical debt dwindles over a period of time.
Do you have anything to add?