Blog, debatni večeri, raziskave, knjiga…

Author: Aljaž Page 2 of 3

Hackmanovo 60-30-10 pravilo in timske vloge

Na internetu smo našli zanimivo predavanje Esther Derby o tem, kako pomembna sta sestava tima in uvodni dnevi sodelovanja, pri čemer ji je kot osnova služilo Hackmanovo 60-30-10 pravilo. Avtor je na podlagi raziskav ugotovil, da je 60% uspešnosti tima določeno še preden se člani srečajo – s sestavo tima. O uspešnosti tima torej v večini odločajo tisti, ki določijo sodelujoče v timu – večinoma linijsko-funkcijski managerji, v nekaterih primerih pa manager projekta (v združbah z visoko projektno organizacijsko kulturo, oziroma tam, kjer je tako opredeljeno z internimi pravili). 30% uspešnosti je odvisno od uvodnih korakov – spoznavanja, kako se člani tima »začutijo«, iskanja kompromisov glede različnih navad in vrednot, ipd. (faza zagona tima), le na 10% uspešnosti pa lahko vplivamo z vodenjem tima med izvajanjem projektnih aktivnosti.  Seveda navedeno sloni na predpostavki, da večina članov še nikoli ni delala skupaj v oddelku ali projektu.

Derbyeva je podala še nekaj priporočil za vodenje tima v posameznih fazah. Pri sestavi tima je potrebno iskati ljudi, ki morajo – poleg tega, da imajo potrebna strokovna znanja in veščine – tudi razumeti »soodvisnost« pri delu in se zavedati skupinske odgovornosti. Tim naj bo majhen: idealno je 5 ljudi! Teoretično vsak dodaten član prinaša višjo produktivnost tima, a hkrati viša potrebe po urejanju medsebojnih razmerij in zahteva več komuniciranja. Raziskave kažejo, da pri največ 10 ljudeh produktivnost še »nadvlada« usklajevanje, potem pa se produktivnost tima začne manjšati.

Timu je potrebno omogočiti dostop do znanja in informacij izven tima (nemogoče je sestaviti tim z vsem potrebnim znanjem). Pri zagonu tima je predvsem pomembno jasno določiti meje odločanja! Npr. tim sprejema vse tehnične odločitve, ki ne vplivajo na delo drugih timov, na druge komponente izdelka ali na druge izdelke. Skupaj z managerji pa se odločajo npr. kdo se bo pridružil timu, kdo bo šel na kakšno dodatno usposabljanje, ipd. Jasno je treba opredeliti, kaj pomeni pojem »narejeno« (ang. definition of done) – ne za posameznike ampak za tim (člani medsebojno prevzemajo naloge, da bi čim prej predali skupen izdelek).

Uspešen agilni tim (hibrid po Hackmanu, Belbinu & Hodi)

Priporoča se tudi pregledna vizualizacija napredovanja projekta! Nadrejeni težko zaupajo, če nimajo informacij, zato pogosto sprašujejo o stanju in napredku, kar timu ni všeč (občutek, da hočejo izvajati »micro-management«). Zato mora tim poskrbeti za vizualizacijo (npr. Kanban tabla, informacijski sistem), ki mora biti na voljo tudi naročniku. Med izvedbo je pomembno, da se manager zna pravočasno vključiti v delo tima – ne prezgodaj in ne prepozno. Vedno lahko vpraša tim, če rabijo kakšno pomoč (in predlaga rešitev), ne pa, da jim govori, kaj in/ali kako morajo delati, da morajo pohiteti…

Ko je govora o vlogah v timu, moramo razlikovati funkcionalne vloge, ki so vezane na delo, ki ga nekdo opravlja (programer, tesni inženir, Scrum mojster, ipd.) in pa »timske« vloge, ki naj bi vplivale na delovanje tima. Najbolj poznane so vloge po Belbinu, ki je leta 1981 po večletnih študijah v svoji knjigi Management Teams: Why They Succeed or Fail pojasnil, da naj bi imel uspešen tim pokritih devet timskih vlog (ki sicer niso enake osebnostnim tipom ljudi s psihološkega vidika, a so povezane). Belbin predlaga naslednje vloge: koordinator, sodelavec in iskalec virov; izvajalec, dovrševalec (zaključevalec nalog) in tvorec; ter snovalec, strokovnjak in opazovalec/ocenjevalec. Navedene vloge je razvrstil v tri skupine – prve tri so usmerjene v ljudi in sodelovanje, druge tri v akcijo, zadnje tri pa v ustvarjalnost in iskanje rešitev za morebitne težave.

Če verjamemo, da je vsak od nas »nosilec« ene ali dveh vlog, potem se najbrž tudi v samo-organiziranem timu vedno najde kakšen koordinator, ki skrbi za usklajeno delovanje tima. Seveda tim brez drugih vlog ne bo deloval optimalno. Najbrž pa se vsi strinjamo, da bi bilo koristno, če bi kadrovski oddelek z ustreznimi testi (in intervjuji) za vsakega zaposlenega ugotovil, kakšne timske vloge se skrivajo v njem, da bi bili potem timi bolj smiselno sestavljeni – velja tako za tradicionalne, kot agilne time. Razen, če ne verjamete v vloge in teste ter verjamete le v sposobnosti vodje tima?

Za konec predpostavimo, da so vloge v agilnih samo-organiziranih timih drugačne. Žal smo pri iskanju vlog naleteli na težavo: večina virov navaja funkcionalne vloge, ne pa timskih. No, našli smo raziskavo Rashine Hoda, ki izpostavi šest vlog. Žal jih ne primerja z Belbinovimi, ampak prikaže drugačen vidik – njene vloge bolj slonijo na vsebinskem delu in manj na osebnosti članov tima. Ena vloga ima sicer isti naziv – koordinator, a ima drugo poslanstvo – v agilnih timih skrbi za ustrezno komunikacijo z naročnikom in usklajuje predloge sprememb. Žal Hoda tudi ni navedla ali se njene in Belbinove vloge izključujejo ali se nadgrajujejo.

Poglejmo še ostalih pet vlog: mentor pomaga pri osvajanju agilnih metod in spodbuja redno upoštevanje pretekle prakse. Prevajalec poskrbi, da se naročnik in izvajalci razumejo – prevaja med poslovnim jezikom uporabnikov in tehničnim jezikom članov tima. Dve vlogi skrbita za uveljavljanje agilne miselnosti izven tima ter s tem zagotavljata podporo (samo-organiziranemu) timu: prvak (ang. champion) pri najvišjem vodstvu, promotor pri naročniku. Terminator prepoznava člane tima, ki ogrožajo produktivnost tima in kakovost rezultatov ter se dogovarja z nadrejenimi, da bi te člane zamenjali.

