Napisao: Luka Skupnjak, Backend Team Lead & Scrum Master

Agile, Scrum, Sprint, Retro, Daily, User Story, Story Point… Siguran sam da ste barem nekoliko ovih pojmova čuli tijekom zadnjih nekoliko dana (možda čak i sati). Koriste se širom IT industrije, različite tvrtke ih koriste za različite stvari, no rijetki su ulovili samu bit tih pojmova – zašto oni uopće postoje i koju svrhu trebaju obnašati.

Ja sam Luka Skupnjak, Backend Team Lead i Scrum Master u SofaScoreu. U ovom tekstu neću dati alternativni prijevod Scrum Guidea. Neću niti detaljno opisivati svaki pojam i kako bi to u teoriji trebalo funkcionirati. Pokušat ću “ogoliti” Scrum, pričati iz prakse i doći do same srži, bez tree-hugging bullshita koji obično prati bilo što povezano s pojmom “Agile”.

1. Što je to zapravo Agile?

Vjerovali ili ne, Agile je zapravo kreacija developera. Ne Marketinga, Salesa, Product/Project Managementa, ili bilo kakvih drugih stakeholdera koji žele proizvesti više u manje vremena. Priča ide ovako – 17 developera se početkom 2001. uputilo u planine na klasično druženje uz jelo, piće, skijanje i da pričaju o tome kako razvijaju softver. Iskustva nije nedostajalo – mnogima će biti poznata imena Martina Fowlera ili Robert C. Martina (Uncle Bob). Rezultat njihovog druženja je “Manifesto for Agile Software Development”, kratki dokument koji opisuje dobre prakse iz razvoja softvera koje su oni doživjeli u svojim godinama rada. Dokument se sastoji od 3 rečenice i 12 principa. Ne govori apsolutno ništa o eventima, alatima, procjenama, ticketima, on samo nudi način razmišljanja kakav je iz iskustava ovih ljudi dao najbolje rezultate.

Prva rečenica manifesta daje glavnu ideju Agilea – “We are uncovering better ways of developing software by doing it and helping others do it”. Dakle, “learning by doing”. Ne puno filozofirati i gubiti se u kompliciranim procesima, nego raditi, na temelju napravljenog dobiti nove informacije koje onda usmjeravaju daljnje odluke i daljnji rad.

U današnje vrijeme to možemo najbolje vidjeti na primjeru startupa – postoji ideja, mali tim strastvenih ljudi okupljenih oko te ideje i idu osvojiti svijet. Naprave prvu verziju svoje ideje, puste ju na tržište, pričaju s korisnicima, nadograđuju. I tako u krug. Nema ticketa, specifikacija, super specijaliziranih timova, stakeholdera – svi rade sa zajedničkim ciljem i s glavnim fokusom na korisnika.

U SofaScoreu se trudimo i dalje zadržati takav pristup iako nas je više od 150. Raditi što više user testinga, slušati ideje korisnika i zaposlenika, te ideje implementirati i što prije dobiti povratnu informaciju od krajnjeg korisnika. “Gut-feeling” stakeholdera može dati puno vrijednosti, ali još je veća vrijednost slušati što kaže više od 20 milijuna mjesečno aktivnih korisnika.

Dakle, Agile je prije svega mindset, odnosno način razmišljanja.

2. Ok, Agile, super, kužim. A što je onda Scrum?

Scrum je samo jedan od okvira (framework) koji daje smjernice kako biti agilan. Nije jedini. Nije savršen. Ne funkcionira za sve organizacije, proizvode, timove. I svi drugi su nesavršeni. Scrum je samo najpopularniji (66% prema State of Agile izvještaju).

Zanimljivo je i spomenuti da je Scrum petnaestak godina stariji od Agilea.

Izvor: https://digital.ai/resource-center/analyst-reports/state-of-agile-report

Većina tvrtki koje su krenule u neku vrstu agilne transformacije to su učinile jer su shvatile da waterfall model ne funkcionira za projekte koji imaju puno varijacija i nepredvidljivosti.

