Agile Management u IT-u - Buzzword ili stvarnost

Agile Management u IT-u – buzzword ili stvarnost?

Danas su svi IT-jevi deklarativno Agile! Jesu li stvarno Agile? Ako jesu, onda to prepoznaje i KLIJENT? Ako klijent ne prepoznaje onda nisu.

Unaprijed se ispričavam na korištenju engleskih izraza i kolokvijalnih informatičkih izraza, ali to je sve zbog jednostavnijeg i boljeg razumijevanja prema ciljanoj skupini čitatelja. Strani ili kolokvijalni izrazi će biti zato pisani kosim slovima.

Ako krenemo od kraja, KLIJENTA, onda klijent od Agile IT-a (živahnog, fleksibilnog, kompetentnog, odgovornog, autonomnog) očekuje da bude u roku, scopu i budžetu. Isto tako vlasnik IT-a ili IT tvrtke očekuje da njegovi djelatnici budu najmanje 20% produktivniji.

Je li u stvarnosti tako? Chaos Report (Standish Group) za 2018. godinu kaže da je uspješnost Agile projekata za 20% bolja od Waterfall. Neuspješnost je rjeđa za 15%. Isto tako kažu da su mali projekti uspješniji od velikih. Brojke se odnose na SAD. Odlično. Agile je bolji. Međutim problem je što je oko 40% uspješnih projekata i dalje je malo. Znači 60% je kasnilo, ili je prekoračen budžet (a to obično ide jedno s drugim) ili je scope promijenjen. Ili sve troje zajedno, što je najvjerojatnije. Ako pretpostavimo da je Hrvatska u laganom zaostatku u primjeni Agile metodologije, možemo pretpostaviti da smo mi negdje na < 20%-25% uspješnosti u najboljem slučaju (izračunato na temelju niže produktivnosti u RH u bilo kojoj industriji).

Agile je nastao u 1954. u Japanu (Toyota Production System)

Nadam se da neću jako razočarati IT-jevce ako kažem da je Agile u primjeni više od 60 godina (od 1954.) kada ga je Toyota izmislila, samo su mu Amerikanci dali novo ime, maknuli neke dijelove (nažalost), upakirali u novi celofan i prodaju ga cijelom svijetu pod nešto novo – SCRUM. Toyota je izmislila KANBAN i KAIZEN davno 1954. kada nije bilo informatike. S ovim želim reći da suština Agilea nije u informatičkoj podršci i terminima (Sprint, BackLog, Daily StandUp,…) ili u procesima, već u nečem puno dubljem, što u stvarnosti čini razliku između Agile i Ne-Agile organizacije. Vjerojatno odatle i ovih malih 40% koji uspijevaju i 60% koji ne uspijevaju dostići rokove, budžet i scope.

Zašto ovih 60% (ili 80% u RH) projekata ne uspijeva, a misle da rade agilno?

Krenimo od američke interpretacije Toyotine logike, odnosno od odgovornosti. SCRUM kaže da postoje 3 role Product Owner, Scrum Master i Developeri. Ako googlate Agile, odmah će vam se pojaviti na primjer „Koja je uloga Business Analysta u Agilu?“. Ako imamo tri role čemu onda četvrta rola? Moglo bi značiti da ove tri role nisu sposobne odgovoriti na izazove po Agile metodologiji.

Product Owner

Product Owner je vlasnik proizvoda u nekoj IT kompaniji. Naglasak je na riječi PROIZVOD (Product). Kada odete kupiti automobil vi kupujete proizvod. Čim ga vidite, platite, sjednete u njega i vozite ga. Za razliku od automobila, da biste „vozili“ neki IT proizvod u poslovanju treba vam od 6-36 mjeseci i korisnik plaća razvoj/prilagodbu po vlastitoj specifikaciji. I tako svakom kome ga „prodate“. Zamislite kada bi svaki vozač pisao specifikaciju recimo Mercedesu i plaćao njegov razvoj/prilagodbu (baš za njega). Da i može (a ne može) zamislite koliko bi to koštalo. Iz toga slijedi logičan zaključak da je IT proizvod u stvarnom svijetu NIJE PROIZVOD, nego POLUPROIZVOD u najboljem slučaju. Kada bi bio proizvod onda bi implementacija trajala do mjesec dana kao kad čekate automobil s nekim posebnim zahtjevima (boja), kojeg eto baš tog trena nema u trgovini. Tako bi pod IT proizvod mogle doći aplikacije s Google Trgovine i računalne igrice, a sve drugo bi bili poluproizvodi.

Prema svemu, nameće se zaključak da kod neuspjelih projekata Product Owner nema kompetencije da napravi proizvod. Tako dolazimo do Business Analysta koji mu treba interpretirati specifikaciju klijenta što i kako njegov vlastiti „proizvod“ treba raditi?!

Ako ne postoji „Proizvod“, već poluproizvod, onda ne postoji niti Product Owner već Polu-Product Owner. Slijedom toga nije moguće primijeniti Agile kako je zamišljen.