Hoda tudi predlaga, kdo naj bi prevzel določeno vlogo. Agilni trener (ang. coach) naj bi bil mentor, prvak, promotor in terminator, poslovni analitik pa koordinator in prevajalec. Zanimiva pa je ugotovitev, da vloge mentorja, koordinatorja in prevajalca pri izkušenejših timih lahko prevzamejo tudi sami razvijalci. Mentorstvo vsekakor omogoča večletna agilna praksa, ostali dve pa razvijejo, ker v agilnem okolju veliko pogosteje sodelujejo z naročnikom, kot pri tradicionalnem pristopu.

Agilni trener, uslužni in agilni vodja

Čeprav Scrum metodologija ne vključuje managerjev, ker njihovo vlogo prevzameta lastnik projekta in Scrum mojster, pa druge agilne metodologije in različni avtorji še poznajo vlogo projektnega managerja. Vendar pa poudarjajo, da moderni, agilni managerji delujejo drugače, kot tradicionalni. Ključna sprememba naj bi bilo višje zaupanje do sodelavcev (namesto stalne kontrole), managerji niso več ocenjevalci produktivnosti, ampak trenerji (ang. coach), vodenje od zgoraj je zamenjalo uslužno vodenje (ang. servant leadership), napake pa niso več sramota ampak priložnost za učenje. Za napake manager ne krivi več tima, in nadrejenih ne informira o ovirah, zaradi katerih člani tima niso dosegli ciljev, ampak ovire odpravlja ter podpira in zagovarja tim (Turgoose 2019).

Danes bomo od navedenega predstavili dva vidika sodobnega managementa – »coaching« in uslužno vodenje, dotaknili pa se bomo še tretjega pojma, ki smo ga zasledili v literaturi – agilnega vodenja (ang. leadership). Slovencem se rado dogaja, da izbiramo različne (tudi napačne) prevode za tuje poslovne pojme (najbolj značilno je prevajanje managementa v vodenje), omenjal sem poskuse prevajanja metode Scrum, danes pa obravnavamo »coaching«. Mnogi, ki se ukvarjajo s tem področjem, uporabljajo kar tuj pojem. Zasledili pa smo tudi pojem usmerjevalec in celo kouč. Kdo bi vedel, mogoče se bo pa z leti pojem uveljavil, podobno kot tim (prvotno so uporabljali team) in menedžment. V tem blogu pa bomo uporabili besedo »trener«, mogoče pa bi jim lahko rekli »poslovni trener«, da jih razlikujemo od športnih

Čeprav Turgoose govori o tem, da bi moral biti moderni manager tudi trener, pa redki povezujejo ti dve vlogi, ampak predlagajo, da naj bo agilni trener posebna funkcija v podjetju. Še več, vloge niti ne pripisujejo Scrum mojstru. Poglejmo kaj in kako deluje poslovni trener. Tole opredelitev smo si sposodili pri enem od slovenskih ponudnikov izobraževanja trenerjev: »Pri coachingu coach pomaga stranki, da sama najde rešitve brez ponujanja nasvetov in dajanja receptov. Coachi so izurjeni, da poslušajo in zastavljajo ključna vprašanja, ki pomagajo posameznikom in organizacijam, da sami pridejo do najboljših rešitev.«

V raznih virih najdemo od 5 do 8 vlog, ki jih prevzema agilni poslovni trener (glej sliko), ključne pa so učitelj – ponuja dodatna znanja, povezovalec (ang. facilitator) – skrbi za ustrezno sodelovanje v timu, svetovalec (ang. consultant) – daje predloge rešitev, mentor – deli svoje izkušnje, in trener (ang. coach), ki pomaga dosegati cilje s pomočjo provokativnih vprašanj. Ključne veščine trenerja pa so, da je dober poslušalec, da zna postavljati prava vprašanja, da zna opolnomočiti (ang. empower) člane tima in da spodbuja pravo vedenje. No, glede na navedeno, bi skoraj lahko trdili, da je Scrum mojster lahko tudi agilni trener.

Agilni trener, prirejeno po Horriganovi, 2020

V nasprotju z agilnim trenerjem, ki naj bi bil »samostojno« delovno mesto, pa stroka uslužno vodenje pripisuje dvem obstoječim vlogam – managerju projekta oziroma enemu od članov samo-organiziranega tima. Mnogi namreč predlagajo, da ima samo-organiziran tim tudi formalno določenega vodjo, ki naj bi deloval po principih uslužnega vodenja. Naša majska raziskava pa je tudi pokazala, da se anketiranci pretežno strinjajo s trditvijo, da se v timu, kjer ni formalno določen vodja, sčasoma »izlušči« neformalni vodja, ki povezuje in usmerja tim ter vodi sestanke. Predvidevamo, da ima značilne lastnosti uslužnega vodje.

Greenleaf, ki je v 70-tih utemeljil uslužno vodenje, meni, da je želja po služenju drugim eden od (samo)motivacijskih dejavnikov nekoga, ki želi prevzeti vlogo vodje. Po njegovem mnenju so uslužnim vodjem lastni interesi manj pomembni od potreb sodelavcev, ko pa slednji prepoznajo dobronamernost vodje, pa tudi oni postanejo bolj uslužni. Osnutke tega pristopa najdemo v kitajski filozofiji, mnogi avtorji pa kot tipične služnostne vodje prikazujejo verske ikone (npr. Budo in Kristusa) ter politične voditelje (seveda tiste, ki so modro in predvsem dobronamerno vladali ljudstvu) – tipičen predstavnik naj bi bil tudi Gandhi. Mimogrede, nekje sem prebral njegovo misel: »Tam gre moje ljudstvo in moram jim slediti, saj sem njihov vodja.«

Seveda imamo v uslužnem vodenju dve nasprotujoči si vlogi – služabnik, kot podrejen, in vodja, kot nadrejen oziroma vladajoč. No, voditeljska vloga pomeni, da mora vodja poskrbeti, da mu sodelavci sledijo, uslužna pa, da to dela na tak način, da mu sodelavci z veseljem sledijo, ker je korekten v odnosih in upošteva njihova potrebe. Tu ne govorimo o »korenčku in palici«, ampak o ustrezni ravni delovne klime, ki sloni na odličnih odnosih.

Uslužni vodja

Sipe & Frick (2009) uslužnega vodjo prikažeta kot zaupanja vrednega sočutnega sodelavca, kot nekakšno etično moralno avtoriteto, človeka, ki je komunikativen, načelen in pronicljiv, med njegove značilne kvalitete pa uvrščata tudi sistemsko razmišljanje na dolgi rok. Nekateri govorijo tudi o ponižnosti (prevod besede »humble«). Menimo, da ta prevod ni ravno na mestu – ne moreš biti ponižen in hkrati pričakovati, da ti bodo ljudje sledili. Si zamislite takle pogovor: »Malo sem razmišljal, če bi bil mogoče tako prijazen in izvedel tole nalogo…« Primernejši prevod bi bil »skromen« (saj veste tisto: »skromnost je lepa čednost«), predvsem pa bi rekli, da uslužni vodja ni nadut, domišljav oziroma aroganten. Vsekakor govorimo o stilu vodenja, ki bi lahko veljal za vse managerje, kajne.

