Sve je počelo sasvim bezazleno

Razgovaramo prije par mjeseci Ivan Krnić i ja kako se industrija softvera oko nas previše fokusira na implementaciju nečeg već definiranog (specifikacija?) dok se ne razmišlja osobito o tome kako je eto baš taj zadatak onaj kojeg treba implementirati, i kako je dospio na vrh liste. Drugim riječima, pitamo li se radimo li pravu stvar ili radimo “što nam gazda kaže, samo brže“.

“Zašto ne bismo o tome progovorili na .debugu?”

“Može.”

I eto prezentacije.

I onda se sve okrenulo naopako

Kako je vrijeme u zadnje vrijeme naklonjeno boravku na otvorenom i roštiljanju, tako i ja vikend prije .debuga s ekipom vrtim meso iznad žara. Na sebi imam majicu koju sam dobio na Global Scrum Gatheringu 2019. u Beču na kojoj, naravno, piše “Scrum Alliance”.

PRO TIP

Uvijek nosite sponzorske majice kad roštiljate!

Sve je bilo u najboljem redu dok jedan, stvarno dobar prijatelj nije shvatio što mi piše na majici:

Šok i nevjerica

“Kako to misliš?”

“A kako ne bi bila glupost? Sazovu nas svaki neki neredoviti petak i onda svatko priča o tome što je radio u proteklih mjesec ili dva. Potpuno je nezanimljivo, informacije koje se dijele su besmislene, sastanak služi za ribanje, sve traje po par sati a sve skupa radimo jer je to ‘agilno’ i ‘svi to rade pa moramo i mi’.”

Ako stvarno dobar prijatelj, koji radi dobar posao u dobroj firmi ima percepciju da su Agile i Scrum “glupost”, onda moja priča na .debugu kako treba razmišljati jedan korak ispred puca u potpuno pogrešnu metu.

Dakle…

Još uvijek se igramo “agilnosti”. Još uvijek trpimo gluposti poput “svi to rade pa moramo i mi”. Još uvijek se na agilno gleda kao na nekakav proces za kontrolu. Još uvijek se smatra da je sve to “skroz jednostavno”, da ne treba “previše filozofirati” i da “to ionako već radimo”.

Nema smisla pričati o istraživanju tržišta, prototipima, MVP-ovima, A/B testiranju i takvim temama kad se elementarne stvari o smislenom i modernom načinu rada ne razumiju, ili čak zloupotrebljavaju.

I tako je moja prezentacija zadržala naslov, ali potpuno promijenila sadržaj. Slajdove pogledajte ovdje (PDF, 16mb), a nadam se da će uskoro biti dostupna i snimka.

Cover photo by Dustin Tramel on Unsplash

• Jer ćemo tako biti brži, ili
• Jer ćemo tako biti efikasniji, ili
• Jer ćemo tako s manjim brojem ljudi napraviti više.

Pa krenimo redom.

Kad radiš agilno onda si brži

Znači, kad radiš agilno onda… brže tipkaš? brže pričaš? brže… misliš? Sumnjam.

Agilno raditi znači, između ostalog, i fokusirati se na najbitniju stvar, riješiti je, i pitati se treba li dalje. Ako treba, onda ćete uzeti sljedeću najbitniju, riješiti i nju, pa se pitati treba li dalje i tako koliko treba.

U jednom trenutku ćete shvatiti da… ne treba dalje.

A to je gotovo sigurno prije nego što ste riješili baš sve. Onda ćete pogledati ostatak backloga i reći si “E za ovo bi nam trebalo još X mjeseci, ali nećemo jer su to nevažne stvari.” Dakle, gotovi smo X mjeseci ranije, zato što smo radili pametnije, a ne brže.

Brzina je posljedica pametnijeg načina rada.

Kad radiš agilno onda si efikasniji

Ovdje treba priznati da se kod nas često izjednačuje efikasnost (raditi nešto na pravi način) i efektivnost (raditi pravu stvar). Moj komentar je obično ovakav, s tim da umjesto gluposti koristim jednu prostu riječ, no kako je ovo blog za pristojne ljude…

Ako radite efikasno, a radite gluposti, onda ćete brže napraviti tu glupost i imat ćete vremena za još jednu glupost.

Savjet je gotovo pa nepotreban: Nemojte raditi gluposti. Radite pametnije stvari. Složite backlog tako da su na vrhu oni poslovi koji u tom trenutku donose najviše vrijednosti. Naprimjer, smanjit će rizik od nepoznatog, pokrit će najveći broj korisnika, izaći ćete na tržište prije konkurencije, postavit ćete arhitekturu na noge i tako otvoriti vrata za niz drugih stvari, itd, itd, itd.

