Projektni management

Blog, debatni večeri, raziskave, knjiga…

Agilna organizacija

V zadnjih letih se je močno uveljavil pojem »VUCA« svet. VUCA je kratica besed nestanovitnost, negotovost, kompleksnost in nejasnost (angl. volatility, uncertainty, complexity, ambiguity). Načeloma pa že kakih 30 let govorimo o tem, da je sprememba edina stalnica našega službenega in privatnega življenja. Informacijska revolucija je res »vrgla svet s tečajev«.

Seveda je vsem jasno, da se je spremembam v okolju treba prilagajati, če želiš preživeti in biti konkurenčen, zato se spreminja tudi organiziranost podjetij in drugih združb (organizacij). Res je, da se vse branže ne spreminjajo enako hitro, pa tudi velikost podjetja (in s tem povezan tržni položaj) vpliva na nujnost in hitrost spreminjanja. Sicer nismo nikjer zasledili trditev, da bi se morale vse združbe nujno prestrukturirati, poglejmo pa, kaj razumemo pod pojmom agilna organizacija in na kakšen način se tradicionalne prelevijo v agilne.

Ob proučevanju literature smo se hitro spomnili na projekte informatiziranja poslovnih procesov, ki so se začeli v 90-tih letih prejšnjega stoletja. Informatizacija je seveda zahtevala tudi prenovo poslovnih procesov, saj je programska oprema avtomatizirala mnoge postopke in procese. Zgodila pa se je tudi velika sprememba v delu managerjev. Naj spomnimo, ključna vloga managerjev je usklajevanje (aktivnosti, zaposlenih, sredstev) ter odločanje (organizacijsko, vsebinsko in strokovno), procesno gledano pa management vključuje planiranje izvajanja nalog, organiziranje ljudi, vodenje ljudi in kontroliranje izvedbe. Pomembno »vsebinsko« področje je tudi skrb za zadovoljivo usposobljenost podrejenih, kar pomeni, da skrbijo za redna dodatna izobraževanja in usposabljanja.

Ukinitev managerskih ravni za večjo agilnost organizacije

V omenjenem času informatizacije pa se je obremenjenost managerjev z navedenimi nalogami močno zmanjšala, saj so njihovi podrejeni začeli dobivati mnogo nalog mimo njih (poslovni procesi!), z opolnomočenjem ljudi pa se je veliko odločanja delegiralo na nižje ravni – manager je po uvedenih spremembah npr. odločal le še o 20% izjemnih primerih, med tem, ko je podrejeni sam sprejel 80% strokovnih (vsebinskih) odločitev. Z manj usklajevanja (kdo bo kaj naredil) in odločanja se je obremenitev managerjev z operativnim delom znižala, zato so mnogi strokovnjaki takrat trdili, da bi morali managerji po novem 50% svojega časa posvetiti razmišljanju, kako bi svojim podrejenim olajšali delo (sistem, metode, dodatna znanja, ipd).

Po drugi strani se je – vsaj tako je slutiti iz mnogih »agilnih« člankov – odvijala borba med izvajalci aktivnosti in managerji projektov (če se omejimo le na projekte, kjer se je agilni pristop najprej uveljavil). Po mnenju prvih, so managerji postavljali nerazumne roke in pozabili, da odličnega managerja – poleg organizacijskih – krasijo predvsem njegove voditeljske veščine. Ne trdimo, da je to ključni vzrok, da so »agilneži« začeli zagovarjati samo-organizirane time (v smislu »postite nas pri miru, mi bolje vemo, kako je treba kaj narediti, kot vi«), je pa vsekakor eden od pomembnejših razlogov.

Žal pa tudi pri samo-organiziranih timih ne gre vse brez težav, poleg tega se v »agilnem svetu« nekako zanemarjajo osebnostne lastnosti ljudi – predpostavlja se, da so vsi ljudje enaki ali vsaj zelo podobni, ne glede na to, da je nekdo bolj ustvarjalec, drugi voditelj, tretji analitik in četrti »prodajalec«. Da ne govorimo o tem, da so nekateri bolj timski delavci, kot drugi, eni bolj uživajo v svojem delu, eni živijo za kariero, ipd. Tako se je pojavila »formalna vloga« uslužnega vodje (o čemer smo že pisali), torej nekoga, ki je koordinator tima, katerega član je, ne pa kot nadrejeni manager.

Vse navedeno je nekako pripeljalo do tega, da so moderne agilne organizacije zmanjšale število managerski ravni, managerji pa so se pridružili timom, katerimi so bili prej nadrejeni (slika 1). No, težko je reči, da so se take spremembe res dogajale v večjih starejših organizacijah, vsekakor pa so mlajše organizirane bolj plosko. Opozorimo pa še na to, da je o agilni organizaciji veliko lažje govoriti v primeru »virtualnih« izdelkov oz. storitev (torej, kadar podjetja ne proizvajajo fizičnih izdelkov) – IT podjetja, storitve bančništva in zavarovalništva, marketinške agencije, spletne rešitve, ipd…

