Največ kritik na račun Scruma leti na (ne)obvladovanje časa, kar je pokazala tudi naša raziskava. Korelacijska analiza rezultatov je pokazala, da projekti najbolj zamujajo tam, ker uporabljajo tipični agilni metodi Kanban in Scrum. Značilen vpliv na zamude pa je bil ugotovljen tudi v primeru, da ima podjetje certificirane Scrum mojstre, poleg zamud pa tam ugotavljajo tudi višje prekoračenje stroškov in porabo ur.

Ugotovitve nas nekako niso presenetile, saj osnovo za to najdemo že v principih v ozadju agilnega manifesta. Npr. »Agilni procesi promovirajo trajnostni razvoj. Sponzorji, razvijalci in uporabniki morajo biti zmožni konstantnega tempa za nedoločen čas.«, kar ni tako zgrešeno, če je možno »zadovoljiti stranko z zgodnjim in nepretrganim izdajanjem vredne programske opreme«. Če vsak sprint prinese dodano vrednost, potem je projekt lahko daljši. Žal pa naša raziskava ni pokazala, da bi agilne metode prispevale k višji dodani vrednosti projekta – ne k boljši funkcionalnosti končnega izdelka, ne k višji uspešnosti projektov.

Predvsem pa je zelo malo takih projektov, kjer bi lahko koristili vmesne rezultate. Zato se vrnimo se nazaj k obvladovanju časa, ki je sestavljeno iz planiranja in kontroliranja. Planiranje smo obdelali v prejšnjem prispevku, kjer smo se delno dotaknili tudi kontroliranja (graf dogorevanja). Spomnimo, da stroka opredeljuje kontroliranje s štirimi koraki: spremljanje napredovanja projekta, primerjavo stanja s planom, ugotavljanje odstopanj in ukrepanje v primeru le-teh. Namen rednega kontroliranja je čimprejšnje odkrivanje težav, ko so še obvladljive in je ukrepanje enostavnejše (da naredijo čim manj škode).

Ob proučevanju različnih »agilnih« virov pa sem prišel do zanimive ugotovitve: avtorji ogromno pišejo o metriki, kazalnikih napredka, tabelah in grafih (naj omenimo še en princip »Delujoča programska oprema je primarno merilo napredka«, kar je zelo konkreten in brez dvoma najboljši kazalnik napredka), zelo malo ali skoraj nič pa ne govorijo o korektivnih akcijah – kaj naj bi naredili, ko se odkrije večje odstopanje rezultatov glede na plan.

Hitrost tima = realizirano število “točk zgodb” po sprintih

Poleg grafa dogorevanja je najbolj tipičen kazalnik hitrost (ang. velocity), lahko bi ga poimenovali tudi produktivnost ali učinkovitost tima. Hitrost pomeni število točk (uporabniških zgodb ali funkcij), ki jih tim realizira v enem sprintu, ki v primerjavi s ciljnimi točkami cikla lahko nakazuje pre-optimistično planiranje ali težave pri izvedbi. Prvo se upošteva pri planiranju naslednjega sprinta, drugo se obravnava v sklopu retrospektive sprinta. Različni avtorji pa predlagajo še kar nekaj kazalnikov, npr. rast obsega projekta (v %), ure dela na točko zgodbe, tveganje zamude izdaje SW, produktivnost sprinta in razmerje med dejansko in planirano produktivnostjo, kazalnik dogorevanja po posameznih sprintih, delujoče stestirane funkcije, strošek popravkov… (Birke, 2015)

Ne glede na navedeno pa nas »mučita« dve stvari. Eno je prelaganje nalog na kasnejše cikle – »če ne boš zaključil v tem sprintu, boš pač v naslednjem«. Ali s tem ne spodbujamo neke kulture v smislu »če ti uspe, dobro, če pa ne, pa tudi ni nobene katastrofe«? Ali se zanemarja dejstvo, da ljudje trud radi prilagajamo rokom, saj nismo stroji, ki delajo z nespremenljivim tempom? Bolj, ko je rok oddaljen, manj zavzeto delamo. Res je, da so roki za izvedbo v sprintih kratki, kar je dobra stran Scruma, vendar pa, če obstaja »kultura zamujanja«, če se v timu ob nedoseganju cilje pogovarjajo v smislu »ni šlo, smola« … se ljudje navadijo, da roki niso (tako zelo) pomembni.

Drugo težava so pogodbeni odnosi z vidika učinkovitosti tima. Kako naj – kot naročnik – vemo, da je tim dal vse od sebe, da bi projekt zaključil v roku? Težko se sprijaznimo z razlago, da so se pač ušteli pri oceni količine dela, kajne. Dokaj neprofesionalno! Mogoče so reševali kak drug projekt, ko bi morali delati na našem? Ni ravno pošteno! Vsekakor moramo v obeh primerih zaupati predpostavki, da so člani tima res pošteni in motivirani, da prinesejo čim večjo dodano vrednost naročniku. O (samo)motivaciji pa več v kasnejših prispevkih, pa tudi pogodbena razmerja bomo še obravnavali.

No, pri nekaj avtorjih pa smo le našli nekaj predlogov ukrepov ob odstopanjih. Highsmith (2010) pri tem priporoča, da je ukrepanje (oz. kot to imenuje avtor: akcije prilagajanja) bolje poimenovati odzivanje (na stanje), kot popravljanje. Ukrepi vključujejo manjše spremembe ciljev, spremembo plana zgodb naslednjega sprinta, dodajanje ljudi, spremembe plana aktivnosti (tudi s spremembo zgodb). Goodpastur (2016) omenja dodajanje oz. odpravo omejitev, kot so avtoriteta, odgovornosti in politike managementa ter prerazporedite virov (denarja, ljudi, orodij, …). Sliger & Broderick (2008) predlagata skupno iskanje rešitev naročnika in tima, kot npr. dodajanje enega sprinta, vključitev dodatnih ljudi, brisanje zahteve (funkcije) ali celo zaustavitev / prekinitev projekta.