Koje bi karakteristike Agile Product Owner trebao imati?

Pa najprije kompetentnost u industriji za koju radi PROIZVOD. Ako je proizvod za neku servisnu industriju onda mora imati 10-tak godina iskustva u različitim servisnim industrija (recimo telekom, IT podrška, Facility Management, Utility (struja, plin, voda)). Tu ne mislim da je bio u IT-u te kompanije nego u osnovnom poslovanju (core business). To iskustvo mora biti praktično iskustvo ili kako to vole reći na zapadu „Hands-On“. Mora imati i operativni (specijalizirani) i menadžerski (široki) pogled na poslovanje. Zahvaljujući tom iskustvu mogao bi ponuditi i više nego klijent očekuje ili traži od proizvoda. Zamislite kad gledate automobile i vidite neke funkcionalnosti koje niste očekivali, a vaš „odabranik“ ih ima (npr. prepoznavanje govornih naredbi, trendovske alu-felge, retro stil i slično).

U tom slučaju, klijent nema potrebe pisati funkcionalnu specifikaciju, nego je piše Product Owner. Razvoj ide na trošak IT tvrtke, a ne na račun klijenta. Kao u automobilskoj industriji. U cijeni automobila plaćate i razvoj. Međutim, ako ne znate voziti automobil, onda plaćate da vas netko nauči. Tako bi implementacija IT proizvoda kod nekog klijenta obuhvatila konfiguraciju ili pripremu proizvoda za baš tog klijenta (kreiranje šafranika, migracija podataka i slično), te edukaciju za korištenje (korisnici). Sve skupa mjesec dana ili do 3 mjeseca najviše. Imamo li kompetentne Product Ownere u Hrvatskim IT tvrtkama?

Scrum Master

Scrum Master je osoba koja bi trebala znati tehnički dizajnirati proizvod, odnosno svaki njegov dio i tako, po dijelovima dati ga na razvoj Developerima. Mora imati izvrsne kompetencije u ciljanim tehnologijama za razvoj front-enda i back-enda. Ako povučemo paralelu s autoindustrijom onda bismo Scrum Mastera mogli poistovjetiti s inženjerom za automobilske motore i samo motore, jer ne postoji osoba u autoindustriji koja je ekspert i za motore i karoserije i kočnice i… U IT-u bi to bila očito osoba koja prati promjene u tehnologiji, ali i u određenom području poslovanja (npr. logističke operacije), pa može dobro razumjeti kako specifikaciju od Product Ownera pretvoriti u aplikativno rješenje. Kako dobro poznaje tehnologiju, može pripremiti i model podataka za razvojne inženjere (developere). Isto tako je u stanju pojasniti do razine koda svakom developeru što od njega očekuje i eventualno zamijeniti nekog developera ako je potrebno. Dakle Scrum Master bi trebao imati ekspertne kompetencije u određenim tehnologijama (npr. Angular za front-end razvoj, Xmarin za mobilne aplikacije, ili Bootstrap za backend,…) i dovoljna (solidna) znanja za neka uža područja poslovanja.

Scrum Master komunicira s Product Ownerom i s developerima i eventualno s klijentovim IT specijalistima koji bi trebali preuzeti aplikaciju-produkt kada je prodana. Nikada ne razgovara s poslovanjem. To znači da inženjer koji radi motor nikada neće razgovarati sa mnom (vozačem) kako će napraviti motor. Ako želi naučiti više o poslovanju da bude bolji u svom poslu, može posjetiti različite potencijalne subjekte na tržištu i vidjeti kako rade određeni segment poslovanja. Ali to je edukacija Scrum Mastera koji se ne bi trebao naplaćivati nego plaćati. Imamo li mi u Hrvatskoj kvalitetne Scrum Mastere i što oni stvarno rade?!

Developeri

Developeri su osobe koji su vrhunski eksperti u jednoj ili više tehnologija koje je neka tvrtke odabrala za razvoj svojih aplikacija. Naravno, razvojni inženjeri kao i u svim industrijama mogu biti više ili manje ekspertni. Tako i cijena razvojnih inženjera ne može biti ista. Kaže mi kolega kojeg izuzetno cijenim da je za razvoj eksperta u nekoj tehnologiji (npr. Angular) potrebno 3 godine. Znači li to da svaki developer koji ima 3 godine iskustva razvoja u Angularu je ujedno i ekspert. Kako se mjeri da je on ekspert, a netko drugi nije? Isto vrijedi i za Scrum Mastera i za Product Ownera? Ako bismo opet povukli paralelu s autoindustrijom, developer je pandan eksperta za razvoj klipova u motoru. Mora biti tehnološki odlično potkovan oko materijala, funkcija i svih drugih tehničkih karakteristika i odlika klipa, ali i njegove uloge u motoru kao cjelini. Developer treba imati načelna znanja o ulozi motora u autu (poslovne funkcije koju razvija u poslovanju), ali zato ekspertno znanje kako napraviti klip (funkciju) da radi brzo i pouzdano, za optimalnu cijenu. Developer, koji nudi i unaprjeđenja, dodatne odlike tražene funkcije za poslovanje je kandidat za Scrum Mastera.