Kot trdi Holub (2015), je šel proces prestrukturiranja še naprej. Kot vidite na desni strani prve slike, so »nadrejeni« narisani pod izvajalskimi timi. Avtor trdi, da »nadrejeni« v agilnih organizacijah ne ukazujejo, delegirajo in kontrolirajo, ampak »uslužno« skrbijo, da timi ustvarjajo š čim manj težavami. No, nekdo mora tudi poskrbeti, da timi proizvajajo »prave stvari«, kar pomeni, da imajo nadrejeni še vedno pristojnosti odločanja, kateri projekti se bodo izvajali.

Agilna organizacija – managerji se preselijo v time

Mnogi »agilni« avtorji tudi omenjajo »silose«, kot značilnost zastarelih organizacij. Saj veste, gre za sindrom »mi in oni … mi smo najboljši, z njimi si ne moremo pomagati«, kar naj bi pomenilo, da se oddelki brigajo le za svoje naloge in težko sodelujejo z drugimi. Res se to še dogaja, a v bolj mili obliki, kot včasih. Predvsem pa so več-disciplinarni projektni timi (ki se niso pojavili šele z agilnostjo) promotorji in spodbujevalci sodelovanja med različnimi strokami in oddelki. No, poleg projektne matrične organizacije obstajata tudi produktno ali regijsko matrična organizacija, ki spodbujata sodelovanje in rušita silose in nevidne zidove med oddelki.

»Agilna nadgradnja« matričnih organizacij pa je prej omenjeno vključevanje managerjev / vodij v delo timov (desna stran slike 2). Managerji projektov so tako postali uslužni vodje timov, managerji področij (funkcijski, regijski, produktni) pa strokovni koordinatorji svojih področij. Poleg tega, da na enem projektu opravljajo svojo strokovno nalogo (kot član tima), so povezovalci vseh zaposlenih iz svojega področja, kjer skrbijo za razvoj stroke in medsebojni prenos dobre prakse (ter opozarjanje na težave in slabo prakso). Naj omenimo še to, da so v nekaterih agilnih organizacijah time preimenovali v moštvo (angl. squad), če pa ima projekt več timov, pa se skupaj imenujejo pleme (angl. tribe).

Za konec pa še – bolj za šalo, kot zares – pohvalimo »agilno« zavest slovenskih managerjev. Čeprav strokovnjaki stalno poudarjamo nujnost profesionalizacije projektnega managementa (zaradi potrebnih organizacijsko vodstvenih veščin managerjev), se v naši praksi to relativno slabo upošteva. Tako projekte – poleg svojega strokovnega dela – vodijo ključni strokovnjaki, kar je v vseh pogledih agilno. Ali pa imajo najboljši »kreativci« tudi sposobnosti uslužnega vodje, je pa že druga zgodba…

Pogodbena razmerja agilnih projektov 2

Vrste pogodb, ki smo jih obravnavali v prejšnjem prispevku, smo povzeli po priročniku ameriškega globalnega združenja PMI (Agile practice guide, 2017). Poglejmo pa si še nekaj drugih vrst. Pogodbo »Čas in material« (angl. Time & Materials), sicer pogosteje uvrščajo med »tradicionalne« pogodbe, a se uporablja tudi pri agilnem pristopu, pri čemer se pri slednjem več omenja nekoliko modificirana različica »Omejen čas in material« (angl. Capped Time & Materials). Ta tip pogodbe, ki je neke vrste hibrid med »Fiksno ceno« in »Stroški+«, se najpogosteje uporablja, kadar obseg projekta ni zadosti jasno opredeljen, da bi omogočal dober plan izvedbe (in s tem plan stroškov). Tipični projekti so raziskovalni in svetovalni, pa tudi nekateri IT projekti.

Medtem, ko naročnik material plačuje na podlagi faktur, ki jih je plačeval izvajalec, se delo slednjega obračunava po v pogodbi opredeljenih urnih ali dnevnih postavkah – izvajalec npr. v ponudbi zapiše, kolikšen je strošek ure dela programerja (poslovnega analitika, arhitekta,…), naročnik pa izvajalcu plača število ur posameznih izvajalcev v dogovorjenem obračunskem obdobju (cikel, mesec, faza projekta). Če pa predpostavimo, da imajo izvajalci v teh urnih (dnevnih) postavkah že vračunan pričakovan dobiček (provizijo), je ta pogodba v delu, ki se nanaša na delo zaposlenih, v bistvu pogodba »Fiksni stroški +« oziroma še celo bolje »Fiksni dobiček« (angl. Fix profit), kjer dobiček raste s številom ur dela. Odlično za izvajalca – tveganja napak, sprememb in vsega dodatnega dela prevzema naročnik.

Za naročnika podpis take pogodbe pomeni, da mora skrbno nadzirati delo izvajalca, predvsem učinkovitost ljudi. Če naročnik nima strokovnjaka, da bi kompetentno ocenil realnost planiranih in porabljenih ur dela izvajalca, mu pač ostane le zaupanje, da izvajalec ne bo pretiraval s količino ur dela… Ponovno pa opozarjamo na težavnost izbire pravega ponudnika na podlagi urne postavke, saj v ponudbi ni navedbe količine ur. No, tveganje se nekoliko zniža pri pogodbi »Omejen čas in material«.

Pogodba “Omejena cena in material”

