“Common sense is not so common.”

— Voltaire, Dictionnaire Philosophique (1764)

Većina stvari koje obrađujemo i jesu zdrav razum (osim možda “push vs pull“, no i to je OK ako se malo razmisli), a svejedno nekako izostaje primjena.

Naprimjer, sasvim je razumno prihvatiti da su današnji poslovi toliko kompleksni da ih ne može odrađivati samo jedna osoba, bar ne dovoljno brzo i u razumnom roku, a svejedno se ne radi na izgradnji multifunkcionalnih timova.

Također je sasvim razumno očekivati da ljudi razgovaraju o svom poslu i sinkroniziraju se o zajedničkom cilju bar jednom dnevno, ako ne i češće, a opet to nekako rijetko viđam. Čak štoviše, ni pravi timovi nisu tako česti.

Ili preskakanje prostora za poboljšanje: razumno je očekivati da i organizacija i ljudi žele raditi bolje (produktivnije, efikasnije, brže – umetni svoju omiljenu poštapalicu), a onda se čude kad treba odvojiti sat vremena tjedno za retrospektivu. Kao, pa nemamo vremena, toliko je posla. Da, jače lupanje po tipkovnici će riješiti sve probleme.

Adding human resources to a late software project makes it later.

— Brooks’s Law

Ili meni omiljeni prigovor, kasnimo (jer nam komunikacija u timu i prema vani ne valja, ali ovaj dio se prešuti), pa ćemo dodavanjem ljudi u tim riješiti problem, jer još više ljudi koji loše komuniciraju će sigurno jače tipkati pa će sve biti brže gotovo. Zdrav razum da treba učiti na prijašnjim iskustvima očito ne pali ovdje, jer je još prije 40 godina primijećeno, i zakucano u Brooksov zakon, da dodavanje ljudi na projekt koji već kasni ustvari čini da će projekt kasniti još više. Ljudi koji su pročitali Mythical Man Month jednostavno ne govore takve stvari. Pro tip: poboljšaj razmjenu informacija a ne brzinu tipkanja. Molim lijepo

Dobro, i kako dalje?

Probajte razumjeti osnovne agilne vrijednosti i principe.

Probajte Scrum, koji jako dobro stavlja “agilno” u okvire koji se mogu primijeniti na razvoj i održavanje kompleksnih proizvoda (i usluga).

Uključite mozak i pomozite drugima da ga uključe.

Redovito stanite na loptu, udahnite duboko i pitajte se prevodite li taj “common sense” u “common practice”.

Prijelazni period

Ako agilnim načinom rada imamo predvidljivije rezultate, u kraćem vremenu napravimo bolje i više, a ljudi su sretniji i zadovoljniji, čemu onda tradicionalizam? Jednostavno, prebacite se (postupno) na agilni način i to je to.

Naravno, spomenuto prebacivanje nije moguće izvesti preko noći, tako da treba uzeti u obzir i određeni prijelazni period, no taj period treba provesti fokusirano s ciljem lagane tranzicije cjelokupnog toka isporuke vrijednosti. Tokom tog prijelaznog perioda treba biti oprezan i paziti da se usvoje pozitivna ponašanja koja dovode do stabilnog i predvidljivog načina rada, kao što je vizualizacija posla, cijepanje zadataka na jednaku veličinu, ne biti preoptimističan u planiranju i slično.

Iskustva s raznih strana

Moje iskustvo pokazuje da uvijek postoji određena količina posla koje članovi tima trebaju obaviti, a koja nije direktno vezana uz proizvod kojeg tim razvija. To su najčešće neki zaostaci ili specifičnosti koje samo pojedini ljudi u timu mogu odraditi (što je poseban problem o kojem ću pisati kasnije).

Bitno je razumjeti da uvijek postoji određena količina posla koje članovi tima trebaju obaviti, a koja nije direktno vezana uz proizvod kojeg tim razvija

Dobro, koliko je inače “neagilnog” posla?

Naravno da je nemoguće dati univerzalni omjer “agilnog” i “tradicionalnog” posla. Taj omjer ovisi o veličini organizacije, broju inicijativa koje se događaju, broju ljudi, raznovrsnosti tehnologija koje koriste i slično. Primjećujem da su ljudi uglavnom preoptimistični u procjeni količine tog posla, odvajajući nekih 15–20% vremena za takve stvari, i to kad ih se pritisne i kad su poprilično izdašni.

