Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Distributed Agile: Teams and Technical Debt

Posted on: 07 October '11

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

  1. team members have a common understanding on the meaning of technical debt, and
  2. they are mindful about technical debt.

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

  1. they have a common understanding on how to organize and manage technical debt, and
  2. they repay technical debt in order to increase business value delivered to stakeholders.

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?

Mindtree Blog Archives

Mindtree blog Archives are a collection of blogs by various authors who have independently contributed as thought leaders in the past. We may or may not be in a position to get the authors to respond to your comments.