Paskutiniajame Agile ir Scrum naudotojų grupės susitikime dar kartą iškilo diskusija apie skirtumus tarp stabilių komandų, kurioms pateikiami skirtingi projektai ir atvirkščio varianto, kai kiekvienam projektui surenkama nauja komanda. Antrasis variantas yra daug įprastesnis Lietuvos įmonėms, tačiau Agile metodologija linksta prie pirmojo. Taigi pasigilinkime į skirtumus.
Valdymo paprastumas
Diegiant Scrum Adform‘e mes be ilgų diskusijų pasirinkome pirmąjį variantą: sukurti stabilias komandas ir projektus padavinėti joms pagal dengiamą sistemos sritį. Kiek pamenu tikrai ilgai dėl šito nediskutavome. Gal dėl to, jog aš jau buvau tokį modelį išbandęs diegiant Scrum Lavasoft‘e, o gal tiesiog dėl to, jog taip siūlo visa Agile literatūra, o mes tikrai norėjome tikro Scrum!
Taigi kas iš to išėjo? Ogi labai supaprastėjo žmonių (o jeigu jūs esate tradicinio metodo šalininkas tai skaitykite „resursų“, bet prašau, NIEKADA šito žodžio netarkite garsiai kai kalbate apie žmones) valdymas. Prieš tai projektų vadovams reikėjo sekti kiek kiekvienas žmogus užimtas, ką šiuo metu dirba, kada atsilaisvins kitam projektui ir pan. Subūrus stabilias komandas pamatėme, jog tai buvo didžiulis laiko (t.y. pinigų) švaistymas.
Dabar produkto šeimininkas planuoja darbus komandai, pagalvoja kuriai komandai (ar kelioms komandoms) šis projektas tinkamiausias skirti, rūpinasi jog komandai visada būtų paruoštų aiškių darbų produkto užduočių sąraše ir viskas. Pati komanda pasiskirsto kas konkrečiai kurią užduotį vykdys, kaip susidėlioti užduotis, kad visi komandos nariai (analitikai, programuotojai, testuotojai) turėtų veiklos ir kad darbų kiekis žmogui tolygiai pasiskirstytų sprinte. Taigi žmonių valdymas labai supaprastėjo ir taupo daug bereikalingai švaistyto laiko (ir pinigų).
Komandinis darbas – sinergija
Daug vadovėlių ir straipsnių prirašyta jog efektyviausiai užduotis vykdo komandos. Jog suburti gerą komandą užtrunka laiko, kad komanda efektyviai dirbtų reikia susidirbti, pažinti vienas kitą. Daug kalbama apie komandos formavimo (team building) svarbą. Kai komanda susižaidžia, pasiekiame efektyvumą, taip vadinamą sinergiją, kai formulė 1+1=3 tampa teisinga. Tą aš puikiai galėjau stebėti tiek Lavasoft‘e tiek Adform‘e.
O kas nutinka kai kiekvienam projektui surenkame naujus žmones? Turime žmonių GRUPĘ, kurią kažkodėl drįstame vadinti komanda. Mes apsimetame, kad tai kas įrodyta moksliniais ir empiriniais tyrimais apie komandos formavimosi laiką, apie sinergiją ir efektyvumą, pasiekiamą tik po kurio laiko yra netiesa. Dar blogiau, naujai suburta žmonių grupė dirbs MAŽIAU efektyviai nei atskiri žmonės (1+1=1,5), nes vieni kitų nepažįsta, bando išsiaiškinti kaip tarpusavyje bendrauti ir pan.
Nieko gero nebus jei mes kiekvienos projekto stadijos metu keičiame žmones „projekto komandoje“. Nes jei keli pagrindiniai žmonės jau yra susidirbę, pridėjus ar atėmus vieną, visas komandos formavimosi procesas prasideda iš naujo. Taigi vien išlaikant žmones stabiliose komandose ir nieko daugiau nedarydami mes galime pasiekti du kartus didesnį efektyvumą(nuo 1,5 iki 3, žr. formules aukščiau)! Neblogai ane?! Ir galiu patvirtinti savo patirtimi, jog toks efektyvumo padidėjimas iš tikrųjų įvyksta.
Bendras tikslo siekimas
Komandų tema naudotojų grupėje iškilo diskutuojant kaip komandoms padėti pasidalinti skirtingų rolių darbus sprinto metu. Pvz. ką testuotojui ir programuotojui veikti pirmas sprinto dienas, o analitikui ir testuotojui sprinto gale? Kaip motyvuoti žmones „dengti“ skirtingas roles, nes visiems aišku, jog kitaip neįmanoma tarp-funkcinėje komandoje?
Nekintanti komanda čia vėl labai padeda. Sprinto darbai yra visos komandos įsipareigojimas ir pažadas. Jie turi bendrą tikslą – sėkmingai baigti sprintą. Komandos nariai labai greitai supranta, jog kaltinti atskirų žmonių (rolių), kai sprinto peržiūra (Sprint Review) nepraeina sėkmingai, neverta. Visa komanda turi per retrospektyvas surasti būdus pasiekti rezultatą: sukurti pilnai pabaigtą produkto prieaugį tenkinantį kliento (ar produkto šeimininko) poreikius. Komanda pati turi išmokti sprinto užduotis išsidėlioti taip, kad visi turėtų darbo. O kai reikia, vieni kitiems padėti. Tik taip įmanoma pasiekti bendro tikslo!
O kas vyksta jei komanda nėra stabili ir kiekvienas žino kad po kelių savaičių jis keliaus į kitą projektą ir testuotojo (tarkim Petro) daugiau nematys. Kodėl man, programuotojui, reikia padėti jam, testuotojui Petrui, testuoti? Aš juk daug greičiau rašau kodą! Taigi neturint tikros komandos, nėra ir bendro tikslo. Neturint bendro tikslo, nėra motyvacijos padėti kitų rolių atstovams ir visa sprintų idėja praranda daug prasmės.
Tuo tarpu stabilioje komandoje mes tokių problemų neturime. Komandos pačios yra motyvuotos padėti kolegoms ir ieško būdų ir patarimų (pvz. diskusijose naudotojų grupėje, konferencijose, tinklaraščiuose) kaip to pasiekti. O tai pasiekus, gauname dar didesnį efektyvumą, kuris nuo 1,5 jau kyla iki 4! (žr. formules aukščiau)!
Darbuotojų karjera
Be abejo, jūs paklausite, o kaip su žmonių karjera, noru dirbti prie skirtingų projektų, sričių, technologijų. Taip, šį žmonių norą reikia gerbti ir juo rūpintis (jei tik norite išlaikyti darbuotojus). Tačiau prisiminkime, komandai padavinėjame skirtingus projektus. Taigi komandos nariai turi galimybę tobulėti ir augti, juolab kad jiems bus privaloma ir žinoti kolegų roles ir jų pasimokyti.
Tačiau kai žmogus nori keisti komandą, dirbti visiškai prie kitos srities, be abejo tai reikia leisti (ir netgi skatinti). Tačiau tokie žmonių perėjimai bus tikrai ne dažni, susiję su metiniais pokalbiais ir karjeros planavimu. Dėl to visos mintys išsakytos aukščiau tikrai lieka teisingos.
O kaip vyksta pas jus įmonėje? Ar priskiriate projektus komandoms ar žmones į projektus? Gal turite daugiau minčių/pastebėjimų kodėl/kada vienas ar kitas variantas veikia geriau/efektyviau?