Jeste li dovoljno spretni, okretni, agilni (ili je vrijeme da krenete na dijetu)?

Stvari nakon toga idu kao po loju, oformili ste Scrum tim, dosadašnjeg Team Leada ste level-upali u Scrum Mastera (i to certificiranog) i svi zajedno očekujete da kroz koji dan s neba počnu padati jednorozi punjeni čokoladnim bombonima.

Malo vas, doduše, kopka činjenica da su glavešine Agile prihvatile pomalo naglo kada su čuli/pročitali da je kompanija X koju oni smatraju početkom i krajem svemira prešla na Agile i kao rezultat unutar sumnjivo kratkog vremenskog perioda razvila poslovne super moći, ali i vi smatrate Agile genijalnom filozofijom, cijeli tim pulsira čežnjom za Scrumom i stoga odlučujete da brinete previše i samo se prepustite.

Postajete Product Owner, i to certificirani. Scrum tim tiho turira i samo čeka vaš mig da krene u juriš. Pokrili ste sve, što bi moglo poći po zlu?

Heh, što bi moglo poći po zlu

Nekoliko sprintova kasnije stvari izgledaju obećavajuće, vaši developeri su sretni k’o prasad u g… blatu, Scrum Master blista od sreće, vi ste praktički postali dio “ekipe”, svi idete barem jednom mjesečno čoporativno na alkoholnu orgiju, retrospektive su otvorene i iskrene, planning poker funkcionira, velocity tima je stabilan, planning accuracy unutar 95%, burndown chart izgleda kao da znate što radite i cijeli tim nikada nije bio povezaniji i sretniji.

No, usprkos svemu, ne možete se otresti nagrizajućeg osjećaja da nešto nije sasvim kako treba. Proizvod kojim se bavite opipljivo je tehnološki izvrsniji nego prije, bugova i nesporazuma je bitno manje… Međutim, iako ste tehnološki “poletjeli”, nemate dojam da se sa samim razvojem proizvoda desilo nešto spektakularno.

Agilni razvoj nije tehnički proces

Sve skupa izgleda kao da su svi uključeni (uključujući i vas – novopečenog Product Ownera) imali sljedeću viziju toga što će Agile donijeti:

1. uvedimo agile
2. ?
3. profit.

Ako se možete prepoznati u gornjem scenariju, okvirno baziranom na stvarnim događajima iz autorovog osobnog iskustva, niste jedini. Ovo je nešto što se događa prilično često i posljedica je činjenice da se agilni razvoj kao takav percipira primarno kao tehnički proces, što u svojoj osnovi zapravo i nije – Agile Development je u svojoj osnovi jednostavno specifičan (vrlo efikasan, po mišljenju autora ovog teksta, vjerojatno i najefikasniji moguć) pristup rješavanju problema, bez obzira na njegov tip.

Kao rezultat navedenoga, ali i sve bržeg i masovnijeg usvajanja agilnih metodologija od strane uprava i menadžmenta ozbiljnih i velikih firmi, sve je vidljiviji fenomen opisan u uvodnoj “priči” – a taj jest da agilnost u praksi često prestaje čim izađete iz prostora u kojemu se nalazi Scrum tim.

Što je zapravo agilnost ili spretnost?

Da bismo mogli početi analizirati zašto je tome tako, za početak trebamo razumjeti što zapravo agilnost jest. Ako pitamo Wikipediju (a ona nikada ne laže), odgovor glasi (preveden na dobri stari hrvatski):

Okretnost (ili spretnost) je sposobnost efikasne promjene pozicije tijela. 

Na netu postoji još gazilijun definicija, ali i ova će poslužiti. Ključno je ovdje “efikasna promjena pozicije”. Ako pokušamo naš Scrum tim usporediti s tom definicijom – stvari izgledaju dobro, tim može efikasno promijeniti poziciju i smjer u trenutku, mehanizmi su tu (kod naravno pišete koristeći principe XP-a i BDD-a?). Tim je OK, što je i u skladu s našim opažanjima, ali što je s ostatkom organizacije, što je sa samim proizvodom?

Što će vam sportski automobil ako ga nećete sportski voziti?

