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

U stvarnom svijetu će se sigurno postaviti pitanje, Zar moramo imati Scrum Mastera za svaki tim? Zar ne može jedan Scrum Master imati dva ili tri tima?

Čini mi se da u argumentaciju krećemo iz pogrešne perspektive. Mi se pitamo koliko SM može imati timova. Pravo je ustvari pitanje koliko timu treba njihov Scrum Master.

Pravo je ustvari pitanje koliko timu treba njihov Scrum Master.

Timovi su ti koji rade posao i SM im pomaže, znači fokus je na timovima. Novi, neiskusni, nezreli timovi – full time SM. Iskusni, zreliji timovi – manje nego full time SM.

Treba se fokusirati na izgranju timova, mjeriti njihovu zrelost i onda otpuštati kapacitete njihovog SM-a, jer je stabilan tim sad u stanju preuzeti aktivnosti koje obavlja njihov SM.

Stabilan je onaj tim koji:

• Redovito isporučuje upotrebljiv komad softvera (tj. proizvoda) na kraju svakog sprinta
• Sam se interno dogovara oko administrativnih stvari (godišnji i sl.) tako da šira organizacija niti ne primijeti da se to događa
• Bez većih problema uvodi nove ljude u rad
• Sam se brine o vlastitom profesionalnom razvoju (planiraju edukacije, konferencije itd tako da to ne utječe na posao)
• Redovito stanu pred produktni backlog i naprave neki npr. tromjesečni plan
• Redovito imaju neka svoja interna druženja (PPPP – petkom piva poslije posla i slično)
• Sam se brine oko logistike rada tima (pronašli su mehanizme naručivanja uredskog materijala i takve, naoko blesave stvari)

Koliko treba timu da postane takav? Nemam pojma, ali sigurno duže nego što mislimo Ovisi o timu, naravno. Kažu istraživanja, 6-12 mjeseci. (Tuckman)

Koliko vremena treba timu da postane stabilan? Duže nego što mislimo

Možemo li otpustiti nešto kapaciteta timskog SM-a i prije tih 12 mjeseci? Vjerojatno. Koliko? Manje nego što mislimo.

Zrelost timova se može mjeriti, a prema tome onda i “dozirati” angažman SM-a, u smislu broja coaching sati kojeg bi pojedini tim trebao.

Svi trebamo uzeti vrlo vrlo oprezno te brojeve, odnosno treba ih gledati više kao neku pretpostavku koju ćemo u nekom trenutku potvrditi ili pobiti, odnosno prilagoditi stvarnom stanju.

Photo by Pascal Swier on Unsplash

Č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.

Pred kraj prvog dana obično imamo ovakav Superbrzi uvod u Scrum, gdje skupimo sve do tada naučeno u jednu polusatnu priču.

Drugi dan se nakon toga bavi upravo Scrumom, u znatno više detalja.

Sve vam izgleda kao drama, ali ustvari nije. Čak vam treba biti pomalo toplo oko srca jer se ovakve situacije događaju u stvarnom životu i dobro je imati stav kako pristupiti rješenju problema.

Kako vam je izgledao sprint?

Recimo da ste od planirane količine posla napravili jednu trećinu (vizualizirate posao pa se sve lako vidi), a ostatak vremena je otišao na ad-hoc zahtjeve i pomoć drugim timovima i okruženju jer:

• Drugi dio organizacije lansira ogromnu produkciju, a vaš tim može pomoći u nekim detaljima.
• Korisnik koji je do prije 2 tjedna znao što želi je potpuno promijenio priču zato što se kod njih interno nešto dogodilo.
• Sustavi koji su do jučer radili stabilno su se počeli ponašati jako čudno pa ste morali pomagati operativi, restartati servere i još koješta.
• Hakeri su vam napali IT i većinu vremena ste proveli stavljajući zakrpe na postojeće aplikacije i servere.
• Poplava u sistem štali, svi kante u ruke i ajmo.

Ne izgleda lijepo. Što dalje?

Najčešće pitanje koje se ovdje postavlja je treba li održati sprint change (review, retrospektivu i planiranje) ili jednostavno preskočiti sve.

Pročitajte čemu zapravo služi Sprint Review.

Iz moje perspektive agilnog coacha odgovor je vrlo jednostavan i jednoznačan (da, treba), ali prije nego što se pokunjite i primite posla, probajte razmisliti o situaciji u kojoj se nalazite. Standardni coaching pristup analizi problema i okruženja je primjenjiv i ovdje. Zapitajte se: što ćemo (kao tim i cijela organizacija) dobiti ako imamo sprint change, a što ćemo izgubiti ako nemamo.

