Največ kritik na račun Scruma leti na (ne)obvladovanje časa, kar je pokazala tudi raziskava o izvajanju projektov v Sloveniji. 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. 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 sem prišel tudi 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.
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.
Avtor:
dr. Aljaž Stare
Vir: Projektni management – teorija in praksa, knjiga avtorja dr. Stare Aljaža
Ne spreglejte tudi:
V praksi učinkovit »TIME MANAGEMENT« – uspešno dosezite zastavljene cilje – Naj vam 24 ur, 1440 minut ali 86.400 sekund na dan prinese lastno izpolnitev tako na poslovnem, kot tudi na osebnem področju.
