Jeste li dovoljno spretni, okretni, agilni (ili je vrijeme za dijetu)?

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

Zamislite ovaj scenarij - voditelj ste tehničkog razvoja solidno uspješnog online proizvoda X i nakon mjeseci pregovaranja i PowerPoint prezentacija, konačno je došao i taj (sunčan) dan kada ste uspjeli uvjeriti glavešine da prihvate Agile kao temeljnu metodu daljnjeg razvoja vašeg proizvoda.

agile

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?

agile

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?

Toyota Product System (slika: Lean.org)
Toyota Product System (slika: Lean.org)

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.
Ili skraćeno: Build-Measure-Learn.
Ili skraćeno: Build-Measure-Learn.

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’

dijeta

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?

ponuda

Komentari

  1. Miki Dojcilo

    Miki Dojcilo

    11. 12. 2015. u 1:57 pm Odgovori

    Agile u razvoju proizvoda u domeni hardvera se nije bas pokazao, nije tome ni namijenjen, ali uporno pokusavaju nametnuti, i ne daju si dokazati da jednostavno priroda posla nije takva kao SW.

Odgovori

Tvoja e-mail adresa neće biti objavljena.

Popularno

Startupi i poslovanje

MVT Solutions iz Pisarovine osigurao 100.000 od 300.000 eura vrijedne runde investicije za brži i jeftiniji razvoj IoT-ja

Ovaj domaći startup u tri je godine, bez ikakve vanjske investicije, razvio IoTaaP, alat koji može uvelike olakšati razvoj IoT proizvoda različitim klijentima. Osim hardvera, njihov poslovni model se skalira kroz softver i cloud, a koliko uspješno su se rješenjem i radom potvrdili do sada, najbolje govori i vijest o prvoj investicijskoj rundi predvođenoj domaćim investitorom.

Startupi i poslovanje

Od agencije do freelancinga: 8 savjeta za život i posao koje sam naučio težim putem

A kako vi ne bi morali, stiže jedna poučna usporedba oblika poslovanja kroz stvarna iskustva.

Video

Što se dogodi kada ekstremnom trolu oduzmete megafon, odnosno društvene mreže?

Počne skapavati od gladi, sudeći prema uvijek dramatičnom istaknutom pripadniku 'alt right' pokreta, Milu Yiannopoulosu iliti Neru iliti Milu Andreasu Wagneru iliti Milu Hanrahanu, što je zapravo njegovo pravo ime.

Što ste propustili

Novost

Albert Gajšak otkrio zašto je mentoriranje od Cara vrjednije od njegovih para

Mentoriranje nije samo za startupe u akceleratorima, već nam svima može pomoći bilo da smo mentor ili mentorirani kako pokazuje i uspješan primjer osnivača Makerbuina i Infinuma.

Sponzorirano

Privući i zadržati zaposlenike nećete šarenim uredom, ali hoćete agilnom transformacijom

Neki nabavljaju stolni nogomet i šarene vreće za odmaranje, neki organiziraju filmske večeri i zabave petkom, a neki se obraćaju - agilnom treneru.

Intervju

Kako do prakse na kojoj si plaćen i na kojoj učiš, ulažeš u sebe i napreduješ?

Nekima je još u redu pripravnike uzimati na neplaćeno pa ih natovariti kao da su Katica za sve. Pripravništva su se promijenila, barem u nekim tvrtkama, a netom diplomirana ekonomistica i njezin kolega na apsolventskoj godini, otkrit će vam i kako.

Startupi i poslovanje

Dragi svi, budite podrška koju želite i sebi; drage žene, nemojte prihvatiti ništa manje

Ladies of New Business Tech edition okupio je domaće i strane IT rukovoditelje, stručnjake i organizatore IT konferencija kako bi raspravili što kao kolege, šefovi i organizatori možemo učiniti kako bi pomogli IT-jevkama da napreduju u industriji te da se osjećaju kao njezin važan dio.

Kultura 2.0

Gen Ashley i Christina Richter na 8. #LadiesZG: bez uzora i edukacije nema jednakosti u tehnološkoj industriji

Kako bismo privukli više žena u tehnologiju trebamo podržati i trenutne žene u industriji koje će svojim primjerom pokazati da ovaj sektor nije "muški svijet".

Startupi i poslovanje

Hrvatski SysKit: Za 90% funkcionalnosti inspirirali su ih njihovi korisnici, među kojima je i američka vlada

Hrvatska softverska tvrtka SysKit već 10 godina pomaže sistemašima i administratorima u više od 3000 tvrtki diljem svijeta. Njezin suosnivač Frane Borozan otkrio mi je strategiju koja im je omogućila kompetitivnost na svjetskoj razini i približila ih ostvarenju želje da postanu jedan od najvećih proizvođača softvera u Hrvatskoj.