Dobit ćemo ako imamo sprint change

Benefiti su više nego jasni.

• Svi stakeholderi imaju jasnu sliku što se radilo i napravilo tokom sprinta, bez obzira je li to iz backloga ili ad-hoc. Vidljivost tima i njihovog posla je pola uspjeha. 
• Svi znaju koliko je kapaciteta otišlo na neplanirane aktivnosti, što je vrlo korisna informacija za buduće slične situacije ili druge timove i inicijative.
• Članovi tima će komentari sprint, što su naučili u datoj situaciji, kako im je izgledalo raditi u takvom okruženju, možda skupa s drugim timovima, imaju li neka saznanja kojih recimo okruženje nije svjesno i slično.
• Svi – članovi tima, PO, stakeholderi – imaju ideju što će se događati dalje, što sa zadacima iz backloga, očekuju li se i dalje slične situacije, i drugo.

Ograničite review na 30 minuta, ili koliko zaključite da vam treba: 20, 45… Vrlo je bitno da review bude fokusiran i ograničen! Najavite o čemu će se govoriti i pozovite sve zainteresirane strane, uz naznaku da prisustvo nije obavezno ali može biti korisno.

Ograničite retrospektivu na 45-60 minuta. Trebalo bi biti jako zanimljivo i korisno jer ste upravo doživjeli sudar dva svijeta – vašeg idealnog kojeg je jednostavno planirati i stvarnog koji je nepredvidljiv i zbunjen, a iz toga se može jako puno naučiti.

Planiranje odradite kao i do sada, s tim da možda već unaprijed znate da ćete imati manje kapaciteta za backlog pa sukladno tome ni planiranje neće trajati predugo.

Ako je baš panika, napravite pauze između reviewa, retrospektive i planiranja da se možete vratiti u stvarni svijet (i pomoći drugima ako treba) ali svakako sve ugurajte u jedan dan.

Izgubit ćemo ako nemamo sprint change

Ako ne napravite sve ovo gore, odnosno počnete rastezati i razvlačiti po danima i terminima, onda se može dogoditi da se neke stvari nikad ne odrade u cjelini, već u nekim dijelovima, automatski sljedeći sprint neće imati smisla, propustit ćete priliku osvrnuti se na trenutni način rada, što može biti korisno već od sljedećeg dana i tako dalje. Više problema nego koristi.

Dobro, nakon svega ovog, što mi je činiti?

Iz mojeg iskustva kao SM i coach, bez obzira na uspješnost ili neuspješnost sprinta, uvijek smo imali review u zakazano vrijeme, retrospektivu odmah nakon toga a zatim planiranje. Naša je sugestija da i vi uradite tako.

Photo by Andrej Lišakov on Unsplash.

 Što da radimo na Sprint Reviewu ako nemamo što za pokazati?

Pitanje koje često čujemo. I obično posljedica primjenjivanja konkretne prakse (ovog puta pokazivanja radećeg inkrementa proizvoda) bez zadubljivanja čemu ta praksa zapravo služi.

Činjenica: Sprint Review je putem postao sinonom za demonstraciju proizvoda.

Pogledamo li u Scrum Guide, tamo stoji “During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.”

Dakle, osnovna svrha Sprint Reviewa je suradnja razvojnog tima i stakeholdera na razvoju proizvoda. Dobar način kako to ostvariti, složit ćemo se najbolji, no sigurno ne i jedini, je pokazati što je napravljeno dosad i pričati o nastavku: zadovoljava li nova isporuka potrebe stakeholdera ili treba nešto mijenjati? Zadovoljava li proizvod u cjelini već sad potrebe stakeholdera pa možemo stati s razvojem? Ako još uvijek ne zadovoljava, koje su od preostalih funkcionalnosti prepoznate kao najvrjednije te će se implementirati sljedeće? Prepoznaju li stakeholderi možda neke nove funkcionalnosti koje donose značajnu vrijednost, a dosad nisu bile razmatrane za razvoj?

Osnovna svrha Sprint Reviewa nije “Dragi stakeholderi, dođite da vam pokažemo što smo napravili.” Pokazivanje onoga što je napravljeno je svakako poželjno i korisno, no pokazivanje nije samome sebi svrha. Osnovni cilj pokazivanja nije izvještavanje. Osnovni cilj pokazivanja je poziv stakeholderima na razgovor i suradnju oko razvoja proizvoda.

