Proč je třeba v agilním vývoji na garance nahlížet jinak než u klasické smlouvy o dílo? Protože u agilního vývoje není zadání zafixováno hned na začátku. Zákazníci pak mývají obavy, že jim agilní vývoj nedodá to, co potřebují. Obrací se proto raději k tradičnímu způsobu vývoje, který jim garantuje jistotu v podobě smlouvy o dílo s přesně určeným rozsahem zakázky a termínem dodání. Tato jistota je bohužel velmi často iluzorní.

Tradiční způsob dodávky softwaru reprezentovaný např. vodopádovým modelem spoléhá na pevný plán. Ten je definován na základě požadavků zákazníka. Protože se ale požadavky zákazníka často liší od jeho skutečných potřeb, musí se plán v průběhu vývoje upravovat. Každá taková úprava přináší nárůst režií a pozastavení vývoje v důsledku složitých změnových řízení. Oproti tomu agilní vývoj staví na rychlých úpravách zadání během vývoje a neustálém ověřování toho, že projekt doopravdy spěje, kam má.

Přesto se i u agilního vývoje může stát, že něco nefunguje nebo se objeví jiný problém. Standardní reklamační proces – kdy se projekt zcela zastaví, aby byla vada posouzena a odstraněna – se v agilním vývoji nepoužívá. Je to proto, že vývoj probíhá cyklicky v iteracích a nikoliv postupně (od jedné fáze ke druhé) jako u vodopádového modelu. V agilním vývoji je proto vhodnější na garance nahlížet jinak. Možné varianty jsou zejména následující:

1. Garance za inkrement (výstup sprintu)
   Ačkoliv u agilního vývoje nevzniká na začátku konkrétní zadání celého projektu, pro jednotlivé sprinty vznikají vždy zadání jejich rozsahu (backlog sprintu). Dodavatel vývoje tím garantuje, že výstup sprintu, nazývaný také jako inkrement (česky přírůstek), bude odpovídat zadání.
   
2. Garance týmu a jeho odbornosti
   Součástí smlouvy by mělo být jasné vymezení rolí jednotlivých členů týmu a konkrétních osob, které budou tyto role zastávat. Podmínky na jejich změnu by měly být přísné, jelikož každá změna může posunout projekt zpět. Jak už jsme zmínili v 1. díle v kapitole „Agilní vývoj je o lidech aneb Na co pamatovat ve smlouvě o agilním vývoji“ – agilní vývoj je o dobře nastavené spolupráci.
   
3. Garance měřitelných požadavků
   Místo široké odpovědnosti za vady se může dodavatel vývoje zavázat, že software bude splňovat požadavky, které jdou jasně otestovat / změřit a u kterých je tím pádem menší riziko sporu. Může jít o reakční časy, maximální kapacitu uživatelů a operací a další metriky.
   
4. Garance za použité technologie a „best practices“
   Strany mohou ve smlouvě popsat, jaké technologie má dodavatel vývoje používat či jaké standardy (metodiky) má dodržet. Nebo se může dodavatel alespoň obecně zavázat, že bude dodržovat „best practices“ v oboru vývoje softwaru.
   
5. Úprava procesu řešení chyb softwaru a rozvoje
   Pokud už dojde k tomu, že určitá funkcionalita nefunguje nebo s ní není zákazník spokojený, měla by smlouva obsahovat proces řešení vady. V agilním vývoji nejlépe funguje vrácení funkcionality zpět do backlogu či její automatické zařazení do dalšího sprintu. Zde je však potřeba, ve vztahu k dalším garancím ve smlouvě, vyřešit, jestli bude zákazník opakovaný vývoj platit, anebo ne. Platit by měl zejména ve chvíli, kdy si funkcionalitu pouze rozmyslel a chce ji změnit. Naopak náklady opakovaného vývoje by měl nést dodavatel vývoje, jde-li o nápravu jeho pochybení.