Tudi agilni projekti poznajo pogodbe s fiksno ceno, vendar se cena ne določi za celoten projekt, ampak za del projekta (vsebinsko ali časovno). Obstajajo pogodbe z določeno fiksno ceno na točko uporabniške zgodbe, cikel ali fazo. Plačevanje po fazah smo omenili že prejšnjič, a takrat smo govorili o faznih pogodbah (z različnimi cenami). V primeru pogodbe s fiksno ceno na cikel se cikli izvajajo, dokler je naročnik pripravljen plačevati izvajalca, dokler ni zadovoljen s funkcionalnostjo proizvoda oziroma ko je dosežena želena dodana vrednost. Za naročnika je ta vrsta pogodbe še posebej uporabna v pogojih stalne dobave uporabnih delov končnega proizvoda (angl. Incremental Delivery), če mu vsak cikel prinese dodano vrednost. Nekateri celo odsvetujejo agilne pogodbe, če ni možno projekta razdeliti v več inkrementalnih dobav (www.people10.com).

Sicer pa, kot smo že omenili v enem od uvodnih »agilnih« prispevkov: dokler vsak cikel prinese naročniku več denarja, kot je plačal izvajalcu (takoj, kmalu oz. v razumnem časovnem obdobju), ne bo želel zaključiti projekta. No, v tradicionalnem pogledu to ni več projekt (ker zaključek ni vnaprej opredeljen), je pa zato vsak cikel neke vrste mini projekt.

Pogodba “Fiksna cena na cikel”

Omenili smo tudi fiksno ceno na točko zgodbe (angl. story point). Tudi ta je podobna pogodbi »Fiksna cena +«, s to razliko, da je tam že na začetku določena cena za uporabniške zgodbe, pri tej pa se določi le vrednost točke, zahtevnost uporabniške zgodbe pa se določa na začetku ciklov. Seveda ni potrebno posebno poudarjati, da naročnik pri izbiri izvajalca ne more vedeti, koliko ga bo projekt stal, in tudi ne more primerjati ponudb izvajalcev – ceno na točko lahko primerja, a ne ve, s koliko točkami bo posamezno zgodbo ocenil izvajalec.

Za konec pokomentirajmo še tisto od štirih vrednot agilnega manifesta, ki se nanaša na pogodbena razmerja: »Sodelovanje s stranko pred pogodbenimi pogajanji!« Jen-Chieh Ko (2017) recimo trdi, da če prepustimo pripravo pogodb pravnikom (poimenuje jih »Pravni vojščaki«, angl. Legal Warriors), bo pogodba za obe strani slaba (angl. Lose-Lose), saj naj bi bila po njegovih besedah (in po videnju pravnikov) dobra pogodba tista, ki je nobena stran noče z veseljem podpisati. Kot mnogi, tudi on poudarja zaupanje, ki je dejansko po našem mnenju ključna vrednota v ozadju agilnih pristopov. Zaupamo, da so člani tima samo-motivirani in da bodo v čim krajšem času prinesli naročniku ogromno dodano vrednost, naročnik pa jih bo za to pošteno nagradil.

Pa vendar, če smo vsi korektni in si zaupamo, potem brez težav podpišemo pogodbo, ki naše namere formalno zabeleži. Saj poznate tisto: »Čisti računi, dobri prijatelji«. Imamo pa Slovenci mogoče malo težav glede »poštenosti«, ker smo se zaradi tujih vladarjev v zgodovini naučili, da goljufanje (oblasti in tujih lastnikov) ni grdo neetično opravilo, ampak »iznajdljivost« in neke vrste »poslovna igra«. Pa vendar, če želimo uspešno uveljaviti agilne pristope izvajanja projektov, bo treba delati na etičnosti tako naročnika, kot izvajalcev. Sodelovanje, transparentnost in zaupanje … pa ne pozabite: če ni nevoščljivosti, bomo vsi pridobili!

Pogodbena razmerja agilnih projektov 1

Ko smo že omenili, naj bi na odločitev o uporabi tradicionalnega ali agilnega pristopa najbolj vplivala jasnost opredelitve končnih ciljev na začetku projekta in s tem povezana (ne)rutinska izvedba projekta, dodaten pomemben dejavnik pa je možnost koriščenja vmesnih rezultatov in s tem povezane dodane vrednosti, ki jo prinaša projekt. Ta naj bi pri agilnem pristopu rasla ves čas trajanja projekta, pri tradicionalnem pa dodano vrednost prinese šele povsem zaključen projekt.

Ker našteti dejavniki vplivajo na možnost jasne ocene (opredelitve) časa in stroškov izvedbe, ki skupaj z obsegom (ki naj bi bil pri agilnih projektih manj natančno opredeljen) predstavljajo ključne postavke pogodbe med naročnikom in izvajalcem, potem je jasno, da se tradicionalne pogodbe zelo težko uporabljajo za agilne projekte. Razlika v »jeklenih projektnih trikotnikih« (obseg, čas, stroški) je lepo prikazana na prvi sliki, pri čemer bi opozoril na trditev avtorjev, da agilni pristop temelji na viziji projekta, kar bi pomenilo, da sledi predvsem dodani vrednosti, ki jo prinaša projekt.

Razlike med pristopi, ki vplivajo na izbiro tipa pogodbe (povzeto po AOE.com)