To se svaki put pokazalo premalo. Iz mog iskustva, relativno velike firme (za hrvatske pojmove) s dovoljno uhodanom proizvodnjom softvera i koji su u postupku tranzicije na agilni način rada imaju oko 35% posla “iz prijašnjeg života”. Sa svakim timom nam je trebalo neko vrijeme da dođemo do tog broja, i još malo više vremena da ga uzmemo u obzir tokom planiranja, no može se.

Kako doći do točnog omjera?

Mjerenjem.

Procjene, očekivanja i neutemeljeni optimizam su beskorisni. Tim si treba uzeti u zadatak praćenje svega što radi i već nakon dva ili tri sprinta će imati točan broj koliko njihovog dnevnog posla otpada na produkt zbog kojeg su tu, a koliko na druge stvari.

Procjene, očekivanja i neutemeljeni optimizam su beskorisni.

Mjeriti se može vrijeme provedeno na drugim zadacima, recimo broj sati dnevno koje svaki pojedini član tima provodi “na drugim stvarima”. Ovo je dosta jednostavno, napravite tablicu u excelu i neka svaki član tima na kraju svakog dana upiše koliko je sati “potrošeno” na vanjske poslove. Podijelite svaki zbroj s 40 i eto postotka.

Bolja bi mjera bila gledati koliko zadataka koji se odrađuju ustvari ne pripadaju u timski backlog. U ovom slučaju svi zadaci se vode na timskoj ploči, što dodatno olakšava praćenje i vizualizaciju.

U svakom slučaju, bilo kakva mjera je bolja od nagađanja ili još gore, ignoriranja posla sa strane.

Što je produkt

Scrum je okvir za razvoj proizvoda (produkata). Proizvod ima svoj životni ciklus, pojednostavljeno:

1. Traženje (ideje, prototipi)
2. Razvoj
3. Održavanje i nadograđivanje
4. Gašenje

Kako se mijenja faza u kojoj je proizvod, tako se mogu primjenjivati i različite izvedbene metode.

Scrum će se najprirodnije snaći u fazi razvoja proizvoda, iako će se i u fazu traženja uklopiti sasvim dobro.

Ovisno o kakvom se održavanju i nadograđivanju radi, moguće je da će prvi izbor biti kanban ili neka kombinacija Scruma i kanbana.

Što je projekt

S druge strane, projekt je više administrativna kategorija. Tokom projekta se može razviti jedan ili više proizvoda. Kroz projekt je također moguće voditi proces održavanja i nadograđivanja proizvoda i slično. U svakom slučaju, projekt i proizvod mogu, ali i ne moraju biti direktno povezani.

Kako se Scrum uklapa

U tom smislu, Scrum se može primijeniti u svakom projektu koji u sebi sadrži nekakav proizvod. Naprimjer, ako imamo projekt kojemu je cilj isporučiti proizvod internet bankarstvo, od inicijalne ideje do razvoja i isporuke u produkciju, Scrum će se sasvim dobro uklopiti u životni ciklus u te dvije faze.

Kad se završi projekt razvoja i započne projekt održavanja i nadogradnje (proizvoda), Scrum se može ali i ne mora primijeniti.

Primjeri

Spomenuto internet bankarstvo je tipičan produkt za čiju bi implementaciju Scrum bio odličan odabir: imamo osnovnu ideju, imamo cijeli niz sitnih funkcionalnosti koje zajedno čine cijeli proizvod i koje su dovoljno neovisne da ih možemo organizirati u kategorije po važnosti, naprimjer moramo imati, trebali bismo imati i bilo bi dobro da ih imamo. Scrumom ćemo postići da na početku implementiramo funkcionalnosti iz kategorije moramo imati, čime već imamo upotrebljiv proizvod. Zatim prelazimo na ostale kategorije i prestajemo kad je došlo vrijeme za isporuku, kad smo potrošili budžet ili kad vidimo da nastavak razvoja ne donosi dovoljno povrata uloženog.

Fukcionalnosti možemo organizirati u kategorije po važnosti, naprimjer “moramo imati”, “trebali bismo imati” i “bilo bi dobro da ih imamo”

Nasuprot internet bankarstvu, organiziranje rođendanske zabave je projekt koji nije prikladan za Scrum: iako ima proizvod (zabavu), taj proizvod ne možemo isporučivati malo po malo a nakon zabave nije potrebno nikakvo održavanje. Možemo odraditi retrospektivu (i inače vrlo korisna praksa) i to je to.

Nategnuto, i rođendanska zabava bi se mogla progurati kroz Scrum, ali bismo se više nabijali na metodu nego što bismo imali stvarnih benefita tokom primjene