Za konec pa še nekaj o agilnem vodenju, ki ni vezano le na agilne metode, kar bi veljalo tudi za uslužno vodenje. V bistvu gre za priporočila, kakšen naj bi bil vodja 21.stoletja! Na internetu najdete ogromno priporočil glede oblik vedenja in delovanja agilnih vodij ter potrebnih osebnostnih lastnosti, veščin in orodij. Večina tega, kar smo o vodenju napisali do sedaj (tudi v prispevkih leta 2011) je vključeno tudi v agilno vodenje. Gre za nov način razmišljanja in delovanja vodij, ki skrbijo predvsem za ustrezne komunikacije, pripadnost ljudi in sodelovanje. Navdihuje, eksperimentira, spodbuja zanosno ustvarjalnost in inovativno razmišljanje, učenje na napakah … in je uslužni vodja. Vodenje sloni na pozitivnih predpostavkah o ljudeh (teorija Y)! Več pa v knjigi…

Agilni samo-organiziran tim

V uvodnih »agilnih« prispevkih smo večkrat omenili, da agilni pristopi pripisujejo manj pomembno vlogo vodjem in managerjem, mnogo večjo pa ljudem in timom. Zelo pogosto se uporablja besedna zveza samo-organiziran tim. Ti se sicer niso pojavili z agilnimi pristopi – v 50-tih letih prejšnjega stoletja so npr. raziskovali samo-organizirane skupine rudarjev, v 80-tih pa so samo-organizirane proizvodne time uvajali v Toyoti (Hoda, 2011) – so se pa z njimi še bolj uveljavili.

Samo-organiziranje pomeni, da tim nima nadrejenega, ki bi jim določal kdo mora kaj, kdaj in na kakšen način narediti, ampak se o vsem tem dogovarjajo sami. Sami se usklajujejo z naročnikom (lastnikom izdelka), organizirajo in izpeljejo sestanke, sami rešujejo vse težave, s katerimi se srečajo. Skratka – so avtonomni pri odločitvah in prevzemajo polno odgovornost za učinkovito izvajanje nalog. Člani tima torej samostojno (in skupaj):

  • planirajo svoje delo (vsak posameznik zase, vsi skupaj za tim)
  • izbirajo svoje naloge
  • odločajo o načinu izvedbe
  • rešujejo tehnične in organizacijske težave
  • rešujejo med-osebne konflikte
  • odločajo, ali uresničiti predlagane spremembe
  • iščejo boljše (učinkovitejše)  pristope za izvedbo nalog
(Najpogosteje prikazana) razlika med tradicionalnim in agilnim timom

Kdorkoli ima že nekaj »projektne prakse« pa bo vedel, da vse navedeno ni tako enostavno, predvsem zaradi tega, ker vsi ljudje nismo enaki, naše delovanje pa tudi ni konstantno in predvidljivo, kot to velja za stroje. Ljudje imamo različne prirojene, privzgojene in priučene osebnostne lastnosti, vrednote, izobrazbo, izkušnje, raven ustvarjalnosti in koncentracije pri delu, način učenja … da o ob-službenih »obveznostih« (družina, hobiji), ki tudi psihološko vplivajo na našo osredotočenost pri delu, ne govorimo.

V literaturi smo našli obilico priporočil glede pogojev za zadovoljivo delovanje samo-organiziranega tima (Schwaber & Beedle, 2001; Moreira, Lester & Holzner, 2010; Atkins, 2010; Gouveia, 2015). Predvsem naj bi bili timi majhni (idealno 5 ljudi, največ 9), delajo naj 100% le na enem projektu, če se le da, v skupnem prostoru. Člani naj bi bili izkušeni, timsko usmerjeni samo-motivirani strokovnjaki, z visoko razvitimi veščinami sodelovanja, hkrati pa bi morali biti sposobni delati samostojno, biti pripravljeni prevzeti pobudo in se zavedati svoje odgovornosti (do podjetja in naročnika).

Večina omenja pomen mehkih veščin – običajno poudarjajo komunikacijske sposobnosti, predvsem pa je pomembno medsebojno zaupanje! Pomembna je zavzetost (biti pripravljen zavezati se nekemu cilju), osredotočenost na delo, odprtost pri pogovorih, medsebojno spoštovanje in transparentnost delovanja (cilji, rezultati, težave). Člani tima morajo imeti tudi  pogum – da se zavežejo ciljem s prepričanostjo, da jih bodo tudi dosegli.

Kar zahtevni pogoji, kajne? Mogoče celo neživljenjski? No, so pa avtorji agilnih pristopov zato vstavili »varovalko«, če vsi ti pogoji niso izpolnjeni: tu je Scrum mojster, ki timu pomaga reševati težave, s katerimi se srečuje. Vendar pa formalno ni tiste vrste vodja tima, ki bi želel in znal iz posameznikov potegniti najboljše. Smo pa naleteli še na nekaj vlog, katerih naloge nekateri pripisujejo Scrum mojstru, drugi managerju projekta, tretji pa enemu od članov tima. To so agilni trener (ang. coach), agilni vodja (leader), uslužni (servant) vodja. O tem pa več naslednjič.

Za konec pa še malo kritičnega razmišljanja. Pri branju »agilnih« virov smo se vedno znova spraševali, kaj je bilo narobe z njihovimi managerji, da se jih tako zelo želijo znebiti. Na spletu smo našli tudi kar nekaj posnetkov s konferenc, kjer agilni trenerji s pomočjo zabavnih iger prikazujejo, da je delo brez šefov bolj učinkovito. Res je, da se ljudje zabavajo, a žal take »instant« delavnice dajo ljudem napačno predstavo, saj je delo v timih nekaj povsem drugega, kot pa se npr. postaviti v kolono glede na datum rojstva. Ljudje imamo različne osebnosti in delo v timu prinaša ogromno izzivov, ki so povezani s tem. Predpostavka »saj smo sami dobri ljudje« je žal preveč poenostavljena, čeprav težimo k njej. Ste kdaj igrali v rekreativni športni ekipi brez trenerja? Potem boste vedeli, o čem govorimo. Si predstavljate nogometno reprezentanco, sestavljeno iz vrhunskih posameznikov, da bi igrala brez trenerja? Pri tem, da je v ekipi nekaj »ego tipov«, ki so sicer »glavni« v svojih klubih, v reprezentanci pa je kapetan lahko le eden! Saj znajo igrati, kajne? Skupaj, brez zavisti, z enako vnemo?

