Kaj je Zombie Scrum in kako ga prepoznamo?

Agilnost je v zadnjem času izjemno popularna, agilne metode uvaja kar nekaj podjetij in to ne samo v IT oddelek, ampak tudi na druga področja kot je HR, marketing,… Agilnost je vsekakor prihodnost, ki omogoča, da smo hitrejši, bolj prilagodljivi in bolj konkurenčni na trgu. Hkrati pa se moramo zavedati, da agilnost in rešitev za vse težave, ki se pojavljajo v podjetju, sploh pa je ne bi smeli uvajati, če v podjetju ni vzpostavljene ustrezne organizacijske kulture in psihološke varnosti za vpeljavo sprememb. Dogaja pa se točno to – agilnost je v določen tim, ekipo, oddelek vpeljana, ker vidi od tega koristi vodja/lastnik podjetja/direktor, ne pa tim sam. Tako je agilnost vpeljana “na silo”. Takrat pogosto prihaja do t.i. Zombi Scrum, ker način dela ostane enak kot prej (po waterfall metodi), samo da je prikaz drugačen – na KanBan tabli. 

Zombie Scrum lahko prepoznamo, čeprav na prvi vtis deluje kot pravi Scrum, pa ima določene simptome.

#1 Simptom: Srce ne bije.

Tako kot pri zombijih, ki na videz še izgledajo kot ljudje, jim ne bije srce. Scrum ekipa deluje skupaj z namenom, da čim hitreje in čim bolje naredi določen produkt, pa naj bo to marketinška kampanija ali pa delujoča programska oprema. To je bistvo agilnosti – da z intenzivnim sodelovanjem in s konstantno povratno informacijo končnih strank nadgrajujemo izdelek v etapah. Tako lahko konstantno testiramo naša prepričanja in predvidevanja in jih popravljamo glede na povratne informacije. Zombi Scrum deluje nekoliko drugače. Ekipa že izvaja določene dogodke v Scrum, ampak napredka pri izdelku pa ni oz. je le-ta minimalen. To se najbolj opazi pri Sprint Review sestanku, kjer se namesto dejanskega trenutnega produkta pokaže predstavitve ali pa se samo govori o napredku. Poleg tega po predstavitvi ni nikakršnje diskusije, izmenjave idej, povratnih informacij, saj so deležniki redko sploh prisotni! Niti Product Owner nima pripomb. Ravno tako je zelo ohlapno opredeljena “Definition of done”, ki ne služi svojemu namenu izgradnje funkcionalnosti dejanskega produkta. Opazimo lahko, da ekipa še vedno deluje zelo silosno. Sicer uporabljajo KanBan tablo, ampak na njej je jasno razvidno zaporedno delanje nalog in opravljanje samo tistih nalog, ki so striktno znotraj silosa. 

#2 simptom: Brez stika z zunanjim svetom in brez želje po njem.

Namesto da bi ekipa iskala stik z zunanjim svetom in pridobivala povratne informacije, se raje drži zase, znotraj znanih okvirjev. Ko produkt ne ustreza pričakovanjem stranke, se pogosto pojavljajo izgovori in prelaganje odgovornosti na druge osebe kot so “to ni moja stvar”, “jaz samo delam po navodilih” in “to bi morala ugotoviti oseba XY”. Skratka ekipa zavzame pasivno vlogo in ne prevzema odgovornosti za razvoj produkta. 

#3 Simptom: Brez čustvenega odziva na (ne)uspeh

Ker ekipa nima stika z zunanjim svetom, tudi ni čustveno vpletena v razvoj samega izdelka. Ne glede na to, ali je bil Sprint uspešen ali ne, je ekipa do rezultata brezbrižna. Morala v timu je nizka, naloge se prenašajo iz Sprinta na Sprint brez vprašanj in to nikogar ne moti. 

#4 Simptom: Brez želje po izboljšanju

V Zombi Scrum ekipah se dogodki in Sprint dogajajo samo zato, ker se morajo. Brez razloga zakaj, brez eksperimentiranja. Dogajajo se, ker to zahteva metodologija Scrum. Te ekipe so izjemno nestabilne, člane ekipe se konstantno posoja drugim ekipam zaradi njihovih kompetenc. Product owner je redko sploh prisoten na Sprint Review sestanku, Scrum Master dejansko ne obstaja, da bi ekipi pomagal rasti in za njih umikal ovire. Ekipa doživlja zunanji lokus kontrole in se postavlja v pasivni položaj, kjer (ne)uspeh ni v njihovih rokah. To se kaže tudi na retrospektivah, ki so samo prostor za pritoževanje in ne sestanek, kjer bi identificirali možnosti za izboljšave. 

V enem izmed naslednjih blogov bomo raziskali še vzroke za Zombi Scrum in si pogledali morebitna “zdravila”. 

Vir: prevedeno in prirejeno po knjigi Zombie Scrum Survival Guide, avtorjev Barry Overeem, Christiaan Verwijs in Johannes Schartau.