Agile/Scrum reikalauja kompanijos kultūros pokyčio

Metų viduryje atsakydamas į vieną iš dažniausiai užduodamų klausimų parašiau straipsnį Nuo ko pradėti Agile/Scrum kompanijoje?. Nuo to laiko sutikau nemažai žmonių, kurie pradėjo naudoti Agile/Scrum. Kai kurie net vadovavosi ten pateiktais patarimais (ar sėkmingai vadovavosi leisim prisipažinti jiems :) ). Diskutuodamas apie diegimą supratau, jog straipsnyje pamiršau akcentuoti vieną labai svarbų momentą. Jei norite jog Agile/Scrum būtų ne tik „kitas projektų valdymo procesas”, bet duotų pagerėjimą matuojamą kartais, svarbu suprasti, jog Agile/Scrum reikalauja ne tik naujo proceso. Kur kas svarbiau yra tai, jog Agile/Scrum reikalauja kompanijos kultūros pokyčio.


Tradicinė kompanijos kultūra


Kompanijos kultūra – visos nerašytos taisyklės, kurių vadovaujasi ir prie kurių yra įpratę kompanijos darbuotojai. Pavyzdžiui, kompanijose su tradiciniais projektų vadovais, architektais ir/ar techniniais lyderiais, programuotojai yra įpratę, jog jie skirsto užduotis, sprendžia kurią užduotį kada daryti, sprendžia dėl techninių dizainų ir pan. „Eiliniams programuotojams” tiesiog reikia kuo greičiau įvykdyti paskirtas mažas užduotis. Taigi iš esmės kompanijos kultūra lemia, jog programuotojai/testuotojai yra vykdytojai be didesnės atsakomybės, o tuo pačiu ir atskaitomybės (na aišku neskaitant užduoties atlikimo termino).


Agile kultūra


Agile ir Scrum reikalauja komandos savi-organizacijos ir atsakomybės prisiėmimo. Taigi vadovams reikia pradėti pasitikėti, jog komandos pačios priims teisingus sprendimus, jog prisiimtas atsakomybes jie įvykdys pažadėtu laiku ir be mikro kontrolės ir priežiūros. Vadovo (projektų vadovo) užduotis lieka tik aiškiai suformuluoti verslo reikalavimus, kad komanda aiškiai žinotų ką daryti. Visa tai yra didžiulis iššūkis kompanijai ir jos vadovams.


Projektų vadovų kontrolė


Aš mačiau dvi kryptis kurias, mano nuomone, neteisingai pasirenka projektų vadovai pradėjus diegti Agile procesus. Vieni, oficialiai deklaruoja, jog naudoja Scrum, bet iš tikrųjų naudoja tik tas veiklas kurios yra „naudingos” jiems. Pavyzdžiui, sprintus, kad planuoti darbus kas pora savaičių (juk vadovams reikia pateikti planus) arba kasdienius Scrum susirinkimus, kurie tampa „kasdiene ataskaita projektų vadovui”. Kiti, fokusuojasi į Agile pritaikytų įrankių naudojimą, nes „jie nubrėžia labai gražias deginimo kreives”. Jose turėtų matytis aiškus projekto statusas, bet turbūt dažniausiai yra matomas „norimas” projekto statusas. Iš esmės, abiem variantas projektų vadovai nepaleidžia kontrolės iš savo rankų. O dažniausiai pasitaikantis pasiteisinimas yra: „žmonės nesugebės patys planuoti”, arba „jei neprižiūrėsim kas dieną, tai jie iš viso nedirbs”.


Siūlymas