Priznajem, odabrati najpametniju stvar nije uvijek jednostavno, i prepoznavanje kriterija za taj odabir je vještina koja se uči.

Kad radiš agilno onda s manjim brojem ljudi napraviš više

Da, sigurno, jer ljudi dobiju super-moći kad im na čelo napišeš A-G-I-L-E. Besplatan savjet: ne dobiju. Molim lijepo.

Ljudi ne dobiju super-moći kad im na čelo napišeš A-G-I-L-E.

Raditi agilno znači, uz druge stvari, i raditi u timu gdje ljudi komuniciraju često i direktno.

To znači da najvjerojatnije sjede skupa, imaju dnevne sinkronizacije i redovne kontrolne točke gdje pričaju o napretku u rješavanju poslovnih zadataka.

Također, imaju i redovne termine za razgovor o svom načinu rada (dakle, ne o proizvodu; to je pokriveno ovim gore spomenutim), gdje uz svoj “pravi” posao dodaju i aktivnosti na poboljšavanju timskog rada, komunikacije itd.

Pa umjesto da se vrijeme troši na slanje mejlova, čekanje odgovora, umiranje po sastancima i slično, članovi tima se direktno dogovore što treba i prime se posla.

Znate li da je komunikacija licem u lice 34 puta uspješnija od slanja emaila?

Zanimljivo, zar ne?

A ustvari pravi odgovori trebaju biti…

• Jer tako smanjujemo rizik, ili
• Jer nam je ROI bolji, ili
• Jer tako brže i lakše razumijemo potrebe korisnika, ili
• Jer je takav pristup poslu humaniji, zanimljiviji i potiče angažiranost u ljudi, ili
• Bilo koji drugi odgovor koji u fokus stavlja “pametnije” a ne “jače”.

Ljudi, ne mašine.

No o tome ću pisati nekom drugom prilikom. Ili mi dođite na tečaj

“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”.

Uzmimo za primjer 3 aktivnosti, zbog jednostavnosti računice neka budu potpuno jednake: angažman, trošak, trajanje, prihod nakon dovršetka – sve je isto. Također, trošak odlaganja početka (Cost of Delay) je identičan, što znači da ne ulazi u matematiku.

Svaka aktivnost traje 5 mjeseci i nakon što je dovršena donosi po 20k eura mjesečno.

Prvi slučaj, radimo svaku aktivnost od početka do kraja, bez prekida.

Tako se treba raditi. Dovrši jednu stvar, pusti je u rad i uživaj benefite – prihode od prodaje proizvoda, korištenja usluge, uštede zbog riješenog problema.

Prva aktivnost se već isplaćuje dok radimo na drugoj, prva i druga se isplaćuju dok radimo na trećoj itd. U našem primjeru, 5 mjeseci nakon dovršetka treće aktivnosti imamo ukupno 600k eura na računu.

Drugi slučaj, mijenjamo fokus svakih mjesec dana.

Ovakve situacije su česte u organizacijama gdje se više cijeni ‘nešto raditi’ nego stvarno dovršiti posao. Glavno da se gurka sve pomalo, da svaki direktor(čić) bude sretan. To što organizacija gubi ozbiljne novce nije njihov problem. Takvi valjda žive od zelene boje u izvještajima u excelu

Svaku aktivnost radimo po mjesec dana. Ako zanemarimo trošak promjene konteksta rada (koji nije zanemariv, i tema je za svoj blog post), prva aktivnost će biti gotova tek nakon 13 mjeseci! Druga nakon 14 i sve skupa nakon 15 mjeseci. 5 mjeseci nakon dovršetka sve tri aktivnosti prihodi u našem slučaju će biti 360k eura.

Razlika između ova dva pristupa je značajna.

Trošak multitaskinga iznosi 240k kroz tih 20 mjeseci!

Još je gore ako gledamo samo trenutak dovršetka.

Fascinantno, zar ne?

Izronilo je i nekoliko pitanja.

“Ne možemo se kladiti samo na jednu aktivnost, moramo raditi više stvari istovremeno.”

Istina, ponekad treba gurkati više stvari istovremeno, ali treba i uključiti mozak: razmišljajte u kontekstu dovršavanja stvari koje se mogu početi naplaćivati.

Naprimjer, imate tri aktivnosti, svaka traje po godinu dana, morate ih tjerati u paraleli? Podijelite ih u manje cjeline koje možete isporučiti, recimo svakih mjesec ili dva, i primijenite princip iz gornje ilustracije.

BTW, to je klasični inkrementalni pristup, nešto što u agilnom načinu rada cijenimo i promoviramo.

“Što ako neka aktivnost zaglavi, hoćemo li započeti sljedeću dok se ta prva ne odglavi?”