Waterfall tipično ima flow: analiza – specifikacija – dizajn – kodiranje – testiranje – isporuka. Za proizvode koji imaju uvijek isti input i očekuju uvijek isti output, to je i više nego dobar model. Nema varijacija, sve možemo predvidjeti, nema potrebe “plivanja uzvodno” – super.

Jeste li ikad u IT-u radili na proizvodu koji je takav? Ja nisam. Većina nije.

Waterfall u praksi u IT-u izgleda tako da postoji veliki dokument sa specifikacijom gdje se pokuša sve predvidjeti, bilo kakva procjena je beskorisna jer se ne može sve predvidjeti, zbog toga se rokovi redovito probijaju, a period testiranja se koristi za ugurati dodatne funkcionalnosti koje se netko nije sjetio dok je pisao onu veliku specifikaciju. U nekom trenutku se shvati da to baš i ne funkcionira, da je development spor, da su rokovi problem, da je dokumentacija beskorisna, i evo spasitelja – Agile. Koji je najpopularniji način za implementirati Agile? Scrum.

Ako se krene površno čitati kroz “obećanja” koja daju Agile i Scrum, jasno je zašto je tvrtkama to toliko sexy:

Promjene su dobrodošle, čak i u kasnoj fazi projekta – zakon!
Rokovi – nema ih! Ne možeš prekršiti rok kojeg nema – briljantno!
Svakih dva tjedna tim treba pokazati što je napravio i dati status report. OMG. Pa to zvuči kao najbolji command-and-control
Developeri rade u Sprintevima, Sprint=Usain Bolt=brzina. YES!

Koji je onda idući površni korak? Ubaci se neki alat (Jira, Youtrack, Trello, …) kako bi podržao takav način rada, preimenuje se Project Managere u Product Ownere i Scrum Mastere, neke od njih se pošalje na certificiranje da imaju papir, ubaci se hrpa sastanaka u kalendar i bam – sad smo agilni. Prati se forma, a ne sadržaj.

Nakon par tjedana ili mjeseci kreće čuđenje zašto ne funkcionira kako je “obećano”, Scrum je bezveze, Agile je izmišljotina, to u “pravom svijetu” ne može raditi. Zapravo se ništa nije promijenilo. Način razmišljanja ostao je isti, način rada isti, komunikacijski kanali isti, uključenost ljudi i timova isto. Dogodilo se samo nekoliko preimenovanja i popunilo kalendar.

Scrum stoji na tri stupa:

Transparentnost
Inspekcija
Adaptacija

Sve što se definira kroz Scrum Guide je u službi nekog od tih stupova. Scrum Guide ne propisuje način kako se ti stupovi MORAJU adresirati. Daje određeni okvir i smjernicu kako se može raditi. Na samoj implementaciji je kako će to izvesti, s time da je važno da se zadrži osnovna svrha. Ako se izgubi – baci u smeće i nađi bolji način. Uncover better ways, sjećaš se? Ako temelj kuće oslabi, kuća se sruši. Isto je sa Scrumom i njegovim stupovima.

Scrum kao framework sastoji se od 3 artefakta, 5 evenata i 3 uloge, pa uđimo u sadržaj svakog od njih.

2.1 Scrum artefakti

Artefakti su konkretni rezultat Scruma. Kao fizički vidljive stvari, služe da pruže transparentnost na različitim razinama. Što je veća razina transparentnosti, što je stvar u koju gledamo bliže istini, to imamo manje pretpostavki i možemo bolje i brže napredovati.

Product Backlog – daje transparentnost na moguću budućnost
Sprint Backlog – daje transparentnost na sve stvari koje se upravo dešavaju
Increment – daje transparentnost na to što proizvod uistinu jest