Ena od oblike pogodb, ki poudarja usmerjenost v ustvarjanje koristi, je, da se pogodba ne podpiše za celoten projekt, ampak za vsako fazo posebej, cene pa se opredelijo na osnovi dodane vrednosti rezultatov faz. Faze načeloma niso cikli (sprinti), ampak več teh skupaj (pri IT projektih je npr. cilj faze izdaja (ang. release) nove verzije programske opreme z dodatnimi funkcijami). Ta tip pogodbe je lahko del obsežnejše več-nivojske pogodbe, kjer se  pogodbeni odnos doreče z več dokumenti – v glavnem so dorečene zadeve, ki se ne spreminjajo (npr. garancije, arbitraža); zadeve, ki se lahko spreminjajo (npr. cene storitev, opisi izdelkov) se opredelijo v terminskem planu storitev, dinamične postavke, kot so obseg, časovni razpored in proračun, pa se formalizirajo v izjavi o delu. Ključna težava faznih pogodb pa je v tem, da težko primerjamo ponudbe različnih izvajalcev, ko izbiramo najustreznejšega.

Dodatna težava pogodb, ki slonijo na dodani vrednosti, pa je tudi merjenje slednje, kar je lahko velik izziv. Eno je merjenje neposrednih in posrednih koristi. Če razvijamo programsko opremo za podporo procesu reklamacij, so neposredni učinki manjše število reklamacij, hitri odzivni čas, manj ur dela ljudi, ne moremo pa pomeriti dviga ugleda firme, posledično več naročil, ipd. Seveda je težava lahko tudi v tem, da izvajalec ne sme videti določenih poslovnih kazalnikov (poslovne skrivnosti). Taka pogodba torej zahteva veliko stopnjo zaupanja med naročnikom in izvajalcem. Je pa res, da ima običajno v takem pogodbenem (partnerskem) odnosu izvajalec obsežnejšo nalogo – če je pri tradicionalnem razvoju programske opreme le »razvijalec«, je pri agilnem tudi »ustvarjalec« (sodeluje pri razvoju »poslovne« rešitve, ne le programske opreme). Če je govora o dolgoročnem sodelovanju (brez časovne omejitve), kjer izvajalec pomaga naročniku že pri analizi delovanja in iskanju smotrnih sprememb, ki jih potem skupaj razvijejo in uveljavijo, govorimo o pogodbi »Razširjena ekipa«.

Naslednji tip pogodbe je »Fiksna cena +«. Obseg projekta se razdeli na mikro-rezultate (npr. uporabniške zgodbe) s fiksnimi cenami. Naročniku omogoča večjo kontrolo porabe denarja, izvajalcu pa zniža finančno tveganje prekomernega dela na raven posamezne funkcije. Veliko težavo pa vidimo v tem, da se uporabniške zgodbe jasno opredelijo šele na začetku posameznih ciklov. Kako naj torej izvajalec lahko realno oceni strošek razvoja uporabniških zgodb, če te še niso opredeljene?

Pogodba »Fiksiran rok in proračun« je oblika, ki popolnoma sledi temu, kar smo jo prikazali na prvi sliki. Prilagodljiv obseg projekta pomeni, da lahko naročnik – v okviru dogovorjenega časa in proračuna – v projekt vključi nove zahteve (funkcije, opravila), ki prvotno niso bile načrtovane, pri čemer naj bi te zamenjale nekatere prvotno planirane. Ta način sloni na pristopu, da lastnik izdelka na začetku vsakega cikla izbere v tistem trenutku najbolj pomembne funkcije … do porabe vseh sredstev in/ali do dogovorjenega roka, najmanj pomembne funkcije pa se ne razvijejo. Zasledili smo tudi poimenovanje Pogodba z dinamičnim obsegom, poznana pa je tudi pod nazivom »Money for nothing, change for free.«. Nekateri avtorji pa priporočajo tudi, da proračun, poleg planiranih stroškov, vsebuje tudi rezervni sklad za primer dodatnih ur dela. Dodatna možnost je deljenje finančnega tveganja, po pogodbi »Dosežen čas in proračun«. Izvajalca je mogoče nagraditi z višjo urno postavko v primeru dobave pred dogovorjenim rokom oz. dobi manjše plačilo v primeru zamude izvedbe.

Večino dodane vrednosti projekta lahko prinese le polovica predvidenih funkcij

Na predpostavki, da lahko želeno dodano vrednost projekta dosežemo v manj funkcijami, kot smo jih opredelili na začetku, sloni pogodba »Možnost predčasne odpovedi«. Če izvajalec pred rokom (tudi na polovici projekta) zadovolji potrebe naročnika, slednjemu ni potrebno plačati preostalega pogodbenega zneska (v pogodbi se določi nadomestilo za prekinitev pogodbe). Naročnik zniža stroške projekta, izvajalec pa dobi plačilo za storitve, ki jih ni potrebno izvesti. Smiselnost predčasnega zaključka projekta je prikazana na drugi sliki, ki izpostavlja tudi pomembno značilnost projekta, ki vpliva na odločitev, ali se projekta lotiti tradicionalno ali agilno – stalno rast dodane vrednosti. Uporaba agilnega pristopa je zelo priporočljiva, če je možno koristiti vmesne rezultate! To je možno pri razvoju programske opreme, novozgrajenega objekta pa ne moremo (ne smemo) uporabljati, če vsa dela niso zaključena! Na pol razvitega avta pa tudi ne moremo začeti tržiti.

