Kada kompanije premeštaju svoja softverska rešenja sa lokalnih servera na cloud platforme, često sebi postavljaju cilj da postanu agilnije. To bi, u idealnom slučaju, trebalo da važi za sve nivoe unutar kompanije, i to istovremeno.
Transformacija procesa, barem u teoriji, deluje izvodljivo. Možete definisati scrum ceremonije i preraspodeliti zaposlene na nove pozicije, kao što su scrum masteri, vlasnici proizvoda, menadžeri isporuke i scrum timovi.
Možete uvesti alate kao što su Jira, Azure DevOps i Miro table i zahtevati njihovo obavezno korišćenje. Ali šta je sa procesima koji povezuju te alate? Šta je sa promenom načina razmišljanja, ponašanja i rada zaposlenih? Jasno je da se takve promene ne dešavaju lako i brzo. Razmotrimo sada zašto je to tako.
Šta predstavlja inicijativa za transformaciju isporuke i zašto se kompanije odlučuju na nju?
Veliki broj kompanija i danas koristi model isporuke „vodopad“. To znači da:
- Se prvo planira krajnji proizvod i procenjuje okvirna cena.
- Se započinje proces prikupljanja zahteva, tokom kojeg se detaljno razmatraju sve specifikacije krajnjeg proizvoda, razmatraju prigovori, vrši analiza, postižu dogovori, i na kraju, potvrđuju zahtevi.
- Se vrši procena celokupnog projekta i potvrđuju budžetska očekivanja.
- Se dizajnira rešenje. Održavaju se sastanci sa zainteresovanim stranama. Izrađuje se dokumentacija i šalje na pregled. Potvrđuje se i odobrava finalni funkcionalni i tehnički dizajn.
- Se implementira rešenje na osnovu dizajna, razvijajući celokupan krajnji proizvod.
- Se prelazi u fazu testiranja gde se sprovode različite vrste testova: jedinično testiranje, sistemsko testiranje, funkcionalno testiranje, integracijsko testiranje, testiranje performansi, regresiono testiranje, testiranje prihvatljivosti od strane korisnika, i potencijalno još mnogo toga (zavisno od kulture kompanije). Sve se dokumentuje i šalje na pregled i odobrenje.
- Se postavlja rešenje u produkciono okruženje gde korisnici počinju da koriste finalni proizvod.
- Se planira faza podrške u kojoj razvojni tim ispravlja potencijalne greške.
Ovaj proces može trajati od nekoliko meseci do nekoliko godina, a krajnji korisnici rezultate vide tek na samom kraju. Nakon dugog čekanja, dolazi trenutak istine ili neuspeha.
Ukoliko se tokom ovog perioda nešto promeni, i krajnji proizvod treba da izgleda drugačije, to se tretira kao zahtev za izmenu. Dizajn se ponovo otvara, prerađuje i odobrava, što produžava vremenski rok.
Jasno je da ovo ni na koji način nije agilno. Svaka promena zahteva ponovno pokretanje celog procesa.
Prelazak na Agilno
Kako se izvući iz ove situacije i preći na agilni pristup? Ljudi su godinama, pa čak i decenijama, radili po modelu vodopada. Imaju uloge i odgovornosti koje im odgovaraju i ne žele da menjaju status quo. Osnovni razlog je taj što promena znači gubitak dela moći koju su imali.
To je glavni razlog zašto ovakve promene nailaze na snažan otpor među zaposlenima.
#1. Restrukturiranje tima
Prvo i relativno najjednostavnije je restrukturiranje timova u scrum timove. Podelite ih prema funkcionalnim oblastima ili nekoj drugoj logičnoj podeli.
Sama podela uglavnom prolazi glatko, ali problem nastaje kada shvatite da su ljudi i dalje vezani za stare strukture. Čak i ako su deo novih scrum timova, u praksi nisu. I dalje rade na starim postavkama jer imaju nedovršene obaveze od pre restrukturiranja. Rukovodstvo ne brine o tome šta treba završiti, već o tome šta treba započeti.
Tako, na kraju imate scrum tim koji nije u potpunosti posvećen scrum načinu rada. To je grupa ljudi koja sada ima više posla. Nemaju dovoljno vremena da rade unutar scrum tima onoliko koliko menadžment očekuje.
Istovremeno, očekuje se da završe prethodne zadatke i nove zadatke u scrum timovima. To je recept za neuspeh.
#2. Zakazivanje Scrum ceremonija
Lako je definisati i naložiti timovima da zakazuju redovne sastanke (sprint ceremonije), barem ako vaši scrum timovi nisu sastavljeni od ljudi iz 3+ vremenske zone (što se često dešava).
Problem nastaje kada ljudi ne prisustvuju redovno ceremonijama. U zavisnosti od toga ko nedostaje i koliko često, mogu nastati različiti problemi. Na primer:
- Ako vlasnici proizvoda ne prisustvuju ceremoniji planiranja, tim nema novih priča na kojima bi radio. Ili su opisi priča toliko loši da ostatak tima ne može da počne da radi na njima.
- Ako scrum masteri nedostaju na sastancima, timu nedostaje osnovna scrum orkestracija i može se izgubiti s vremenom.
- Ako članovi razvojnog tima često izostaju, ne mogu se sinhronizovati, a komunikacija unutar tima je otežana. Potrebno je više sastanaka da bi se nadoknadilo izgubljeno, što oduzima još više vremena.
Na kraju, ljudi nisu krivi što propuštaju ceremonije. Postavka im ne dozvoljava da budu prisutni (pogledajte deo o paralelnim zadacima).
#3. Stabilnost tima
Možda imate scrum tim sa strukturom i ceremonijama, ali ako taj tim nije stabilan duži vremenski period – recimo bar pola godine, idealno godinu dana – takav tim ne može napredovati i poboljšavati se.
Verovatno nikada nećete dobiti potpuno nezavisan scrum tim koji radi sprintove po planu. Stalno ćete morati da obučavate ljude u timu kako bi razumeli scrum način razmišljanja i procese. To je iscrpljujuće.
Ovo je veoma potcenjen problem, posebno od strane rukovodstva. Tretiranje timova kao „resursa“ i planiranje njihovog „iskorišćavanja“ iz kvartala u kvartal je siguran put u propast.
#4. Nove uloge za iste ljude
Još jedna prepreka je preraspodela postojećih zaposlenih na nove pozicije. Oni koji su ranije upravljali timovima sa velikom moći, sada postaju vlasnici proizvoda. Iako je to važna uloga u scrum timu, može se posmatrati kao slabija u odnosu na prethodnu.
Vlasnici proizvoda sada moraju da se sinhronizuju sa scrum masterom ili menadžerima programa. I dalje su odgovorni za sadržaj, ali ne toliko za proces isporuke. Ova situacija zahteva odustajanje od nekih odgovornosti koje su ljudi ranije imali, što im teško pada.
#5. Načini rada
Često se čuje da moramo da usvojimo nove načine rada kako bismo bili konkurentni na tržištu gde je agilnost očekivana. Ali šta ti načini rada zapravo znače?
Menadžment obično pod tim podrazumeva da se postigne (mnogo) više za kraće vreme. Nakon uspostavljanja scrum timova, očekuje se da će svaki član tima iznenada postizati određene dokumentovane rezultate iz dana u dan. Ako se to ne dogodi, rukovodstvo će se pitati zašto agilni proces ne funkcioniše dobro.
Rukovodstvo očekuje da se svaki sat računa i da timovi nemaju slobodnog vremena, samo zato što su scrum procesi uvedeni. To je kratka definicija „novih načina rada“ iz perspektive rukovodstva.
Ovo očekivanje nije realno. Iluzorno je očekivati da će ljudi početi da rade više u istom vremenskom periodu samo zato što su se neki procesi promenili. Neki možda hoće, ali samo manji broj. Međutim, čak se i taj broj dodatno smanjuje zatrpavanjem sa više zadataka istovremeno.
Razlika između cilja i stvarnosti
Opis krajnjeg cilja je često dobar i smislen. Obuhvata sledeće principe:
- Stabilni scrum timovi koji rade na nezavisnim zadacima sa jasnim KPI i OKR-ovima.
- Vlasnici proizvoda kreiraju detaljne planove i određuju prioritet sadržaja koji će biti isporučen u određenom roku.
- Definisan backlog sa relevantnim funkcijama koje su detaljno opisane pre početka rada.
- Pouzdan proces testiranja koji se sprovodi paralelno sa redovnim sprint razvojem.
- Redovno puštanje u produkciju – najmanje jednom mesečno, idealno nakon svakog završetka sprinta.
- Praćenje rizika i problema i komunikacija između različitih scrum timova u slučaju zavisnosti.
Međutim, stvarnost je da nijedna od navedenih tačaka nije lako ostvariva.
- Formirate scrum timove, ali se oni stalno menjaju (iz kvartala u kvartal). Ulažete vreme da ih obučite, a kada počnu da prihvataju i menjaju način rada, reorganizujete ih. Planovi se menjaju, odlažu ili otkazuju.
- Vlasnici proizvoda nemaju pravu predstavu o detaljima plana i delegiraju zadatke direktno timu. Tim nema vremena za razvoj sadržaja jer mora prvo da osmisli šta da razvija.
- Procesi testiranja su ručni i zahtevaju mnogo koraka, odobrenja i komplikovane procedure. Nije moguće završiti testiranje u istom sprintu kao i razvoj.
- Puštanje u produkciju kasni nekoliko sprintova.
- Komunikacija između timova je haotična i neefikasna. Vlasnici proizvoda dodeljuju timovima previše zadataka za svaki sprint. Nema šanse da tim sve završi, pa su stalno pod stresom zbog rokova.
Ispravljanje grešaka
Na osnovu iskustva sa nekoliko projekata agilne transformacije, želeo bih da sumiram neke od najvećih grešaka koje sam iskusio i da iznesem subjektivna mišljenja o njihovom prevazilaženju.
#1. Prave odgovornosti za prave uloge
Ako pokušate da izmenite definicije i rasporedite odgovornosti drugačije od onoga kako bi trebalo biti u scrum/agilnom okruženju, ceo projekat je osuđen na propast.
- Vlasnici proizvoda su zaduženi za sadržaj i održavanje backlog-a. Ako priče nisu dobro definisane, njihova je odgovornost da to isprave. S druge strane, ne bi trebalo da utiču na zadatke ljudi u scrum timu ili odluke o budžetu projekta.
- Scrum masteri nisu odgovorni za sadržaj. Oni su tu da orkestriraju ceremonije i obučavaju tim o agilnom načinu rada. Ne bi trebalo da budu sekretarice vlasnika proizvoda, već da štite razvojni tim od vlasnika proizvoda i spoljnih zainteresovanih strana.
- Svaki scrum tim treba da ima vođu isporuke koji povezuje vlasnika proizvoda, scrum mastera i razvojni tim. On definiše procese isporuke i rešava sve potencijalne rizike, probleme ili sukobe. Vođa isporuke je odgovoran za kadrovska pitanja i budžet. On stvara okruženje u kojem svako može raditi najbolje što može.
- Odgovornost razvojnog tima je da razvija priče iz backlog-a. Mogu pomoći vlasniku proizvoda da kreira sadržaj za neke priče (uglavnom one tehničke prirode), ali nisu odgovorni za priče koje kreiraju sadržaj mapa puta.
#2. Stabilan tim
Ulaganje u agilnu obuku tima je važno i mora biti brz proces. Gubitak znanja svakih nekoliko meseci je gubljenje vremena za sve.
Prvih pet sprintova možete iskoristiti kao period učenja za tim da se upozna i uvežba osnovne scrum aktivnosti. Kada to postane jasno celom timu, može početi kontinuirano poboljšanje. Ali ako se članovi tima redovno menjaju, stalno ćete se vraćati na transfer znanja i obuku.
Takav tim verovatno nikada neće dostići puni potencijal, a rukovodstvo će se pitati zašto je tim bio efikasniji pre agilne transformacije.
Izgradite tim, uložite znanje, a kada tim savlada nove procese, samo ga zadržite i nastavljajte da se razvijate. To je put ka izvrsnosti.
#3. RACI Matrica
Pre početka posla, korisno je izraditi i dogovoriti RACI matricu (odgovoran, zadužen, konsultovan, informisan) između svih timova. Ovo može ukloniti mnogo potencijalne zbrke na početku.
Ovo je veoma važno, posebno u ranim fazama inicijative za transformaciju. U suprotnom, ljudi će početi da postavljaju pitanja ko treba šta da radi, posebno u situacijama koje nisu jasno definisane.
Evo primera RACI matrice za neke od odgovornosti. Vaš projekat može imati drugačiji skup. Važno je da uhvatite relevantne elemente.
| Zadatak | Podnosilac zahteva | Vođa isporuke | Vlasnik proizvoda | Scrum Master | Razvojni tim |
| Planiranje sprintova | C/I | C | A/I | R | C/I |
| Isporuka inkrementa | N/A | A | I | C/I | R |
| Revizija sprinta | C/I | I | I | R | C |
| Retrospektiva sprinta | I | I | A/I | R | C/I |
| Uređivanje backloga | I | A/I | R | C/I | I |
Zaključak
Moglo bi se još mnogo pisati o ovoj temi jer postoji mnogo načina da agilna transformacija skrene sa pravog puta. Cilj je bio ukazati na neke probleme koji se često ponavljaju.
Sama inicijativa je dobra ideja. Međutim, može brzo postati noćna mora ako se ne poštuju osnovna pravila. Naveo sam neka od njih, ali zdrav razum je ključan. 🙂
Dodatno, istražite resurse za učenje za sticanje agilnih sertifikata.