Klasična zamka, ide ruku pod ruku s onim “glavno da se nešto radi”. Započinjanje aktivnosti ne donosi novce, završavanje donosi. Najbolje bi bilo uložiti napore u odglavljivanje, dovršiti aktivnost i onda nastaviti dalje.

“Što ako nije moguće odglaviti prvu aktivnost?”

Tu svakako pomaže inkrementalni pristup, odnosno do trenutka zaglavljivanja neki dijelovi proizvoda su već u upotrebni i vraćaju uloženo. Mali inkrementi su super!

Isto vjerojatno vrijedi i za bilo kakav drugi tip proizvoda. Ako je nešto poznato, onda je to datum kad moramo izbaciti proizvod na tržište. Možda unutra neće biti sve što smo zamislili, ali će biti najvažnije stvari.

Gledajte na proizvod kao da izlazite na ispit. Rok je zadan i svima jasan. Prvo ćete obraditi i naučiti najvažnije stvari, kako biste prošli ispit, a one sitne detalje — za bolju ocjenu — ako stignete. Kroz vrijeme ćete naučiti kako učiti — kad se početi pripremati, kako prepoznati nevažne sitnice i slično, tako da će i ocjene postajati sve bolje.

Kod softvera, prvi ispit je potvrda smjera. Kad tu dobijete prolaznu ocjenu, onda idete dalje u dodavanje “sitnica”, a najbolje je kad se sve to događa po unaprijed određenom rasporedu (khm*iteracije*khm).

Zašto bi se zabavljala samo djeca? Napravite danas nešto ludo i zaigrajte “Pronađi u 5 minuta što više razlika između dva mindseta”!

Spoiler alert! Moji rezultati su ispod.

#1 (00:01)

Agilno: Iterativno i inkrementalno (malo pomalo).

Tradicionalno: Waterfall – sve odjednom (rizik od integracijskih problema, rizik da radimo krivi proizvod).

#2 (00:19)

Agilno: Fiksan je rok i trošak, a o opsegu se dogovaramo (najbitnije radimo na početku).

Tradicionalno: Fiksan je opseg, a varijabilni su rok i trošak (trpi kvaliteta).

#3 (00:44)

Agilno: Plan se radi iterativno, a poslovi se procjenjuju u trenutku kad znamo više informacija.

Tradicionalno: Plan i procjene se rade na početku u trenutku kad imamo najmanje informacija o poslu.

#4 (01:02)

Agilno: Prioritizacija se vrši kontinuirano i osigurava da se uvijek radi posao koji je u danom trenutku najvrjedniji, a na temelju informacija od stakeholdera. Organizacija putem uči.

Tradicionalno: Poslovi (funkcionalnosti) se prioritiziraju na početku projekta kad imamo puno pretpostavki i najmanje informacija. Organizacija putem ne uči.

#5 (01:29)

Agilno: Kontinuirano se evaluira što donosi najveću vrijednost i to se radi, u okviru roka i budžeta.

Tradicionalno: Zbog unaprijed dogovorenog fiksnog scope, rade se funkcionalnosti za koje se ispostavi da nisu potrebne/nužne, samo da se ispoštuje ugovor.

#6 (01:53)

Agilno: Procjene za implementaciju se ne podebljavaju jer se donose u trenutku kad je poznato dovoljno informacija i jer se radi transparentno.

Tradicionalno: Procjene za implementaciju se podebljavaju jer se donose prije početka rada (na početku projekta) radi osiguranja od rizika od nepoznavanja opsega na početku projekta.

#7 (02:14)

Agilno: Nema Change Requestova jer prihvaćamo promjene tijekom projekta i zajedno prognoziramo što se može odraditi u zadanom roku i budžetu.

Tradicionalno: Moguće dorade opsega uzrokovane novim saznanjima se provode kao Change Request (dodatno ugovaranje)

#8 (02:27)

Agilno: Partnerski odnos.

Tradicionalno: Odnos Naručitelj-Izvođač.

#9 (02:51)

Agilno: Isporučitelj transparentno radi posao, transparentan je projektni tim i posao kojeg on radi. Isporučitelj je transparentno plaćen sukladno stvarno odrađenom poslu.

Tradicionalno: Naručitelj optimizira da se što više posla odradi u ponuđenom roku i budžetu. Isporučitelj optimizira svoje troškove, angažira manje kompetentne ljude, odbija dorade koje imaju smisla, ali nisu u opsegu, pati kvaliteta.

#10 (03:16)

Agilno: Nije obavezna implementacija svega što je inicijalno razmatrano. Naručitelj može ranije zaključiti da ima dovoljno funkcionalnosti za normalan rad i da ne treba implementirati ostatak te tako može ostvariti uštedu.

Tradicionalno: Obavezna je implementacija svega što je inicijalno dogovoreno u opsegu.

#11 (03:42)