Vrste pogodb smo povzeli po priročniku Agile practice guide (PMI, 2017).

Tradicionalna pogodbena razmerja

Pri vseh tipih projektov investitorji del projekta pogosto zaupajo v izvedbo pogodbenim izvajalcem, lahko bi celo trdili, da večina projektov vsebuje vsaj nekaj pogodbenega dela. Za podjetja, katerih ključni posel pa je izvajanje projektov za druge (gradbena in druga inženiring podjetja, IT podjetja, organizatorji dogodkov, svetovalna podjetja, odvetniške pisarne, ipd.), pa vse projekte izvedejo na podlagi pogodb z naročnikom.

Poleg jasne opredelitve obsega projekta in nedvoumnih specifikacij ciljev (s kriteriji kakovosti), pogodbe vključujejo tudi ključna kriterija učinkovite izvedbe – rok in ceno izvedbe. Pri tem seveda velja, da ceno storitve sestavljajo stroški izvedbe in provizija izvajalca (dobiček, ki ga ustvari s projektom), za naročnika pa cena predstavlja njegov strošek po naslednji formuli:

Strošek naročnika = cena storitve = stroški izvajalca + provizija izvajalca

Zelo redko pa se zgodi, da so dejanski stroški izvajalca enaki planiranim. Eden od možnih razlogov je seveda neustrezna ocena izvajalca, obstaja pa še kar nekaj drugih virov spreminjanja stroškov: spremembe zahtev naročnika, dražitev / pocenitev materiala, tehnične težave, nepredvidena dela, itd. V primeru višjih dejanskih stroškov od planiranih bo izvajalec zaslužil manj (manjša provizija), lahko pa se tudi zgodi, da bo projekt izvedel z izgubo. Zato se želi s pogodbo zavarovati tako, ne bo kril vseh dodatnih stroškov, ki niso neposredno njegova krivda (kot je npr. napačna ocena), ampak si kritje le-teh razdeli z naročnikom.

Po drugi strani želi naročnik s pogodbo znižati možnost zamude izvedbe s strani izvajalca, najpogosteje pa se to izvede s stimulativno »nagrado« – ob izvedbi pred rokom, je lahko plačilo višje, ob zamudi pa manjše. To je torej še dodatni dejavnik dejanske končne cene in dodatna pomembna postavka pogodbe.

Poglejmo najprej »tradicionalne« pogodbe (največkrat uporabljanje v gradbeništvu, pa tudi pri »neagilnem« razvoju programske opreme) in ocenimo primernost le-teh za agilne projekte. Poznamo dve osnovni skupini pogodb – pri prvi se v pogodbi določi cena, pri drugi pa stroški in provizija izvajalca.

Verikalna črtkana črta prikaže delitev denarja v določeni situaciji

Najbolj poznana je Pogodba s fiksno ceno. Izvajalec prevzame celotno tveganje s tem, ko sprejme nespremenljivo plačilo za delo, ne glede na dejanske stroške. Pogodba je značilna za projekte “na ključ”, kjer izvajalec prevzame celotno odgovornost, naročnik pa na samo izvedbo nima vpliva, kjer je zelo jasno opredeljen končni cilj (in se večjih sprememb ne pričakuje), poleg tega pa je način izvedbe dokaj »rutinski«. V primeru sprememb obsega in specifikacij sledijo dodatna pogajanja in podpis aneksa. Ker zahteva ta vrsta pogodbe jasno dorečene cilje in »fiksiran« končni rok, je neprimerna za agilne projekte.

Če želimo izvajalca stimulirali za učinkovitejše obvladovanje stroškov in izvedbo pred rokom, izberemo pogodbo s Fiksno (maksimalno) ceno in stimulativno provizijo (ang. Fixed price incentive fee, FPIF). Poleg bonusa za izvajalca, če zaključi izvedbo pred rokom, oz. penalov v primeru zamude, pogodba opredeli tudi kdo krije morebitne dodatne stroške. Izvajalcu ta tip pogodbe ustreza prav z vidika skupnega prevzemanja tveganj, pri čemer se v pogodbi doreče delež prevzema tveganj (npr. 40/60%). Priporoča se, da večji delež prevzame stranka, ki laže obvladuje več tveganj (npr. napake pri izvedbi veliko lažje obvladuje izvajalec, kot naročnik). V razmerju, kot je zabeleženo v pogodbi, tako stranki pokrijeta prekoračitev stroškov ali pa si razdelita prihranek, če so dejanski stroški manjši od planiranih). Velikokrat take pogodbe vključujejo tudi nabor ključnih tveganj in oceno pomembnosti le-teh. Ta pogodba je nekoliko primernejša za agilne projekte, saj vsebuje mehanizem prilagajanja cene ob spreminjanju količine dela, vseeno pa zahteva jasno opredelitev ciljev ob podpisu pogodbe, kar ni značilno za agilne pristope.