Kako razlikovati developera eksperta od developera početnika ili specijaliste. To sam naučio dok sam radio u Nizozemskoj kada sam popunjavao evaluacijski obrazac. Postoji čarobno pitanje koje su postavili: „Koliko puta postavi pitanje, traži pojašnjenje ili ga vraćaš na ispravke prije nego uspješno riješi zadatak / problem?“ Prema tome, jednom kada je Scrum Master pojasnio što treba napraviti, ekspert neće postavljati pitanje kako, nego zna kako, dok će specijalist postavljati kontinuirano pitanja ili će napraviti veliki broj grešaka. Pojednostavljeno, ekspert će biti brži i njegova rješenja neće trebati dorade i obratno. Dakle, vrijeme i kvaliteta (broj dorada i popravaka) je prava mjera. Vrhunski ekspert će napraviti sve traženo i dodati odlike kojim će taj proizvod ili dio proizvoda biti konkurentniji nego drugi sličan. Znamo li razlikovati developera eksperta od početnika s istom brojem godina iskustva?

Je li autoindustrija usporediva s IT industrijom?

Informatičari će reći da nije! Ako nije zašto onda uzimaju metodologiju iz autoindustrije u IT? Agile metodologija podrazumijeva određene preduvjete kao što je visoka razina kompetencija, odgovornosti i autonomije razvojnog tima. Drugo, u slučaju razvoja kompleksnih sustava potrebu za segmentiranje (modularizaciju) poslovnih funkcija u jednostavnije cjeline (aplikacije) koje može pokriti jedan Product Owner, a onda poseban Agile tim integrira te poslovne funkcije (aplikacije) u cjelinu. To se sve jako dobro vidi na Start-Up-ovima koji rade igrice ili male aplikacije. Razvoj rade na trošak tvrtke i nude gotov proizvod tržištu. Dakle, moguće je i u IT-u proizvoditi „automobile“, doduše male i jednostavne, ali ipak proizvod. Netko je proizveo i taj Angular (proizvod- razvojnu platformu). Ima bugove kao što imaju i svi automobili, ali „vozi“ od točke A do točke B, može ispuniti svoju namjenu ako ga koriti ekspert. Što razlikuje Agile IT od „Agile“ IT-a?

Kompetentnost, samostalnost i odgovornost razvojnog Agile tima čiji je cilj (scope) usklađen s njihovim sposobnostima /ekspertizom.

To znači da za neki kompleksniji proizvod trebate imati više Agile timova specijaliziran za pojedinu funkcionalnost, gdje u svakom timu postoji po jedan Product Owner, Scrum Master kako je gore opisano, a developeri (djelomično i Scrum Masteri) se mogu dijeliti između timova po potrebi, ekspertizi i opterećenju. Kompleksne projekte generalno ne možete rješavati jednim Agile timom, što potvrđuje i Chaos report. Kao što jedan Agile tim ne može napraviti automobil tako isto jedan ne može napraviti kompleksno informatičko rješenje.

Prema tome Agile /Scrum metodologija je najmanje proces koji su svi uveli s terminologijom i rolama. Međutim nekim nisu svi postali uistinu Agile u smislu brzine, kvalitete i rokova isporuke proizvoda korisniku. Uvođenjem terminologije i naziva procesa, maltretiranjem klijenta sa specifikacijom i danonoćnim radionicama neće se dogoditi neka magična promjena. Promjena dolazi s ljudima, a ne s procesima i metodologijama. Ako su vaši ljudi kompetentni, kreativni, odgovorni, autonomni i timski igrači, proces će doći sam od sebe, o prioritetima će se dogovoriti u 5 minuta, a backlog će biti napunjen novim idejama, a ne popravcima grešaka od prethodnog razvoja.

📷

Toyota Agile

Agile metodologija je nastala u Japanu (Toyoti) 1954. godine kada je bilo potrebno naći način kako uništenu zemlju nakon 2. Svjetskog rata uzdići. Nije bilo računala i BPM-a, pa je zato cijela metodologija zasnovana na motivaciji, kompetencijama i odgovornosti. Tako je nastao TPS (Toyota Production System ili Toyota Just In Time metodologija). To nije samo KANABAN i KAIZEN. Tu je Gemba, Hyojunka, Hashin Kanri, Taimuri, Muri, Mura, Muda, Jidoka, 5S i druge metode koje djeluju na pojedine segmente razvoja i poslovanja, te primarno djeluju na psihologiju djelatnika i cijele organizacije.  Najmanje na proces!

Preporučam video na YouTube-u o važnosti kreativnih ljudi u 21. stoljeću. [https://www.youtube.com/watch?v=ystdF6jN7hc]