Pri navajanju prednosti samo-organizacije smo velikokrat tudi naleteli na opisovanje tradicionalnega pristopa v potenciranju skrajne oblike »enoumja«, npr. delovanje policista prometnika v križišču, kjer vozniki samo ubogajo in nič ne mislijo s svojo glavo. Vodenje ljudi je del managementa, odličnost le-tega pa ne sloni na samostojnem planiranju in odločanju managerja, ampak na njegovih voditeljskih sposobnostih vključevanja sodelavcev! On mora poznati svoje sodelavce, kje blestijo, kje so slabši, kaj delajo z užitkom in katerega dela ne marajo, kaj jim podžge delovno vnemo in kaj jim gre na živce. Mogoče bi veljalo – naj bo tim čim bolj samostojen, a za vsak slučaj naj ima še izkušenega, odgovornega vodjo, ki ima visoko razvite voditeljske sposobnosti?

Scrum: obvladovanje časa?

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.

Scrum: točke, poker in dogorevanje

Vrnimo se danes na največ uporabljeno agilno metodo, Scrum in si razjasnimo ključne tri tehnike planiranja in kontroliranja dela. Hotel sem napisati »tehnike za obvladovanje časa«, a v večini virov poudarjajo, da se pri Scrumu ne obremenjujemo preveč s časom, da ga je težko planirati … in da je pomembneje, da so izdelki narejeni … a več o tem v nadaljevanju.

Torej, avtorji poudarjajo, da naj pri planiranju zahtevnost uresničevanja uporabniške zgodbe ne bi ocenjevali s potrebnimi urami (dnevi) za izvedbo, ampak s točkami, ki naj bi izražale kompleksnost zgodbe / naloge, pri tem pa priporočajo ocenjevanje po Fibonaccijevi lestvici (0,5, 1,2,3, 5, 8, 13, 21, 34…). Nekateri avtorji predlagajo zelo enostaven način – od izbranih zgodb sprinta tim izbere najmanj in najbolj zahtevno, ostale pa razporedi vmes (s postopkom medsebojne primerjave). Seveda se sprašujemo, ali je najbolj enostavna ocenjena z 0,5 ali 3 … in s koliko točkami naj bi ocenili najzahtevnejšo. Naslednje vprašanje je seštevek točk vseh teh nalog, ki naj bi ga izenačili s točkami, ki jih tim zmore doseči v sprintu.

Odgovor na prvo vprašanje sem našel v več virih: podjetje ima lahko pripravljeno tabelo, ki je timu v pomoč pri oceni. V tabeli so opisani dejavniki, ki vplivajo na kompleksnost naloge, kot so: obsežnost zgodbe / naloge, potreben vložen trud, morebitna tveganja, nepredvidljivost, odvisnost od drugih zgodb ali izvajalcev, število neznank, ipd. (glej primer na sliki).

Pomoč pri oceni točk zgodbe (povzeto po medium.com)

Ostaja pa vprašanje, koliko točk zmore tim v enem sprintu. Po navedbah avtorjev naj bi imel vsak tim svoj maksimalni zbir točk sprinta. Povsem razumljivo je, da je to odvisno od števila članov tima, a podjetja nimajo nekega standarda, kjer je zapisano, da naj bi vsak član tima zmogel npr. 12 točk na sprint. Moramo se zavedati, da so tudi člani tima različno učinkoviti, kar je odvisno od znanja, izkušenj, kreativnosti, motiviranosti, ipd. Ali kot pravi Czerniak (vir): točke niso merilo, ki opisuje učinkovitost razvijalcev in niso osnova za primerjavo učinkovitosti dveh različnih Scrum timov. Skratka, v prvem sprintu se vsota točk določi po občutku (po možnosti se uporabi učinkovitost članov tima iz prejšnjega projekta), potem pa se z vsakim zaključenim sprintom izkristalizira maksimalni zbir točk, ki jih zmore tim na tem projektu.

Zanimiva tehnika ocenjevanja zahtevnosti zgodb, ki bi jo bilo smiselno uporabiti tudi pri planiranju tradicionalnih projektov, pa je planski poker. Koristimo ga za natančnejšo oceno zahtevnosti izvedbe neke naloge (zgodbe), ne glede na to, ali jo ocenjujemo s potrebnim časom za izvedbo ali s točkami. Ključni pogoj za izvedbo pokra pa je, da imamo več članov tima iz iste stroke. Ko lastnik izdelka predstavi neko zahtevo (uporabniško zgodbo), vsak član pri sebi oceni zahtevnost, nakar v istem trenutku vsi sodelujoči (običajno s posebnimi kartami, lahko pa z listki, kamor napišejo točke) podajo svojo oceno. Tim potem ne vzame povprečja točk, ampak tista dva člana tima, ki sta napisala najnižjo in najvišjo oceno, ostalim pojasnita razloge za to. Z novimi spoznanji potem ponovijo ocenjevanje, po potrebi pa sledi še ena razlaga in še en krog glasovanja, v katerem pa naj bi bila ocena enotna, dosežena s konsenzom sodelujočih.

Po planiranju sledi izvedba nalog, ki se pri Scrumu meri s točkami opravljenih nalog (uresničenih zgodb). Običajno se to prikazuje v grafu, kateremu v angleškem jeziku rečejo »graf dogorevanja« (ang. burndown chart), v našem »poslovnem« jeziku pa bi ga bilo najbolje poimenovati »graf napredka ali napredovanja« projekta (sprinta). Z zaključkom prve naloge oz. uresničitvijo uporabniške zgodbe se od celotnega zbira točk sprinta odštejejo točke te zgodbe, na grafu pa prikaže preostanek točk. Ob zaključku naslednje se odšteje od preostanka, itd. … V grafu se torej prikazuje zbir točk nalog, ki jih je treba še dokončati v sprintu, ob primerjavi z linijo, ki povezuje maksimalno število točk ob začetku sprinta z 0 ob koncu, pa ugotavljamo napredek in ustrezno hitrost izvajanja nalog ter ocenjujemo raven verjetnosti, da bo tim do konca sprinta izvedel vse naloge.

Hibridni – agilno tradicionalni pristop

Naša majska raziskava je pokazala, da v Sloveniji redko najdemo agilne projekte v »čisti« obliki. Pri večini »agilnih« združb še vedno najdemo ostanke tradicionalnega necikličnega projektnega dela. Razlogi za to so različni – mogoče so še v fazi prehoda iz tradicionalnega v agilno, mogoče organizacijska kultura in navade ljudi zavirajo vpeljavo novejših pristopov, mogoče ljudje v praksi ne verjamejo povsem v agilnost (ali vsaj ne v vse agilne tehnike), ali pa so ugotovili, da je za njihove projekte najboljši neke vrste kombiniran pristop, hibrid.

