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

Jednostavnost Kanbana je i dobra i i ne baš dobra stvar. Dobra je jer se može krenuti bez neke silne pripreme. Nije baš dobra jer se brzo osjeti da tu ima još materijala za savladati pa nekako splasne entuzijazam. Ako ste zainteresirani za stvarne benefite Kanbana, čitajte dalje.

Signal, sistem, metoda

Da odmah na početku smirimo strasti ekipi koja voli tjerati mak na konac, ovaj članak objašnjava pojmove na sljedeći način:

• Kanban je “signal(na kartica)”, tj. informacija da se nešto treba dogoditi. Naprimjer,  naljepnica na zidu na kojoj piše “Baci smeće” i koja stoji u koloni “TO DO” je signal da treba… baciti smeće, a kartica na kojoj piše “Operi suđe” u koloni “DONE” vjerojatno (!) znači da je suđe oprano.
• Zid na kojem je gomila takvih naljepnica u nekakvim kolonama je “Kanban ploča”, tj. vizualizacija različitih signala, naprimjer što se sve radi po kući. 
• Kanban sistem je skup “kanbana” koji putuju kroz proces. Npr. vizualizacija je samo jedan od elemenata Kanban sistema. Tu su još i ljudi (tim) koji koriste tu vizualizaciju i ostale elemente, te način na koji koriste sve to skupa, odnosno o čemu pričaju kad stoje pred pločom.
• Kanban metoda je donekle strukturirani pristup poboljšavanju načina rješavanja zadataka, tj. procesa rada, koji god to proces bio.
• Kanban, pa bilo što od ovog gore navedenog, ne ulazi u sadržaj posla. Bilo da su to zadaci po kući, rješavanje prijava u internom IT-ju, razvoj aplikacije za klađenje, zapošljavanje ljudi ili bilo što drugo, gotovo sigurno vam Kanban (sistem) može pomoći da to radite malo bolje.

Sad kad smo riješili pasivno-agresivni dio i ostavili akademsku raspravu o značenju pojma “kanban” u japanskom jeziku za neki drugi put, možemo dalje.

Zašto naglašavam sistem?

I noga u guzicu je korak naprijed, pa je tako i vizualizacija (zid sa šarenim papirima) odličan korak naprijed. Pogotovo je tako u situacijama kad nemate pojma na koliko stvari već radite, a koliko stvari tek čeka da bude napravljeno. Stavite sve na zid i šokirajte se. 

Kad se oporavite od šoka, počnite razmišljati što bi valjalo srediti u procesu rada da se izvučete iz takvih situacija. 

Shvatit ćete sljedeće, i režite me gdje god hoćete ako griješim:

• Radite previše stvari odjednom i da bi se tu trebalo nešto učiniti.
• Radite stvari koje možda i nisu baš najpametniji izbor, odnosno da ima stvari koje bi bilo isplativije napraviti s tim ionako ograničenim kapacitetima koje imate.
• Ponavljate neke greške koje onda dovode do ove dvije gore spomenute situacije.

Tu pomaže sistem. Ograničite količinu paralelnog posla. Novi posao uzimajte kad imate kapaciteta. Dogovorite pravila za odabir sljedećeg posla. Periodički provjerite radite li stvari na pravi način.

Čestitam! Dobit ćete značku od Kanban policije kad vam dođe na vrata.

“I to je to?”

Da.

“Negooo… zar baš moram imati sve to?”

Naravno da ne morate, ali propuštate ozbiljnu priliku za olakšati si život (i posao). “Survival is optional”.

“Hm. Okej.”

I mislio sam da će tako biti

Priča o tri kolone

Često je prva verzija “kanbana” zid s tri kolone: TO DO | DOING | DONE. To je fantastičan naziv za blog, ali nije baš najbolji izbor za vizualiziranje vlastitog procesa rada. 

Pitate se zašto? Pa pobogu… svaki proces ima neke zadatke koji čekaju da ih se napravi, pa se onda radi na njima, i onda su gotovi. Gdje je tu ikakav pomak naprijed? Kako išta možete zaključiti iz takve vizualizacije? Takva ploča nije dovoljna ni za prolaz. 

