Agilnost je jedna od suštinskih poluga za učinkovitu provedbu digitalne transformacije

Zašto je teško biti agilan?

Živimo u vrijeme kad je agilan pristup u razvoju softvera odavno prešao svoju prekretničku točku (tipping point) i udomaćio se u brojnim organizacijama širom svijeta pa tako i kod nas. Razmjenjuju se iskustva i ideje kroz bezbrojne forume, blogove i konferencije, sve su brojnije edukacije i savjetovanja za one koji su novi u svijetu agilea.

PIŠE: MARKO KEBA

Možemo reći da se agile iz open source modela velikim dijelom preselio u klasični business model. Tako se kroz višednevne tečajeve SW developeri uče novom pristupu svom poslu što će njihovim uredima i kompanijama donijeti bolje poslovne rezultate. Ipak, preko istih onih foruma, blogova i konferencija svjedoci smo da se očekivano poslovno unapređenje vrlo često ne ostvaruje, barem ne u onoj mjeri koju je očekivao investitor u promjenu svoje organizacije.
U čemu je problem?
Pokušat ću objasniti kompleksnost agilnog pristupa razvoju softvera i poslovanju općenito, kroz osobno šestogodišnje iskustvo tranzicije u jednom dijelu Ericssona, kao i kroz brojne kontakte i iskustva drugih pojedinaca i organizacija. Problematiku sam podijelio u četiri cjeline: neintuitivnost, izoliranost promjene, transparentnost i disciplinu.

Neintuitivnost

Ljudi su skloni raditi i vjerovati u ono za što imaju neposredno iskustvo ili im je intuitivno, logično. Naprimjer, intuitivno je očekivati da će se dva lista papira udaljiti puhnemo li među njih. Točno? Naprotiv, papiri će se jedan drugome približiti, uvjetovani istim principom koji i avionsko krilo diže u zrak, što je Bernoulli otkrio i opisao još u XVIII. stoljeću.
U agilnom pristupu razvoju softvera ima nekoliko primjera klasične neintuitivnosti. Naprimjer,  jedna od osnovnih XP disciplina je programiranje u paru. Prema njoj, dva će developera prije isporučiti kvalitetan kod ako rade za jednim računalom i zajedno pišu kod nego ako svatko od njih uzme dio posla i radi samostalno. Kao i u eksperimentu s papirima, tek će neposredno iskustvo potvrde tog pristupa potaknuti nekoga da tako radi i ubuduće. Mnogi će timovi zaobići tu neintuitivnu praksu, a da je nisu nikad ni probali.

Ogoljeti rješenje do najosnovnijih elemenata koji odgovaraju potrebama kupca ili korisnika prilično je zahtjevan posao. Mnogo je jednostavnije obogatiti ga raznim kad-već-to-radimo elementima koji u konačnici poskupljuju proizvodnju, test i kasnije održavanje te često kompliciraju i usporavaju konačni sustav.

Sljedeći primjer i jedan od temelja agilnog pristupa uopće je flow pristup kao korekcija intuitivnog batch pristupa. O čemu je riječ? Svaki se posao može podijeliti u nekoliko sekvencijalnih faza pa tako kod software developmenta imamo fazu analize zahtjeva kupca, fazu skice ili definiranja solucije, fazu kodiranja, nekoliko faza testiranja, fazu isporuke rješenja kupcu te dokumentiranje, najčešće kao jednu od zadnjih faza. Batch pristup izvršenju tog posla bit će da se završi cijela prva faza prije nego što se krene u drugu, koja se završi prije nego što se krene u treću itd. Suprotno tomu,  flow pristup sugerira niz kraćih prolaza kroz sve faze od prve do zadnje i stvaranje više prirasta rješenju nizom iteracija kroz faze. To je suština Scruma i XP-a (Extreme Programming). Mnoge su organizacije i strukturno podijeljene prema batch principu, što pokazuje dobre rezultate u poslovima predvidljivih ishoda, ali razvoj softvera to nikako nije.
Jedan od principa agilnog razvoja softvera je jednostavnost – umjetnost maksimiziranja neobavljenog posla je esencijalna. Prema mom iskustvu to je jedan od najmanje razumljivih principa i iz inženjerske perspektive prilično neintuitivan. Manje je više, rekao je Mies van der Rohe i primjerom u arhitekturi pokazao na što misli. Takav je pristup lako našao svoje mjesto u arhitekturi, umjetnosti i dizajnu (iako vjerujem da smo svi češće svjedoci dijametralno suprotnog pristupa u hrvatskoj arhitekturi), ali u biznisu, posebno softveru, malo je manje zastupljen. Ogoljeti rješenje do najosnovnijih elemenata koji odgovaraju potrebama kupca ili korisnika prilično je zahtjevan posao. Mnogo je jednostavnije obogatiti ga raznim kad-već-to-radimo elementima koji u konačnici poskupljuju proizvodnju, test i kasnije održavanje te često kompliciraju i usporavaju sam konačni sustav.
Ali, tko je rekao da je biti agilan jednostavno?