Da odgovorimo na pitanje: pokazivanje na Sprint Reviewu je svakako poželjno i mi kao coachevi uvijek inzistiramo da se pokazuju opipljive isporuke: radeći softver, konkretizirani dizajn i slično… No ponekad se dogodi da tim iz ovog ili onog razloga nema što za pokazati. U tom slučaju suradnju na razvoju proizvoda između razvojnog tima i stakeholdera treba temeljiti na nečemu drugome, npr. na pregledu produktnog backloga, razgovoru o vrijednosti pojedinih funkcionalnosti, diskusiji koje funkcionalnosti već danas možemo izbaciti iz backloga a da konačni proizvod zadovoljava potrebe stakeholdera. Pokazivanje radećeg inkrementa je kul, ali nepostojanje radećeg inkrementa nije razlog za preskakanje Sprint Reviewa. Osnovni cilj Sprint Reviewa je suradnja, a ne pokazivanje.

A zašto tim nije imao što za pokazati, e to je pak tema za retrospektivu

Odmah da razjasnimo na početku, ne postoji pravilnik ponašanja u ovakvim slučajevima, niti će vam na vrata doći Scrum policija ako nešto napravite mimo regula. Ipak, mogu se dati neki iskustveni savjeti kako pristupiti problemu.

User Story nije niti započet

Najlakši slučaj, vratite US u backlog i ponašajte se kao da se ništa nije dogodilo (osim što trebate o ovome popričati na retrospektivi). Ako je bitan, uzet ćete ga u sljedeći sprint tokom planiranja i to je to. Ako nije bitan (možda je to razlog zašto nije niti započet?) onda se ne bi trebao pojaviti u sljedećem sprintu. Ne može jednostavnije.

User Story je započet, ali nije dovršen

Najčešći slučaj. Bitno je shvatiti zašto se ovo dogodilo:

• US je prevelik pa niste stigli?
• US je bio nejasan pa ste potrošili vrijeme na razjašnjavanje?
• US je ovisio o nekom vanjskom događaju (ili pojedincu, timu, entitetu)?

U svakom slučaju, problem nije u nedovršenom user storyju već u nedovoljno dobroj analizi tokom planiranja sprinta. Probajte napraviti bolju analizu tokom sljedećeg planiranja kad ćete već unaprijed odgovoriti na gornja pitanja.

Što se tiče samog US-a, vratite ga u backlog, vjerojatno cijelog pa onda tokom sljedećeg planiranja analizirajte što je još ostalo od posla i dopunite ovaj ili napišite novi US, a ovaj bacite u smeće.

User Story je dovršen, ali je otkriven bug

Kad je otkriven bug, tokom testiranja u okviru sprinta? Pa popravite ga, i dopunite svoj Definition of Done tako da uključuje i testiranje. US nije gotov dok testiranje ne potvrdi da ne može naći bug. Bez obzira je li bug trivijalan ili ozbiljan, potrudite se riješiti ga tokom sprinta jer tako ne ostavljate repove za sobom već dovršavate stvari a to se cijeni.

Otkrili ste bug tokom reviewa? Odlično! Bolje nego u produkciji. Zapišite ga i stavite u backlog. Ako je drama (npr. našla ga je direktorica financija pred svima ili je bloker) vjerojatno će biti na vrhu liste za popravak, inače ide u redovnu proceduru.

Bug je otkriven nakon što je sprint dovršen? Ide u backlog i u redovnu proceduru prema nekom SLA (service level agreement) kojeg već imate.

Važnije je što radimo nakon “incidenta”

Svi repovi nakon sprinta su ustvari poziv na razgovor i analizu problema, vjerojatno već tokom sljedeće retrospektive. Pitajte se zašto se dogodilo pa da sprint nije dovršen i ideje za rješenje ugradite već u sljedeće planiranje. Kao tim želite biti predvidljivi (ma kako to dosadno zvučalo) tako da i vi sami, ali i okruženje oko vas može računati na termine isporuka.

Dobro i precizno planiranje je i pokazatelj zrelosti tima.

Što nije pametno raditi

Nepametna ideja #1: US (ili razlika) automatski ide u sljedeći sprint

Iako će US vjerojatno na kraju i dospijeti u sljedeći sprint, podrazumijevati da će tako biti je greška.

S druge strane, ako je ostalo “još samo malo”, možda vrijedi dovršiti US i skinuti ga s vrata jednom i zauvijek. Neka PO odluči

Nepametna ideja #2: Produživanje sprinta