Seveda Slovenija v tem pogledu ni nobena izjema, podobno se agilni pristopi uveljavljajo tudi drugod posvetu. Danes bomo zato pogledali, kaj o hibridnih pristopih pišejo drugi avtorji. Najpogosteje je hibridni pristop sestavljen iz tradicionalnih zaporednih faz (snovanje, priprava, izvedba, zaključevanje), pri čemer izvedba poteka ciklično (glej sliko).

Podrobna opredelitev zahtev (ki sicer lahko poteka ob koncu snovanja, na začetku priprave ali vmes) je razdeljena v dva dela, kar sicer velja tudi za sam Scrum pristop. V prvem »tradicionalnem« delu se opredeli le nabor zahtev, brez podrobnega opisa le-teh, npr. seznam funkcij (zahtevnik, ang. backlog). Na začetkih posameznih sprintov se te zahteve podrobneje opredelijo s pomočjo uporabniških zgodb. Včasih se na začetku izvedbe izdela zasnova izdelka (na sliki »zasnova (modela)«, npr. arhitektura programske opreme), ki jasneje opredeli strukturo končnega izdelka in skupaj z zahtevnikom predstavlja »ogrodje« nabora sprintov razvoja.

Hibridna izvedba projekta

Plan izvedbe projekta se v fazi priprave opredeli z mejniki in fazami (ki so sestavljene iz ciklov). Za razliko od »čistega« Scruma, kjer lastnik izdelka določa vsebino posameznega sprinta šele na začetku sprinta, se pri hibridnem načinu v fazi priprave določi okvirna vsebina sprintov in vrstni red le-teh, poleg tega pa se jih tudi razvrsti po fazah; ena možnost pa je tudi, da se jih določi šele na začetku posameznih faz. Ključna razlika glede na tradicionalni pristop pa je v tem, da se »mikroplan« aktivnosti sprinta izdela na začetku vsakega sprinta, pri čemer plan pripravijo sami člani tima.

Mimogrede, tudi naša raziskava je pokazala, da ima 85% cikličnih projektov izdelan plan izvedbe ciklov že na začetku projekta, kar bi lahko govorilo o tem, da so projekti v Sloveniji bolj hibridni, kot agilni. No, težko trdimo na podlagi enega podatka – potrebna bo podrobnejša analiza vseh kazalnikov agilne in tradicionalne izvedbe, več o tem pa v knjigi.

Sicer pa hibridni pristop ohranja »tradicionalni« način poročanja o napredku projekta (mesečno, ob fazah, SPI, CPI), ob koncu faz pa je možna dobava / uporaba vmesnih rezultatov (agilno!). Seveda ima hibridni pristop managerja projekta (kar ne velja za Scrum), pri čemer Strasser (2020) predlaga, da to vlogo prevzame Scrum mojster.

Ob iskanju informacij o hibridih na internetu pa smo odkrili tudi hibridni manifest (Hybrid project management manifesto), pod katerega sta se podpisala Robins in Ariel, sicer pa ni navedeno, koliko imata »podpornikov« (kot je to navedeno za agilni manifest). Zato tudi ne vemo, koliko ljudi se strinja s priporočili avtorjev, ki sicer med FAQ navajata, da je to »formalna metodologija, ki pridobiva vse več podpore, tako s strani akademskih kolegov, kot praktikov«. Glede na vsebino bi se strinjali, da je to  bolj metodologija, kot manifest, saj natančno opredeljuje hibridni proces izvedbe projekta in vloge sodelujočih, pri čemer se najbolj osredotoči na delitev odgovornosti med managerjem projekta in Scrum mojstrom.

Naj za konec omenimo še uporabo agilnih tehnik v tradicionalnih projektih, kar bi tudi lahko šteli kot neke vrste hibrid, čeprav menimo, da je neciklična izvedba še vedno predvsem »tradicionalna«. Kakorkoli, projektnim managerjem predlagamo sledeče agilne tehnike za učinkovitejšo izvedbo in večji uspeh projektov:

  • določanje pomembnosti zahtev (kaj se potrebuje prej, kaj kasneje) … seveda, če ne pridemo navzkriž s tehnologijo – to je možno pri razvoju programske opreme, pri gradnji pa bi težko zahtevali najprej sobo v prvem nadstropju, brez temeljev, zidov…
  • opredelitev zahtev z uporabniškimi zgodbami, predvsem, ko je govora o razvoju storitev, IT rešitev, reorganizaciji delovanja ali prenovi procesov
  • pogostejše vključevanje naročnika – za opredelitev prioritet zahtev, potrjevanje idej in usmeritev, testiranje in potrjevanje vmesnih rezultatov (obseg – funkcije in kakovost),
  • dnevne 15-minutne stoječe sestanke ob Kanban tabli
  • revizijo rezultatov in retrospektivo (so)delovanja ob mejnikih

Avtorji še omenjajo osredotočenost na poslovno vrednost (pri opredelitvi ciljev in obravnavi sprememb) ter večjo svobodo tima pri samo-organizaciji dela. Menimo, da naj bi bili obe »vrednoti« že del tradicionalnega izvajanja projektov, od organizacijske kulture in veščin managerjev pa je odvisno, ali se držijo priporočil stroke ali ne…

Nexus, LeSS, SAFe, … agilni pristopi za obsežnejše projekte

Večina agilnih metod, ki smo jih predstavljali do sedaj, je namenjena predvsem manjšim timom, danes pa predstavljam nadgradnje agilnih metod, predvsem Scruma, ki se uporabljajo pri projektih, v katerih sodeluje več ljudi.

Najenostavnejša rešitev, ki je sicer zelo podobna tradicionalni organizaciji, je tako imenovan »Scrum of Scrums« (SoS) ali »meta Scrum«. Vsi sodelujoči se razvrstijo v Scrum time s 3 do 9 člani, koordiniranje dela med timi pa se izvaja prek tima, ki ga tvorijo predstavniki timov (Scrum of Scrums). Ko posamezni timi zaključijo dnevne sestanke, se predstavniki dobijo na usklajevalnem sestanku, a ne nujno vsak dan (priporoča se 2-3 sestanki tedensko), pri čemer usklajevalni sestanki niso omejeni na 15 minut. Vsebina sestanka je podobna vsebini predhodnih sestankov timov. V kolikor je sodelujočih še več, obstaja še en višji nivo (Scrum of Scrums of Scrums).

Neposredna nadgradnja Scrum metode je Nexus. Za koordniacijo med večjim številom timov skrbi usklajevalni tim (Nexus Integration Team, v nadaljevanju ga bom imenoval Nexus tim), v katerem so – poleg lastnika izdelka in Scrum mojstra – še člani tima, običajno sistemski inženirji, lahko pa tudi predstavniki timov. Sistemski inženirji nastopajo predvsem kot ključni strokovnjaki, ki usmerjajo delo timov in jih tudi učijo uporabe določenih orodij in praks. Nexus tim naj bi zagotovil, da vsak sprint prinese vsaj en uporaben rezultat.