Tu stvari više nisu tako čiste. Iako Product Owner u teoriji može zaokretati smjer razvoja za 180 stupnjeva svaki sprint – u praksi se to najčešće svodi na niz kratkih, u svojoj srži zapravo waterfall projekata koji se definiraju dva-tri tromjesečja unaprijed i koji povremeno promijene redoslijed i uleti poneki novi, ali to je u odnosu na moguću agilnost Scrum tima kao da imate skupa sportska kola koja nikada ne vozite preko 50 km/h.

Trik je u tome da debela većina organizacija “iznad” Scrum tima i dalje funkcionira na waterfall način – s poslovnim planovima i budžetima planiranima za više tromjesečja unaprijed (pa i dulje – kod nekih težih slučajeva), usprkos tome što je svima zapravo jasno da to tako više jednostavno ne funkcionira (Fun fact 1: Autor je prije nekoliko tjedana bio na Web Summitu u Dublinu i jedan panel je bio otprilike na temu investiranja i procjene rizika. Veliki “čvarci” iz svijeta investitora komentirali su kako već godinama nisu pročitali niti jedan poslovni plan niti ih to zanima – jer isti pokrivaju vremenski okvir koji jednostavno nije moguće planirati na tržištu dinamičnome kao što je internet i u osnovi predstavljaju ništa više od liste samozavaravajućih želja). Stvar je psihološke naravi – šefovi imaju šefove koji imaju šefove i svaki od njih mora svojem šefu pokazati nešto što govori “imamo jasnu viziju za sljedećih x godina i stvari su pod kontrolom”.

Fun fact 2: gotovo 90% startupa propada prije no što dosegne “zrelost”.

Nemojte sad prestati čitati jer “vi niste startup” – vjerojatno jeste. Bilo kakav novi proizvod, nova funkcionalnost ili ponovno lansiranje postojećeg proizvoda može se gledati kao startup jer na njega u osnovi djeluju ista pravila. Jedna od boljih definicija startupa jest “grupa ili organizacija čiji je cilj postizanje održivog tržišnog modela rasta u limitiranom periodu prije nego ostanu bez sredstava”.

Ima li pomoći?

Srećom, ima. Problemi ovog tipa nisu od jučer (usvajanje agilnih metoda samo ih čini vidljivijima u IT svijetu) i, što je zanimljivo, uopće nisu izvorno IT-jevski i riješeni su (ili barem započeti biti kvalitetno rješavani) još sredinom prošlog stoljeća u automobilskoj industriji. Danas je Toyota japanski Mercedes, a jedan od glavnih razloga za to je takozvani Toyota Production System (TPS) iz kojeg direktno potječu vjerojatno svi ili barem debela većina kul japanskih termina koje koristimo danas u IT industriji (Kanban – Trello anyone?, Kaizen…). No, onaj koji je zapravo tema ovog teksta, jest onaj koji su zapadnjaci nadjenuli kompletnom konceptu (uz manje izmjene i proširenje cjelokupnog koncepta), a taj termin je Lean.

Radi “vitko”

Lean je model upravljanja koji se fokusira na jednu stvar – na uklanjanje “sala”, odnosno “viška”, pri čemu se viškom smatra sve ono što ne doprinosi konkretnoj vrijednosti za krajnjeg korisnika. Pritom je važno ne interpretirati “uklanjanje viška” kao štednju i rezanje troškova – jer jedno s drugim nema veze – cijeli je trik u tome da za uklanjanje viška morate kristalno jasno znati prepoznati (i mjeriti) što predstavlja vrijednost za vaše klijente/krajnje korisnike, a što u konačnici predstavlja višak. Taj proces osvještavanja “što mi zapravo činimo za svoje klijente” zna biti prilično otrežnjujući – ali predstavlja preduvjet za agilnost, zato što, jednostavno rečeno, ono što ne možete mjeriti – ne možete niti poboljšati.

Lean je sam po sebi tema za čitavu seriju članaka, no ono što nas ovdje zanima jest činjenica da nudi metodu dolaženja do odgovora pitanje koje je noćna mora većine menadžera, a glasi otprilike ovako:

Znam da ću u jednom trenutku morati promijeniti smjer i koncept daljnjeg razvoja mojeg proizvoda, ali kako da znam kada?

A varijacija toga jest i klasično:

Vidim da stvari ne idu po planu, ali ako samo dodamo još funkcionalnost X stvari će biti bolje…

U osnovi je isti poriv koji tjera ljude da spiskaju pola plaće u kladionici na parove finske druge ženske nogometne lige – i sjeme je i majka svih feature creepova ikada igdje.

10 koraka Leana

Lean cijelom problemu pristupa koristeći praktički znanstvenu metodu – naizgled jednostavnu:

1. korak: odredite što predstavlja vrijednost za krajnjeg korisnika, a što predstavlja višak;
2. korak: odredite jasne mjere (metrics) na osnovu kojih možete pratiti ponašanje svojeg proizvoda;
3. korak: odredite jednu ili više mjera čije vrijednosti želite poboljšati;
4. korak: definirajte postulat – “ako učinimo X, tada će mjera Y promijeniti vrijednost na sljedeći način što će predstavljati uspjeh, a ako mjera Y promjeni vrijednost, na sljedeći način to će predstavljati negaciju postulata X”;
5. korak: definirajte eksperiment (minimum viable product) u vidu minimalne funkcionalnosti s A/B testovima koji potvrđuje ili opovrgava postulat koji testirate
6. korak: implementirajte i rolloutajte;
7. korak: mjerite;
8. korak: analizirajte rezultate;
9. korak: ako je potrebno, promijenite smjer i mjere;
10. korak: go to korak 3.

Korak 9 rješava menadžersku dilemu navedenu iznad, a korak 4 je ključan – jer iz cijelog procesa odlučivanja uklanja cijeli management mumbo jumbo i tjera vas da izađete iz svojeg polja distorzije stvarnosti, jasno verbalizirate svoju pretpostavku i, što je još važnije, da jasno verbalizirate do kada ćete “mlatiti mrtvog konja”, odnosno da definirate opaženi rezultat koji će predstavljati poraz vaše teorije i koji a priori prihvaćate kao takav. Čime efektivno sprječavate feature creep.

Riječ je, dakle, o iterativnom, kružnom procesu koji je zapravo vrlo analogan Scrumu u svojoj osnovnoj ideji – no primjenjivom na općenitu organizaciju i upravljanje razvojem proizvoda u najširem smislu. Ukratko, to je okvir koji vam objašnjava kako voditi organizaciju koja je agilna u pravom smislu te riječi i koja odbacuje lažnu sigurnost dugotrajnih poslovnih planova na isti način na koji agilno pokret odbacuje lažnu sigurnost waterfall pristupa razvoju softvera.

Ne možeš biti i okretan i vući ‘višak’

Priča o Leanu, doduše, ovdje tek počinje. Pojmova je hrpetina (pivot, actionable metrics, impact mapping, lean canvas, one metric that matters…) i svaki od njih je dubok i otvara cijele nove koncepte i poglede na upravljanje procesima općenito. Međutim, sam je koncept izrazito jasan, racionalan, u svojoj srži zapravo vrlo jednostavan te bih svakako bih onima koje sam uspio zainteresirati za temu preporučio sljedeće naslove kao ozbiljniji uvod u Lean metodologije: 

• Lean startup (Eric Ries)
• Lean analytics (Alistair Croll, Benjamin Yoskovitz)
• Impact mapping (Gojko Adzic)

I, na kraju, kao što je rijetko koji dvjestokilaš spretan i okretan (bez da se podvrgne ozbiljnoj dijeti), tako je i uvjerenje autora ovog teksta jest da prava agilnost bez Leana jednostavno ne postoji, odnosno da je imanje razvojnog Scrum tima u organizaciji koja nije Lean isto kao posjedovanje Subaru Impreze kojom se vozite isključivo na posao. Istina, tu i tamo u pokoji zavoj uletite brže i između dva semafora ponekad ostavite sve iza sebe, ali to vas baš i ne čini reli vozačem niti iz vaše skupo plaćene pile izvlači više od 2% onoga za što je u krajnjoj liniji i dizajnirana. Zar ne?