Pracując w projektach zwinnych mamy szczególnie jako zespół, ale również jako poszczególni jego członkowie, do dotrzymania wiele zobowiązań w ramach każdej z iteracji. Każdy członek zespołu jako kawałek samo-organizującej się grupy pracującej nad wspólnym przedsięwzięciem projektowym chce zazwyczaj wypaść jak najlepiej, dużo z siebie dając w iteracji zamkniętej ramą czasu (od ok. 2 tygodni do miesiąca). Jak dobrze wiemy z praktyki nie zawsze jest łatwo, często trudno dowieść rzeczy wysokiej jakości bez uznania żadnych kompromisów. Kompromisy o których tu mowa to zazwyczaj robienie czegoś na skróty podczas budowy software’u tak aby coś zyskać i to nazywa się długiem technicznym/technologicznym. Zazwyczaj powstaje w konkretnych obszarach takich jak: dokumentacja rozwiązań, testy, refactoring kodu, niewrażliwość na statyczną analizę kodu, brak przestrzegania standardów pisania kodu.
Z definicji dług techniczny (znany również jako dług architektury lub dług kodowania) jest ucieleśnieniem ewentualnych problemów powstałych w oparciu o ubogą, nie dopracowaną wystarczająco architekturę rozwiązania czy nie umiejętne kodowanie wymagań. Jest to porcja pracy która musi zostać dodatkowo zrobiona zanim funkcjonalność uznamy za w pełni zrobioną. Każda zmiana pociąga za sobą potrzebę wykonania zmian pośrednio zależnych, jeśli nie w kodzie to chociażby w aktualizacji dokumentacji. Porcja pracy, która nie zostanie wykonana na czas jest postrzegana jako dług, który kiedyś w przyszłości będzie musiał być spłacony, im dłużej czekamy tym bardziej może nas to kosztować.
Koncepcja po raz pierwszy zauważona i opisana przez Howarda Cunninghama w 1992 roku. Zakłada, że już wypuszczenie kodu po raz pierwszy jest zaciągnięciem długu. Mały dług który jest spłacany pozwala napędzać development. Problem powstaje w momencie kiedy przystajemy spłacać dług. Kiedy pracujemy nad nie optymalnym rozwiązaniem płacimy jakby puste odsetki.   

Najczęstsze przyczyny powstawania długu technicznego:

1. Presja biznesu, zazwyczaj biznes oczekuje aby nowe funkcjonalności były dostarczane jak najszybciej, często zanim wszystkie czynności około projektowe zostaną wykonane chociażby na minimalnie akceptowanym poziomie
2. Brak wiedzy i zrozumienia po stronie biznesu, biznes nie zdając sobie sprawy z długu technicznego podejmuje decyzje które mają późniejsze implikacje dla całego projektu
3. Problemy z architekturą rozwiązań, funkcjonalności nie są właściwie zaprojektowane, odseparowane od siebie, nie są wystarczająco elastyczne tak aby łatwo adaptować się do zmieniającego się otoczenia biznesu i wymagań
4. Brak testów lub nie wystarczające testy, znacząco zwiększają ryzyko wystąpienia incydentów na produkcji, błędy ulokowane w produkcji mogą dawać niespodziewane efekty uboczne
5. Nie wystarczająca dokumentacja lub brak dokumentacji, jeśli tworzony kod nie ma wystarczającego pokrycia w  dokumentacji, jest ciężki w utrzymaniu
6. Brak współpracy w zespole, kiedy to wiedza od doświadczonych członków zespołu nie przepływa w dostateczny sposób do mniej doświadczonych i/lub osób z biznesu
7. Równoległy development kilku wersji produktu, jednoczesna praca zespołu nad kilkoma wersjami tego samego produktu powoduje powstawanie długu który będzie potrzebny chociażby na finalne złączenie, czasem wymagany podczas złączenia refactoring rozwiązań
8. Nie dostateczny refactoring kodu, tak jak zmienia się wymaganie w trakcie życia produktu tak samo w ślad za tym powinien podążać kod. Im dłużej zwlekamy z refaktoringiem rozwiązań tym dłużej stary kod jest ponownie używany w  innych miejscach aplikacji, co nastręczy więcej prac w momencie przejścia na nowe rozwiązanie bądź konieczność przepisania softu na nowo.
9. Trudności w pisaniu wartościowego kodu, kiedy członkowie zespołu nie wiedzą jak pisać elegancki kod a później efektywnie nim zarządzać.  

Wobec powyższego cele do których powinni dążyć członkowie zespołów agilowych to między innymi, konsekwentne zmniejszanie i eliminowanie długu technicznego w trakcie trwania projektu. Każdy zespół powinien kontrolować przez cały okres trwania projektu dług techniczny i podejmować świadome decyzje w oparciu o tą wiedzę. Pracując nad przeciwdziałaniem długowi traktujmy to jako nisko budżetową inwestycję w nasz projekt która z wysokim prawdopodobieństwem przyniesie spory zwrot z inwestycji. Na koniec przypomnę tylko abyśmy umieli świadomie rozróżniać dług techniczny od celowych ulepszeń, nie wszystko jest długiem.

Pojęcie długu technicznego w projektach agailowych jest dość specyficzne, mamy tu kilka rozwiązań które pomagają zarządzać długiem. Po pierwsze iteracyjność projektu i otwartość na zmiany. Z góry wiadomy czas trwania iteracji oraz wpisana w założenia wysoka responsywność na zmianę wymuszają potrzebę stosowania elastycznych rozwiązań, architektury, standardów. Zespoły mając tą wiedzę z tyłu głowy, oferują rozwiązania które muszą obronić tą wizję. Po drugie pojęcie Definition of Done, czyli zbioru reguł które muszą być spełnione aby zespół wspólnie uznał pracę za skończoną. Reguły Definition of Done napisane przez zespół na początku projektu z każdą iteracją ewoluują w stronę coraz  dojrzalszej koncepcji budowy produktu, bardziej i bardziej zawężając pole możliwych niesolidności(tzw. nieustanne doskonalenie).

Wobec powyższego nie bójcie się świadomie zaciągać długu, tak jak kredyt dla firm jest z reguły kołem zamachowym, tak dług technologiczny pozwala napędzać development a przez to wspierać inicjatywy biznesowe. Pamiętajmy jednak, że dług jest kosztem który prędzej czy później przyjdzie nam spłacić…. jaki będzie jego finalny koszt zależy od nas samych.