Promjene u IT industriji su nužne, normalne i cijeli svijet se naviknuo da se svakih 10 godina cjelokupna paradigma u IT svijetu mijenja. I razdoblje promjene se kontinuirano smanjuje pa će te promjene biti još brže.
No, u isto vrijeme, IT poduzeća koja stvaraju spomenutu paradigmu, unutar sebe često imaju problema s brzim reagiranjem na promjene. Razlog tome leži u činjenici da se, kao i kod drugih poduzeća, operacije takvog poduzeća temelje na kvaliteti, što podrazumijeva jasne procese u radu, najbolje prakse i stabilnost u obavljanju djelatnosti, poglavito mission critical sustava ili postupaka koje neko IT poduzeće provodi.
Stoga, kad se u takvom uhodanom organizmu predloži da se uvede promjena koja utječe na kompletne operacije poduzeća, a i šire, npr. okvir Scruma (Izvor: Scrum Framework), nailazi se na velik broj pitanja i nedoumica, otpora i razloga zbog kojih to ne treba raditi.
Čemu služi Scrum?
Ovo je najčešće pitanje koje organizacija postavlja u trenutku kad netko predlaže promjenu u procesu razvoja proizvoda. Ako je ta organizacija još i zrela i “uhodanih” procesa, to pitanje će biti još glasnije i zahtijevati dublja obrazloženja. Moram priznati da sam i osobno bio suzdržan pri početnim koracima, iz nekoliko razloga. Prvo, neke se od paradigmi koje okvir Scruma uvodi odmiču od standardnog pogleda na upravljanje poduzećem. Npr. činjenica da u Scrum timu ne postoji vođa i glavni šef te da je tim “samoorganizirajući” za neke je teško racionalno prihvatiti tu činjenicu. No, prava je istina da se prema tome treba težiti, a put do toga je sve samo ne jednostavan. Drugo, okvir Scruma odskače od tradicionalnog poimanja projekta u kojem su budžet, rok i opseg fiksirani te glavna zadaća projektnog tima je ostati unutar tog trokuta (što je često vrlo izazovno). Umjesto toga, Scrum u prvi plan stavlja čestu isporuku gotovih dijelova proizvoda provjerene kvalitete. Na temelju povratnih informacija od korisnika revidiramo daljnji plan rada. Dugoročno gledano, na taj način krajnjim korisnicima ranije isporučujemo više poslovne vrijednosti.
U stvarnosti glomazni projekti i “standardni uhodani” waterfall procesi realizacije projekata imaju sve manje smisla. Naime, vidljivost onog što radimo treba što prije u projektu otvoriti prema korisniku jer to korisnik zapravo želi, tehnologija to sve više podržava, promjene i prilagodbe su sve lakše, a poslovna okolina oko projekta se mijenja brzinama u kojima može znatno utjecati na projekt, pa ga time i ugroziti. Sukladno tome poduzeća koje se bave IT projektima trebaju dobro razmisliti o promjeni waterfall paradigme, kako u prodajnoj fazi, tako i u fazi realizacije.
Svim ovim promjenama treba pristupiti “sa zrnom soli” u smislu da ih treba usvajati postupno, brzinom kojom je organizacija (tu se misli i na tržište na kojem organizacija nastupa) spremno obraditi i prihvatiti promjene koje one nose. U nastavku je kratko opisano kako je u
našem poduzeću izgledala prva godina uvođenja okvira Scruma, izazove s kojima smo se susreli i rezultate koje
smo postigli.
Također, treba uzeti u obzir da oko agilnih metoda, kao i oko Scruma, postoje ogromne fame i predrasude – ljudi se na forumima u pravim “flame wars” dopisuju oko raznih štetnih karakteristika – od toga da se previše vremena posvećuje “ceremonijama” (sastancima), do toga da se ubija kreativnost. No, svatko tko je posvetio kratko vrijeme da pročita tih nekoliko stranica Scrum priručnika (da, samo desetak!), zna da vas nitko neće tražiti da kao zombije, forme radi, izrecitirate “što radim, koji su problemi, što ću raditi”. Isto tako, Sprint ima svoju glavu
i rep, upravo kako bi smanjio ad-hoc nepotrebne sastanke i omogućio timu da se usmjeri na postizanje cilja. No, želimo kolaboraciju članova, što znači da ćemo ionako razgovarati, planirati, dogovarati se – zar ne?
Pitanje raspoloživosti resursa za Scrum
Kao i puno drugih poduhvata koji ne spadaju u operativno poslovanje, za ovakvu promjenu poduzeće mora proći pripremu, u prvom redu pronalaska resursa koji će projekt kontinuirano operativno podržavati. Osim internih resursa, potrebno je pronaći i vanjske stručnjake (ako već ne postoje unutar poduzeća) koji će interni tim usmjeravati i pružiti im podršku u pripremi projekta i stvaranju kritične mase za promjenu unutar organizacije. U našem slučaju to su: Ana Roje Ivančić i Ognjen Bajić iz Agilist informacijskih tehnologija, Professional Scrum treneri licencirani od strane Scrum.org. U Omegi Software smo oformili interni tim (nazvali smo ga Development Process Optimization – DPO) i povjerili im zadatak istraživanja Scrum okvira te izrade prijedloga plana kako ga uvesti u poduzeće. Naravno, u svojem djelovanju rukovode se Scrumom i tako su primjer i inspiracija drugima. Osim Scruma, DPO tim je na sebe preuzeo i brigu o drugim aspektima rada (npr. migracije centralnog Wikija poduzeća na Azure Devops Wiki).
(kliknite na fotografiju za veći prikaz)
Usporedno s izgradnjom tima, gotovo sve operativne kolege (60+) su se uključile na osnovni tečaj Scruma gdje su se upoznali s osnovnom idejom, podlogom, terminologijom, pristupom i alatima te smo prikupili očekivanja i rizike koje kolege vide u uvođenju ovakve promjene u
organizaciju.
Također, važno je za napomenuti kako je velika većina djelatnika koja je slušala edukaciju i položila Professional Scrum Master I certifikat pa se tako kao organizacija ponosimo sa velikim brojem certificiranih djelatnika u području Scruma.
U pristupu ovakvoj promjeni važno je zadržati svijest da tekuća organizacija i poslovanje trebaju nastaviti neometano (koliko je to moguće) raditi tako da odluke koje donose promjenu trebaju biti donašane pažljivo i postupno.
Naša iskustva u uvođenju okvira Scruma u poslovanje
Nakon ustrojavanja DPO tima i dodjeljivanja odgovornosti za uvođenje ove promjene i obavljenih temeljnih edukacija, tim je krenuo s definiranjem osnovnih procesa koje bi Scrum timovi trebali prihvatiti. Sve ideje su prvo usklađene s vanjskim stručnjacima, dokumentirane, prvo kod sebe primijenili te nakon toga predali timovima na usvajanje. Pri tome smo otvoreno slušali timove i tome prilagođavali dinamiku promjene. Članovi DPO tima su podržavali timove u usvajanju procesa – putem su zapravo preuzeli dio uloge Scrum mastera u tim timovima, budući da smo ih dosta teško nalazili na tržištu.
Što smo napravili u prvih 18 mjeseci uvođenja Scruma u Omega Software?
• Educirali smo 60+ djelatnika osnovama Scruma, od kojih je većina kolega i položila PSM I Scrum certifikat; time smo dobili kritičnu masu za daljnje izmjene u procesu
• Upogonili 9 Scrum timova tako da su svi počeli prakticirati dio Scruma, svaki u svom ritmu
• Ustrojili smo osnovnu arhitekturu Azure DevOpsa i prilagodili je našem modelu poslovanja te sada svi timovi dijele isti workspace i nove promjene nam je lakše i učinkovitije uvoditi
• Unificirali smo bitne procese (Definition of Ready i Definition of Done) na razini svih timova tako da postoji jedan pogled na to kako opisati što treba raditi i kako reći da je to što radimo gotovo i ispravno
• Uveli smo proces refinementa i continuous supporta našim korisnicima u Scrum proces i uskladili ga s projektnim procesima
• Migrirali smo naš stari wiki na centralni Azure DevOps wiki kojeg sada puno lakše dijelimo i nadograđujemo
• Počeli smo razvijati pristup pripremi i “startup-anju” novog projekta analizom alata za otvaranje Azure DevOps sadržaja korisniku
• Migrirali smo osnovne postupke testiranja na Azure DevOps odgovarajuće alate i time otvorili širu priču kvalitete testiranja
• Iskovali ambiciozne planove za budućnost Scruma u Omega Software
• Sve to prakticirali na našem DPO timu i pri tome mnogo naučili
• U godinu dana smo DPO projekt uspjeli istaknuti kao točku s koje je uvesti promjene u organizaciji operacija poduzeća znatno lakše nego što je bilo prije godinu dana na što smo jako ponosni.
(kliknite na fotografiju za veći prikaz)
Trenutno smo fokusirani na stabilizaciju do sada uvedenih procesa i izgradnju kvalitetne Scrum master grupe unutar organizacije koja će podržati timove u aktivnom radu. Na vrhu development boarda DPO tima imamo nove ideje.
Nakon godinu dana aktivnog uvođenja Scruma u operativni rad Omege Software korisno je istaknuti slijedeće:
• Nakon početnog uhodavanja i otpora promjeni, većinu energije smo uložili u konkretne procese i detalje kako iskoristiti dostupne alate da bi procesi bili što učinkovitiji i prilagođeni specifičnim procesima, navikama ili terminima unutar poduzeća
• Za početak smo se fokusirali isključivo na operacije u poduzeću – nismo se bavili vezom prema drugim segmentima poduzeća na koje bi ova promjena mogla utjecati; cilj nam je bio dovoditi sustav iz jednog u drugo stabilno stanje bez da potresamo ostatak poduzeća (uostalom, to i cilj rada u Scrumu)
• U uvođenju smo pokušavali uvažiti što više toga što Scrum okvir donosi, no nismo ga shvaćali kao “religiju”; u dijelovima procesa gdje se naša organizacija previše razlikuje od onog što Scrum propisuje, nismo agresivno inzistirali na doslovnoj primjeni, već smo napravili razumne odluke
• U tranziciji prema agilnom načinu razvoja bitnu ulogu su nam odigrali voditelji projekata (makar ih okvir Scruma kao takve ne opisuje); u njima se nalazi ono bitno iskustvo koje trenutno koristimo da timove naučimo kako biti samostalan u što više aspekata posla
• Tijekom projekta smo shvatili da je pozicija Scrum Mastera vrlo rijetka na tržištu i da je kvalitetne ljude tog profila izazov pronaći
• Vrlo je važno da operativne pripreme promjena budu provođene paralelno s internim edukacijama i marketingom prema ostatku poduzeća i upravi; ovo je projekt koji je u svojoj biti investicija, a vidljivost njegovih efekata je indirektna i teško ju je kvantificirati
• Osim promjene u radu u razvoju proizvoda, projekt donosi pozitivne efekte na motivaciju djelatnika, koji u donesenim promjenama vide smisao i žele raditi sukladno modernim praksama i na modernim alatima
• Trud i investicija u promjene koje smo postigli se isplate i preporučam da, ukoliko vaša organizacija razmišlja o promjeni ovakvog tipa, date podršku entuzijastima koji pokušavaju takvu promjenu provesti.
Naša osnovna Azure Devops arhitektura
U nastavku ćemo ukratko opisati detalje platforme koju smo upotrijebili za podršku okviru Scruma.
Kao temelj podrške procesima okvira Scruma upotrijebili smo Azure Devops. Budući da u poduzeću imamo više (9) Scrum timova podijeljenih po različitim poslovnim područjima, cilj nam je bio objediniti timove na centralnu platformu koja će olakšati kolaboraciju, kontrolu nad procesima i omogućiti lakše preseljenje ljudi među timovima u trenutku kad nekom treba promjena.
Organizacija rada predviđa da se projekt, tj. određena poslovna aktivnost dodijeli timu, a ne da se klasično za svaki projekt formira zasebni projektni tim. Stoga smo se odrekli upotrebe više Azure Devops projekata unutar organizacije. Umjesto toga, unutar našeg jednog zajedničkog projekta imamo razrađenu strukturu timova: svaki tim ima više timskih ploča (team board) – ploča za razradu (refinement), ploča za razvoj i ploča za podršku. Ako tim u isto vrijeme provodi više aktivnosti/projekata, internih i eksternih, malih ili velikih, sve će transparentno biti praćeno na istim pločama te je time u svakom trenutku jasno što je prioritet.
Svatko može dodati nove stavke (work item) na ploču za razradu, a Product Owner potvrditi će interes i odrediti prioritet kao predstavnik dionika (stakeholders). Kroz ploču za razradu pratimo spremnost (Definition of Ready) svake pojedine stavke. Važno je da kroz periodičke sastanke za razradu, cijeli tim prokomentira zahtjeve, te da zatim zajednički usvoji što treba napraviti – za početak samo osnovnu analizu. Pri tome nastaje zajednička procjena truda potrebnog za izvršenje (effort). Time se gradi timska odgovornost za sve što je tim preuzeo, umjesto da se svatko zakopa u “svoj zadatak”. Stavke koje su spremne prebacujemo na ploču za razvoj. Naravno kroz proces razrade,
strukturiramo stavke u cjeline po hijerarhiji Epic - Feature - Product Backlog Item.
Ploča za razvoj je backlog razrađenih, spremnih stavaka. Prilikom planiranja Sprinta tim će prema prioritetu naznačenom od Product Ownera, preuzeti stavke u Sprint te pratiti povezane zadatke na Sprint ploči (Sprint Taskboard).
Ploču za podršku imamo jer prepoznajemo da svaki tim samo dio svojeg kapaciteta može držati u stanju strukturiranog Scrum Sprinta. Aktivnosti u podršci su često reaktivne, neplanirane te stoga ploča za podršku podržava Kanban način rada. Dežurne osobe u timu prate stavke podrške (Ticket, Bug) te samostalno rješavaju. Ako kompleksnost prelazi onu koju mogu dežurni riješiti, na ploči je naznačeno da se Product Owner mora uključiti što će dovesti do toga da se kompleksniji zadaci timski rješavaju kroz (budući) Sprint. Dežurne osobe se rotiraju u timu kako bi svi imali jednaku odgovornost za kvalitetu isporučenih rješenja, tj. kako bi svi osjetili što znači održavati ono što su napravili.
Zajednički devops projekt ima više repozitorija (Git Repo), za svakog klijenta i povezano rješenje/platformu. Koristeći cjevovode (Pipelines), omogućavamo Continuous Integration i Continuous Deployment dio procesa kako bismo kontinuirano pratili kvalitetu koda uz automatsku
statičku analizu i automatizirane testove. Naposljetku, time ubrzano dostavljamo rješenja na odredišne okoline, što uključuje interne testne, naručiteljeve testne/edukacijske, a uz dopuštenje i produkcijske okoline.
Potencijali agilnog načina razvoja
Zamjena načina na koji radi development u IT poduzeću koje izrađuje složene IT sustave je u mnogome slično kao kad se u pekari ide u remont stroja za pečenje peciva. Veliki rizik za poslovanje, stres za zaposlenike i one koji rukovode tim projektom, neizvjestan ishod, no i u jednom i u drugim slučaju radi se o promjeni s vrlo velikim potencijalom za budućnost. Svako IT poduzeće želi biti
u korak s načinom na koji svjetske uspješne kompanije (npr. Microsoft, Amazon, Tesla) razvijaju svoje proizvode. Agilni način razvoja je trenutno “in” i po puno kategorija ima smisla to što propisuje.
Manje je važno koji agilni okvir se preuzme – puno je važnije da na taj zadatak budu stavljeni ljudi koji to strastveno žele uvesti i da im bude dana podrška i kvalitetna vanjska ekspertiza da tu promjenu i provedu. I potrebno je dostići kritičnu masu promjene, kad timovi počinju sami težiti biti “samoorganizirajući” – i sami počinju željeti nove segmente agilnog pristupa razvoju. Tada se prestaje davati ljude na projekte, a počinje davati projekte timovima ljudi.
