Žao mi je, ali Scrum nije rješenje za vaše organizacijske probleme.

U nekom trenutku u “davnoj” prošlosti Scrum je došao kao tsunami i preplavio sve organizacije. One koje je trebao, i one koje možda nije. Scrum evanđelisti propovijedali su o nevjerojatnoj efikasnosti i brzini, mogućnosti trenutne prilagodbe tržištu, svim benefitima koje nudi developerima i tako je Scrum postao sinonim za rješenje svih organizacijskih problema. Počela je era Scrum Mastera, Agile Coacheva i training organizacija.

Nakon prvobitnog ushita i zanesenosti uslijedilo je triježnjenje. U velikom broju slučajeva rezultat nije bio na očekivanoj, hypeanoj razini i Scrum je djelomično dobio stigmu pomodarstva i buzzworda jer: “Scrum ne rješava probleme kako smo očekivali.” Tvrtke za edukaciju i coachevi djelomično su se okrenuli novim industrijama, a Scrum je ušao u status quo.

Iz ovog ste već mogli iščitati sukus problema – Scrum, za početak, uopće nije rješenje problema, iako se često tako prodaje. Scrum je alat pomoću kojeg se do rješenja dolazi, a kao i sa svakim alatom, njime treba znati baratati. U ovom konkretnom slučaju, trebalo bi se znati ponešto i o povratnoj vezi.

Mala digresija o regulaciji i povratnoj vezi

„Srce svakog sustava automatske regulacije jest ideja povratne veze!“

A. Isidori

Kao što svaki inženjer koji se susreo s automatizacijom i/ili regulacijom zna, automatsko upravljanje sustavom zahtjeva povratnu vezu ili – feedback. Ono što povratna veza omogućuje je usporedba željenog ili očekivanog rezultata s trenutnim. Razlika između ta dva rezultata razlog je promjene koja će uslijediti.

Primjeri povratne veze prisutni su svugdje oko nas, pa tako i u našem tijelu. Primjerice, kad završeci živčanih stanica na koži i u mozgu primijete da je temperatura tijela prešla 37°C, centar za regulaciju temperature u mozgu prilikom jednog od ciklusa provjere aktivira znojne žlijezde po cijelom tijelu. Mogli bismo reći da je takav tip upravljanja vrlo doslovno – organski.

Vjerojatno ste točno pretpostavili u kojem smjeru će ovaj članak nastaviti. Ono što nam Scrum omogućuje je izvrstan framework za implementiranje “povratne veze” –  tek će povratna veza dovesti do rješenja.

Feedback po Scrumu

Prema Scrum Guideu, tri su stupa Scruma: transparentnost, provjera i prilagodba, a upravo oni čine mogućim da imamo kontinuiranu povratnu vezu kada je riječ o projektima ili proizvodima na kojima radimo.

Artefakti u Scrumu, kao što su Product Backlog, Sprint Backlog i Increment, nam omogućavaju transparentnost. Oni moraju biti dostupni osobama uključenima u projekt ili razvoj proizvoda kako bi uvijek imali pregled trenutnog i željenog stanja. Ako ne koristimo jedan od tih artefakata, smanjujemo mogućnost da stvorimo realne zaključke o stanju proizvoda, timu i načinu rada.

Scrum događaji ili ceremonije (Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective) su tu da nas “natjeraju” da redovito provodimo provjere. To je ujedno i glavni razlog njihovog postojanja pa preskakanjem jednog od Scrum događaja dodatno smanjujemo prilike za provjeru.

Prilagodba je pak promjena koju smo odlučili provesti kako bismo se približili našem željenom cilju nakon detaljne provjere artefakata. To je vjerojatno najvažniji korak i uvelike ovisi o timu ljudi koji ga provodi i organizaciji koja ih podupire. Time zatvaramo povratnu petlju našeg procesa.

Kada se pravilno provodi, Scrum na ovaj način vrlo brzo ukazuje na sve probleme s timom, organizacijom i proizvodom. To je upravo njegova svrha, da bude alat kojeg koristimo kako bismo što brže i efikasnije mogli pronaći probleme i isprobati potencijalna rješenja koja će nas dovesti bliže našem cilju.

Mrze li neki developeri Scrum… ili samo loš Scrum?

Naša je uloga kao Agile Coacheva i Scrum Mastera voditi timove i tvrtke kroz taj naporan proces provjera i promjena kako bi tim ili organizacija pronašli vlastita dobra rješenja (pogotovo na početku).

Ono što se događa je da se umjesto toga bezglavo ponavlja nekoliko pripremljenih generičkih “špranci”. Još jedna česta pojava je da se Scrum samo “uglavi” unutar svih ostalih administrativnih i birokratskih procesa u tvrtki, što onemogućuje povratnim informacijama da stignu na pravo mjesto. Ako se Scrum provodi u “izoliranom containeru” također ne može ispuniti svoju svrhu – potaknuti promjenu.

Ponekad imam osjećaj da je guranje Scruma i Agilea u mainstream izjednačilo njihova imena s lošim i nepravilnim implementacijama, a one su pak priskrbile Scrumu loš glas.

Zbog nedostatka potpore s vrha organizacije, članovi tima koji su nerijetko prepušteni sami sebi s pravom razvijaju strah od rada u takvoj okolini. Nije ni čudo što dio developera s prezirom govori o radu unutar tih frameworkova gdje ostaju frustrirani činjenicom da bi trebali dijeliti dio organizacijske odgovornosti uspjeha ili neuspjeha tima, a zapravo nemaju nikakav realan utjecaj ili podršku.

Agile je mrtav, živio agile

U zadnje vrijeme se često susrećem i s člancima koji prikazuju primjere vrlo uspješnih organizacija s “novim pristupima” gdje developeri preuzimaju uloge Product Ownera (često uz potporu Product Managera) i gdje se priča o velikoj fleksibilnosti i neovisnosti timova te minimalnoj birokraciji.

Očito smo svi zaboravili da u Scrumu developer može imati ulogu Product Ownera, da Scrum pruža veliku fleksibilnost, da je praktički uveo pojam “self-organizing” te da potiče uklanjanje wastea te Lean pristup. Taj “novi” pristup zapravo jest Agile tj. Scrum, onako kako je inicijalno zamišljen.

U jednom trenutku možda svi preispitamo jesmo li zaboravili kako je sve počelo i kažemo: “Agile” je mrtav, živio Agile!

Manifesto for Agile Software Development:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.