Razbijte DOING u ono što stvarno i radite dok radite. 

Recimo da ste HR u nekoj firmi i zapošljavate ljude. U TODO vam dođe zadatak “Zaposli nekoga za vođenje projekata”. DOING je, moguće:

• Smisli kriterije
• Raspiši oglas
• Razvrstaj prijave
• Pozovi kandidate na intervjue
• Odradi prvi krug intervjua
• Odradi drugi krug intervjua
• Pošalji ponudu
• Potpiši ugovor

Proces traženja voditelja projekata je tako u fazi, recimo, “Razvrstaj prijave”, dok je proces traženja programera u fazi “Pošalji ponudu”. Puno jasnije nego da su oba u DOING.

A što se sve tek može zaključlti o procesu rada kad imate tako jasne informacije…

“Ali… ne odgovaraju te kolone svakom tipu posla kojeg radimo”

Naravno da ne odgovaraju. Povucite horizontalnu crtu po sredini i podijelite DOING na neki drugi način. Kanban ploča ne mora biti simetrična.

“Ali… ali… bit će mi šuma od papirića na zidu!”

Vjerojatno hoće, i vjerojatno iz jednog od ova dva razloga:

1. Radite previše stvari odjednom. Lijek: ograničite WIP.
2. Radite stvari koje ne trebate raditi. Lijek: nemojte raditi baš svaku glupost koju vam je netko zalijepio na zid.

Pravi benefit je u WIP limitu

Sve dok ne uvedete WIP (work in process) limit u svoj Kanban sistem nećete moći izvući prave benefite. Da, oštra rečenica, ali istinita. 

Ograničite količinu posla koja je između TO DO i DONE kolona (DOING, dakle) i odmah ćete osjetiti benefite:

• Nevjerojatno ali istinito: ako radite manje stvari istovremeno onda ćete brže završiti stvari koje radite! Osim zdravog razuma, postoji i cijela matematika iza ovoga.
• Otkrit ćete gdje su vam uska grla u procesu pa ćete se moći fokusirati na njihovo rješavanje.

Da, umjesto da implementirate 50 novih funkcionalnosti istovremeno i nikad ništa ne stižete isporučiti, stavite WIP limit na 49 i ne uzimajte ništa novo dok se ne oslobodi kapacitet. Pa spustite WIP limit na 48, pa 47 i tako dalje, dok ne dođete do broja koji vam omogućava normalno disanje, odnosno isporuku na vrijeme. Ustvari, vrlo jednostavna tehnika.

Opcije u pomoć

Druga taktika za olakšavanje disanja na radnom mjestu je: prije nego što uzmete komad šarenog papira na kojem je opisan zadatak i zavrnete rukave, razmislite treba li uopće to i raditi.