Ako je nešto od toga “zamućeno”, i istina je na neki način sakrivena, artefakti ne ispunjavaju svoju svrhu. Npr. ako Increment ne ide prema korisnicima dovoljno često, ako se od tih korisnika ne dobije feedback na to što proizvod jest, onda Increment možda i nije previše koristan. Možda je to OK u konkretnoj situaciji, ali barem treba toga biti svjestan. Ako Sprint Backlog sadrži samo dio stvari na kojima tim radi – zašto je to tako? Što se skriva i od koga? Ako je Product Backlog pun “smeća” i ideja koje nikad neće doći na red, a radi se samo na ad-hoc stvarima – možda i to treba adresirati.

2.2 Scrum eventi

S eventima obično ima najviše problema i osjećaja da se gubi vrijeme. Često se zna čuti “Umjesto da sam sjedio 2 sata na Sprint Planningu mogao sam tri ticketa riješiti”. I to je istina, ako taj event služi samo da se tamo sjedi i ako tih dva sata nije produktivno.

Sprint je srce Scruma i glavni pokretač učenja. Na Sprint Planningu dizajniramo kako ćemo surađivati i fokusiramo se na cilj kojeg želimo ostvariti u tom Sprintu.

Želimo učiti na svim razinama i biti bolji svaki sprint.

Učenje = inspekcija + adaptacija.

Daily Scrum – učenje na razini izvršenja – kako da danas kreiramo proizvod bolje nego jučer
Sprint Review – učenje na razini projekta – što smo napravili, što korisnici i stakeholderi kažu o tome, što je odlično, a što treba drugačije
Sprint Retrospective – učenje na razini kolaboracije – kako da bolje surađujemo kao tim

Ako eventi ne potiču učenje, ako se nakon njih ništa ne mijenja – nešto smrdi. Ne koristimo na pravi način informacije koje smo skupili u zadnjem periodu da bismo bili bolji u idućem. Stojimo. Nismo agilni. Sasvim je nebitno koliko je vremensko trajanje kojeg eventa i koliko često se on dešava, puno bitnije je da ispunjava svoju svrhu. Kad ispunjava svrhu onda je produktivan i nije gubitak vremena.

Daily Scrum ne mora biti svaki dan ujutro u trajanju od 15 min gdje svaki član tima odgovara na tri pitanja – što sam radio jučer, što radim danas, što me blokira. Forma je nebitna, bitan je sadržaj. Na timu je da otkrije na koji način će se najbolje uskladiti i poboljšavati na razini izvršenja.

2.3 Scrum uloge

Još su nam ostale uloge u Scrumu. I tu je stvar vrlo jednostavna:

Product Owner – ima fokus da se rade prave stvari – da se proizvodi ono što daje najveću vrijednost od svega što bi htjeli raditi
Developers – imaju fokus da se stvari rade na pravi način – odgovorni su za tehničku izvrsnost i kvalitetu rješenja
Scrum Master – ima fokus da se prave stvari rade na pravi način – čuva proces i osigurava da svi dijelovi procesa ispunjavaju svoju svrhu

I to je to. Scrum DONE.

Kažu jednostavan za shvatiti, kompliciran za implementirati, i to je stvarno istina.

Ako si prepoznao da neki od dijelova Scruma ne ispunjavaju svoju svrhu u trenutnoj implementaciji u tvojoj okolini – ne može ni Scrum funkcionirati na najbolji način. Izvor frustracija onda nije ni Scrum ni Agile, nego nešto što se radi na krivi način. Ako voziš auto stalno u prvoj brzini i svaki tjedan si kod mehaničara – nije stvar u tome da je auto loš, nego ga ti loše voziš. Uncover better ways.

3. Agile & SofaScore – kako mi to radimo

SofaScore zapravo funkcionira na agilan način od svog samog početka.