Agilno: Obzirom da svaki release može ujedno biti i posljednji, u okviru svakog releasea se radi integracija i testiranje. To osigurava da se integracijski problemi rješavaju kontinuirano, dok su još mali, pa je za njihovo rješavanje potreban manji angažman.

Tradicionalno: Obzirom da je sav opseg unaprijed poznat, projekt započinje fazom analize, nastavlja se faza implementacije, pa faze integracije i testiranja. Obzirom da se prva prava integracija komponenti događa kasno u projektu, kasno se otkrivaju integracijski problemi koji su uvećani količinom koda kojeg treba integrirati (tzv. Late Integration Breakage).

#12 (03:57)

Agilno: Svaki release je integiriran i testiran i potencijalno može u produkcijsko korištenje. Time To Market je puno brži.

Tradicionalno: Projekt je gotov kad je implementiran cijeli opseg, tj. kad je obavljena analiza, implementacija, integracija i testiranje – svega. Time To Market je loš – na kraju projekta.

#13 (04:19)

Agilno: Prioritizacija se događa kontinuirano te se osigurava da se uvijek radi funkcionalnost koja je najvrjednija. Ako se ne implementira sve što je na početku zamišljeno, ovime se osiguravamo da su svakako implementirane najvrjednije funkcionalnosti. Ako nešto nije implementirano, nije drama, to su najmanje vrijedne funkcionalnosti.

Tradicionalno: Prioritizacija se događa na početku projekta prilikom izrade plana, kad imamo najmanje informacija. U slučaju probijanja roka, rok se produljuje jer obično ključne funkcionalnosti nisu implementirane/dovršene.

#14 (04:42)

Agilno: Iterativno isporučujemo cjelovite funkcionalnosti krajnjim korisnicima, slušamo njihov feedback i validiramo hipoteze koje smo postavili na početku o vrijednosti funkcionalnosti. Smanjujemo rizik da ćemo izgraditi krivu stvar jer kontinuirano provjeravamo/potvrđujemo da radimo pravu stvar.

Tradicionalno: Opis funkcionalnosti i njihova prioritizacija je postavljena na početku projekta temeljem informacija koje imamo na početku projekta. Postoji veliki rizik da radimo krivu stvar i da ćemo to otkriti na kraju kad je sve gotovo.

(05:00) drrrrrrriiiiinnnnngggggg

P: Zaglavio sam u poslu i ne mogu se pomaknuti s mjesta. Trebam li čekati sutrašnji daily standup da popričam s timom?

O: Ne.

P: Gotovi smo s dosta velikim komadom posla kojeg možemo pokazati stakeholderima već sad. Trebamo li čekati kraj sprinta i review?

O: Ne.

P: Način na kojeg komuniciramo s poslovnjacima ne drži vodu, očigledno je čim smo probali. Trebamo li čekati retrospektivu da popričamo kako promijeniti taj način?

O: Ne.

P: Shvatili smo da ćemo biti u mogućnosti puno jednostavnije riješiti trenutni zadatak ako prije njega riješimo jedan koji je u planu tek za sljedeći sprint. Trebamo li nastaviti raditi na trenutnom jer je tako isplanirano, i čekati planiranje za sljedeći sprint da počnemo raditi na tom drugom?

O: Ne.

Do sljedeće prilike, uspješnu primjenu vlastitog zdravog razuma želi vam vaša

— Scrum policija.

Photo by Praveesh Palakeel on Unsplash

Kad primijeniti Scrum?

Scrum se pokazuje najboljim kad trebamo konačni proizvod kojeg nije moguće unaprijed definirati do najsitnijih detalja, ali gdje imamo ideju koju vrijednost želimo isporučiti krajnjem korisniku. Na kraju svakog kratkog i fokusiranog ciklusa (iteracije, sprinta) želimo biti malo bliže svom cilju. Po putu se sama konkretna izvedba — implementacija — prilagođava novim zahtjevima, saznanjima i informacijama. Dodajte periodičke kontrolne točke (dnevno na temu tekućih poslova; recimo jednom po ciklusu na temu samog rada i timske dinamike) i imate Scrum.

Nije samo za softver

Scrum čak nije ograničen na softver. Ako ste u marketingu, posve je primjenjiv u razvoju marketinških kampanja. Ako ste u izdavaštvu, vrlo je lako zamisliti iterativni i inkrementalni pristup kod pripreme i izdavanja časopisa. Moguće ga je primijeniti i na proizvodnju hardvera, pa čak i automobila.

Prirodan odabir

Gledajte na Scrum kao na implementaciju principa do kojih ćete ionako i sami doći ako se odmaknete jedan korak unatrag i pogledate što vam može pomoći u boljem, lakšem i jednostavnijem obavljanju svog posla.