Izoliranost promjene

Uspjeh u poslu postižemo ako smo zadovoljili dvije perspektive: da radimo prave stvari (doing the right things) i da obavljamo posao na pravi način (doing things right). Razvoj softvera tu nije iznimka: možemo raditi na pravom i krivom rješenju (ili za kupce/korisnike potrebnom i nepotrebnom) te isto to rješenje razvijati na više-manje efikasan, brz ili jeftin način. Lako ćemo se složiti s Peterom Druckerom da je najveća šteta vrlo efikasno raditi na nečemu što nismo ni trebali počinjati.
Agile se često stavlja isključivo u kontekst obavljanja posla na pravi način - efikasno, zanemarujući perspektivu rada na pravim stvarima. Agilizacija  neke organizacije često se svodi na upoznavanje softver razvojnih timova u  metodama Scruma ili XP praksama te prilagodbi dotadašnjih uloga u nove. Poslovni dio organizacije često ni na koji način ne sudjeluje u toj promjeni, kao ni menadžment, HR i drugi. Promjena se izolira na developere, na metode i  mehaniku proizvodnje softvera na efikasniji način. Neki od osnovnih elemenata agilnog razvoja su izravni (ili što manje posredan) kontakt razvojnog tima s kupcem i velika sloboda istog tog tima da se samoorganizira u obavljanju posla. To implicira da u timu postoje sve kompetencije potrebne za sve faze obavljanja posla kao i da se ostatak organizacije (strukturno i operativno) prilagodi takvom jednostavnom pristupu.

Potrebna je i promjena paradigme o organizaciji po kojoj se razvojni tim stavlja na prvo mjesto, a menadžment, HR i ostali dolaze u poziciju podrške istom tom timu i brinu da su mu osigurani svi potrebni resursi.

U organizaciji kontakta s kupcem promjene su neizbježne kako bismo imali brzu vezu za provjeru radimo li na pravim stvarima. Potrebna je i promjena paradigme o organizaciji po kojoj se razvojni tim stavlja na prvo mjesto, a menadžment, HR i ostali dolaze u poziciju podrške istom tom timu i brinu da su im osigurani svi potrebni resursi. Isto tako, osim promjene strukture organizacije u cilju podrške timovima, promjene su potrebne i u pristupu nagrađivanju, edukaciji, ulogama itd.
Mijenjati cijelu organizaciju istodobno nije jednostavan posao, ali tko je rekao da je biti agilan jednostavno?

Transparentnost

U kojem trenutku znamo najmanje o projektu? Dakako, u početku, a radom na projektu saznajemo sve više i više. Nažalost, naši planovi nužno ne profitiraju od tog sve boljeg razumijevanja. Agile na taj paradoks odgovara jednostavno: planiramo usporedno s razvojem, a planove korigiramo periodički na temelju usvojenog znanja, uz uključenost svih zainteresiranih za ishod.

Iskustvo nas uči da će projekti na kojima radimo ponekad malo odstupati od naših inicijalnih planova, odnosno pretpostavki. Uzroci mogu biti razni: kompleksnost implementacije rješenja, nepredviđeni ili novi zahtjev, impakt na sustav, kompetencije ili dostupnost razvojnog tima itd. Kako tada reagiramo? Informaciju o problemu sigurno će imati oni koji su neposredno uključeni u razvoj, tim koji radi na projektu. Hoće li se ta informacija brzo i transparentno prenijeti na sve zainteresirane za uspjeh, kao što su menadžment i poslovodni ured - one koji su posao dogovorili s kupcem te prema samome kupcu ili naručitelju projekta? Odgovor na to kontroverzno pitanje ovisit će o agilnosti i povjerenju među svim zainteresiranim stranama. Konzervativniji pristup navodit će nas na blokiranje ili korekciju - ublažavanje informacije o problemu prema menadžmentu ili kupcu. Takav pristup često će to podržavati širenjem informacija putem raznih izvještaja, nerijetko posebno strukturiranih za razne razine korisnika tog izvještaja te striktno držanje plana, odnosno pretpostavke s početka projekta.