Planiranje sprintov se izvaja v dveh korakih. Na prvem sestanku predstavniki timov, skupaj z Nexus timom, pregledajo in pokomentirajo aktualen zahtevnik (ang. Backlog) in za vsak tim določijo zahteve (funkcije, naloge) za tekoči sprint. Vsak tim nato samostojno splanira svoj sprint, pri čemer po potrebi sodeluje z drugimi timi. Skupni zahtevnik sprinta zagotavlja preglednost vseh izbranih postavk zahtevnikov timov in morebitne odvisnosti med njimi.

Nexus (Schwaber, 2018)

Na dnevnih sestankih Nexus tima sodelujejo predstavniki razvojnih timov, ki poročajo o napredku dela v svojih timih in kritično ocenijo dotedanji skupni (integriran) rezultat. Tega oceni Nexus tim tudi v reviziji sprinta (v razvojnih timih revizije ne izvedejo). Retrospektiva pa se izvede v treh korakih: na prvem sestanku predstavniki timov z Nexus timom izpostavijo težave, ki si jih imeli izven »meja« svojih timov, sledi retrospektiva po razvojnih timih, v tretjem koraku pa isti sodelujoči, kot na prvem, predlagajo korektivne akcije in spremembe (so)delovanja.

Tudi LeSS je zasnovan na Scrum metodi, kar pove že ime (Large-Scale Scrum). Ključna značilnost metode je, da za usklajevanje dela med timi ni formalno določenih koordinatorjev, ampak se timi po potrebi sestajajo sami, usklajujejo zahteve, delo in rezultate. Druga značilnost je pogostejše sodelovanje uporabnikov (poleg lastnika izdelka). Na polovici vsakega sprinta se timi namreč dobijo s končnimi uporabniki in pregledajo vmesne rezultate ter po potrebi podrobneje razjasnijo zahteve. Sicer pa se tudi pri tej metodi planiranje sprintov izvede v dveh korakih – v prvem si na skupnem sestanku vsak tim izbere naloge / funkcije, ki jih bo razvil v sprintu, po tem pa si vsak tim posebej splanira aktivnosti sprinta. Tudi revizija sprinta se izvede z uporabniki (in ne le z lastnikom izdelka): preveri se, če so rezultati skladni z zahtevami, željami in pričakovanji uporabnikov, odstopanja pa se odpravijo v naslednjem sprintu. Podobno, kot se planira, se tudi retrospektiva sprinta izvede v dveh korakih: najprej tim izvede svojo retrospektivo, potem pa se dobijo vsi sodelujoči in izmenjajo izkušnje, poleg tega pa ocenijo tudi sodelovanje med timi.

V kolikor v projektu sodeluje več kot 8 timov, se projektu priključijo še »področni lastniki izdelka« (APO – Area Product Owner). Govora je o strokovnih področjih, kar pomeni, da npr. en APO koordinira delo programerjev, drugi pa razvijalcev elektronike, itd…

LeSS (less.works)

SAFe v prevodu pomeni »Razširjen agilni okvir« (ang. Scaled Afile Framework). Metoda sistematično pokriva štiri ravni projektov. Na osnovni ravni – manj obsežnih projektih (in manjših timih) – sledi metodam Scrum in Kanban (ter Scrumban). Obsežnejši projekt na naslednji ravni imenujejo »Bistveno« (ang. Essential), projekt pa je razdeljen na programske cikle (ang. Program Increments), ki se običajno izvedejo skozi 5 dvotedenskih ciklov (ki jih ne imenujejo sprinti, ampak iteracije). Po koncu vsake iteracije se izvede skupen sestanek (ang. System Demo), kjer se ugotavlja stanje izvedbe, oceni dotedanje rezultate cikla, timi pa dobijo povratne informacije za izboljšanje rezultatov v nadaljevanju. V teh projektih sodeluje 5 do 12 timov (50 – 125 ljudi), timi pa so multi-disciplinarni. Vse time skupaj poimenujejo Agile Released Train (ART), koordinator pa je Release Train Engineer (RTE). Poleg njega so v ekipi še lastnik izdelka, Scrum mojster, sistemski arhitekt ter poslovni direktorji (ang. business owners).

Naslednja raven projektov je »Večja rešitev«, kjer prej omenjeni ekipi pridružijo novi timi ter kreator rešitve (ang. Solution Manager). Celotno ekipo poimenujejo »Vlak rešitve«, ključni koordinator pa je Solution Train Engineer (STE). Četrta raven metode se imenuje »Portfelj« in obravnava vse projekte v družbi.

FDD, XP, DSDM, Kristalno

Scrum in Kanban sta, kot smo omenili v prejšnjih prispevkih, najbolj uveljavljeni agilni metodi, kar je pokazala tudi naša raziskava, pa čeprav Scrum pogosto in redno uporablja le 41% tistih združb, ki projekte izvajajo ciklično, 31% teh pa uporablja Kanban. Od preostalih poznanih metod se največ uporablja Razvoj osredotočen na funkcionalnosti (FDD, Feature driven development), katerega pogosto in redno uporablja 28% združb, ki projekte izvajajo ciklično, pa tudi 20% tistih, ki projekte izvajajo tradicionalno.

Naj še enkrat spomnim, da se je – ko je govora o agilnih pristopih – večino metod razvijalo na področju razvoja programske opreme, kar se še posebej kaže v metodah, ki jih predstavljam danes. Zato ne moremo govoriti o agilnem (projektnem) managementu, ampak bolj o agilnejših projektnih pristopih. Za razumevanje tega si lahko preberete moj prvi prispevek na blogu, kjer sem opredelil pojem management. V kolikor obstaja manager projekta (ki naj ne bi obstajal pri Scrum metodi), ta še vedno planira, organizira, vodi tim in kontrolira izvedbo … le da se pri agilnih pristopih to delo izvaja ciklično.

No, vrnimo se na agilne pristope, ki so omenjeni v naslovu. FDD je pristop, ki se uporablja za obsežnejše programske rešitve, pri čemer so – poleg managerja projekta in razvijalcev – »predpisane« še naslednje vloge: glavni arhitekt SW, vodja razvoja, glavni programer, odgovorni za razvoj dela kode (ang. class owner) in poslovni analitik (domain expert). Metoda določa način razvoja programske rešitve, ki se začne z razvojem celotnega modela, na podlagi katerega se izdela nabor vseh funkcij (ang. Feature list) in plan razvoja funkcij (glej prvo sliko). Sledi ciklična izvedba, vsak cikel pa vsebuje zasnovo in razvoj funkcije (nekateri avtorji pa svetujejo podrobnejše planiranje razvoja posamezne funkcije na začetku cikla). Pri tem so cikli različno dolgi, odvisno od zahtevnosti razvoja posamezne funkcije. Pristop vključuje tudi povratno zanko – celoten model se lahko dopolnjuje na podlagi rezultatov ciklov.

