Stvar koja konstantno ne prestaje da me istovremeno i začuđuje i impresionira je potreba nekih ljudi da sve što je vredno uvaljaju u blato, a zatim da viču “Prljavo je!”. Agilni razvoj softvera je tema koja je meni bliska i o kojoj veoma često imam priliku da razgovaram sa ljudima koji rade u potpuno različitim kompanijama. Opšti utisak je sličan, razumeli smo mehaniku i našli smo hiljade izgovora zašto to ne radi. Nalazimo se u vremenu u kome samo-prozvani konsultanti i zajednice propovedaju kako se za nekoliko dana kurseva može naučiti Scrum, IT zajednice podržavaju jedne druge jer će im biti korisno, a svi uključeni u razvoj softvera ostaju besni na neki Agile/Scrum/Whatever koji im je neko nametnuo bez da se bilo ko zapitao čemu sve ovo.
Na kraju, priča sa “konsultantima” se uglavnom svodi na isto. Skinuli smo kravate, na prevaru i dalje nismo gadljivi. Ovaj put je još skuplje, upakovano u još sjajniji papir i sve to sa obećanjem da je to sledeća velika stvar koja rešava sve vaše probleme.
U ovom članku želja mi je da postavim granicu između čarobnjaka, jednoroga i vilenjaka i bića koja stvarno postoje i odgovorno rade svoj posao.
Scrum Master
Kada neko kaže da je Scrum Master na šta prvo pomislite? Master u imenu prosto vuče na to da osoba iza te titule ima neki autoritet. To je veoma čudno s obzirom da je sama uloga te osobe da služi timu i organizaciji.
Kod Scrum Master-a stvar koja magično treba da reši sve probleme je sertifikacija. Jer kad je neko i sertifikovan i Scrum i Master sigurno će dobro raditi. Čak se u oglase za posao stavlja da je sertifikacija poželjna. Interesantno je da neke kompanije koje nude tu istu sertifikaciju nude i treninge pod nazivom “Scrum Repair Guide”. Zamislite da kupite novi računar, a onda morate još da platite da bi on potpuno ispravno radio?
Taj Scrum Master bi odjednom trebalo da postane sposoban da pomaže timu bez da im govori šta i kako da rade. Trebalo bi da on zna da nauči Product Ownera kako da bolje radi svoj posao.
Uz sve to što se od njega odmah očekuje, on se suočava i sa time da mora da radi još jedan posao u timu jer “šta će on po ceo dan da radi?”. Ako ne mora da radi još jedan posao u timu, onda ga stavljaju da bude Scrum Master u više timova. Opšte prihvaćeno (i pogrešno) uverenje je da SM radi samo kad se bavi procesnim stvarima, npr. organizuje retrospektivu. Kad već postoji uverenje da SM radi samo kad se bavi procesom, onda kompanije odluče da ga nazovu Agile Project Manager. Očigledno veruju da kad već mogu da od ozbiljnog posla prave Mikijev zabavnik, mogu i da izmisle titulu koja je sama po sebi oksimoron.
Scrum Master nije nikakav vođa niti šef tima. On nema formalni autoritet. On ne određuje ko će da bude u timu, šta će koji član tima da radi, kada će koji član tima na odmor.
Scrum Master zna kako se organizuje proces donošenja odluka u grupi. On zna kako da moderira “brainstorming” sesiju. On zna da kada se traži rešenje nijedna ideja nije glupa. On zna da je važno da na kraju tog procesa treba da postoji bar jedna konkretna akcija. On zna da ponekad treba podsetiti tim da proveri rezultat akcije.
Scrum Master želi da bude neprimetan. On pomaže timu da tim nauči da rešava probleme bez njega. On je ogledalo za tim.
Scrum Master zna da Scrum nije zapisan u kamenu. Dobar Scrum Master ne pritiska tim da radi Scrum. Dobar Scrum Master veruje da su vrednosti i principi važniji od imena procesa.
Scrum Master zna da je krajnji proizvod ogledalo kompanijske kulture. On je katalizator promena. On poštuje tradiciju, a istovremeno zagovara promenu. On podržava one koji u promenu veruju i ohrabruje one koji se nje boje.
Scrum Master veruje u ljude.
Product Owner
“Od danas radimo agilno i ti više nisi Business Analyst nego Product Owner.”
Da li možete da zamislite menadžera u nekoj kompaniji koji ovo izgovara? Uz ovu rečenicu samo mu nedostaje da zamahne čarobnim štapićem i da se pojavi duga. To bi sve bilo super kada bi taj jadni novi PO imao jasan set instrukcija po kojima treba da radi novi posao. Međutim, Scrum kao framework je ostao nem na tehnike za kreiranje backloga, preciznu definiciju šta je to “product backlog item” i tehnike za prioritizaciju.
Naravno taj novi PO može da ode na kurs i postane sertifikovani PO. Sad taj sertifikovani PO dobija sertifikovane veštine sa kojim verovatno može da pravi sertifikovani backlog. Na kraju, kada taj sertifikovani PO napravi sve to što je trebalo i krene da radi sa timom, onda se neretko pojavi onaj menadžer koji mu je rekao da bude PO i kaže mu da on ipak nema pravo da odluči šta su prioriteti.
Product Owner nije Business Analyst. Njegov primarni zadatak nije da piše “user story-je”. Njegov zadatak nije da ispunjava tuđe želje i da ih samo prenosi timu.
Product Owner zna šta je vizija proizvoda. On aktivno učestvuje u njenom kreiranju. On je oblikuje. On je živi.
Product Owner stalno uči. Uči o korisnicima. Uči o poslovnom okruženju. Uči zajedno sa timom. Uči kako da bude bolji.
Product Owner razume kompleksnost. On razume da se proizvodi razvijaju u kompleksnom okruženju u kome procene nisu obećanja. On zna da kompleksne zadatke treba konstatno deliti na manje celine.
Product Owner zna da ne postoji samo jedna verzija istine. On podržava eksperimentisanje. On zna da je izvor problema obično dublje ispod površine i spreman je da učestvuje u pronalaženju rešenja.
Product Owner je deo tima.
Samoorganizovani tim
Samoorganizovani tim je jedan od prvih pojmova koji čujete kada neko krene da priča o Scrum-u. Kao i sve drugo vezano za Scrum i ovo deluje jednostavno. Dođete kod tima predstavite se kao Scrum Master i kažete od danas ste samoorganizovani tim. Ako je Scrum Master još ambiciozniji onda on dodatno organizuje radionice na kojima tim duva neke balone, pokušava da razveže zamršene ruke ili pravi neke igračkice od Lego kockica. Na kraju dobijamo tim koji zna 2000 načina da složi Lego a ne zna XP prakse.
Da stvar bude još interesantnija baš taj tim, koji treba da radi zajedno i ostvaruje rezultate, obično sastavi neko drugi po kriterijumima koje je napisao neko treći.
Kad je neko već sastavio taj tim i rekao mu da se sam organizuje, obavezno dolazi neki guru koji će da kaže timu gde oni greše, kako treba da rade i do kada treba da završe posao.
Samoorganizovani tim nije skup super heroja koji magijom rešava probleme. Nije ni pojam koji postoji samo u knjigama. Nije ni nešto što može da se stvori samo u određenoj kulturi.
Samoorganizovani tim nema vođu.
Samoorganizovani tim se gradi. Svaki dan. Mesecima. Kontinuirano. Uprkos greškama. Svesno. Namerno. Iskreno. Posvećeno. Bez odustajanja.
Samoorganizovani tim ima pravo da odluči koliko posla može da uradi. Bez obzira na to koliko neko drugi mislio da je moguće. Ima pravo da traži više informacija. Ima pravo da priča sa krajnjim korisnicima. Ima pravo da promeni proces rada, ako će im to pomoći da bolje rade.
Samoorganizovani tim podstiče različitost. Ohrabruje slobodu mišljenja. Istrajava u pronalaženju rešenja za konflikte. Komunicira.
Samoorganizovani tim radi odgovorno.
Ostala mitska bića u agilnom razvoju softvera
Head of Scrum – Ovo mitsko biće se javlja u nekim kompanijama koje veruju da Scrum Masteri treba da imaju “šefa”. Njegova uloga je da organizuje osobe koje treba da promovišu princip samoorganizovanja.
Project Manager – Pojedine kompanije i dalje veruju da se proizvod razvija tako što se unapred definiše obim posla i rokovi, a onda se samo implementacija radi po Scrum-u. Samim tim one veruju da im i dalje treba Project Manager.
Program Manager – Još jedno mitsko uverenje je da jedna osoba istovremeno može praviti planove za razvoj više proizvoda, da treba da bude zadužena za “change control process”, “risk management” i za sve ostale cool reči koje su pronašli na drugim sajtovima.
SAFe, DAD ili Less Consultant – Ovo biće nije u potpunosti mitsko. Međutim, s obzirom na to da prodaje carevo novo odelo, definitivno ga možemo svrstati u ovu grupu. Ovo biće se obično pojavljuje u velikim kompanijama nudeći univerzalni recept za agilnost na nivou kompanije. S obzirom da je ovo uspeo da otkrije, verovatno uz taj recept daje i tajnu za večan život.
Rezime
Ignorisanjem ljudi i forsiranjem procesa Agile gubi svoj smisao, a Scrum postaje još jedna propala ideja.
Agilni razvoj softvera čine ljudi. Ti ljudi imaju svoja znanja i veštine. Oni imaju svoje mane i svoje strahove. Oni u timove donose svoja uverenja i svoje vrednosti bez obzira na to koji framework ili metodologiju im nametnuli. Pre svega oni imaju emocije.
Ako želite da stvorite kompaniju koja je istinski agilna, za početak verujte u ljude koji su već tu. Oni najbolje znaju kako se love jednorozi.
1 Responses
Uvod u Kanban - Agilizing.us
[…] pokušajte da vidite da li je to pravo rešenje za vas. U nekim od prethodnih tekstova pisali smo o Mitologiji razvoja softvera i Zašto Scrum nije rešenje za sve probleme. U našem okruženju danas svi pokušavaju da rade […]