Drugim riječima, razlikujte kolonu “Opcije” (ili “Backlog”, ili “Bunar”, ili kako god je zvali) i kolonu “TODO” (ili “Spremno”, ili “#maykemi ćemo ovo napraviti”, ili kako god je zvali).

Trećim riječima, postoji svijet izvan vašeg Kanban sistema i poprilično su rigorozna pravila da bi nešto ušlo unutra. Između tog vanjskog svijeta i Kanban sistema postoji debela crta na kojoj piše: Svaki zadatak koji zadovolji ove kriterije (sad neki kriteriji specifični za vaš sistem) će biti primljen u naš velebni Kanban sistem, i bit će napravljen do kraja, na vrijeme i po najvišim standardima kvalitete, ne zvali se mi (sad ime vašeg tima). 

Tu debelu crtu ponekad nazivamo “commitment line”, a popis ovih kriterija “pravilnik” ili “policy”. Čak štoviše, isti princip možete, ustvari trebate primijeniti kad god neki komad posla prelazi iz jedne faze u drugu. 

Žalopojka

Svako toliko mi se netko javi s rečenicom “Ali mi nemamo izbora, sve što nam i dođe moramo odraditi.” Šta da vam kažem, pričajte s naručiteljima. Kanban, nažalost, nije magična metoda za rješavanje takvih problema. Istina, pomoći će vam da bolje vidite problem i da imate argumente za razgovor, ali ćete problem morati riješiti sami. Ljudi se često iznenade koliko su naručitelji (šefovi, korisnici) razumna bića.

Još par brzinskih savjeta

Nema vraćanja! 

Posao putuje isključivo s lijeve na desnu stranu. Kad je nešto gotovo u fazi A, prelazi u fazu B i ne može se vratiti. 

Što ja to čujem, ne možete napraviti posao u B jer je A odrađen kilavo? Šteta, ali nema vraćanja papirića na zidu. Naravno da ćete odraditi A dok je papirić u B, ali ćete se i zapitati kako to da ste se uopće doveli u takvu situaciju? Što trebate promijeniti da se to više ne dogodi? Što se treba promijeniti da u trenutku kad posao prelazi u B, A stvarno, ali baš ono stvarno i do kraja bude gotov?

Ako selite poslove unatrag, gubite vrijedne informacije koje vam mogu pomoći da poboljšate svoj radni proces.

Bloker je status, a ne faza

Tu i tamo neki komad posla zaglavi i želite to nekako prikazati? Imate genijalnu ideju i napravite kolonu “Blokirano”? Svako malo posao stavljate tamo, vadite, malo radite, opet ga stavite tamo? To je OK, ali može i bolje.

“Blokirano” je status po zadatku, a ne faza procesa. Označite nekako da se na tom konkretnom komadu posla ne može ništa raditi, recimo crvenim post-itom. Gore napišite datum blokiranja, datum “oslobođenja”, razlog blokiranja i sve ono za što mislite da bi kasnije bilo korisno u analizi. 

Ne bacajte te “blokere” već ih skupite na hrpu i periodički prođite kroz njih. Zbog čega su poslovi bili blokirani? Nejasni zahtjevi? Nedostupnost ljudi koji su trebali uskočiti i pomoći? Tehnološki probemi? Eto materijala za retrospektivu!

I da, i blokirani poslovi se računaju u WIP-u.

Imajte retrospektivu!

To što koristite Kanban a ne Scrum vas ne razrješava retrospektive! Ali kada imati retro ako nemate dvotjedne sprinteve?! Kad god hoćete, samo je imajte. Recimo, PPP (petak, pola pet) je dobar pristup: zatvorite radni tjedan potvrdom dobrih stvari i idejom kako da unaprijedite one koje mogu biti i bolje.

Niste sigurni kako izgleda retrospektiva u svijetu Kanbana? Isto kao i bilo koja druga.

Kad smo kod toga…

Scrum ili Kanban?

Svejedno je. Oba okvira imaju za cilj pomoći učiniti vaš način rada agilnijim.

Moj pristup manje ovisi o okviru, a više o timu koji će koristiti taj okvir. 

Ako imamo postojeći tim, koji već radi neki posao, zadaci su u različitim fazama, dolaze s različitih strana i slično, onda bih vjerojatno krenuo s Kanbanom. Ako je novi tim koji se okupio i tek se treba izgraditi, vjerojatno bih krenuo sa Scrumom. U konačnici ćemo završiti na istom mjestu.

Naravno, tu je i pogled iz perspektive samog posla: imate proizvod (npr. aplikaciju za mobitel) ili više kao proces (npr. zapošljavanje ljudi)? Proizvod: krenimo sa Scrumom. Proces: krenimo s Kanbanom. U konačnici… isto mjesto.

“Ček malo – i to je to, sad znam sve?!”

Ako si postavljate to pitanje, vjerojatno na Kanban gledate kao na taktički alat kojim biste rado htjeli zakrpati neki problem. To je kratkovidan pristup. Kanban je metoda za upravljanje promjenama, i to tako da se brinete o vlastitom procesu rada, razvijate ga i unapređujete. Znači, dugoročni pristup, nešto poput evolucije.

“Okej, sad si me demolirao”

Nije mi to bila namjera. Svaki napredak je dobar, pa bila to i obična ploča s prvom verzijom vizualizacije i neki dogovor kako ćete je koristiti. Važno je osvijestiti potencijal kojeg Kanban (metoda) ima, zavrnuti rukave i primiti se posla na poboljšavanju načina rada.

Kanban sistem nije magični alat kojeg ćete jednom postaviti i zaboraviti. Kao što redovito ažurirate OS na svom mobitelu, tako je potrebno brinuti se o svom procesu rada i nadograđivati ga. Zanemarite taj dio i ubrzo ćete se naći u situaciji da ponovo lijepite šarene papiriće na neki novi, prazni zid. U tom slučaju, pročitajte ovaj članak od početka i javite se za pomoć.

Cover photo by Suzanne D. Williams on Unsplash

I sad smo u međuprostoru: organizacije (uglavnom) razumiju potrebu za novim načinom rada koji odgovara misaonim poslovima, ali često ne razumiju potrebu za coachom (Scrum Masterom).

U nastavku je tekst kojeg sam napisao za potrebe jednog svog korisnika, upravo s ciljem razumijevanja te role i vezanih aktivnosti. Isprike na engleskom jeziku, ali mi se čini da nema potrebe prevoditi

What Being a Scrum Master, and a coach in general, means

The role of a Scrum Master is often misunderstood, especially in
environments where no similar role already exists. We're not the
first organisation facing this issue, and we should learn from a
wider community and experiences of other people.

How to see what a Scrum Master does?

Scrum Master, and a coach in general, is often seen through
activities which are easily observable, such as meetings
facilitation. But, the main focus of a Scrum Master is not to teach
a team to be better from a mechanical perspective (such as, to have
short meetings).

The main focus is to make the problems (impediments) visible and to
teach the team to solve them.

At the beginning, probably the biggest impediment is inefficient
meetings, so SM could focus on that. After the team learn how to do
the meetings well, next impediment is usually connected to the
team’s tendention to take too much work at the same time, and to be
late with the delivery as a consequence. Next, problems with people
relationships will surface, or the environment will press harder on
the team. The Scrum Master has to tackle those impediments as well.
Then, personal development of the team members, as they would think
they’re lagging in knowledge due to focus on deliveries. Next,
inevitable technical debt will be the hottest topic, while the
Product Owner still thinks it’s not worth it. 

The list goes on.

It is not without a reason that Scrum is sometimes called "the
problem finding framework". We’ll for sure encounter a number of
problems which Scrum helped us to recognise. It’s up to us to solve
them.

However, if we want to look at the SM role from that 'observable'
perspective, there’s a lot more Scrum Masters do:
http://scrummasterchecklist.org/pdf/ScrumMaster_Checklist_12_unbranded.pdf

It’s best if we actually don’t see a Scrum Master at all, but only
the effects of their efforts, which are:

[Product Development] Quality deliveries at the end of each sprint
[Team Development] Self-sufficient and self-sustainable
[People Development] People clearly express their views on products,
their own knowledge, their career paths
[Competency Development] Team works more efficiently in terms of
technical excellence
[Environment Development] Spreading of the agile views in otherparts
of the organisation, better meetings, faster decision making
[etc...]

But also:

Continuously growing list of impediments a team is encountering
At the same time, growing list of solved impediments
[etc...]

If we have a SM working with a team in a good way, helping the team
to get better each iteration, we can accept the idea that at some
point in time, the team is "excellent enough" -- meaning that the
value that particular SM brings to that particular team is not
proportional to the value the same SM would bring to "still not
excellent" team.

In that case, that SM could take the second team, while still
maintaining close relationship with the first one. 

We assume that the first team is mature enough to be able to
recognise and solve their own impediments up to some level, above
which they would still need a Scrum Master.

That’s the state we want to achieve.

To get there, we propose the following (rather optimistic) timeline:
* We begin with Scrum Masters helping one team only
* While launching new teams, we have one Scrum Master per team
* Each SM stays with their teams for at least three months
* At the end of that period, we assess how the teams are "mature"
  and stable, and if there’s some space to free for their SM, so
  that he/she could take another team. 
** It is important to understand that that another team should not
   be completely new one, since such a team would require a full
   time SM
* Each three months we repeat the exercise.

At some point in time we will have:
* A number of experienced Scrum Masters
* A number of long-lasting, experienced teams
* Every single team will have a Scrum Master
* Most of the Scrum Masters will have only one team
* Some experienced Scrum Masters might have two experienced teams

Photo by Christopher Burns on Unsplash

Ustvari, problem — koji god bio — će samo biti pojačan, ili u boljem slučaju ranije otkriven.

Zašto? Ići brže u lošem smjeru nikako nije dobra ideja.

Ići brže u lošem smjeru nikako nije dobra ideja.

Pogledajte sljedeći graf.

Smjer je vektor, brzina je veličina vektora… Koliko postoji smjerova? Jeste li sigurni da ste na pravom smjeru? Ako idemo u bilo kojem osim u pravom smjeru brzina će samo učiniti štetu. Znači, brzina dobro dođe jednom kad znamo smjer.

Brzina dobro dođe jednom kad znamo smjer.

Kako znati je li nam smjer dobar? Dosta teško, jer…

Predviđanje je teško, osobito o budućnosti.

Danska izreka

Teško je znati što će se dogoditi sutra. Hoće li padati kiša? Teško je reći, ali si možemo pomoći.

Pada li kiša upravo sada? Je li padala jučer? Ima li oblaka? Kakvo je obično vrijeme u ovo doba godine?

Još je teže predviđati dalje u budućnost. Kakvo će vrijeme biti za 180 dana? Ili, što će se prodavati na tržištu za 3 godine?

Nemamo informaciju kakvo će vrijeme (ili tržište) biti sutra ali imamo pregled stanja kakvo je danas i kakvo je bilo prethodnih dana. Imamo i neke povijesne podatke.

Sve u svemu, s uključenim mozgom i otvorenim očima možemo imati nekakvu sliku o sutrašnjem vremenu, temeljenu na razumijevanju postojećih informacija.

Predviđanja imaju smisla u kraćem razdoblju, a ni onda nisu predviđanja, već prognoze koje se temelje na nekim skupljenim podacima.

Da bismo mogli imati smislene podatke o tome što radimo, trebamo to što radimo smisleno i raditi

Dakle, da bismo mogli davati dobre procjene (o budućnosti) moramo dobro raditi u sadašnjosti. Da bismo imali dovoljno podataka, moramo ih često uzimati (mjeriti).

I sad dolazimo do ključnog dijela: agilni način rada, dakle kratke iteracije i redovno praćenje rezultata, će nam pomoći da imamo bolje prognoze budućnosti. Agilni način rada je značajno predvidljiviji od klasičnog, u kojem se planiranje temelji više na željama nego na stvarnim podacima.

Razmišljajte o agilizaciji kao o načinu postizanja predvidljivosti, a brzina će doći nakon toga.

I sad si ja mislim, okej, možda i ima smisla. Neke teorije i prakse mgmta, odnosno organizacije posla postoje 50 ili 100 godina… ZA POSLOVE KOJI SU POSTOJALI PRIJE 50 ILI 100 GODINA. 

Kako način organizacije posla od prije 100 godina može biti dobar za vrstu posla koja je nastala prije 20 godina? Ili prije godinu dana? Ili koji će tek nastati sljedeće godine??

Kako pristup organizaciji posla koji odgovara proizvodnji milijun identičnih miksera odgovara proizvodnji jednog i samo jednog internet bankarstva, na tržištu i u okruženju koje postoji samo sad i nikad više, i koje će već sutra biti drugačije?

Može li se uopće organizirati proizvodnja internet bankarstva od početka do kraja, sa svim prepoznatim i definiranim zahtjevima i jasnim izlazom? Naravno da ne može.

Nemoguće je naučiti proizvoditi identična internet bankarstva. Ustvari, to niti nema smisla.

Ono što možemo je naučiti se nositi s tom jedinstvenom kombinacijom tržišta (potreba klijenata, konkurencije, tehnologije i drugih faktora), okruženja i naših sposobnosti i kapaciteta. To se, naravno, ne može preko noći, ali nije niti nešto osobito teško.

Naslovna slika: Photo by Philip Swinburn 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!

Često u poslu dođem do teme primjene Scruma kao okvira za podizanje razine agilnosti organizacije. Koliko god Scrum bio jednostavan za razumjeti, toliko ga je u stvarnosti teško dobro primijeniti, pogotovo ako je tim neiskusan ili se, još gore, radi o organizaciji koja je striktno podijeljena u vertikalne silose (č: Odjel za smišljanje ideja, Odjel za programiranje ideja, Odjel za puštanje ideja u rad).

Zanimljivo mi je vidjeti kako se i sama razina razumijevanja podiže kako ljudi stječu iskustvo, tako da sam im prije nekog vremena prestao uopće spominjati Vodič kroz Scrum sve do dva ili tri mjeseca zajedničkog rada po Scrumu; tek ih onda uputim na službenu stranicu.

Ovaj blog je dijelom i nastao kao pomoć boljem usvajanju agilnih principa u svakodnevnom radu, pa se nadam da će i “anotirana” verzija Vodiča biti od koristi. Ne zaboravite i Demistificirani Scrum, “off broadway” pogled na sve ovo skupa.

Na kraju se moram zahvaliti Goranu Kelečiću i Amiru Hasanoviću na pomoći kod prevođenja.

Upravo to mi se dogodilo ovo ljeto. Rutinska tko-zna-koja po redu retrospektiva s timom koji je već duže na okupu. Znamo što slijedi, možda i predobro pa nam je proces postao rutina. Međutim, taj dan na stol dolazi pomalo kontroverzna tema koju smo iz objektivnih razloga par puta odgađali. Felšana lopta. Kukavičje jaje.

Tema je stvarno kontroverzna. Neki članovi tima vrlo živo iznose argumente. Kako nervoza raste, tako objektivni argumenti degradiraju u subjektivna mišljenja i neargumentirane pretpostavke. Stvar se otela kontroli. Facilitiranje je kao spuštanje Airbusa 380 bez hidraulike.

Usred prepucavanja pogledam semafor. 0-3. Desni bek isključen. W-T-F se dogodilo u zadnjih 45 minuta?!

Kad se prašina slegla, pričali smo što se dogodilo. Više su nego očite dvije stvari.

Krivo stanje uma

Retrospektive su uistinu glavni pokretač unaprjeđenja, ali samo ako su svi prisutni ispravnog stanja uma. To stanje uma najbolje je opisao Norm Kerth principom koji je u međuvremenu postao poznat kao Prime Directive. Pravim fanovima Star Treka ne treba posebno objašnjavati što to znači. Svima ostalima, to je jako-jako-jako važan princip kojeg se nikad ne smije zanemariti. Prime Directive retrospektiva kaže:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Gledajući unazad, mi smo u retrospektivu ušli s previše nervoze i potpuno izignorirali Prime Directive. Cilj nije bilo zajedničko unaprjeđenje procesa nego tuđi grkljan. Što više krvi, to bolje. Tarantino bi bio ponosan.

Previše nervoze

Odakle sva ta nervoza? Dva puta smo odgađali temu jer smo htjeli da svi budu prisutni i da uvjeti za razgovor budu savršeni. Odgađanje je samo nagomilalo neizvjesnost što će se dogoditi i nervozu koja je eksplodirala odmah na početku i uništila okvire za konstruktivan razgovor.

Odgađanje razgovora nije dobro ma koliko nam plemenite bile namjere. Čekanje i neizvjesnost kod ljudi potencira razmišljanje o najgorem. Odgađanjem smo stvorili percepciju da se radi o nekom super-problemu, a ne o standardnom business-as-usual problemu. Umjetno smo ga napuhali. Zato, da parafraziram generala Pattona, dobra retrospektiva odmah je bolja od savršene retrospektive za dva tjedna. Brzi feedback jede spori feedback za doručak.

Na kraju mi je drago da je ovo eksplodiralo kako je eksplodiralo jer nas je naučilo nečemu i konačnici ipak ojačalo tim. Black Box Thinking FTW!

*Photo by Corentin Marzin on Unsplash