Razvoj osredotočen na funkcionalnosti, FDD (vir: aist.global)

Največkrat omenjena agilna metoda razvoja programske opreme, ki jo je razvil eden od soavtorjev agilnega manifesta Kent Beck, je ekstremno programiranje (XP), ki pa se v slovenskem prostoru (še) ni uveljavil. Po naši raziskavi ga redno nihče ne uporablja, 6% tistih, ki projekte izvajajo ciklično, pa je navedlo, da ga uporabljajo pogosto. Kot lahko vidimo na drugi sliki, so je metoda podobna Scrumu, koraki pa so tako vsebinsko, kot časovno dokaj natančno in sistematično opredeljeni.

Avtor priporoča razvoj manjših rešitev z veliko vrednostjo, zahteve se – podobno, kot pri Scrumu –  opredeljujejo s scenariji in zgodbami, pa tudi tu naj bi bil naročnik stalen član tima. Kot posebnosti je potrebno izpostaviti razvoj testnih procedur pred razvojem rešitve ter delo v parih – zaradi višje kreativnosti in takojšnjega odkrivanja morebitnih napak, poleg tega pa naj bi bil posameznik težko 100% skoncentriran 8 ali več ur programiranja. Omenimo pa naj še vrednote pristopa: pogum * povratne informacije * enostavnost * komuniciranje * spoštovanje!

Extremno programiranje, XP

Ostali dve metodi bom tokrat omenil le na kratko. Kristalne metode zahtevajo kar obsežno razlago, ključno pa je, da metoda sistematično nadgrajuje ekipo glede na obsežnost sprememb, ki jih vpeljuje in glede na poslovno škodo, ki bi jo povzročil morebitni neuspeh projekta. Metoda dinamičnega razvoja sistemov DSDM, pa spet na drug način opredeljuje cikle, potem ko se na podlagi študije izvedljivosti in poslovne študije razvoj izvede v treh fazah – a) razvoj funkcionalnega modela, b) zasnova in razvoj in c) uvedba. Vsaka od teh faz pa ciklično vsebuje štiri korake. Avtorji pa še posebej poudarjajo, da sta pri tem pristopu »fiksirana« čas in proračun, funkcionalnost rezultata pa je prilagodljiva, za razliko od tradicionalnega pristopa, ko določimo cilje in se projekt izvaja, dokler vseh ciljev ne dosežemo (in zato lahko zamudimo rok in povečamo stroške). Pri DSDM pa naj bi tim zaključil projekt po planu in v okviru proračuna, pri čemer manj pomembnih funkcij, ki do roka niso bile razvite, sploh ne bi razvili. Več o obeh pristopih pa si boste prebrali v knjigi.

Kanban in Scrumban

Kanban je druga najpogosteje uporabljena agilna metoda, pri čemer se uporablja tudi izven projektov, poleg tega pa je občutno starejša od večine ostalih agilnih metod in Agilnega manifesta. V Agile practice guide (PMI, 2017) navajajo, da izhaja in principov vitke proizvodnje (ang. Lean Manufacturing), razvil pa naj bi jo Taiichi Ohno in prvič uvedel v proizvodnjo v Toyoti leta 1953. »Kanban« naj bi v prevodu pomenil »kartica«, v sklopu metode pa to pomeni, da so naloge vizualno prikazane s karticami na tako imenovani Kanban tabli. S pomočjo razdelkov na tabli pa prikazujemo stanje nalog v različnih korakih izvedbe (glej sliko).

Ključni stolpci na tabli so vedno »nabor nalog« (ang. To do), »v delu« (In progress) in »narejeno« (Done), lahko pa se statusi še podrobneje delijo, kar pomeni, da se dodajo npr. analiza, razvoj, testiranje, uvedba / predaja, ipd., vsak od teh korakov pa se še dodatno deli na »v delu / izvedbi« in »narejeno«.

Tipična značilnost Kanaban metode je možnost »pull« sistema izvajanja oz. izbire nalog. To pomeni, da izvajalcem naloge niso neposredno dodeljene, ampak jih izbirajo sami. Vsak, ki izvaja določen korak naloge, v predhodnem stolpcu izbere eno od nalog in jo začne izvajati, s tem pa naloga dobi status »V delu«. Ko zaključi, listek prestavi v naslednji stolpec (narejeno), kjer jo prevzame naslednji izvajalec. Seveda pa obstaja tudi možnost, da naloge dodeljuje vodja projekta, oddelka, tima, pri čemer še vedno ohranjamo bistvo metode – vizualizacijo napredovanja projekta / nalog.

Kanban tabla

Ker ima projekt na začetku lahko sto in več aktivnosti (zahtev, funkcij, uporabniških zgodb) izvajalci ne izbirajo nalog iz celotnega nabora, ampak se v tabelo doda stolpec »pripravljeno za izvedbo«, kamor vodja oddelka, projekta ali naročnik projekta (Product Owner) iz celotnega nabora prenese v danem trenutku najnujnejše naloge. V »Scrum« žargonu bi bil torej prvi stolpec »Product Backlog«, drugi pa »Ready«. Če so v prvem navedene predvsem funkcije oz. uporabniške zgodbe, se v drugem navedejo tudi naloge, ki so del neke zgodbe. Praksa kaže, da je vse skupaj bolj obvladljivo, če so naloge dolge največ en teden, zato se uporabniške zgodbe velikokrat delijo na več manjših nalog. Delitev naj bi bila naloga lastika izdelka in managerja projekta, ki skupaj tudi določata katere naloge naj bi šle v izvedbo. Poleg zgodb in nalog pa se v prvem ali drugem stolpcu lahko znajdejo tudi napake, ki se odkrijejo pri testiranju, ali popravki že dokončanih nalog. Tip naloge se običajno opredeli z barvo listka.

Da je celoten tim bolj osredotočen, se glede na velikost tima določi, koliko nalog na enkrat lahko čaka na izvedbo. Mejno vrednost je označena s kratico WIP (ang. work in progress). Pristojni torej dodaja naloge v stolpec do meje WIP in ko eden od izvajalcev začne izvajati eno od nalog (in se ta prestavi v stolpec »v delu«), se doda nova naloga. Naloge so lahko ovrednotene z ravnijo obsežnosti, kar posredno določa predviden čas izvedbe, vodja pa lahko tudi določi rok izvedbe. No, če pristojni res uspejo »razdrobiti« naloge do ravni, ko se lahko izvedejo v enem tednu, potem je obvladovanje časa dokaj enostavno.

Metoda je manj formalna od Scruma, zato zahteva uvedba v prakso občutno manj časa in formalnosti. Potrebujemo le tablo ter uveljavitev nekaj osnovnih pravil. Za razliko od ostalih agilnih metod, Kanban tudi ni ciklična metoda, pa tudi ne vključuje dnevnih sestankov ter analiz dela (retrospektiv).