Obstaja pa še tretji tip pogodbe s fiksno ceno, imenujmo jo Prilagodljiva fiksna cena   (ang. Fixed price economic price adjustment, FP_EPA), ki prvi tip pogodbe (Fiksna cena) nadgradi z možnostjo spremembe cene zaradi sprememb cen materialov in vrednosti denarja. Govora je o morebitni inflaciji, nihanju valut, spreminjanju cen surovin, ipd. Uporablja se predvsem za daljše mednarodne projekte, kjer je več možnosti inflacije in sprememb cen. Kljub prilagajanju je ta pogodba, iz istih razlogov, kot prva, neprimerna za agilne projekte.

Drugi tip tradicionalnih pogodb ima za osnovo stroške projekta, poznamo pa jih pod nazivom »Stroški+«. Osnovna opcija je pogodba Stroški+ s fiksno provizijo. Izvajalec poroča naročniku o stroških izvedbe, ki mu jih naročnik povrne, ob tem pa še vnaprej dogovorjen dodatek (provizijo, kot % planiranih stroškov). Ne glede na višino stroškov je provizija izvajalca enaka. Ta pogodba je primernejša za agilne projekte, če predpostavimo, da se stroški spreminjajo z spremembami zahtev (obsega). Je pa res, da se donosnost projekta z naraščanjem stroškov (pri nespremenjeni proviziji) manjša, kar ni motivacijsko za izvajalca. Zato obstaja še opcija, kjer »fiksna provizija« pomeni fiksen % dejanskih stroškov (večji stroški > večja provizija), a o tem več v knjigi.

Drugi tip pogodbe je Stroški+ s stimulativno provizijo, pri katerem se provizija spreminja z višino dejanskih stroškov. Pri nižjih stroških od planiranih je dodatek višji, pri višjih pa nižji. Npr. izvedba po planu prinaša izvajalcu provizijo v višini 4% stroškov, v primeru prihranka 6%, ob presežku pa le 1%). Lestvica pa je lahko še bolj progresivna, kjer presežek lahko pomeni tudi izgubo za izvajalca (glej sliko). Zaradi slednjega je pogodba nesprejemljiva za izvajalce agilnih projektov.

Tretji tip pogodbe – Ciljni stroški – je v določenem tolerančnem polju planiranih stroškov podoben pogodbi s fiksno ceno – izvajalec dobi nespremenljivo plačilo kadar so stroški npr. za največ 10% višji ali manjši od planiranih (prihranki gredo izvajalcu, ki krije tudi presežke), v primeru večjih prihrankov ali presežkov pa si izvajalec in naročnik te razdelita v vnaprej dogovorjenem razmerju (kot je to veljalo pri pogodbi s Fiksno ceno in stimulativno provizijo). Tudi ta tip pogodbe je značilen za pogodbe, ki vključujejo tudi oceno tveganj in se običajno uporablja pri razvojnih projektih, ko je rezultat relativno dobro poznan, a ne v celoti (zato je primeren tudi za agilne projekte). Izvajalec se lahko dogovori tudi za odstotke trženja izdelka.

Mednarodni virtualni (agilni) timi

V prejšnjih prispevkih smo pisali o tem, da zagovorniki agilnih pristopov priporočajo, da so agilni timi majhni, da so med delom locirani v skupnem prostoru, najboljša komunikacija pa je pogovor ob tabli. Za primere obsežnejših projektov pa priporočajo, da se projekt izvaja v večjem številu (majhnih) timov, kar je sicer podobno običajni organizaciji večjih projektov. Zelo pomembna razlika pa je v tem (vsaj kolikor smo uspeli razumeti priporočila stroke), da naj bi pri agilnem pristopu ljudje 100% delali le pri enem projektu, kar pa je v naši projektni praksi žal bolj izjema, kot pravilo. Večina projektov je organizirana matrično, pri čemer ljudje istočasno delajo v več timih (več-projektno okolje), timi pa so več-disciplinarni (sodelujejo ljudje iz različnih strok, časovno pa so različni strokovnjaki različno obremenjeni). Ker so oddelki locirani na različnih lokacijah (lahko v objektu, lahko v enem kraju, lahko po celem svetu), se združbe vse bolj poslužujejo različnih medijev za komuniciranje na daljavo, namesto da bi izgubljali čas in denar za potovanja. Ne smemo pa zanemarjati niti komuniciranja z naročnikom in podizvajalci.

Kadar člani tima niso locirani skupaj, govorimo o virtualnem timu in delu (sodelovanju) na daljavo. Komuniciranje je delno osiromašeno (razlaga), a moderna orodja za video komuniciranje zagotavljajo dokaj zadovoljivo sodelovanje. Pri proučevanju literature smo našli kopico priporočil za uspešno delovanje virtualnega tima. Čeprav ljudje delajo na daljavo, je priporočljivo, da se na začetku projekta srečajo v živo, da se med seboj bolje spoznajo. Uvodni sestanek (ang. kick-off meeting) izkoristimo tudi za pogovor o problemih (in dobrih praksah) v predhodnih virtualnih timih, na podlagi česar tim skupaj doreče pravila komuniciranja, določijo pa se tudi enotna orodja za sodelovanje na daljavo.

Priporočljivo je, da se uvodni sestanek nadaljuje z izgradnjo tima (ang. team building). Vsekakor priporočamo, da vodja tima opravi tudi individualne pogovore s člani tima – o njihovih vrlinah, slabostih, (de)motivatorjih, ter o tem, kaj jim pomeni projekt (izziv, priložnost za razvoj ali dodatno delo).