Budući da se radi o razvoju vlastitog proizvoda, tu su uvijek bili entuzijastični ljudi okupljeni oko zajedničkog cilja. U početku je tih ljudi bilo malo, i kroz svakodnevne razgovore se dolazilo do novih ideja, koje su se brzo implementirale, popratila se povratna informacija korisnika i onda nastavljalo dalje s tim informacijama. Tipično startupovski. Kako je SofaScore rastao, više nije bilo fizički moguće sve informacije podijeliti kroz usputni razgovor. Određeni procesi su se morali postaviti kako bi prave informacije došle do pravih ljudi u pravo vrijeme. Agile kao način razmišljanja je tu već prirodno bio, a Scrum se odabrao kao okvir kojim idemo naprijed prije otprilike godinu i pol.

Krenulo se “školski”, prateći smjernice u Scrum Guideu. No, nakon nekoliko Sprinteva, timovi su otkrili neke nove i drugačije načine kako mogu radi bolje, brže, kvalitetnije. Važno je to slušati. Uncover better ways.

Backend tim nema daily svaki dan 15 minuta, nego dva puta tjedno po 30-45 minuta. Predložili su taj eksperiment jer sitne stvari ionako riješe tijekom dana čim se pojave pa je ovih 15 minuta bezveze, a ovako mogu zajedno kao tim raspravljati o nekim rješenjima ili ući dublje u neki kompleksniji problem koji rješavaju. Vrijeme se isto promijenilo – krenulo se u 9.15, trenutno je u 10.00.
Backend tim je krenuo bez Sprint Reviewa. U tom trenu nije baš izgledalo da ima koristi, stakeholderi su prvenstveno timovi koji rade na web i mobile aplikacijama, a s njima je ionako konstantna komunikacija tijekom developmenta. No, nakon nekoliko mjeseci, ti timovi su došli do Backenda sa željom da im se pokaže što je napravljeno u zadnje vrijeme, a da ima posljedica na platforme, i da se zajedno prođe što iduće dolazi od takvih promjena. To totalno zvuči kao Sprint Review, pa smo ga onda uveli. Kad nema nečeg posebnog za platforme, onda ga nema. Ne trošimo vrijeme bez potrebe.
Jedan novo formirani tim je cross-functional. Okupljeni su oko velikog featurea koji će uskoro biti u produkciji. Svoj Sprint Review spojili su sa reviewom drugih timova koji rade na generalnim featurima. Tako svi ostajemo u toku što se dešava u ostalim timovima, i možemo jedni drugima pomoći, dati ideju ili neki prijedlog dorade.
Tu je i tim koji je fokusiran na administraciju SofaScorea. Njima su glavni stakeholderi ostali timovi u Sofi, koji rade na unosu i ispravljanju podataka. Ono što je posebno sjajno je način kako zajedno dolaze do glavnog uzroka nekog problema, i onda ponovno svi zajedno dolaze do najboljeg rješenja tog problema. To se vidi kod svih timova, a kod njih možda i najviše.
Story Pointsi za procjenjivanje? Nikad ih nismo uvodili, niti vidimo potrebu za njima. Radimo vlastiti proizvod, nitko nas ne ganja s rokovima i za planiranje kapaciteta sasvim su dovoljne prst-palac procjene dan-dva-pola sprinta-sprint.
Članovi tima koji rade unutar cross functional timova izrazili su želju da se usklade i s ostalim kolegama iz iste tehnologije, kako bi lakše dijelili znanje – tako su nastali platformski sinkovi. Takve stvari nisu uopće dio Scruma, ali se vidjela korist i to smo napravili.
Pokazalo se i zanimljivo podijeliti dobre prakse i zanimljive probleme sa svima u Sofi, pa jednom mjesečno imamo interni developer meetup, gdje bude predavanje ili dva, neka klopa i cuga. Opet, nije dio Scruma, ali nam je korisno.
Dodatna incijativa je Petak 10%, o kojoj je pisao kolega Marin.

Ono što se vidi iz svih ovih primjera je da i mi i dalje učimo. I to je OK. Svjesni smo da nikad neće biti savršeno, da se svijet mijenja, i da se mi moramo mijenjati s njime. Pridruži nam se u tom uzbudljivom putovanju i skupa s nama Uncover better ways.