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!

Tagged with: , , , ,
Posted in Agile, Komanda, Scrum
2 comments on “Agile/Scrum reikalauja kompanijos kultūros pokyčio
  1. Aleksej says:

    Geri ir teisingi pastebėjimai, kad Agile metodikos ir praktikos veikia geriausiai, kuomet atitinkamai paderinti organizaciniai procesai, atsakomybės bei autonomijos perdavimas.

    Tačiau tema išvystyta nepilnai ir kažkaip vienšališkai. Dominuoja labai jau klasikinis užvažiavimas ant blogio ir neefektyvumo įsikūinijimo – vadovų, kurie neva laiko talengintus ir gabius programuotojus / testuotojus marionetėmis, tuo metu, kai anie tik ir laukia nesulaukia išvadavimo. Rebellion vs Dark Side. Kažkaip ši karta į Dark Side papuolė netgi techniniai ekspertai – architektai su tech. leadais.

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

    Deja, šitas pokytis yra ne vien tik vadovų pasitikėjimo ar delegavimo komandoms klausimas. Patikrinta – minos yra.

    “Klasikiniai” projektų vadovai daugumoje nėra analitikai ir sugeba formuluoti tik labai aukšo lygio verslo reikalavimus arba deklamuoti funkcinę specifikaciją (kas toli gražu nėra backlog). O tokiais atvejais savarankiškos Scrum komandos ima skustis kad viskas neaišku, kad nepakankama analizė, etc.

    Taipogi “klasikinių” progamuotojų geriausi draugai – “klasikiniai” analitikai, mokantys pateikti verslo informaciją, būna sunkiai prisiima decision maker rolę (o to reikia PO). Geri analitikai – kruopštūs ekspertai, kurie kaip tik mėgsta gauti konkrečią užduotį tolesniam giliam ir visapusiškam nagrinėjimui. O čia prasideda – įtrauk klientą, pamatyk verslo prioritetus, tikslai >> reikalavimai…

    Saviorganizuojančių komandų efektyvumas verslui yra atskiras klausimas. Taip, be abėjo saviorganizuojančios, KOMPETETINGOS ir SUSIDIRBUSIOS komandos yra LABIAUSIAI EFEKTYVIOS. Tačiau saviorganizuotumas negali būti tikslu, o tik priemonė efektyvumui ar rezultatui pasiekti. Tam, kad naudotis laisve efektyviai Rebellion dvasios neužtenka, reikia žinių, savi-disciplinos ir vidinės atsakomybės. Šis iššūkis jau nebe vadovų, o jį vertinčiau svarbiausiu.

    O dėl idejos pardavimo – pionieriai, pilotai, konsultantai ir evangelikai labai padeda. Taip pat labai (o gal labiau?) padeda dar vienas akcentas – nauda verslui, nauda kompanijai. Kompanijos yra žmonių sistemos, kurios kūriamos tam tikrų tikslų įgyvendinimui. Deja, Scrum adaptacija, komandų saviorganizacija ar padidinta programuotojų atsakomybė – nėra kompanijos tikslai. Galvokite, ko reikia vadovams, sverkite rizikas visapusiškai, papildykite savo užsidegimą, vystant Agile organizacijoje, kažkuo ekonomiškai naudingu. Sėkmės!

  2. Dėkui Aleksej už komentarą kuris labai taikliai papildo straipsnį. Ypac paskutinis akcentas del naudos kompanijai/verslui! Bet koks procesas yra tik priemone siekti naudos komanijai/verslui. Jei galvojat diegti Scrum vien del to kad tai dabar madinga… manyciau tikrai neverta pradeti.

    Tikrai nenorėjau vadovų pavadinti “Dark side”. Mano nuomone Agile vadovams labiausiai tinka tėvo metaforai kurią jau minėjau straipsnyje apie Scrum Master: http://scrum.blogas.lt/scrum-3-scrum-meistras-komandos-lyderis-ir-mokytojas-295.html. Taip, kai komanda tik buriasi, kai tik pradeda naudoti Scrum jie bus maziau saviorganizuojantys, kaip mazi vaikai. Laikui begant komandos brandumas/kompetencija/susidirbimas augs. Norėjosi akcentuoti, jog reikia pasitiketi komanda ir po truputi duoti jai daugiau atsakomybiu. Kartais net leisti suklysti, kad patys galetu is savo klaidu pasimokyti. Ir visa tai tam, kad neuzauginti “mamyciuku” , t.y. kai “gerieji teveliai” aka projektu vadovai sukramto uzduotis, isanalizuoja, sudelioja ant lekstutes ir komandoms paduoda tik igyvendinti. 🙂 Susidirbusios komandos turetu kuo toliau tuo labiau pacios analizuoti, skaidyti, kurti dizainus, juos igyvendinti ir atasakyti uz kuriama produkta.

    Taigi pilnai pritariu, jog saviorganizacija yra priemone, tikrai ne tikslas. Taigi perfomuojant klausimą komantarams: įdomu kiek Lietuvoja žmonių mano jog ši priemonė yra veiksminga pasiekti kompanijos/verslo naudos?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Artimiausi mokymai
Data Mokymai - Lektorius
2017 m. spalio 2-3 d. Certified Scrum Master (CSM) - Tomas Björkholm (EN)
2017 m. spalio 3-4 d. Management 3.0 Change and Innovation Practices - Ralph van Roosmalen (EN)
2017 m. spalio 3-4 d. Certified Agile Leadership CAL1 - Angel Diaz-Maroto (EN)
2017 m. spalio 9 d. Reikalavimų valdymas Agile projektuose - Vaidas Adomauskas (LT)
2017 m. spalio 10 d. Agile projektų valdymo pagrindai - Vaidas Adomauskas (LT)
2017 m. spalio 11 d. Better Retrospectives - Jeff Campbell (EN)
2017 m. spalio 10-11 d. Kanban System Design (KMP I) - Gaetano Mazzanti (EN)
2017 m. spalio 10-11 d. Certified Scrum Product Owner (CSPO) - Lasse Ziegler (EN)
2017 m. spalio 10-11 d. ICAgile sertifikuotas profesionalas (ICP) - Vaidas Adomauskas (LT)
Visi mokymai
Archives
Categories
Kontaktai

Viešos mokymų klasės:
E-paštas: mokymai (at) agilecoach.lt
Mob. tel.: 8 686 32487

Konsultacijos ir mokymai įmonėms:
E-paštas: vaidas (at) agilecoach.lt
Mob. tel.: 8 686 32487