Ovo je ustvari glupa ideja. Produživanjem sprinta poništavate metrike o kapacitetu tima, brzini rada ili broju US-a koje tim može isporučiti tokom sprinta, a time kvarite i svoju predvidljivost isporuka.

Nedavno smo s jednim vrlo dragim korisnikom potvrdili činjenicu da informacija iz svijeta agilnih i lean metoda ima stvarno puno, ustvari i previše, i da je dosta teško sustavno ući u temu. Može se, naravno, ali je pravo pitanje kako optimalno usvojiti znanje, bez previše lutanja i gubljenja vremena. Kroz naš coaching angažman se dobije i dosta široki pogled na cjelokupno područje što u konačnici budi želju za još više detalja.

Pokazalo se da ljudi žele čitati i slušati o iskustvima iz stvarnog života, što je i razumljivo jer tako mogu sagledati tuđe okruženje i usporediti ga sa svojim. U takvim situacijama obično preporučujemo sljedeću listu knjiga i filmova na YouTubeu.

Knjige

Scrum Guide

Scrum Guide (Vodič kroz Scrum, uskoro i u hrvatskom prijevodu) je obavezno štivo za svakog koga se Scrum dotiče na bilo koji način. Istina, nije baš razumljiv ako se čita bez ikakvog predznanja, pa preporučujemo da posvetite 2 sata i pročitate ga u miru tek nakon što ste proveli neko vrijeme u organizaciji koja usvaja ili već prakticira Scrum. Bit će puno lakše razumjeti što piše unutra, a istovremeno ćete dobiti bolju sliku što Scrum znači i u vašem okruženju.

Scrum: The Art of Doing Twice the Work in Half the Time

Jeff Sutherland je autor ove knjige, i autor Vodiča kroz Scrum. Pročitajte je zbog vrlo konrektnih savjeta, cijelog niza primjera i boljeg razumijevanja zašto se u Scrumu nešto radi na određeni način.

Lean from the Trenches

Henrik Kniberg je njuška, a ova knjiga to dokazuje “jedan kroz jedan”. Naći ćete jako dobro opisan projekt implementacije sustava za švedsku policiju i detalje o primjeni Scruma, Kanbana, XP-a i srodnih metoda i to od početka do kraja. Knjigu ćete pročitati za jedan vikend, toliko je dobra da je nećete ispuštati iz ruku.

This is Lean

This Is Lean: Resolving the Efficiency Paradox je knjiga još jednog švedskog autora, Niklasa Modiga, koja će vam brzo i bez previše okolišanja objasniti što je i zašto vrijedi uložiti napore kako biste bili “lean”. Izravan pristup “u glavu”, jednostavni primjeri, kratka knjiga zbog koje ćete preskočiti blesavi film na TV.

The Five Dysfunctions of a Team

Svi su vidjeli piramidu o pet razina disfunkcija tima. E pa ta piramida dolazi iz ove knjige, The Five Dysfunctions of a Team: A Leadership Fable.

Filmovi

Agile Product Ownership in a Nutshell

U samo 15 minuta prođite kroz temelje agilnog razvoja softvera. Film je pogledalo više od milijun ljudi, očito vrijedi nešto

Jeff Patton i filmovi o User Story Mappingu

Jeff Patton je autor knjige User Story Mapping, vrlo korisne tehnike vizualizacije posla i iteracija (sprinteva). Knjiga se ne bavi samo mapiranjem korisničkih priča već se dobar dio posvećuje upravo razjašnjavanju što User Story jest, kako ih dobro pisati i što je još važnije, kako ih iskoristiti.

Na YouTubeu je nekoliko filmova s različitih konferencija gdje Jeff prolazi kroz jednostavne i razumljive primjere. Krenite redom, nećete se razočarati. Možda je najbolji ovaj dvosatni iz priloga.

Scrum je metoda kojom tim implementira neki proizvod primjenjujući agilne principe rada. Sav posao kojeg tim radi planira se na razini jednog sprinta i vidljiv je na timskoj ploči. Ne postoji dodatni posao sa strane, niti postoji posao za nekog određenog člana tima.

Za više detalja pogledajte Može li Scrum tim raditi na više projekata i Što s redovnim poslom koji je van “agilnog” projekta

Stvarni svijet

Posebno je česta pojava u novoformiranim timovima da se zadaci upućuju pojedinim ljudima (imenom i prezimenom). Razloga može biti više:

• prije formiranja tima ljudi su radili neke poslove koji nisu gotovi pa ih treba dovršiti
• netko u timu ima specifično znanje kojeg nitko drugi nema
• nečiji šef želi da baš ta osoba odradi zadatak

