• 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

SPOCK daje infrastrukturu i organizira redovne radionice iz različitih područja, sve kako bi ekipi bilo lakše probiti se kroz šumu… pa… svega

U prošli petak sam tamo održao Agilnu radionicu za drugu generaciju timova i dojam je odličan: fokus, energija, komunikacija, možda malo previše inženjerskog razmišljanja no sudeći prema reakcijama tokom i nakon radionice, agilni principi i vrijednosti će se svakako primiti.

Ako nakon svega ovoga što čitate na t|d|d i dalje mislite da je agilizacija samo nekakvo lijepljenje šarenih papirića, onda vas moram razuvjeriti i pokazati da se dobar dio svodi na crtanje još šarenijih slika:

I, naravno, loptanje:

Pogledajte slajdove (ako ih tako uopće možemo nazvati?)

Prečesto se timovi formiraju samo za potrebe projekta. Sastavljaju se na početku projekta i rastavljaju na kraju.

Formiranje tima nije jednostavan posao. Tuckman kaže da vrlo brzo nakon formiranja tima stvari krenu nizbrdo. I obično bude gore prije nego postane bolje. Prolazeći kroz faze storminga i norminga timu treba 6-12 mjeseci da uđe u fazu pune produktivnosti. A današnji su projekti takvi da tipično završavaju prije nego što se tim u potpunosti formira.

I što mi onda radimo? Baš kad se tim krene fino formirati, mi ga fino razmontiramo, jer projekt je gotov pa što bi drugo s timom nego ga razmotirati, jel tako? I onda promiješamo ljude i krenemo raditi neke nove timove koji opet ulaze u storming fazu i tako u krug. I stalno radimo s neformiranim timovima. I stalno vozimo Ferarije u drugoj brzini.

Ima li tome rješenja? Pa jasno da ima. Učinimo tim važnijim od projekta! Nemojmo ga razmontirati završetkom projekta. Iskoristimo dobro formirani, produktivan tim i dajmo mu da radi sljedeću najvrjedniju stvar iz našeg portfolija projekata. Dodjeljujmo projekte timovima, a ne timove projektima.

Zato sljedeći put kad pomislite na projekt…. nemojte… mislite na tim!

TEAM FIRST! Project second.

Bus factor ili kako se riješiti voditelja tima

Mnoge agilne prakse poput dijeljenja odgovornosti u timu, zajedničkog rada cijelog tima na poslovnim zahtjevima, suradnje developera i poslovnjaka na testiranju, na papiru i ekranu zvuče super sve dok se ne spustimo u rovove i probamo sve to implementirati u stvarnom životu i u stvarnom okruženju.

Darko Špoljarić Špula  nas je na našem petom meetupu poveo na putovanje kroz šumu problema, nejasnoća i zbunjujućih ponašanja koristeći živi primjer projekta na kojem sada radi. Meetup je bio glavolomka (jel’ se tako kaže?)! Darko nam je koristeći Causal Loop Diagram koji nam dolazi iz systems thinking domene nacrtao uzročno posljedične veze svih svojih problema (onih poslovnih dakako), a mi ostali smo u grupama razgovarali, tražili rješenja i prezentirali prijedloge.

Od mnogih prijedloga, par stvari koje smo zapamtili:

• Ne zaboravimo na bus factor – tim koji se raspadne ako X pregazi autobus, nije dobro posložen tim – neovisno o tome da li je X voditelj tima, developmenta, jedini analitičar ili bilo koji čovjek/rola. Puno praksi nam tu može pomoći, jedna od njih je rad u paru, od početka razrade zahtjeva do popravka zadnjeg buga. Izbjegnimo “to radi samo x” situacije.
• U nekim (svim!) timovima dobro dođe Scrum tečaj da bi razumjeli zašto nešto ne radimo.
• “Ček ček, što je ono točno rečeno na sastanku za ovaj zahtjev?” situacija – ako klijenta i Product ownera vidimo rijetko, trebamo li razmisliti kako dokumentiramo te razgovore?
• Komunikacija mora biti konstantna, eksplicitna i zadatak svih članovi tima. Ako netko ima veći autoritet u timu, makar bio zasnovan na znanju, ne smijemo dopustiti da se ostali zbog toga povuku. Vraćamo se na bus factor, ali i na smisao kolaboracije i timskog rada.
• Respect the WIP! Ili se izgubi u multitaskingu.

