How do software development teams manage technical debt? – An empirical study

ContentslistsavailableatScienceDirect

The

Journal

of

Systems

and

Software

journalhomepage:www.elsevier.com/locate/jss

How

do

software

development

teams

manage

technical

debt?

– An

empirical

study

Jesse

Yli-Huumo

_,

_Andrey

_Maglyas

_,

_Kari

_Smolander

a_{Lappeenranta University of Technology, School of Business and Management, Department of Innovation and Software, PO Box 20, Skinnarilankatu 34,} Lappeenranta FI-53851, Finland

b_{Aalto University, School of Science, Department of Computer Science, P.O.Box 15400, FI-00076 Aalto, Finland}

a

r

t

i

c

l

e

i

n

f

o

Article history:

Received14May2015 Revised10December2015 Accepted10May2016 Availableonline11May2016

Keywords:

Technicaldebt

Technicaldebtmanagement Exploratorycasestudy

a

b

s

t

r

a

c

t

Technical debt(TD) isametaphorfor taking shortcutsorworkaroundsin technicaldecisions togain short-termbenefitintime-to-marketandearliersoftwarerelease.Inthisstudy,onelarge software de-velopmentorganizationisinvestigatedtogatherempiricalevidencerelatedtotheconceptoftechnical debtmanagement(TDM).Weusedtheexploratorycasestudymethodtocollectandanalyzeempirical datainthecaseorganizationbyinterviewingatotalof25personsineightsoftwaredevelopmentteams. WewereabletoidentifyteamswherethecurrentstrategyforTDMwasonlytofixTDwhennecessary, whenitstartedtocausetoomuchtroublefordevelopment.Wealsoidentifiedteamswherethe manage-menthadasystematicstrategytoidentify,measureandmonitorTDduringthedevelopmentprocess.It seemsthatTDMcanbeassociatedwithasimilarmaturityconceptassoftwaredevelopmentingeneral. Developmentteamsmayraisetheirmaturitybyincreasingtheirawarenessandapplyingmoreadvanced processes,techniquesand toolsinTDM.TDMisanessentialpartofsustainablesoftwaredevelopment, andcompanieshavetofindrightapproaches todealwithTDtoproducehealthysoftwarethatcanbe developedandmaintainedinthefuture.