Sigurno će se pronaći još koji razlog, no zajedničko svima je očito ignoriranje elementarne postavke Scruma:

Posao dolazi u timski backlog, tim povlači (preuzima) zadatke, ljudi sami u timu određuju tko će konkretno odraditi posao.

Dodjeljivanje zadataka nekom određenom članu tima je znak da okruženje još uvijek nije prihvatilo agilni način rada, i to je svakako nešto na čemu treba poraditi.

Kako u međuvremenu odgovoriti na gore navedena ponašanja?

Konkretni zadatak je iz “prošlog života” određenog člana tima

Osim ako nemamo tim sastavljen od potpuno novih ljudi, sigurno će neki od članova imati zaostatke iz prijašnjih projekata. Ponekad se takav posao naziva i “Business as Usual” (BAU), što je vjerojatno znak da organizacija nije do kraja prihvatila agilni način rada. U svakom slučaju, cilj je osvijestiti da takav dodatni posao postoji i da ga treba napraviti, a da istovremeno odvlači koncentraciju i krade vrijeme za izvršavanje zadataka zbog kojih je tim i formiran.

Najzdraviji pristup je, kao i u cijelom nizu sličnih situacija, vizualizirati taj dodatni posao, naprimjer u posebnoj koloni na timskoj ploči.

Na retrospektivi se može napraviti analiza takvih zadataka gdje će se provjeriti koliko ih je, je li baš bilo nužno da svaki dođe u tim, koliko su utjecali na redovni posao i prema tome reagirati.

Netko u timu ima specifično i jedinstveno znanje

Ništa lakše, uparivanje! Na prvi pogled zvuči nelogično i neefikasno ako dvije osobe rješavaju isti zadatak, ali praksa pokazuje se u našem poslu, koji se temelji na kreativnom radu, uparivanje itekako isplati: podiže se kvaliteta isporuke, posao se napravi brže i manje je repova nakon isporuke. Uparivanjem ćemo također proširiti i znanja koja pojedini ljudi imaju u timu i sljedeći put kad dođe tako specifičan zadatak bit će ga lakše odraditi.

Čak i IKEA preporučuje uparivanje.

Ukratko, uparujte ljude!

Nečiji šef želi da baš ta osoba odradi zadatak

Ovo je vjerojatno najozbiljniji problem od svih navedenih i ovakvo (šefovo) ponašanje je znak ili nepoznavanja načina rada po Scrumu ili namjerno kršenje dogovora o formiranju tima, njegovoj stabilnosti i neovisnosti.

U prvom slučaju pomaže direktna edukacija (tečajevi, coaching) a vjerojatno je još učinkovitija popularizacija Scruma preko odgovarajućeg ponašanja samih članova tima.

Naprimjer, tim može predložiti da će uzeti zadatak, riješiti ga na timski način i šefu isporučiti rješenje uz objašnjenje kako se radilo.

Kvaliteta i brzina isporuke će vjerojatno biti na višem nivou, što je svakako benefit timskog rada.

Drugi slučaj je puno ozbiljniji. Stav “Moj čovjek je moj čovjek i radit će ono što mu ja kažem” se ne mijenja preko noći, pa i pripadajući odgovori moraju biti pomnije osmišljeni. Često je dobra ideja napraviti eksperiment: naprimjer dogovoriti se da svaki drugi ovakav zadatak ide u tim umjesto pojedinom članu tima i poslije dva ili tri sprinta usporediti rezultate — kvalitetu i brzinu isporuke, utjecaj na redovni timski posao i slično.

Ljudi su razumni i fokusirani na rezultate.

Ako možete pokazati da tim radi bolje od nakupine pojedinaca, onda će i takav način rada vrlo brzo biti prihvaćen.

Ako imate nerazumnog šefa s druge strane onda… što reći, nemate sreće.

Kako god, ovo je tipična situacija u kojoj Scrum Master priprema teren i rješava problem.

Nevidljivi posao

Posebno je opasan posao koji se ne vidi u timskom backlogu. Ovakav posao najčešće dolazi određenom članu tima od njegovog šefa (nadređenog, linijskog voditelja ili koju već hijerarhiju pronalazimo u organizaciji) i jedini savjet kojeg ovdje mogu dati je: vizualizirajte baš sve.

Vizualizirajte baš sve!

Baš svaki posao treba biti vidljiv na timskoj ploči tako da se na kraju sprinta može pokazati koliko se radilo na kojim stvarima i sukladno tome reagirati.