Scrumban metoda je – kot pove že ime – kombinacija metod Scrum in Kamban. Večinoma metoda sledi priporočilom Scruma, pri čemer je spremljanje nalog sprinta vizualizirano s Kanban tablo. Na začetku sprinta se torej izbrane zgodbe / naloge dodajajo v stolpec »Pripravljeno«, WIP meja pa se ne opredeli s številom nalog ampak s maksimalnim številom točk sprinta (glej prispevek o Scrumu). Če se vse izvede po planu, naj bi bile na koncu sprinta vse naloge v stolpcu »Narejeno« (ali Uvedeno / Dobavljeno). Dnevni sestanki se pri tej metodi izvajajo ob Kanban tabli.

Seveda v sodobnem »virtualnem« svetu obstajajo tudi virtualne table – programske rešitve, kjer se vse skupaj obvladuje z računalniki in telefoni. V tem primeru tablo na sestanku gledamo s pomočjo projektorja, vseeno pa mnogi še vedno prisegajo na klasičen pristop s fizično tablo in listki. Vsaj tako bi lahko sodili glede na kopico fotografij na internetu…

Scrum mojster … in ostali ključni deležniki Scrum projektov

Poglejmo vloge in naloge ključnih sodelujočih pri izvajanju projektov po metodi Scrum. Naj takoj opozorimo, da metoda ne omenja projektnega managerja oziroma naj ga ne bi potrebovali, saj naj bi se tim sam organiziral, pri čemer naj bi jim pomagal Scrum mojster.

Scrum mojstru stroka pripisuje lepo število nalog, za katere bi moral imeti visoko razvite predvsem veščine vodenja – tako prirojene, kot priučene. V prvi vrsti skrbi, da se tim (in lastnik izdelka) držijo pravil metode, seveda s tem, da jih kot Scrum trener in mentor uči uporabe tehnik in da razumejo »filozofijo« metode.

Zanimivo pa je, kako avtorji opisujejo vlogo Scrum mojstra v primerjavi s projektnim managerjem. Scwaber, ki naj bi metodo razvil (skupaj s Sutherlandom), pravi, da projektni managerji »le« delegirajo naloge (po tem, ko sami izdelajo plan) in kontrolirajo, ali se člani tima držijo njegovega plana. S tem avtor ignorira dejstvo, da je vodenje ljudi (ang. leadership) del managementa. Ali pa ameriški managerji nimajo občutka za vodenje ljudi? In zato potrebujejo Scrum mojstra, ki naj bi imel vse potrebne »mehke veščine« – mentorstvo, spodbujanje sodelovanja in inovativnosti, motiviranje…

Scrum mojster

Veseli me, da agilni pristopi dvigujejo zavedanje o pomembnosti voditeljstva, a moram opozoriti, da se stroka za to relativno (ne)uspešno trudi že pol stoletja –  poznan je npr. mrežni model avtorjev Blake in Mouton (1965), kjer so ugotavljali, da so najboljši managerji odlični organizatorji in vodje ter svoje oddelke vodijo “timsko”. Ali managerji napačno razumejo svojo voditeljsko vlogo ali pač niso rojeni za to, sedaj ne bomo razglabljali, a dejstvo je, da imamo na tem področju še veliko rezerv. No, vrnimo se nazaj na Scrum mojstra.

Scrum projekt naj ne bi imel managerja, tim naj bi bil samo-organiziran. To pomeni, da člani tima sami planirajo delo in si ga razdelijo med sabo, poleg tega pa naj bi tudi sami reševali težave, nesoglasja, različno učinkovitost in motiviranost posameznikov… To je dokaj utopično razmišljanje, kot nadgradnja nerealnih predpostavk, da smo vsi ljudje enaki, ko je govora o samo-motiviranosti, vrednotah, ustvarjalnosti, sodelovanju, znanju … in posledično enako učinkoviti pri delu. No, za vsak slučaj (ker tim nima vodje), je tu Scrum mojster, da rešuje nesoglasja in skrbi za ustrezno motiviranost članov tima.

Ob vseh teh pozitivnih lastnostih in vlogi Scrum mojstra, pa je zanimivo, da je le posredno odgovoren za uspeh projekta. Ključno odgovornost naj bi imel naročnik oz. lastnik izdelka (ang. Product owner), ki naj bi usmerjal izvedbo projekta z določanjem obsega nalog na začetku vsakega sprinta, preverjal kakovost in ustreznost rezultatov, skrbel za potrebne dopolnitve (neustreznih ali nekakovostnih) rezultatov sprintov, predlagal spremembe zahtev, ipd.

Da bi kakovostno usmerjal delo razvijalcev, mora zelo natančno poznati zahteve (proces, izdelek, potrebe posameznih uporabnikov), kar pomeni, da mora pripraviti podrobno analizo zahtev / potreb pred projektom (nabor funkcij, ang. product backlog), pred začetkom sprintov pa pripraviti uporabniške zgodbe ali pa po potrebi na planske sestanke povabiti konkretne uporabnike. Če nekako povzamemo naloge: priprava uporabniških zgodb na podlagi analiz in intervjujev, sodelovanje pri planiranju, dnevnih sestankih in reviziji / retrospektivi, pa seveda sodelovanje pri kreiranju rešitev in potrjevanje rezultatov, testiranje  … potem bi lahko rekli, da mora posvetiti projektu vsaj 50% svojega časa, če ne še več.

Za konec se še enkrat vrnimo k Scrum mojstru in primerjajmo njegovo vlogo s priporočili glede odličnosti projektnega managementa (ICB 4.0). Lahko ugotovimo, da naj bi imel Scrum mojster podobne voditeljske veščine, kot projektni manager, pri čemer ne prevzema odgovornosti (razen za dobro vzdušje in metodološko ustrezno izvajanje projekta). Formula bi bila:

Scrum mojster = projektni manager – (planiranje + organiziranje + kontroliranje + odgovornost)

Mogoče jim s tem delam krivico, a res mi ni jasno, zakaj ob vsej svoji »veličini« ne upajo (nočejo) prevzeti odgovornosti za uspeh projekta.

In še minuta za slovenski jezik. Kot ste opazili, sem uporabil pojem »mojster« in ne angleškega – master, kot se naslavlja večina slovenskih Scrum mojstrov. Zavoljo »oživljanja« mojstrstva bi rad spomnil, da je mojster direktni prevod besede master, pogostejša uporaba v projektnem okolju pa bi najbrž pomagala k »ohranitvi« mojstrske vloge. Zdi se mi, da so mojstri nekako ogrožena vrsta v sodobnem svetu. Čeprav me po drugi strani skrbi, da je za »moderne« managerje mojster preveč zastarel izraz in raje uporabljajo nekakšne slengovske tujke (npr. »na sestanek smo povabili tri Scrum mastre).

Page 2 of 3

Powered by WordPress & Theme by Anders Norén