Jedan od temeljnih principa agilea je odgovaranje na promjenu, umjesto slijeđenja plana. U kojem trenutku znamo najmanje o projektu? Dakako, u početku, a radom na projektu saznajemo sve više i više. Nažalost, naši planovi nužno ne profitiraju od tog sve boljeg razumijevanja. Agile na taj paradoks odgovara jednostavno: planiramo usporedno s razvojem, a planove korigiramo periodički na temelju usvojenog znanja, uz uključenost svih zainteresiranih za ishod.
Dakle, inzistira se na potpunoj transparentnosti svih ključnih informacija i zajedničkom dogovoru tijekom cijelog trajanja projekta, što uključuje i reakciju na sve uočene probleme. Takva vrst pristupa projektu nije jednostavna pa traži stalan fokus i usredotočenost te brze reakcije svih.
Podjednako je bolna i jedna druga vrst transparentnosti - feedback ili povratna informacija. Od razvojnih se timova očekuje da se poboljšavaju kroz vrijeme temeljem zajedničkog stečenog iskustva i sustavnog rješavanja problema na koje nailaze. Timske retrospektive usmjerene su upravo k tom cilju. U jednom će dijelu mjera poboljšanja tima ovisiti o iskrenosti njegovih članova. Svaki će član dobiti najbolji  feedback od ljudi koji s njim svakodnevno rade. Taj se potencijal rijetko iskorištava pa se događa da član tima najčešće dobiva povratnu informaciju od svog menadžera koji je mora najvećim dijelom formirati posredno, na temelju informacija koje je dobio od drugih. Tako gubimo mogućnost da povratna informacija bude svježa te da diskusija bude vezana uz detalje i okolnosti koje ne mogu biti poznate iz druge ruke. Zašto na poslu rijetko dajemo feedback jedni drugima? U principu možemo otvoreno reći da nas nitko nije naučio vrijednostima i kvalitetnom načinu davanja feedbacka. To nije dio sustava školovanja pa uvođenje tog oblika komunikacije mora biti popraćeno jasnom definicijom vrijednosti i cilja davanja povratne informacije kao i nekim oblikom formalne edukacije ljudi u organizaciji.


Disciplina

Timovi imaju slobodu da sami definiraju sustav razvoja na svojoj razini (standard), ali isto tako i odgovornost da taj sustav bude maksimalno uspješan. Retrospektive su usmjerene upravo na to - na prepoznavanje mjesta na kojima se sustav može unaprijediti te na korekciju sustava temeljem te analize.

Često sam čuo od onih koji su površno upućeni da je agile ono kad svatko radi što hoće. Tek rijetki će reći da agile traži visoku disciplinu u razvoju softvera, čak i nakon određenog iskustva s npr. Scrumom.  Oni koji poznaju XP primijetili su da je disciplina u pristupu razvoju softvera  jedan od temelja ove metode: sav se kod programira u paru, koristeći TDD (test driven development)uz refaktoriranje u svakoj iteraciji te kontinuiranu integraciju novog koda (CI).
Već smo dvaput spomenuli - od timova koji razvijaju softver očekuje se da se kontinuirano poboljšavaju u tom poslu. Dakle, imaju slobodu da sami definiraju sustav razvoja na svojoj razini (standard), ali isto tako i odgovornost da taj sustav bude maksimalno uspješan. Retrospektive su usmjerene upravo na to - na prepoznavanje mjesta na kojima se sustav može unaprijediti te na korekciju sustava temeljem te analize. Iako zvuči prilično trivijalno i teško je naći argument protiv te logike, svjedoci smo da taj model teško ostvaruje očekivani rezultat - poboljšanje. Zašto je to tako? U korijenu tog problema je disciplina. Sustav se može poboljšati samo kad postoji i kad se slijedi neki standard po kojem se obavlja posao. Tada uočavamo probleme ili nesavršenosti sustava (retrospektiva) i korigiramo ih te novim slijeđenjem korigiranog sustava profitiramo,  jer ne ponavljamo ono što je bilo uzrok problema. Tu je disciplina temelj - poštovati i slijediti dogovoreni standard.

Autor Marko Keba diplomirao je na FER-u 1996. godine. Zaposlen je u kompaniji Ericsson Nikola Tesla 18 godina gdje posljednjih šest godina vodi jedan od ureda za razvoj telekomunikacijskog softvera. Godine 2010. uključio se u tranziciju kompanije na agilan način poslovanja gdje surađuje s kolegama iz svijeta, drži edukacije i promovira taj pristup. Član je udruge Agile Croatia.

Taiichi Ohno, otac Toyota Production Systema, koji je uvelike utjecao na agilni razvoj softvera rekao je: - Gdje nema standarda nema ni poboljšanja (Where there is no standard, there can be no kaizen). Što to znači? Ako ne postoji jasan standard koji slijedimo, svako poboljšanje otvarat će novi put koji nećemo nužno slijediti pa ni profitirati od dogovorenog poboljšanja. A baš to se vidi gotovo svakodnevno: retrospektive ili sastanci s fokusom na poboljšanja koji ne daju očekivano poboljšanje, jer dogovor o poboljšanju ne postaje nužnost, nego samo još jedna alternativa. Jedna od očitih posljedica je i gubitak interesa za retrospektive s obzirom na to da se ne vidi efekt uloženog vremena i fokusa ljudi.
Možemo reći da će očekivani benefit spomenute discipline biti prepoznat tek kad ga iskusimo u poslu. Jednako tako, disciplina se kao vrijednost mora prepoznati na svim razinama, ne samo kod razvojnih timova, što u našoj kulturi orijentiranosti prema cilju a ne procesu nije lako.
Ali tko je rekao da je lako biti agilan?