Virtualni tim in sodelovanje na daljavo

Med samo izvedbo je potrebno skrbeti za redno komunikacijo. Pri virtualnih timih se še bolj kot sicer priporoča izvedba kratih dnevnih sestankov (ang. daily Scrum), nekateri avtorji pa priporočajo tudi »virtualne kave« (pitje kave na daljavo ob pogovoru, ki ni vezan na delo), pa tedensko proslavitev uspehov tima (zaključevanje težjih nalog ali tistih nalog, ki so bile zelo dobro izvedene v zadnjem tednu). Redno komuniciranje, poleg strokovnih usklajevanj in debat, tudi dviguje pripadnost timu in projektu. Poleg osebnega komuniciranja pa ne smemo pozabiti na obvladovanje dokumentacije!

Moramo pa opozoriti tudi na različne oblike virtualnih timov, ki vplivajo na razmerja in naloge managerja projekta. Ena oblika so partnerski projekti, kjer manager le koordinira delo timov (pri čemer večine ljudi ne vodi (ang. leadership), prisotnega je manj timskega dela, razmerja pa so dorečena s pogodbami). Druga oblika ne vključuje pogodbenih odnosov, vsi člani tima pa so interni sodelavci (lahko tudi iz sestrskih / hčerinskih podjetij), kar pomeni, da manager tudi vodi (motivira) ljudi, več pa je tudi (med)timskega sodelovanja (ustvarjalne delavnice in soodvisne / skupne aktivnosti na daljavo). Tretja oblika je kombinacije prej navedenih. Razlika je tudi v tem, ali imamo dislociran tim (z vodjem na lokaciji) ali posameznike (ang. freelancer), ali delajo v službi ali od doma, itd. O tem več v knjigi…

Lewisov model med-kulturnega komuniciranja

In če še malo dodatno zakompliciramo situacijo, ne smemo pozabiti na mednarodne virtualne time, ki so pogosti v partnerskih projektih, če ima podjetje hčerinske / sestrske podjetja na različnih kontinentih, pa tudi če iz drugega kontinenta prihaja naročnik ali kak podizvajalec. Poleg težave z različnimi časovnimi conami, velikokrat naletimo na druge kulture, kjer imajo različne stile komuniciranja (če se omejimo le na ta pokazatelj med-kulturnih razlik). Najbolj poznan je Lewisov model, v katerem je opredelil tri ključne kulture (glej sliko), države pa razporedil kot tipične za en stil ali med te. Seveda je za dobro sodelovanje potrebno poznati čim več značilnih dejavnikov kulture (znana je npr. Hofstedejeva teorija dimenzij kulture). Za uspešno komuniciranje se je treba zavedati značilnosti kultur, pri čemer pa ni zadosti le prilagoditi stila pogovora – ne smemo niti dopustiti, da nas sogovornikov način moti in nas spravlja ob živce, ker potem manj pogosto komuniciramo oz. pogovore (pre)hitro zaključimo. Nekateri celo na ljudi, ki ne komunicirajo »kot bi morali«, gledajo z viška in z njimi ne želijo sodelovati.

Naj omenimo še težavo z znanjem angleščine, slabšo izgovorjavo (kot posledica sinhroniziranih filmov) in naglase (Indija). Včasih je v teh primerih boljša komunikacija preko e-pošte, še boje pa je uporaba video konference, kjer se slišimo in vidimo, za boljše razumevanje pa še kaj napišemo ali narišemo na tablo.

Komuniciranje v (agilnem) timu

Ob pregledu literature o posebnostih komuniciranja v agilnih timih smo prišli do zanimive dileme. Medtem, ko je v zadnjih dveh desetletjih v porastu število partnerskih projektov, ki slonijo na virtualnih timih in delu na daljavo (ki se je zaradi znanih okoliščin še posebej uveljavilo v letošnjem letu), agilni pristopi slonijo na timih, ki delajo v enem prostoru. Pisali smo že, da se priporoča, da so agilni timi majhni, zasledili pa smo trditve, da je pogoj za učinkovito (so)delovanje tima, da delajo skupaj (ang. co-located) in da je z dislociranimi člani agilnega tima težko sodelovati.

V projektnem timu imamo, ne glede na pristop (tradicionalni ali agilni), naslednje vrste komuniciranja: medsebojno strokovno/vsebinsko usklajevanje članov tima, organizirane ustvarjalne delavnice (iskanje idej, reševanje težav), koordiniranje dela (razdeljevanje nalog) in poročanje o izvedbi. Pri tradicionalnih projektih imamo še planske sestanke v fazi priprave projekta ter obravnavo sprememb med izvedbo, pri agilnem pristopu pa so planski sestanki v vsakem ciklu, ki se konča s skupno revizijo in retrospektivo.