A tu su i slike koje je Kele uslikao krumpirom kroz bocu osušenog balzamika, tako da je i kvaliteta istih odgovarajuća.

Implementacija agilnih principa temelji se na multifunkcionalnim timovima koji su stabilni, samostalni i imaju sva potrebna znanja i vještine kako bi obavili svoj posao. U takvim se timovima znanje kvalitetnije dijeli, posao se bolje balansira, ovisnost o vanjskim resursima je minimalna, a različiti profili ljudi i različita mišljenja potiču nove ideje i inovacije.

Puno teorija opisuje proces razvoja tima, a vjerojatno najpoznati je Tuckmanov model. Imajući na umu sve faze Tuckmanovog modela kroz koje tim mora proći te da je potrebno između 6 i 12 mjeseci da nakupina ljudi uistinu postane tim, čini se razumnim da im u tome nekako pomognemo. Odličan poguranac razvoju svakog tima daje kickoff radionica.

Na kickoff radionici sudjeluje cijeli tim, a cilj radionice je propuhivanje komunikacijskih kanala, bolje međusobno upoznavanje članova tima i dogovaranje oko načina kako će kao tim funkcionirati. Kao i za sve ostale radionice svojstvene agilnom načinu rada, i za ovu vrijedi da ne postoji jedan jedini ispravan način kako se radionica provodi. Ranije navedeni cilj radionice ujedno predstavlja i tzv. enabling constraints, odnosno ograničenja unutar kojih tim ima slobodu realizacije sve dok je cilj ispunjen.

Ipak, postoje dobre prakse provođenja kickoff radionice, odnosno ima aktivnosti koje su se pokazale korisnijima od drugih.

U domeni “dogovaranja oko načina kako će tim funkcionirati” korisnima su se pokazale aktivnosti zajedničkog definiranja:

• pravila ponašanja/funkciniranja tima (Working Agreement)
• kriterija kad je neki komad posla spreman za realizaciju (Definition of Ready)
• kriterija završenosti posla (Definition Of Done)

U domeni “boljeg međusobnog upoznavanja članova tima” posebno su korisne aktivnosti:

• definiranja imena i slogana tima – potiče zajedništvo i stvaranje timskog identiteta
• Market of Skills – aktivnost u kojoj članovi tima prezentiraju svoja znanja, vještine i afinitete prema područjima u kojima bi se htjeli usavršavati i sl.
• Star Skill Map – aktivnost u kojoj članovi tima identificiraju znanja i vještine koje će im trebati na konkretnom projektu i samoocjenjuju se u tim kategorijama. Svrha ove vježbe je provjera ima li tim uistinu sve potrebne vještine te kreiranje baselinea prema kojem možemo pratiti usavršavanje članova tima.

Dobro je u okviru kickoff radionice odraditi i upoznavanje tima s opsegom posla kojeg će raditi te inicijalno razrađivanje backloga (backlog refinement) i planiranje prvog sprinta. Na taj se način timu daje kontekst i spremni su za prvi sprint.

Ako vam se čini da je ovo puno posla, u pravu ste. Kickoff radionice su tipično dvodnevna događanja, ali vrijede svake minute. Razina međusobnog razumijevanja članova tima i razumijevanja budućeg posla na kraju ovakve radionice ne može mjeriti ni sa kakvim drugim ad-hoc prezentacijama. Imajući u vidu da stvarate dugoročan i stabilan tim, investicija od dva dana se zaista ne čini velikom.