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

Video

Svi su gubitnici u bitci za i protiv paušalnih obrta: Tvrtke, radnici – i sami “paušalci”

Zato što se IT scena razjedinila oko teme paušalnih obrta, zato će svi iz nje izaći i poraženi. No, koja je perspektiva svih uključenih strana? Ivan i ja smo provjerili u drugoj epizodi Netokracija Podcasta.

SEO i tražilice

Velika analiza online sadržaja o cijepljenju pokazuje da HZJZ olakšava posao – antivakserima

SEO koji život znači. To bi mogao biti alternativni naslov ove analize, iako ovdje nije riječ o samoj optimizaciji sadržaja za tražilice, nego optimizaciji za - korisnika. Jer u vrijeme kad procijepljenost pada, optimiziran i korisniku prilagođen sadržaj na stranicama HZJZ-a i drugih zdravstvenih institucija mogao bi doista značiti razliku između života i smrti.

Tehnologija

Cenosco: Nizozemska tvrtka koja iz Pule i Zagreba putem softvera, VR-a i AR-a sprječava eksplozije na naftnim platformama

Aplikacije koje kontroliraju rad naftnih platformi i postrojenja za preradu derivata direktno su zaslužne za sigurniji i čišći svijet, a jedna od najboljih stvara se velikim dijelom u Hrvatskoj.

Što ste propustili

Startupi i poslovanje

Kako bi Rimac, Bakić, Car i drugi hrvatski poduzetnici uložili 100.000 kuna da imaju startup?

Good Game Liftoff startup natjecanje prošle je godine u žiriju okupilo poznate hrvatske poduzetnike i stručnjake, a koji su tada prepoznali potencijal mladog tima iza društvene igre Mundus. Ususret novom izdanju Lifoffa vraćamo se do Mundusa i žirija po par dobrih savjeta.

Startupi i poslovanje

Primjer za Hrvatsku: Srbija predstavila olakšice za zapošljavanje ‘paušalaca’ i test samostalnosti

Porezne olakšice za zapošljavanje donedavnih paušalaca, jasan test samostalnosti... Što Hrvatska može naučiti iz srpskog primjera, komentiramo u novoj epizodi Netokracijinog podcasta.

Izvještaj

Kako se gradi konzultantska karijera otkrili smo uz prvi Tech Consultant Meetup u Zagrebu

Što ljudi misle da konzultanti rade, a što im je zapravo posao? Zagrebački meetup tražio je odgovor upravo na pitanje kako postati tech konzultant i što očekivati ako se odlučite za konzultantsku karijeru, a dobre primjere čuli smo kroz razgovore i predavanja mStartovih stručnjaka.

Najava

EBZG otvara David Bizer koji je vodio Googleovu strategiju regrutiranja na društvenim mrežama

Kako iskoristiti blog, društvene mreže, nativno oglašavanje, ali i direktora svoje tvrtke za 'employer branding'? Otkrijte na regionalnoj konferenciji Employer Branding Zagreb koju će 15. 11. otvoriti David Bizer, osoba koja je postavila strategiju regrutiranja putem društvenih mreža za Google!

Vodič

Što je esport i zašto bi vas za njega trebalo biti briga?

Čuli ste za esport, ali samo u prolazu? Ne brinite, na jednom mjestu donosimo sve važne informacije o ovom globalnim fenomenu koji danas prati više od 400 milijuna ljudi.

SEO i tražilice

Velika analiza online sadržaja o cijepljenju pokazuje da HZJZ olakšava posao – antivakserima

SEO koji život znači. To bi mogao biti alternativni naslov ove analize, iako ovdje nije riječ o samoj optimizaciji sadržaja za tražilice, nego optimizaciji za - korisnika. Jer u vrijeme kad procijepljenost pada, optimiziran i korisniku prilagođen sadržaj na stranicama HZJZ-a i drugih zdravstvenih institucija mogao bi doista značiti razliku između života i smrti.