Za vse navedeno velja, da na kakovost komuniciranja in izmenjave informacij vplivajo trije »mediji«, ki se dopolnjujejo: napisana ali povedana informacija (pisna ali ustna), telesna govorica ob ustnem podajanju informacije (ki je pri pisnem komuniciranju ni, pri telefonskem pogovoru pa je okrnjena), ter vizualizacija, ko »tekst« nadgradimo z »grafiko« – komuniciranje je veliko učinkovitejše, če ob debati še kaj narišemo na tablo, pa naj bo to pot dokumenta v podjetju, proces dela prodajnega referenta, tloris naprav in transportnih poti v proizvodni hali, skica novega izdelka ali tiskanega vezja, ali pa le zapišemo ključna dejstva, npr. prednosti in slabosti neke ideje (da so članom tima stalno pred očmi, ko se odločajo za »pravo« idejo).

Načini komuniciranja (Prince, 2017)

Vse navedeno je lepo prikazano v grafu, ki smo ga povzeli po Princeu. Zvočni posnetek je boljša informacija, kot le napisan tekst, saj dodaja ton izgovorjenega, delno pa se zazna tudi obrazna mimika (ali se je govoreči pri podajanju informacije smehljal ali je govoril jezno »skozi zobe«). Mnogi se ob tem spomnijo na Mehrabianovo pravilo 7-38-55, ki govori o tem, da sporočilo, ki ga dobimo od nekoga, sestavljeno takole: 7% besede + 38% ton govora + 55% obrazna mimika. Vendar pa moramo opozoriti, da pravilo ni splošno veljavno, ampak velja le za primer izražanja čustev in stališč (všeč mi je, ni mi všeč). Nekje sem našel zanimiv primer glede (ne)veljavnosti pravila v vseh primerih: nemogoče je razumeti informacijo, če na TV poslušate in gledate nekoga (38%+55%), ki govori v nekem afriškem jeziku (le 7%).

Vsekakor zaznavanje tona govora in opazovanje telesne govorice vpliva na komuniciranje v timih, a ne v takšni meri, kot navaja Mehrabian. Pokaže nam, kako sodelavec sprejme neko delo v izvedbo, kako je navdušen nad neko idejo (ali če mu ni všeč), opazimo, kdaj je brezbrižen ob neki debati, koliko ga je neka težava ali napaka vrgla s tira, in konec koncev tudi, če pošteno poroča o opravljenem delu. Glede slednjega si lahko veliko preberete na internetu (znaki, da nekdo laže).

Video posnetek je torej še boljši od zvočnega, na grafu pa opazimo, da je med njima e-pošta, ki pa je na začetku druge krivulje. Razlika med krivuljama je v tem, da prva nakazuje enosmerno komunikacijo, druga pa dvosmerno. V primeru e-pošte je torej pisna, telefonski klic pa ustna. Ključna prednost dvosmerne komunikacije (pogovora) je, da nam omogoča postavljanje dodatnih vprašanj za pojasnjevanje slišanega, preverjanje razumevanja in s tem niža možnost nesporazuma. Komunikacija je hitrejša in omogoča povratni odziv prejemnika informacije (ki pri e-pošti ni samoumeven). Veliko bolj verjetno je, da bo nekdo nekaj naredil, če ob prejetju naloge potrdi izvedbo.

In če se vrnemo na prej omenjeno govorico telesa, prek telefona slišimo ton glasu, na video konferenci pa tudi obrazno mimiko (seveda odvisno od tehnike in nastavitev – včasih vidimo le množico majhnih obrazov na ekranu telefona, kjer gledamo tudi risbe…). Zato je najboljša komunikacija iz oči v oči, ki omogoča vse prej našteto, lahko pa spremljamo celo telo sogovornika. Kot že rečeno, pa je komuniciranje še učinkoviteje, če si zraven še kaj narišemo ali napišemo – zadnja raven v grafu: iz oči v oči ob tabli.

Zdaj torej razumemo, zakaj se priporoča, da naj bodo agilni timi locirani skupaj in zakaj je tipična fotografija agilnega tima tista, ki jih kaže, kako debatirajo ob tabli. Našli pa smo še nekaj navodil glede komuniciranja v agilnem timu:

  • čim več se osebno pogovarjajte (ang. face to face)
  • ob težavah čim prej načnite debato (s skrivanjem ali zanemarjanjem se težava veča)
  • ne sme vas biti strah povedati svojega mnenja oziroma podati predlog ali idejo (tudi ob tveganju, da bodo drugi mnenje zavrnili)
  • pomembno je stalno učenje od drugih ter širjenje svojega znanja in izkušenj
  • bodite »potrpežljivi poslušalci« (razmišljate širše, o različnih možnostih … resno razmislite, preden kategorično zavrnete idejo)
  • vedno podajte povratno informacijo – pohvalite dobro delo, povejte, če kaj ni bilo v redu (ne zatrite v sebi)

Člani agilnega tima se morajo medsebojno “vzgajati”, da se uveljavi kultura komuniciranja, kot je prikazana v zgornjih alinejah. Seveda, če imamo formalnega vodjo tima, se to pričakuje od njega ali pa je to naloga Scrum mojstra. Vsekakor bi vse našteto veljajo tudi za delo v »tradicionalnih« timih, “tradicionalna” priporočila pa veljajo za agilne time. Pri tem pa ne pozabimo na uslužno vodenje tima, ki ga seveda priporočamo tudi tradicionalnim (projektnim) managerjem.

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.

Page 1 of 12

Powered by WordPress & Theme by Anders Norén