Deloitteova ljestvica

Tri hrvatske tvrtke među najbržima

Na ovogodišnju rang-listu petsto najbrže rastućih tehnoloških tvrtki u EMEA regiji, koja obuhvaća Europu, Bliski istok i Afriku, uvršteno je čak 39 tvrtki iz Srednje Europe među kojima se nabolje plasirala poljska tvrtka Codewise zauzevši treće mjesto s rastom prihoda od 13.052 posto. Na ljestvici vodi švedska tvrtka Fingerprint Cards iz sektora biometrike, koja je u protekle četiri godine zabilježila rast prihoda od 28.000 posto..
Deloitteova ljestvica petsto najbrže rastućih tehnoloških tvrtki u regiji EMEA (Deloitte Technology Fast 500 EMEA) obuhvaća najbrže rastuće tehnološke tvrtke i sastavlja se prema postotku povećanja prihoda od prodaje za protekle četiri godine.
Cilj Deloitteovog Technology Fast 500 EMEA programa jest objektivno rangiranje tvrtki u sektoru tehnološkog ekosustava, čime se daju priznanja onima koji su u protekle četiri godine ostvarili najveće stope rastaIz Hrvatske su ove godine na popis petsto najbrže rastućih uvrštene tri  - najbolje je plasirana tvrtka Rimac automobili na 151. mjestu sa 702 posto rasta prihoda, zatim slijedi Hangar 18 na 216. mjestu s 527 posto rasta prihoda te Serengeti na 296. mjestu s 385 posto rasta prihoda u protekle četiri godine. Kao i prethodnih godina, najviše tvrtki uvrštenih na ljestvicu ima Francuska - 94, a slijede je Ujedinjeno Kraljevstvo i Nizozemska.
Evo što su najbrži  izjavili za OpenInfoTrend:
■ Direktor Codewisea, Robert Gryn: - Čast nam je i ponosni smo što je naša tvrtka zauzela treće mjesto među petsto najbrže rastućih tehnoloških tvrtki regije EMEA. Pobjeda na natječaju Zvijezda u usponu 2015., a zatim na ovogodišnjem glavnom natječaju Technology Fast 50 te na Big 5 Srednje Europe dokaz je kontinuiteta naše uspješnosti. Prethodni uspjesi, kao i ovaj plasman u EMEA regiji pojačava našu vjeru u sposobnosti i ambicije za izgradnju globalne poljske tvrtke. Čvrsto sam uvjeren da je ovo početak nečega velikog.  
■ Mate Rimac, vlasnik Rimac Automobila: - Kad sam počeo, svi su rekli kako u Hrvatskoj nije moguće napraviti automobil. Ipak, odlučio sam to učiniti i ostati u Hrvatskoj bez obzira na velike izazove s kojima smo se suočavali. I, ne samo da smo stvorili jedan od najbržih svjetskih električnih automobila nego smo stvorili i snažnu tvrtku koja svojom tehnologijom nove generacije može postati veliki igrač, pozicionirajući Zagreb kao poželjnu lokaciju za poslovanje voditeljima globalnih tvrtki. Kod nas važi ona uzrečica - Mislimo globalno, djelujmo lokalno.
■ Goran Kalanj vlasnik i direktor hrvatske tvrtke Serengeti: - Naša je tvrtka već drugi put zaredom na Deloitteovoj rang-listi petsto najbrže rastućih tehnoloških tvrtki u Europi, Bliskom istoku i Africi. Taj smo rezultat uspjeli postići jer smo se dokazali kao pouzdani, dugoročni, strateški partner vodećih hrvatskih i svjetskih tvrtki.
Dokazali smo da smo sposobni realizirati i najzahtjevnije projekte razvoja poslovnog softvera. Danas su naši korisnici najveće tvrtke u Hrvatskoj i svjetski tržišni lideri kao što su Knapp i Daimler. Kontinuirano ulažemo u edukaciju i stjecanje novih tehnoloških znanja kao i u unapređenje organizacije i internih procesa kako bismo stvorili respektabilnu globalnu tehnološku konzultantsku tvrtku.


* (Više informacija o Deloitte programu i prethodnim pobjednicima dostupno je na: www.deloitte.com/2016/emea-fast500)