© 2016TheAuthors.PublishedbyElsevierInc. ThisisanopenaccessarticleundertheCCBYlicense(http://creativecommons.org/licenses/by/4.0/).

1. Introduction

Technical debt (TD) is a metaphor used to describe a situa-tioninsoftwaredevelopment, wherea shortcutorworkaroundis used ina technicaldecision(Kruchten et al., 2012b ).TD hasalso similarities tothree aspects of financial debt:repayment, interest, andin some caseshigh cost(Allman, 2012 ). In software develop-ment, a shortcut or workaround can give the company a bene-fit in the short term with quicker release to the customer and an advantage in time-to-market over the competition (Kruchten et al., 2012a; Yli-Huumo et al., 2015a ). However, if these short-cutsandworkaroundsarenotrepaid,TDcanaccumulateandhurt theoverallqualityofthesoftwareandtheproductivityofthe de-velopment team in the long term (Zazworka et al., 2011b ). Cre-ating temporary solutions to the codebase increasescomplexity, whichmakes furtherdevelopmenthard andtime-consuming(Yli- Huumo et al., 2015a; Yli-Huumo et al., 2014 ).Asimplesolutionfor the problemwouldbe torepaythe knownTDbefore issuesstart

∗ _{Correspondingauthor.}

E-mail addresses: jesse.yli-huumo@lut.fi(J.Yli-Huumo),andrey.maglyas@lut.fi(A. Maglyas), kari.smolander@aalto.fi(K.Smolander).

toshow. However, thehighly competitivesoftware market forces companies to work in tight schedules and deadlines to release softwaretocustomersinfastercycles.Thiscreatesconstant pres-sureforthedevelopmentteamstodeliverworkingfeaturesto cus-tomers within the given deadlines. In addition, perfection as an objectiveisalsoa risk,becauseitmaycausedelaysandthatway frustrationto thecustomers,whomaythenselectother commer-cialalternatives.Therefore,itisimportanttoidentifyanddevelop processesforcompanies to livewithTD andtoknow how, what andwhen the TD should be repaid. Technical debt management (TDM) consistsof activities, processes, techniques,and toolsthat canbeusedtoidentify,measure,prevent,andreduceTDina soft-wareproduct.

TDand TDM receiveattentioncurrentlyboth in theacademia andthe industry (Li et al., 2015a ). Researchers andpractitioners are becoming moreinterestedin theconcept of TD andthe rea-sonswhyitshouldbeanessentialpartofdecision-makingin soft-waredevelopment(Falessi et al., 2014 ).The currentliterature has identifiedanddevelopedsometoolsandpracticestoconductTDM. However,accordingtoarecentmappingstudy,theproblemisthe lack ofempirical evidence aboutTDM in a real-life software de-velopmentenvironment(Li et al., 2015a ).Itisimportanttogather http://dx.doi.org/10.1016/j.jss.2016.05.018

evidenceaboutTDandTDMinreal-lifesoftwaredevelopment sit-uations to understand how TDM is currently perceived by real software development teams, and to use that knowledge to im-provetheexistingprocessesandtools.

In order to understand TDM in a real-life software develop-mentenvironment,we studiedeightsoftwaredevelopmentteams ina largeorganization thatisa providerofmultiplesoftware so-lutions.For data collectionand analysis, we used the eight TDM activities identified by Li et al. (2015a) in semi-structured inter-viewstogatherempiricaldataaboutTDMintheselectedsoftware developmentteams.We used the exploratorycasestudy method (Robson, 2002 )toanswerthefollowingmainresearchquestion:

RQ: “How do software development teams manage technical debt?”

Since the main research question can be considered quite a widetopic, includingseveralother topics,wedecided tocreatea setofsubquestionstotacklespecifictopicsofourinterest.

RQ1.1: What TDM activities areused in thestudied development teams?

Technical debt management can be separatedintothe follow-ingactivities:identification,measurement, prioritization, prevention, monitoring,repayment,representation/documentation,and communi-cation(Li et al., 2015a ). However, it isnot certain what activities areactuallyusedandtakenintoconsiderationinreal-lifesoftware development. Therefore, it is importantto study andunderstand whichTDMactivitiesarecurrentlyapplied/usedandwhicharenot. The results obtained from the studied development teams could revealwhichactivitieswillneedmoreresearchinthefuture.

RQ1.2:Whatmethods,models,practicesortoolsdothestudied de-velopmentteamsuseforeachTDMactivity?

There are a numberofpossible methods,models, practices or toolsforeveryTDM activity(Li et al., 2015a ).Theyhavebeen de-velopedandsuggestedintheliterature,buttheylackempirical ev-idenceoftheirusabilityandfunctionality(ibid.).Therefore,itis es-sentialtogather empiricalevidencefromreal-lifesoftware devel-opmentto understandwhat approachesdifferent software devel-opmentteamsuseforeachTDMactivity.Collectingsuch evidence could helpto evaluate which TDM approachesshould be catego-rizedtoeachTDMactivity.

RQ1.3:ArethereanymaturitydifferencesinadoptingTDM activi-tiesbetweendevelopmentteams?

Every software development team is different, working with different products in different environments, and using different methods, models, practices, and tools in their unique way. It is highlypossiblethat softwaredevelopmentteams ingeneral have differentactivitiesandapproachesasregardsTDM.Somesoftware developmentteams mayusemoretimeon TDM,whilesome de-velopmentteamsmaynotpaymuchattentiontoit(Power, 2013 ). Therefore, it is important to understand if it is possible to dis-tinguishbetween differentmaturities ofTDM, similarly asinthe capability maturity model (CMM)(Paulk et al., 1993 ). The results of this study can be used to develop a similar maturity model for TDM, which researchers and practitioners could use to con-ductmoreresearch,ortoimprovecompanies’internalandexternal practices.

RQ1.4:WhatarethebiggestchallengesinTDM?

Softwareprocessimprovementincludesthechallengeof adopt-ingnewpracticesandtoolstodevelopmentteams.Understanding thischallenge inrelationto TDMisbeneficial forsoftware devel-opmentteamsandresearchers.

The restofthe paperisorganizedasfollows: Section 2 intro-ducesthe theoreticalbackground ofTDandTDM insoftware de-velopment,Section 3 describestheresearch methodologyused in thisstudy, andSection 4 presents the results received fromthe empiricalanalysisofthe studied softwaredevelopmentteams.In Section 5 presentthedevelopedframework. In Section 6 we

dis-cusstheresultsandimplicationstofutureresearch.Section 7 con-cludesthepaper.

2. Background

2.1. Technicaldebt

Themetaphortechnicaldebt(TD)hasbeenintroducedbyWard Cunningham (Cunningham, 1992 ). He describes the metaphor as

‘Shipping firsttime code is likegoing intodebt. A little debt speeds development solongasitis paidback promptlywitha rewrite. Ob-jects make thecost of this transactiontolerable. The dangeroccurs when the debt is not repaid. Every minute spent on not-quite-right codecountsasinterestonthatdebt.”(op.cit.,p.29-30).Eventhough the metaphor was first introduced over twenty years ago, a re-cent mapping study shows that it has received the attention of researchersandpractitioners onlyinthepast fewyears(Li et al., 2015a ).

TheTDmetaphorwasfirstassociatedwithcompromisesonthe codelevelofsoftware(Cunningham, 1992 ).Inaddition,termslike

code smells (Fowler et al., 1999 ) have describedsituations where poortechnicalchoicesinsoftwaredevelopmenthavecaused prob-lems in code quality and architectural soundness. However, the TD metaphorhas beenrapidlyexpanded afterthe initial concept on the code level, and it has been associated with other stages of the software developmentlifecycle aswell (Tom et al., 2013; Alves et al., 2014 ). The current literature identifies such terms as requirements (Brown et al., 2010 ), design (Zazworka et al., 2011b; Zazworka et al., 2011a ), architectural (Nord et al., 2012 ), test(Brown et al., 2010 ),process(Lim et al., 2012 ),documentation (Kruchten et al., 2012a ), andpeople debt(Kruchten et al., 2012b ) todemonstratethesameeffectofshortcuts orworkarounds hap-peningintheotherstagesofthesoftwaredevelopmentlifecycle.

Shortcuts and workarounds in software development usually happenforintentionalreasons,suchasforbusinessdeadlinesand developmentcomplexity(Yli-Huumo et al., 2015a ).Time-to-market andcustomer feedback are importantfactors forcompanies’ suc-cess, and it is essential to deliver solutions on time (Lim et al., 2012 ).Thisisthereasonwhybusinessstakeholdersareoftenmore focusedondeadlinesandcustomersthantheactualqualityofthe software, which is more in the developers’ interest area (Barney et al., 2008; Boehm, 2006 ).Therefore,strict deadlinesmay some-timesforcethedevelopmentteamtocreatesolutionswith second-tierquality tomeetthe requirementswithinthe deadlinesset by thebusinessstakeholders(Yli-Huumo et al., 2014 ).WhenTDstarts toaccumulate,itisoftenasaferandfasterchoicetotakemoreTD witha quickanddirtysolution, becausethere isa risk of break-ing the product even more by modifying a complex part of the code base (Yli-Huumo et al., 2015a ). Thus, code base complexity canforcethecompanytotake moreTD intentionally,becausethe fixingofcurrentTDwouldtaketoomuchtimeandmoney,while quickanddirtysolutionsare easierandfastertoimplement(Yli- Huumo et al., 2014 ).

TD canalso occur unintentionally(McConnell, 2007 ). The rea-son for unintentional TD can be lack of competence, a need to upgrade existing technologies, or a customer or market -induced needforchange.Acodermaylackcompetencetodevelopan opti-malsolution.Adevelopmentteammaynotbeabletoprovide ad-equateinstructions andcodingstandardsfordevelopment, which reduces the quality of the solution. In legacy software, the old technologythatisstillinusecanalsobeseenasunintentionalTD. In thesesituations, a company sometimes hasto start upgrading thetechnologytoanewerversion.Itisalsopossiblethatchanges comingfromthemarket oracustomer canturntheeffortofthe developmentteamtoanewdirection.Thismeansthat previously developed parts need to be changed to make the product more

”We don’t have me

for design”

”We must ship now

and deal with

consequences”

”What’s layering?”

”Now we know how

we should have done

it”

Reckless

Prudent

et

ar

e

bil

e

D

t

n

et

r

e

v

d

a

nI

Fig.1. Technicaldebtquadrant(Fowler,2009).

suitable forthechangingbusinessneeds.Fig. 1 showsaTD quad-rant(Fowler, 2009 )that identifiesfourcategoriesofhavingTDfor intentionalandunintentionalreasons(McConnell, 2007 ).

TD isoftenseen onlyasanegativeconceptinsoftware devel-opment (Lim et al., 2012;Yli-Huumo et al., 2014 ). Software devel-opersthinkthatcreatingshortcutsandnon-scalablesolutionswill increase the complexity within the code base (Yli-Huumo et al., 2014 ).WhenthecodebasestartstoaccumulatewithtoomuchTD thatisnotfixedafterwards,thedevelopmentbecomesmore chal-lenging,becausetheshortcutsarenotdesignedtoworkwell with otherpartsofthecodebase.Complexitiesinthecodebasestartto reduce theoverall qualityandproductivitygoesdownwhen new solutions andfeatures must be implementedto the codebasein debt(Yli-Huumo et al., 2015a ).

Taking TDisneveran optimalsolution,andcompanies should avoid it when possible. However, actions that lead to TD can be beneficial to software companies, and in that sense TD can be seen only as a negative side effect. When taking TD, companies are able to speed up the release cycles to the customer, which can increase customer satisfaction and provide advantage in the market. Anotherbenefitforcompanies iscustomer feedback(Yli- Huumo et al., 2015b ). Companies are able to adjust the product and its business model based on faster customer feedback. This waythecompaniescan identifyandprevent bothintentionaland unintentional TD more efficiently, when customer feedback pro-videsknowledgeaboutthemostimportantdevelopmentneedsin the software(ibid.). Therefore,while TD inthe software isnever a benefit,actions thatincurTD intosoftwarecanbe beneficialto asoftwarecompanyintermsofacquiringbusinessadvantageand knowledgeofcustomerandbusinessneeds.

Overall, the current conceptualizations of TD vary, and there is no clear, common definition. According to some scholars, TD shouldbe associatedonlywithintentionaldecisionshappeningin thecodebase,andmessycodeshouldnotbecountedasTD,while somethinkthatoldtechnologiesinlegacysoftwareshouldalsobe countedasTD(Norton, 20 09; Fowler, 20 09 ).Theadditionof mul-tiple terms relatedto shortcuts happeningin other stages ofthe life cycle of software developmentalso confuses the concept. In thisstudywe focuson TDrelatedto abadly structured architec-ture/code (“smelly code”) anda code that violates coding guide-lines. Even though concepts such associal debt (Tamburri et al., 2013 ) and people debt (Alves et al., 2014 ) describe similar phe-nomenaofhavingshortcutsandnon-optimalsolutionsinsoftware

developmentandorganization,webelievethattheyshouldbe cat-egorizedassourcesforTDratherthanasactualTD.Therefore,the definitionofTDweuseinthisstudyisthefollowing:

“Abadlystructuredtechnicalsolutionorarchitecturaldesignin thesystem,incurredbyeitheranintentionaldecisionoran un-intentionalside effect,which causes omitted quality and pro-ductivity”

Our goal is to understand how software development teams manageintentionaltechnicaldecisionswhenmakingcompromises insoftwaredevelopment.WealsobelievethatunintentionalTDis anessentialpartofsoftwaredevelopment.Ouraimisalsoto iden-tifyhowdevelopmentteamstrytopreventandreduceboth inten-tionalTDandunintentionalTD.

2.2.Technicaldebtmanagement

Technical debt management (TDM) is conducted to manage, prevent,measure andreduce technicaldebt(TD) duringsoftware development. TDM includes processes, techniques and tools that are used in software development. The current literature related to TDM has identified and developed some processes and tools (Li et al., 2015a ).Managingtechnicaldebt(MTD) workshopshave gatheredmultiplestudiesrelatedtoTDandTDMinthepastyears (Seaman et al., 2015 ).However,TDM ischallengingtoimplement, andit ishardformanagersanddeveloperstoestimate and iden-tifywhat andhow muchTD the currentsystemhas,how it will change,andwhateffectsitwillhaveinthefuture(Li et al., 2015a ). Power (2013) identifies seven main challengessurrounding TDM: (1)agreeingwhattechnicaldebtis;(2)quantifyingtechnicaldebt; (3)visualizingtechnicaldebt;(4)trackingtechnicaldebtovertime; (5)impactofneglecting technicaldebtovermultiplereleases;(6) identifyingtechnical debtasa rootcause ofdefects; and(7) un-derstandingthecostofdelay.

ThereductionandrepaymentofTDaredone byrefactoringor rewriting thebad solutions (Codabux and Williams, 2013 ). Refac-toringorrewritingcan beseenasprocessesfor“changinga soft-waresysteminsuch awaythatitdoesnotaltertheexternal be-haviorofthecodeyetimprovesitsinternalstructure.Itisa disci-plinedwaytocleanup codethatminimizesthechancesof intro-ducingbugs.Inessencewhenyourefactoryouare improvingthe designofthecodeafter ithasbeenwritten” (Fowler et al., 1999 , p.9).However,changingoldsolutionsinthecodeisnoteasy, be-causeimprovingthecode baserequiresa significantlycompetent developer,andthecompany cannotjustusealldevelopmenttime on refactoringor rewriting the solutions. Therefore,having some assistingapproachestoknowwhenandwhatrefactoringisneeded canbeusefulfordevelopmentteams.

Aportfolioapproach forTDMhasbeen suggestedbyGuo and Seaman (2011) .Theapproachiswidelyusedinthefinancedomain asa risk reduction strategy forinvestors, todetermine the types andamountsofassetstobeinvestedordivested.Thecore compo-nentoftheproposedapproachisa“technicaldebtlist” (ibid.).The listcontains TD “items”,each ofwhich represents an incomplete taskthatmaycauseproblemsinthefuture.Portfoliomanagement could be adapted to manage TD, wherethe company would col-lectalltheTDitemstoa listanduseittoreduce TDandto con-duct refactoring systematically. Li et al. (2015b) have also devel-oped similar TD list management for architecturaltechnical debt (ATD).

UnintentionalTDcausedbychangesinthecustomerormarket can be harder to manage andpredict, because the development teamcannotnecessarilyknowtheseTDsinadvance.However,the currentliteraturehasidentifiedsomepracticestoprevent uninten-tionalTD.Implementingcodingstandardstothedevelopment pro-cesscanpreventTD,whenthedevelopershaveacohesivewayto

producea similar style code,which makes it readable and mod-ifiable (Green and Ledgard, 2011 ). Code reviews can be used to checkother developers’solutionsbeforethe releasetocatch pos-sibleTDissues inthedesign (Mantyla and Lassenius, 2009 ). Also simplepracticesin agilemethodologies, such astheDefinition of Donepractice can reduce TD in theearly stagesof development (Davis, 2013 ).

An extensive mapping study of 49 primary studies has been recentlyconductedbyLi et al. (2015a) tounderstandthe current state of the art on TDM. The study identifies eight activities for TDM:(1)identificationdetects TDcaused byintentionalor unin-tentionaltechnicaldecisionsinasoftwaresystemthroughspecific techniques,such asstaticcode analysis;(2)measurement quanti-fiesthebenefitandcostofknownTDinasoftwaresystemthrough estimationtechniques,orestimatesthe levelof theoverall TD in asystem;(3)prioritization ranksidentifyTD accordingtocertain predefinedrulestosupportdecidingwhichTDitemsshouldbe re-paidfirstandwhichTDitemscanbetolerateduntillaterreleases; (4)preventionaims toprevent potential TDfrombeingincurred; (5)monitoringwatchesthechangesofthecostandbenefitof un-resolvedTDovertime;(6)repaymentresolvesormitigatesTDina softwaresystembytechniquessuchasreengineeringand refactor-ing;(7)representation/documentationprovidesawaytorepresent andcodify TD in a uniform manner, addressing the concerns of particular stakeholders; and (8) communicationmakes identified TDvisibletostakeholderssothatitcanbediscussedandmanaged further.

Overall,thecurrentunderstandingofTDMincludessomeideas forprocesses,techniquesandtoolstomanageTD.Eventhoughthe currentliteraturehasstartedtotackleandidentifytheconceptand solutions of TDM, the problem is that there is a need for more empiricalevidence fromreal-life software development(Li et al., 2015a ).

2.3.Empiricalstudiesontechnicaldebtmanagementinpractice

There arefew empiricalstudiesonTDM. Guo et al. (2011) use aspecificTDMframeworktotrackdownonedelayedmaintenance taskinareal softwareproject.TheirTDM framework startsfrom theidentificationofaTDitem, whichthenwillbeaddedtoaTD list.After this, theTD itemgets measured basedontheprincipal andinterest,which arebased onestimates. Then,the TD item is readyforprioritizationbasedoncostandbenefit.Withthis frame-work,theauthors havebeenableto trackdownandquantifyTD items, and see the costs of delaying maintenance tasks. A simi-larapproach hasalso been used by other researchers to identify anddocument TD issues in order to make TD easier to manage (Zazworka et al., 2013 ).

Klinger et al. (2011) interviewedfourexperienced software ar-chitects to understand how decision-making regarding TD was conductedin anenterprise environment.The resultsshowedthat thedecisionsrelatedtoTDissueswereofteninformalandadhoc, whichledtoa lackoftrackingandquantifyingthe decisionsand issues.Thestudyalsoidentifiedthatthere wasa large communi-cationgapbetweentechnicalandbusinesspeople asregards dis-cussionaboutTD.

Different tools have been developed for TDM. The SQALE method (Letouzey, 2012 ; Letouzey and Ilkiewicz, 2012 ) has been developed for the purposes of identifying, estimating, analyz-ing, measuring, and monitoring TD in a software. DebtFlag (Holvitie and Leppänen, 2013 )hasbeendevelopedtocapture,track andresolve TD insoftware projects. The SonarQube tool andits pluginshavebeenappliedinseveralstudiestoidentifyand mea-sureTDfromsoftware(Al Mamun et al., 2014; Griffith et al., 2014 ). AsetofothertoolstosupportTDmanagementwere identifiedin themappingstudybyLi et al. (2015a) .

MostoftheempiricalstudiesofTDMtakeinconsiderationonly fewaspectsoftheeightTDMactivities(Li et al., 2015a ).Aspecific tool toidentifyandmeasureTD doesnothelp inother activities, such ascommunicationorprioritization. Thereis aclearneed to knowhowTDshouldbemanagedfromtheorganizationalpointof view.ThemappingstudybyLi et al. (2015a) foundalargenumber ofdifferentmodels,methods,practices,andtoolsintheliterature foreach separate TDM activity. However, there isno single solu-tionthattakesthewholeproblemofTDMintoaccount.Therefore, a framework ormodel forTDM that combinesall TDM activities isneeded,bothbyresearchersandpractitioners,tounderstandall theaspectsofTDM.

3. Researchprocess

3.1. Researchmethodology

This study is qualitative, and it uses case study as the re-search methodology. Thedefinitionby Yin describesacasestudy as‘anempiricalinquirythatinvestigatesacontemporaryphenomenon within its real-life context, especially when the boundaries between phenomenonandcontextarenot clearlyevident’ (Yin, 2003 ,p.13). As a research strategy, case study is used to contribute to our knowledgeofindividual,group,organizational,social,political,and relatedphenomena(ibid.).Therefore,casestudyhasbeena com-monresearch methodologyespeciallyin socialsciences.However, the case study methodology has also been used in economics (ibid.), andit has become morepopular in software engineering aswell(Runeson and Höst, 2008 ).

Softwaredevelopmentiscarriedoutbyindividuals,groupsand organizations, and therefore social and political questions are of importanceforsoftwaredevelopment,whichmakessoftware engi-neeringamultidisciplinaryareawherecasestudyisarelevant ap-proach(Runeson and Höst, 2008 ).Therearemultiplewaystostudy TDinsoftwareengineering.Theresearch caninvestigatethe writ-tencodeitself,where thefocusison understandinghowa badly structuredcodeaffectstheotherpartsofthesoftware.Thistypeof research can be done withquantitative research methods, where theresultsshowmeasurements onhowforexampleperformance orotherqualityattributeschangedependingondifferentstructural possibilitiesinthecodebase.ItisalsopossibletostudyTDfrom theorganizationalpointofview.InanorganizationalTDstudythe researchfocusesonhowvarious processesandpractices areused insoftware-relatedTD.Thistypeofastudycanbeperformedwith qualitative methods,whichcan,forexample,produceresults that show howpeopleandprocesses affectthe existenceofTD inthe software.

Sincetheaimofthisstudyisto understandhowsoftware de-velopment teams conduct TDM to control and reduce TD, rather than what are the best possible code structures or architectural solutions, we believe that the case studymethodology is an ef-fective approach to understanding how people withdifferent re-sponsibilitiesworking together insoftware developmenthave or-ganized TDM. The case study methodology makes it possible to examinetheconceptofTDMinreal-lifesituations,togather qual-itativedata,andtoaddtoexistingresearchrelatedtoTDM.

This studycan be defined asan interpretive exploratorycase study(Robson, 2002 ), asthegoalofthestudyistodiscoverhow softwaredevelopmentteams haveorganizedTDM,without a pri-orihypotheses.Thepurposeofanexploratorycasestudyistofind outwhatishappening,seekingnewinsightsandgeneratingideas andhypothesesfornewresearch(ibid.).Inaddition,aninterpretive casestudyaimsatunderstandingphenomenathroughthe partici-pants’interpretationoftheircontext(Runeson and Höst, 2008 ).

We decided to use the guidelines provided by Runeson and Höst (2008) to conduct the case study process. The case study

Design and development of data collecon protocol Conduct case A Conduct case B First results publicaon First round data analysis Conduct case C Conduct case D Conduct case E Conduct case F Conduct case G Conduct case H Improvement of data collecon protocol / Selecon of round two companies Second round data analysis, Cross-case analysis, conclusions Final results Appendix 1. (Yli-Huumo et al. 2014) Appendix 2. 2 teams, 11 interviews, 12 persons, 342 minutes 6 teams, 6 interviews, 14 persons, 285 minutes Case study design / Selecon of round one companies

Step 1 Step 2 Step 3 Step 4 Step 5 Step 1-2 Step 3 Step 4 Step 5 Steps of case study process (Runeson & Höst, 2008)

Fig.2. Casestudyresearchprocessusedinthisstudy.

process isdivided intofivemain steps:(1)case studydesign: ob-jectivesare definedandthecasestudyisplanned;(2)preparation fordatacollection:proceduresandprotocolsfordatacollectionare defined; (3)collecting evidence: executionwithdata collectionon the studied case; (4) analysis of collected data; and (5) reporting

(ibid).Fig. 2 showstheresearch processused inthestudy,based on guidelines by Runeson and Höst (ibid.). The steps of the re-search processare discussedandexplainedincloserdetailinthe followingsubchapters.

3.2. Casestudydesignandcompanyselection

The design step of the casestudy process should contain the followingelements:objective,thecase,theory,researchquestions, methods,andselectionstrategy(Runeson and Höst, 2008; Robson, 2002 ). The design anddevelopmentof the datacollection proto-col wasstartedby examiningthe currentliteraturerelatedto TD andTDM. On thebasis of the literature,we designed and devel-opedasetofquestionsandtopicsfordiscussiontounderstandthe reasons,effectsandmanagementrelatedtoTD.Wedecided to or-ganizetheinterviewsintwoseparate rounds.Thereasonfor con-ductingtheinterviewsintwo rounds wasthat wewanted to un-derstandtheconceptofTDMfirstthroughasmallernumberof de-velopmentteamstobeabletoadjusttheinterviewsforthesecond round cases. Thisapproach is similar to the theoretical sampling used in thegrounded theory method (Strauss and Corbin, 1998 ), wherethenext datasampleischosenonthe basisofan analysis ofaprevioussample,creatinganiterativeprocessfortheory con-struction.Inthiscase,we wantedto beableto modifyour ques-tionsandtopicsbasedonthedatareceivedfromthefirstroundof interviews.

We decided to use semi-structured interviews (Charmaz, 2014 ) for data collection, which makes this research a flexible study (Runeson and Höst, 2008 ). Semi-structured interviews include a mixture of open-ended and specific questions, designed to elicit not only the information foreseen, butalso unexpected types of information(Seaman, 1999 ).We thoughtthat semi-structured in-terviewswouldprovideuswithgoodresults,sincetheterm ‘tech-nicaldebt’mightbe unfamiliar tothe interviewees,andalso tak-inginconsiderationthecomplexityinitsdefinition,itwas impor-tanttoexplainitcarefullytocreatesimilarunderstandingbetween theinterviewerandtheinterviewee.Inaddition,itwasimportant to introduce all the aspects of TDM activities in the interviews, as it was highly possible that the interviewees would not have knowledgeontheirdefinition.Thus,theuseofsemi-structured in-terviewswould makeit possibleforus totalkwith the intervie-weesfacetoface,andinacaseofmisunderstanding,wewouldbe abletoexplainthequestionsmorepreciselyandaskmorespecific follow-upquestionstoidentifyanswersto theresearchquestions. Apotential drawback ofusing semi-structuredinterviews can be thetrustworthinessoftheanswers.However,webelievethatthere wasnoissuewiththetrustworthinessoftheanswers,sinceallthe developmentteams in this study hadexpressed their interest in developingTDMintheirorganizations.

As ourgoal wasto study TDM activities and their maturities, andwealso assumedthat theTDM activities wouldbe used dif-ferently in teams within an organization, we decided to use the multiple-casestudyapproach.Yin (2003) separatescasestudiesto

holisticcasestudiesandembeddedcasestudies.Inholisticcase stud-iesthecaseisstudiedasawhole,whileinembeddedcasestudies multipleunitsofanalysisarestudiedwithinasinglecase.This re-searchfulfillsthecharacteristicsofaholisticcasestudy,asourgoal wastostudyeachdevelopmentteamasawholetounderstandthe

Table1

Summaryofthecasesoftwaredevelopmentteams.

Team Roleoftheteamintheorganization Description

A Developmentofasingleproductline. Theproductprovidesafinancialmanagementsolutionasacloudservice.Thecurrentsizeof theteamis18.Thewholedevelopmentteamislocatedinthesamecountry.Thedevelopment teamusesaScrum-likeapproachasthedevelopmentmethodology.

B Developmentofasingleproductline. TheproductisaSaaS-basedprojectmanagementsolutionformulti-organizationprojects.The currentteamsizeis13,andthewholedevelopmentteamislocatedinthesamecountry.The developmentteamusesaScrum-likeapproachasthedevelopmentmethodology.

C Developmentofaplatforminfrastructure. Theplatforminfrastructureisusedbytheotherdevelopmentteamsthatdeveloptheactual productsforcustomers.Thegoalofthedevelopmentteamistobeagatewaybetweenallthe productsandintegrationswithinandoutsidetheorganization.Thecurrentteamsizeis12, andthedevelopmentisdistributedintoseveralcountriesinEurope.Asthedevelopmentteam workswithotherproductlinesintheorganization,itusesScrumandKanbaninparallel. D Licenseintegrations Thedevelopmentteamhastwomainresponsibilities:(1)licensingandgeneratingtheinvoices

basedontheusage,andgrantingtherightsandaccountingtheusagesfortheservicesthe customershavebought,and(2)integrationofallthesmallersystemsthathavebeenbought bythecompany.Thecurrentteamsizeis11,andthedevelopmentisdistributedintoseveral countriesinEurope.Asthedevelopmentteamworkswithotherproductlinesinthe organization,itusesScrumandKanbaninparallel.Thedevelopmentteamalsoworksclosely withdevelopmentteamC.

E Developmentofservicesandsoftwareforthe organization.

Themainresponsibilityofthedevelopmentteamisaplatformfromwhichalltheservicesof macrosegmentsarestartedandadministrated.Thecurrentteamsizeis12.Thedevelopment isalsodistributedintoseveralcountriesinEurope.ThedevelopmentteamusesaScrum-like approachasthedevelopmentmethodology.

F Developmentofasingleproductlineinthe organization.

Theproductisaweb-basedsolutionthatallowsapprovinginvoicesandexpenseclaimsonline ormobile.Thecurrentteamsizeis8,andthewholeteamislocatedinthesamecountry.The developmentteamusesaScrum-likeapproachasthedevelopmentmethodology.

G Developmentofasingleproductline. Theproductisaweb-basedsolutionformakingbudgetingandforecastingpredictionsfor businessmonitoringandreporting.Thesoftwarecollectsinformationonthecompany’s financialrecordsandothersystems,aswellastheformofreal-timereports.Thecurrentteam sizeis8,andthedevelopmentisdistributedintoseveralcountriesinEurope.The

developmentteamusesaScrum-likeapproachasthedevelopmentmethodology. H Developingintegrationandsecuritytasksforthe

organization.

Themaingoalofthedevelopmentteamistohandleintegrationandsecuritytasksforthe organization.Thecurrentteamsizeis17,andthedevelopmentisdistributedintoseveral countriesinEurope.ThedevelopmentteamusesScrumasthedevelopmentmethodology.

processrelatedtoTDM, insteadofstudyingmultipleunitswithin onedevelopmentteam.Thereasonforstudyingmultiplesoftware developmentteamsoveronesingleteamwasgatheringabroader amount of empirical data related to the research topic. We be-lievedthatstudyingseveraldevelopmentteamswouldprovideus withmoreinformationrelatedtoTDM,andcomparingtheresults wouldhelp usunderstandwhat approacheswere the most com-monlyusedonesandwhy.

The selected case company is a large software supplier with around5600employees,currentlyoperatinginmultiplecountries in Europe. The company is a supplier of business software and business process solutions, outsourcing services, commerce solu-tions, and IT consultancy. It has currently about 340,000 cus-tomers. Westudied eightsoftware developmentteams inthe or-ganization. A summary of the software development teams and theirrolesintheorganizationispresentedinTable 1 .Weselected thecasecompanybecauseitssize,numberofteams,andindustry area,whichmadeitverysuitableforstudyingTDandits manage-ment. In addition, even though all the development teams were fromthe same organization, mostof them were not workingon thesameproduct.Instead,mostoftheteamshadtheirown prod-uctindevelopmentandaseparate management,originatingfrom thecompany’s history of mergersand acquisitions.The company combines severalproduct lines andincludes teams coming from differentbackgroundsandcultures,butcurrentlysharingthesame organization.Therefore,weconsideredthecompanytobeoptimal forstudyingTDMactivitiesindevelopmentteams.

3.3.Datacollection

The semi-structuredinterviewswere conductedintwo rounds betweenFebruary2014 andApril 2015.The first roundwithtwo developmentteamslocatedinFinland(CasesAandB)wasstarted

in February 2014, and it lasted until April 2014. We started the interviews by contacting the manager of the team. The manager ofteamAgave usalso areferralto themanagerin development team B.We conducted thefirst two interviews withthe product line managers of teams A and B. After that we used the snow-balling technique (Charmaz, 2014 ) to get referrals to other per-sons in the teams. As both development teams were located in Finland,we were ableto travelphysically tothe officesand con-ductalltheinterviewsfacetoface.Thetotalnumberofinterviews wasfiveindevelopmentteamAandseven indevelopmentteam B. In one of the interviews in team B (Interview ID B3), we in-terviewedtwopersonsatthesametimebecauseofschedule con-straints. Theinterview sheetforthe first roundinterviews is en-closedinAppendix A .

Thesecond roundstartedinMarch2015andlasteduntilApril 2015.Before startingthe interviews,we decidedtomake changes to the interview structure for two reasons. The first reasonwas thatthedatagatheredandanalyzedinthepreviousroundgaveus newideasfortheinterviewsregardingTDM.Inthefirstround in-terviewswe identified alackofTDM activities,which gaveusan ideaoffocusingmoreonTDM.Intheprevious interviews,the fo-cuswasalsoontheeffectsandcausesofTD.Theanalysisofcauses and effects of TD is available as a separate publication by Yli- Huumo et al. (2014) .ThesecondreasonforfocusingmoreonTDM wasthepublicationoftheTDMmappingstudybyLi et al. (2015a) . ThemappingstudyidentifiedeightTDM activities,whichwe con-sideredasagoodbasiccorefortheinquiryonTDM.Theresultsof themappingstudygaveusnewideasforimprovingtheinterview structure moretowards TDMactivities. The updated structurefor thesecondroundinterviewsisshowninAppendix B .

Thesecondroundconsistedofsixsoftwaredevelopmentteams located in various countries in Europe. The team manager of development team A gave us new referrals, which we used to

Table2

Rolesoftheinterviewees.

InterviewID. Round Team Role(s) Experienceinthe organization A1 1 A Softwarearchitect 6years A2 1 A Softwaredesigner 1year A3 1 A Projectmanager 4years A4 1 A Softwaretestengineer 1year A5 1 A Productlinemanager 14years B1 1 B Softwarearchitect 6years B2 1 B Softwaredeveloper 6years B3a 1 B Productlinemanager 2years B3b 1 B Softwaretestengineer 4years B4 1 B Softwarearchitect 5years B5 1 B Softwaredeveloper 1year B6 1 B Userinterfacedesigner 1year C1a 2 C Teammanager 5years C1b 2 C Softwarearchitect 17years C1c 2 C Softwarearchitect 3years D1 2 D Softwarearchitect 7years E1a 2 E Teammanager 15years E1b 2 E Softwarearchitect 8years E1c 2 E Softwarearchitect 5years F1a 2 F Teammanager 4years F1b 2 F Softwarearchitect 9years G1a 2 G Teammanager 1year G1b 2 G Softwarearchitect 4years H1a 2 H Teammanager 3years H2b 2 H Softwarearchitect 3years

contacttheothersixdevelopmentteams.Becausetheteamswere not located in Finland, we had to change the interview method from face-to-faceinterviews to onlinevideo calls. The interviews also changed from singleperson interviews to two-three person interviews.Thiswasrequiredbecausethetimeallowedforuswas limited.Theintervieweeswereusuallyoneteammanagerandone software architect discussingthe approaches toTDM. The risk of interviewingtwo ormorepeopleatthesametimeisthat the in-tervieweeswouldnotnecessarilybeabletospeakopenlybecause ofthepresenceofanotherinterviewee.However,we noticed dur-ing theinterviews that thiswasnotthe case, andall thesix de-velopment teamswere eagerto talkabouttheproblemswithTD andTDM,andwantedtofindpossiblesolutionsforimprovements. Inaddition,wenoticedthat allthesoftwarearchitectshad multi-pleyearsofexperiencewiththesoftwareproduct,whichwas ap-preciatedbytheprojectmanagersinvolved.Therefore,we believe that theinterviewswerenot disturbedbyhavingmultiplepeople presentat thesame time. Instead,we believe that the qualityof theinterviewswasimproved,sincetherewasacommongoalfrom bothbusinessandtechnicalperspectivetounderstandandimprove TDM.TherolesoftheintervieweesareshowninTable 2 .Whenthe interviewengagedmorethanoneperson,thisisreferredtointhe interviewIDasE1a,E1betc.

3.4. Datacodingandanalysis

In exploratory case studies, the technique for the analysis of qualitativedataishypothesisgeneration(Seaman, 1999 ).Aswedid nothaveanypriorihypothesesforthisstudy,ourgoalwastouse the techniquesfordatacoding andanalysisofqualitative datato findhypothesesfromthecollecteddataandinterviews.The tech-niques fordataanalysisused inexploratorycasestudiesare con-stantcomparisonsandcross-caseanalysis(Seaman, 1999 ).

Fig. 3 givesan overview ofthe data coding andanalysis pro-cessesconductedinthisstudy.Thedatacodingandanalysiswere completedinvarioussteps,guidedbytheworkofRobson (2002) . Overall, we conducted a total of 17 interviews with 25 persons related to eight studied cases, and had 627 minutes of audio-recorded data. When all the interviews were conducted, we

be-ganthedata transcriptionphase. Thefirst roundinterviewswere transcribed by the authors, and the second round interviews by a hired personwith English language proficiency. The reasonfor theauthors to transcribethe first round interviewswas that the interviews were conducted in the Finnish language. The authors transcribed and translated the first round interviews to the En-glish language to make the coding and analysisstage easier, be-causetherewouldbeonlyonemainlanguageinuseinthestudy. AllthesecondroundinterviewswereconductedinEnglish.During theinterviewswe werealsoabletogathersomeadditional docu-mentationdata.InoneoftheinterviewswereceivedaPowerPoint presentationrelated to the TDM activity the team wascurrently conducting.

After all thedata wastranscribed,we startedthedata coding andanalysisstage.ThetotalwordcountoftranscriptionsinWord was73 955. We useda tool specialized forqualitative data cod-ing and analysis, Atlas.ti. In data coding, one code is usually as-signed to many pieces of text, and one piece of text can be as-signed more than one code. The codes can form a hierarchy of codes and sub-codes (Robson, 2002 ). Our data coding stage fol-lowed the top-down approach, because the categories were de-rivedfromthemappingstudybyLi et al. (2015a) ,whichidentifies eight activities for TDM. The categories used in the data coding wereTD repayment,TD representation/documentation,TD identifica-tion,TD prioritization,TD measurement, TD monitoring, TD commu-nication,andTD prevention.Table 3 showsanexampleofthedata codingprocesswithAtlas.ti,wheretheinterviewsareusedto ex-tractquotationstotheidentifiedcategories.Webelievethatusing the top-down approach in the data coding wasan effective way tounderstandhoweveryTDactivitywasapproachedinevery de-velopmentteam,whichhelpedustodrawconclusionsand under-standtheTDMprocess.

When all the quotations were extracted andidentified to the specific categories, we analyzed every case independently and drewaconclusionontheprocessusedforTDMineachcase.When we had a complete view on every case, we started a cross-case analysis to find out the similaritiesand differences between the cases.

4. Results

4.1. CaseA

TDrepaymentwithrefactoringandrewritingwasbasedonthe general developmentbacklog, where some of the code base im-provement issuescould be found.However, we were not able to findanyrepayment strategyforthe TD that wasincurredduring the development. The developers in the team mentioned that it issometimesimpossibleto gettimetorefactorthesolutionsthat were developed previously with shortcuts. The reason was that new features were already waiting in the next sprint’s develop-mentbacklogthatwereprioritizedhigherthantechnical improve-mentsinthecodebase.Therefore,TDrepaymentwithrefactoring orrewritingwasmostlydoneunofficially duringtheactual devel-opmenttime that wasreserved fornewfeatures.Sometimes this refactoringwasnotevenmentionedtothemanagement.Theteam managementhadadoptedapracticewhereeveryFridaywas dedi-catedtobugfixing.However,thedevelopersfeltthatitwasmostly dedicatedtofixingonly bugs,insteadofconducting architectural-levelrefactoringorrewriting.

TD representation/documentation was not systematically con-ductedby thedevelopmentteam.Thedevelopmentteamdidnot haveaseparate TDbacklogtodocumentTDitemseither.When a developeridentified apossibleTDinthecodebase,therewasno clearprocess orguidelineonhowtodocumentittothe manage-mentsystem.Oneofthedevelopersmentionedthattheteamused

Case E Case G Case H Case D

Case F

Case A Case B Case C

Events in the studied cases

Interviewees’ opinions and experiences

Recordings of interviews

Transcripon of recordings Extracon of quotes

Grouping of quotes and documentaon data / Cross case analysis

Conclusions

Fig.3. Thecodingandanalysisprocess.

Table3

Exampleofthedatacodingprocess.

Interviewtranscripts Categories

“WehaveEpics,andwehavesomekindofgoal,so20%ofdevelopertimetobeininternalquality.” TDrepayment “Wehavequiteoftensecurityreviews,andmaybesometechnicaldebtcancomefromsecurity” TDprevention “Wecanmeasurealsohowmuchtimewespendonthissliceofthebacklog.Forexample,on

internalqualityasthewholeintheteam,think,spend218h,andweseepeople,someoursystem architects,someourdevelopers,someourQAtestersandsoon.So,wehavethisconsoleandhaving thisanobjective20%ofdevelopertime,wecancheckifwespendthattime,thatbudgetonnot.”

TDmonitoring,TDmeasurement,TDrepayment

“AlsoasateamwehavesomeKPIs.Intheteam,wearepartofproductunit,R&Ddepartmentfor ERPsandotherproduct-related.AndthenweasateamdefineKPIstomeasure,andforexample,we haveonekeycontrolontechnicaldebt.”

TDcommunication,TDmeasurement,TDmonitoring

“Andasateam,wehavekindofdemo,somekindofretrospectiveonmonthlybasis,thenwedoall thenumbersandthendiscussit:thisstrengthisgood,thisnumberistoolow,whattodo,andthen weputonbacklogactions.”

TDcommunication,TDmonitoring,TDdocumentation

theJIRAmanagementsystem,whereitispossibletocreatetickets forissues found duringthe development. However, this wasnot alwaysdonebythedevelopers,whichresultedinsituationswhere some TD remained undocumented andwas kept in the notes of thedevelopers,andevensometimesforgotten.

TDidentificationwasmainlyconductedduringthedevelopment, when a developer noticed a problematic area in the code base, whichthensometimesresulted infixingthecaseinthe manage-mentsystem.TD identificationwasalsoconductedby thesystem architectsandteammanagers,who sometimesanalyzedthecode basetofind whatshould be changed toimprove thequality and maintainability,andaddedsomerefactoring taskstothe develop-mentbacklog.

TD prioritizationwasmostlydone on a hunch. When a TD is-suewasraisedinthemanagement system,thedevelopmentteam would discuss the importance of that specific case and give it prioritization. The most important factors taken in consideration when deciding issues to be refactored were the scalability and businessvalueofthatspecificfeature.

TD measurementandTDmonitoringwerenot conductedbythe teammanagerorthesoftwarearchitects.Thereasonfornot mea-suringormonitoring TDwasthefact that thedevelopmentteam didnot haveanyclear process fordocumenting TD items, which meant that the team management did not have the possibility togather oranalyze anycleardata.Onlyestimations ofTD were basedoncurrentknowledgeaboutthecodebaseandissuesinit.

TD communication was structured well and the development teammembers understoodtheconcept ofTD.The teammanager hadagoodtechnicalknowledgebackground,whichhelpedthe de-velopersandsoftwarearchitectstocommunicateanddiscussabout thepossibleTDissuesthathadoccurredduringthedevelopment. Thiswasthereasonwhythedevelopmentteamwouldsometimes getmoretime tofixandrepayTDissuesthathadbeenbothering themintheactualdevelopment.Theteammanagerwouldalsoact asafilterbetweenthebusinessteamandthedevelopmentteam. When the business stakeholdersgave tasks that were impossible to develop within the given deadlines,the team manager would explain thesituationto thebusiness managers,which sometimes gavemorespacetothedevelopers.

TDpreventionwasdonewithcodingstandardsandcodereview practices. The developmentteam hadtakenin usesome levelof codingstandardswithcodingbooksandinstructionvideostoshow thedeveloperswhatkindofcodingwasexpectedtobedeveloped. Code reviews were sometimes conductedby two software archi-tects, butit wasnot mandatory tocheck every newly developed code.Assupervision ofTDpreventionwasnot always conducted, one of the developers mentioned that sometimes the developers wouldjustusethe oldcodeandcopyittotheother partsofthe codebase,whichcouldberisky.

Overall,theTDMstrategyindevelopmentteamAwasnot orga-nizedasasystematicprocess.Thedevelopmentteamdidnothave anyclearTDdocumentationorTDrepaymentprocesstogatherTD

issues,anditwasoftenorganizedunofficially.Thiswasthereason whyitwasalsoimpossiblefortheteam managementto monitor ormeasureTD.However,thedevelopmentteamhadagoodbasis forstartingTDM,becausethecommunicationwasactiveregarding TD,andtheteammanagerwasconsideredtohavegoodtechnical knowledge,whichhelpedthedevelopmentteamtodealwithTD. The developmentteam also hadgood TD preventionpractices in use,eventhoughtheiractualusewasnotconfirmed.

4.2. CaseB

TDrepaymentindevelopmentteamBwasmostlyconsideredas part of the normal work duringthe development. In a situation where a developeridentified a small refactoring case, there was no needto createaseparate issueout ofit.In asituationwhere therefactoringcasewasbigger,thedevelopmentteamwould orga-nizeadiscussionwiththeteammanagerandsoftwarearchitectto discussthe next steps andwhethertherewasa needto conduct refactoring or rewriting of that specific solution. The team man-agementhadalsoorganizedapracticewhereonedayoftheweek wasdedicatedtofixingbugsandmakingsmallrefactoring.

TD representation/documentationwasnotcurrentlyasystematic practicewithinthedevelopmentteam.Whenadeveloperdecided to takea shortcutduringthedevelopment, therewasno manda-toryprocessdefinedonhowitwouldgetstoredanddocumented intheJIRAprojectmanagementsystemthatwasused.We identi-fiedsituationswherethedevelopersmighthavecreatedJIRA tick-ets to the management system, but also situations where they werejustleftinthecoder’sownnotes.Thedevelopersalsodidnot always informthemanagementaboutwhatshortcutswere made. The team manager and the software architect would sometimes add someTDissues tothedevelopmentbacklog,whentheissues wereraisedduringthedevelopment.

TD identificationwas mainly done during thedevelopment by thedevelopers.When thecodebasewasdeveloped,the develop-erswouldidentifytherefactoringneeds,whenthecurrently devel-opedpartwasextremelycomplexandhardtodevelop.Sometimes alsothesoftwarearchitectswouldgothroughthecodeandtryto identifypossibleplaces,especiallyinthearchitecture,where refac-toringwasneeded.

TDprioritizationwasoftenbasedonahunchandprevious expe-riencewiththecodebase.However,prioritizationwouldgetdone accordingtothelocationoftheissue.Iftheissuewasinthecore ofthecode base,dependingonseveralother places,itwouldget prioritized as highest. After this, issues inthe business logic and userinterfacewereprioritizedunderit.

TDmeasurementandTDmonitoringwerenotcurrentlydoneby theteammanagement.Thereasonwasthatitwasatthemoment impossiblefortheteammanagerandsoftwarearchitectstoknow what TD thesoftware currentlyhad, becauseit wasnotproperly documented anywhere. The team management did not have any specific tools in use to measure TD, either. This wasthe reason why there were no accurate measurements or monitoringto see thecurrentstatusofTD.

TD communication was structured well in the development team. The team manager had wide technical knowledge, which helpedTD communicationbetweenthemanagement andthe de-velopers. This also helped the development team in situations wherethebusinessstakeholdersgaveimpossibledeadlinestowork with, becausetheteammanagerwouldexplaintheissuesof pos-sibleTD tothe businessmanagement. However,the development teamexpressedaproblemincommunication,asthedevelopment ofnew features wasalwaysprioritized the highest, andthecode baseimprovementswerenotdonebeforethem.

TD prevention was done with coding standards and code re-views. However,theteammanagermentionedthatthey werenot

on a good level at the moment, and there was a need for im-provement.Thecurrentcodingstandardsdidnotfulfilltheneeded requirements, and the development team did not always follow them.Also, thecodereviewswereconductedby thesoftware ar-chitects,butit wasnotalways possible togo throughall the de-velopedcode,asitwasnotprioritizedenough.

Overall,the TDM strategy indevelopmentteam Bwassimilar toCaseA.Therewascurrentlynomandatoryprocessusedto doc-ument TD issues in the JIRA system, andthe development team did not have a special TD backlog in use. Refactoring was con-ductedmostlyunofficiallyduringthedevelopment,andtherewas no systematic process to repay TD in certain periods. Similar to CaseA,thiswasthereasonwhyitwasextremelydifficultforthe teammanagementtomeasureandmonitorTD.However,theidea ofTDMwasunderstoodbythemanagement,andtheywereeager tofind improvements.This iswhyTD communicationwasactive withinthedevelopmentteam,whichgavemorespaceforthemto workonsomeTDissues.

4.3.CaseC

TDrepaymentwasidentifiedasanessentialpartofsoftware de-velopmentby thesoftwarearchitect, andthemanagement ofthe teamhadrealizedthatitshouldbeapartofthedevelopment pro-cess.DevelopmentteamCusedtheKanbanmethodologyandJIRA tooltomanagethesoftwareproject.IntheKanbantable,theteam management hadassigned 20% of the development time specif-ically to improving internal quality. Internal quality was divided into five main parts: refactoring, test automation, DevOps, plat-formsecurity,andperformance.Thedevelopmentteamusedthese fiveinternalqualityfactorstoassignissuestoifsomethingneeded to be refactored,rewritten orredesigned. The developmentteam identifiedTDasanimportantkeyperformanceindicatorwithin in-ternalquality.Ifa personinthe developmentteam sawa bigger needfor refactoring,he/shecreated an issueinJIRA under inter-nal quality, which then was included in the actual development backlog after a discussion with the team management and soft-warearchitects. Smallerrefactoring caseswherejustdone during thedevelopmentwithoutmentioningthemtothemanagement.

TD representation/documentation was not always done system-atically by the developers. The development team did not have any mandatory guidelines for the developers for representation anddocumentationofTD.Inacasewhereadevelopercreatedor foundeda TD issue,there was noclear process ofhow to docu-mentitsystematicallyafterwards.Instead,thedevelopermayhave sometimescreatedaJIRAissueticketforrefactoring,anditcould befoundintheinternalqualitysection,orinsomecasesitwould notgetdocumented. Theinternal qualitysection inthiscasewas used as a TD backlog. The management felt that this should be improvedalotinthefutureandthereshouldbeclearerguidelines forsystematicaldocumentationofTD.

TD identification wasconductedmainly by the software archi-tects.Thetwosoftwarearchitectsweregivenresponsibilitybythe managementto identifyTD inthecode base.Therefore,the soft-warearchitectsusuallywentthroughthecodebasetounderstand andidentify possible items to refactorand improve, which were thenaddedtotheinternalqualityissues.Theidentificationwas of-tendonejustbygoingthroughthecodebasemanually,andtrying to understand what parts of the code basewere the most com-plexones.Partoftheidentificationwasconductedwiththe Sonar-Qubetool,butthearchitectsmentionedthatitwasnotnecessarily thebestwaytoidentifyallTD,becauseitdoesnot takedeepand complexarchitecturalissuesintoconsideration.Forexample,with SonarQubethesoftwarearchitectswereabletofindissuesrelated tosinglelineproblemsorcode violations,butit couldnot detect somecomplicatedbusinesslogicissues,whichwasconsideredasa

realtechnicalproblem.Therefore,theidentificationwasseenmore asthe responsibilityofthepeople andprocesses.The team man-agerand software architects also mentioned that the developers were not currentlyinvolved heavily inthe TD identification pro-cess,andhopedthat they wouldstartto identifymoreTDissues inthefuture.

TD prioritizationresponsibilitywasgiventothesoftware archi-tects.TheprioritizationofTDissueswasusuallydoneonahunch andprevious experienceofthecodebase.Thedevelopmentteam didnot haveanysystematic waytogive estimations ornumbers toprioritize TD issues. Oneof the softwarearchitects mentioned thatsometimestheywouldtakeintoconsiderationissueslikehow heavilythefeaturewascurrentlyusedorwhetheralotofnew fea-tureswereexpectedtocometothatarea inthefuture.The team managermentioned that he trustedpeople’s opinions morethan numberswhenmakingdecisionsaboutrefactoring.

TD measurement was done by one of the software architects, whousedSonarQubetomeasureTD.TheSonarQubetoolgave val-uesofTD asautomated test coverageandviolations inthe code. Thesoftware architectused thesetwomeasurements to estimate thecurrent TD monthly.However, thesoftware architect respon-sibleforthemeasurement thought thatusing onlySonarQube to have measures of automated test coverage and violations in the codebasecannotbetheonlygoodwaytomeasuretheactual TD. TheproblemwasthatSonarQube onlyidentifies minorTD issues, suchasissuesinthecode,butnot realproblemsinthe architec-ture.Thiswasthereasonwhyitwashard togeneraterefactoring issuesfromtheSonarQubetooltotheinternalqualitybacklog.

TD monitoringwasdone by usingdatagatheredfromthe JIRA tool,which gavethe managementthe possibilityto estimate and followhow much time hadbeen spent on internal quality com-pared to the overall development time in a certain period, and whether it was aligned with the agreed 20% rule. The software architect also used data from SonarQube to monitor the current status of TD monthly, and it was analyzed and reported to the management,toshowwhetherTDwasincreasedordecreased.The combineddatafromJIRAandSonarQubewasusedtomonitorhow TDwaschancing.

TD communication was an important area of discussions be-tweentheteam management,softwarearchitects anddevelopers. The team manager worked closely with the software architects, which helped in communicating aboutissues related to internal quality andTD. This waythe development teamwas able to re-duce issues related to internal quality and TD, instead of using thedevelopmenttime tocreate onlynew features withbusiness value.Thesoftwarearchitect alsooftendiscussedwiththe devel-opersaboutissuesrelatedtoTD.

TD preventionwasconductedsometimeswithcodingstandards andcode reviews.The teamused Javacodingstandardsasa rec-ommendationtodeveloperstoproducesimilarcode.Bothsoftware architectsalsosometimesreviewedthecodetocatchbaddesigns. However, these were only used as recommendations,and it was revealedthat inrealitythecodingstandardswerenot always fol-lowedorcodereviewsconducted.

Overall,thestrategyforconductingTDMwasstructuredwellin developmentteamC.Theideatouse20%ofthedevelopmenttime toimprove the codebase andrefactor architecturalissues wasa goodstrategytoreduceTDsystematicallyinthesoftware.Also,the measurementandmonitoring withtheJIRA andSonarQube tools gavethemanagementsome levelofestimationsaboutthecurrent statusofTDinthesoftware.TheissueswithTDMindevelopment teamC were TD documentationand TDprevention. Eventhough theTDM structure waswell-designed to repayTD systematically, thedevelopmentteamdidnothaveaproperdocumentation prac-tice in use. When the developers took or found TD issues, they werenotalwaysreportedordocumented,whichmadeithardfor

thesoftwarearchitectstounderstandthestatusofthecurrentTD issues.TDpreventionwithcodingstandardsandcodereviewswas alsolackingandconsideredabigproblembythemanagement.

4.4. CaseD

TD repayment was conducted, similarly to Case C, by assign-ing20% ofthetotaldevelopmenttime toreduce TDissuesinthe software. The time for improvements wasmostly used for addi-tions ofautomated testsandunit tests. The software architectof theteamfeltthatthey couldreduce TDthemost,becauseit pre-vents TD fromoccurring in the software. If a need for refactor-ing was found during the development, it was assigned to the 20% internal qualitysection in theJIRA managementsystem that was used in the team. The 20% rule was also used for bigger refactoring and rewriting issues to remove bad designs from the code base. The development team had a two-month release cy-cle, wherethelast twoweekswere dedicatedtothestabilization of the code base. During the two weeks,the development team would discuss current TD issues and what should be refactored inthenexttwomonths’iteration.Thesoftwarearchitectalsohad the authority to use the JIRA system to see internal quality is-sues,andmakedecisionsonwhatshouldberefactoredinthenext iteration. The goal was to fulfill the 20% rule in every iteration. Sometimes onlyforexample 10% wasrequiredtobe used on in-ternalquality,because theremayhave beena needfor new fea-tureswithimportantbusiness value.However, theteam manager mayhaveadded 25%to thenext iteration afterthat, tokeep the average on theagreed 20%. The refactoring or rewriting ofsmall TDissues wasconductedduringthedevelopment,anditwasnot necessary to mention them to the management or report to the system.

TD representation/documentationwasdone totheJIRA manage-ment system. When a member of the development team saw a possibilitytohavearefactoringcase,theinstructionwastocreate anissuetothesystemaboutit.Inaddition,ifadeveloperneeded totakeanintentionalshortcutduringthedevelopment,itwasalso instructed tobe reportedinthesystem. In thiscase,the internal qualityintheJIRAsystemworkedasaTDbacklog.

TDidentificationwasdonemostlybythesoftwarearchitect re-viewing the code base manually or with a tool. The tool used for identification was SonarQube. The software architect ran the SonarQubetooleverynightwhenthenewversionofthesoftware wasout and used itto gather statistics aboutTD. Ifthe tool re-portedanymajorissues, itwastheresponsibility ofthesoftware architect to report andgothrough every critical issueandtry to fixthembeforetheendoftheiteration.

TD prioritizationwas done by simple low,medium, high, and blocker scales. High and blocker TD issues were repaid immedi-ately or in the next iteration. Medium TD issues were also re-paid in the next iteration or the one after that. Low TD issues did not usually get repaid ever, becausethe backlog was usually floodedwiththem.Thesoftwarearchitect feltthatfixinglow pri-orityissues wouldnotbringanyvalue tothesoftware.The man-agement andsoftware architect alsoassigned story points to TD issues,based onthe Fibonacciscale.Forexample amedium case wasusuallyassigned5or8points,whilehighorseverecasesgot 13or21points.Themanagementandsoftwarearchitect responsi-bleforprioritizationdidnotuseanyspecificcalculationstocreate theseprioritizations.Thedecisionaboutasingleprioritizationwas mostlybasedonahunchandtheexperienceofthesoftware archi-tectwiththecodebase.

TD measurement was conducted with the SonarQube tool by thesoftwarearchitect.TheresultsoftheSonarQube wereusedto have a measurement of the current TD. The team manager also used Fibonacciscale prioritization tomeasure the velocityin the

developmentin orderto understandhowmuch the development team could repayTD inthe next iteration. The management and softwarearchitect feltthat thesetwo measurements forTD could beusedtohavegoodTDestimation.

TD monitoring was conducted with the JIRA and SonarQube tools. The management was able to use JIRA asa tool to moni-torthedevelopmenttimeforvarioustasksoneithernewfeatures orTDreduction.Themanagementusedthisinformationto gener-atereportsattheendofeachiteration.Thesoftwarearchitectalso tried tousethedatareceivedfromtheSonarQube toolconstantly asawayofmonitoringTD.

TD communication wasperformedbetweenthe team manager andsoftwarearchitect,whodiscussedtheimportanceofTD repay-ment.Theteammanagerinitiatedthediscussionatthebeginning ofeach iterationto discussandlistthings thatwouldneed tobe done inthenext iteration.The softwarearchitectmentioned that thedevelopmentteamwascurrentlyinalucky situation,because the team manager understood the concept of TD and waseager tohelpthedevelopmentteamindealingwithit.Eventhoughthe current team manager was not described as someone who took partactivelyintechnicaldecisions,shestillunderstoodthe impor-tanceofTDandthefactthatsoftwarequalitywouldbean impor-tantfactorinthelongterm,whichgaveincreasedvisibilitytothe effortofreducingTD.

TD prevention wasconductedwith codingstandards andcode reviews. The development team had created a rule that nobody could not commit anything to the code base before another de-veloper hadreviewedit andit fulfilledthestandardsofthe Defi-nitionofDone.Ofcourseinreality thismeant thatifa developer changed a minimum amount of code,it would not be necessary to be reviewed, but in a case where there was a risk of break-ingthesoftware,areviewwasmandatory.Inthemostchallenging cases, morethan one review wasneeded. Alsoa discussion with the wholeteam wasorganizedto understand,learn andfindthe bestsolution.The softwarearchitectmentioned thateven though thisrulewasgoodtohave,itwasnotalwaysfollowedverystrictly. TheoverallTDMstrategyinsoftwaredevelopmentteamDwas constructed well. Themanagement hada clearvisionand under-standingofthefactthat20%ofthedevelopmentwouldbeusedfor TDrepayment.ThiswascompoundedwiththeJIRAandSonarQube toolsthatwere usedtodocument,measure,monitor,andidentify TD.The developmentteamhadalsowell-conductedrulesincode reviewsandstandardstopreventTD.

4.5. CaseE

TDrepaymentandimprovementdecisionsofthecodebasewere createdonthebasisofastakeholders’meetingonceamonth.The managerofthedevelopmentteamwouldmakeasuggestioninthe stakeholders’meetingonhowmuchtimewouldbeneededto re-payTD andimprovethecode baseinthenext month.The man-ageroftheteammentionedthatforexampleinthethreeprevious months,thedevelopmentteamhadmadeanagreementwiththe stakeholdersthatonethirdofdevelopmentwasassignedto repay-ingTD.However,theproblemwiththerepaymentofTDwasthat even ifthe developmentteamgot the time agreed torefactor or rewriteissues,inreality itwasnotpossibleto doso,becausethe newfeatureswouldalwaystakemoretimetocompletethan esti-mated,whichtookawaytimethatwasreservedforTDrepayment.

TDrepresentation/documentationwasdonebycreatingabacklog approachforTDissues.Whenadevelopmentteammembermade a decision to create a shortcut to some solution, or identified a needtorefactoroldtechnologyorbaddesign,itwasdocumented inaseparate‘technicaldebtbacklog’intheJIRAmanagement sys-tem. ThisprocesswasusedbythedevelopmentteamtomakeTD morevisibleinthedevelopmentprocess.Asthenatureofthe

de-velopmentteamwastoactasaplatformforotherproductlinesin theorganization,thebacklogwasalsousedtocommunicateabout TDissuesintheplatformwithother developmentteams.The de-velopmentteamwasabletopresentthebacklog totheother de-velopmentteamswithinformationaboutpossibleissuesinthe fu-turewhereTDwouldbemostdisturbing.

TD identification was mostly done by the software architects, whospentalotoftimewiththecodebase,tryingtoidentify pos-sibleimprovementsregarding TD.The developmentteamdidnot haveanyspecialtool to identifyTD inthecode base,anditwas mostlydonebyjust“smellingthecode”.

TD prioritizationwasdone by theteam manager andsoftware architects.However,theprioritizationprocesswasdescribedasnot wellconstructed.Theteammanagerandsoftwarearchitects men-tionedthattheywouldcategorizethefirstTDaccordingtoitstype. Issuetypes were usually relatedto refactoring, security and per-formance.Afterthis,theactualprioritizationwasmostlydoneata hunch,basedonopinionsandexperiencewiththeissue.Themost importantfactorstakeninconsiderationwhenmakinga prioritiza-tionwereoftenrelatedtohowTD wouldaffectthecustomerand futureprojects.Alsosecurityandperformancewerementioned to be important when deciding on the most important refactoring cases.

TDmeasurementandTD monitoringweremainlydonewith in-formationthatwasavailable intheJIRAissues.TheTDbacklogin JIRAwasusedtogathersomestatisticsandtoestimatethecurrent statusregardingTDintheplatform.Themanagerandsoftware ar-chitectsusedsomebasicinformationinthebacklogtomonitorand measurehowmuchTD theplatformhadbycalculatingthe num-berofissuesandprioritizingthemaccordingtotheir importance, tomakerefactoring.

TDcommunication wasdone mainlyinthestakeholders’ meet-ing.The managementandsoftwarearchitects gavesuggestions to thestakeholdersinthemeetingaboutthecurrentlyhighest prior-itizedTDandwhyitshouldbeimportanttorepayandrefactoras soonaspossibletopreventfutureissueswithit.

TDpreventionwasdonewithcodeguidelinesandcodereviews. Thedevelopedcode wasalways checkedwithatool called Style-Cop to ensure that it waswritten accordingto the guidelines. It wasalso mentioned that the developers did sometimes do code reviews, butthiswasnot describedas mandatory.Ifa developer wantedsomeonetocheckthe code,he/shecouldask someoneto do it.However, codereviews were instructed to be conductedif thedeveloped code wasdone in a section ofthe code basethat wasknowntobeextremelycomplex.Themanagementmentioned that thereasonfornot conductingcode reviewsinall developed codeswasthat mostofthedevelopers’ timewasassignedto the developmentofnew features,and therewasno time to haveall codesreviewed.

Overall,the TDM strategy indevelopment teamEwas mainly focusedonthedocumentation ofcurrentTD issues,andtrying to find time to refactoron the basis of stakeholders’ meeting once amonth.The managementdid notcurrentlyhaveanysystematic way to identify, measure or monitor TD. The management also mentioned that TD prevention wascurrentlynot the most effec-tive,andmoretimeshouldbereservedtoit.

4.6.CaseF

TD repayment wasnot done in any organizedprocess. One of thesoftwarearchitects mentionedthatinthecurrentprocess,the repaymentofaTDissuewasusually startedonly whentheissue startedtobehighlyproblematicforthedevelopmentteamto han-dleand there wasno other waythan just torefactor, rewrite or redesign it. If a developer noticed a need for refactoring, it was