Deja, su tokiu požiūriu daug naudos iš Agile/Scrum labai sunku tikėtis. Mano siūlymas tokiais atvejais yra paprastas: pabandykit vieną (galbūt du) sprintus pažaisti pagal tikras Scrum taisykles. Jei neveiks, grįšit prie kontrolės, daug juk neprarasit. Jei veiks, gausit daug naudos ir galėsit tęsti. O tos taisyklės yra tokios:

  • Rolės: nuspręskite kas pas jus yra Scrum meistras, o kas Produkto šeimininkas. Mano siūlymas tradicinėje situacijoje yra pradėti nuo to, jog projektų vadovas taptų produkto šeimininku. Scrum meistro rolę tegu prisiima to norintis komandos narys, arba nuspręskite jog šią rolę rotuosite kas sprintą. Pradžioje tai tikrai veikia, kol komanda nesuranda kuris žmogus labiausiai mėgsta atlikti papildomas Scrum meistro rolės funkcijas prie savo kasdieninio darbo.

  • Sprinto planavimas: susirinkite visi (visa komanda įskaitant analitiką, testuotoją, programuotoją) ir susiplanuokite sprintą kartu. Suskaidykite funkcionalumą į detalias užduotis (4-16 val. trukmės). Kai žmonės patys jas planuojasi, prižada jog jas įvykdys, atsiranda daug didesnė atsakomybė ir atskaitomybė. Atsiminkite, kad Produkto šeimininkas (šiuo atveju buvęs projektų vadovas) negali įtakoti komandos kaip planuotis užduotis.

  • Kasdieniniai Scrum: šie trumpi susirinkimai yra skirti komandai sinchronizuotis darbus. Pradžioje projektų vadovui gal geriau iš viso juose nedalyvauti, kad komanda suprastų, jog tai nėra ataskaitos davimo susirinkimas. Ką prižadėjome padaryti parodyti reikės sprinto gale.

  • Sprinto peržiūra (Sprint Review): sprinto gale būtinai atlikite įgyvendinto funkcionalumo peržiūrą. Leiskit programuotojams pademonstruoti ką jie iš tikrųjų padarė. Tai suteikia pasitikėjimo komandai, jog tai ką jie daro yra svarbu ir kažkam rūpi, išgirsti jūsų nuomonę apie rezultatą.

  • Retrospektyvos: būtinai susėskite su komanda ir padiskutuokite, ką galima padaryti, kad kitas sprintas būtų efektyvesnis. Pati komanda turi sugalvoti kaip sau pasilengvinti gyvenimą. Ir jie tikrai gali tai padaryti!

Be abejo, tokiam kultūros pokyčiui reikia drąsos, pasitikėjimo žmonėmis ir tikėjimo jog savi-organizacija tikrai veikia efektyviau. Be abejo, reikės kalbėti su žmonėmis. Jie nenorės/bijos iš pradžių prisiimti atsakomybę (juk anksčiau niekas to neprašė!). Keli, galbūt tikrai to ir nesugebės padaryti, bet tikrai ne dauguma. Dauguma jūsų kompanijoje yra tie kurie nori dirbti gerai, prisiimti atsakomybę, tik metai iš metų jūs to neleidot jiems daryti, patikėkit!


O grįžtant prie kolegų minčių išsakytų Agile ir Scrum naudotojų grupėje, pradėti Agile/Scrum diegimą, reikia užsidegusio „pionieriaus” ar „driverio”, kuris kultūros pokytį nuolat stumtų į priekį. Kolegos taip pat minėjo jog parduoti komandai/vadovams naują Agile procesą ar motyvuoti komandą jau jį naudojant buvo lengviau ir naudingiau pasikvietus konsultantą. Tiek kompanijos darbuotojai tiek vadovai visada daugiau klauso žmogaus iš išorės, taip pat drąsiau klausia apie galimus iššūkius ir kaip jie sprendžiami kitose kompanijose. Tad nebijokite ieškotis pagalbos, jos tikrai galite surasti ir ji bus labai naudinga. Arba tiesiog prisijunkite prie Agile ir Scrum naudotojų grupės. Ateikige į susitikimus ir diskutuokite savo iššūkius su kitais Agile ir Scrum naudotojais! Kitas susitikimas jau sausio mėnesį. Sekite informaciją.

Tie kurie naudojate Agile/Scrum: ar pasikeitė jūsų kompanijos kultūra? Ar pavyko pamatyti naudą iš komandų savi-organizacijos? Tie kurie dar nenaudojate Agile/Scrum: ar sunku būtų pas jus pakeisti kompanijos kultūrą? Parašykit komentaruose!

Peržiūrų: 17