Tas, kam teko įgyvendinti pokytį ar transformaciją, patvirtins, kad tai nėra pats paprasčiausias dalykas. Kodėl žmonės vengia pokyčių ar jiems priešinasi? Yra keletas priežasčių, kaip antai:
- nežinomybės baimė – baimės ir netikrumo jausmas, kylantis žengiant žingsnį į dar nepažįstamą „teritoriją“,
- kontrolės praradimas – esamų aiškių procesų, struktūrų, darbo būdų sutrikdymas gali sukelti jausmą, kad situacija tampa nevaldoma,
- išėjimas iš komforto zonos prireikus keisti nusistovėjusias normas ir įpročius,
- statuso arba darbo vietos praradimo baimė,
- informacijos, komunikacijos ir aiškumo trūkumas,
- ankstesnė neigiama pokyčių patirtis.
Kai kalbame apie transformacijas, viskas prasideda nuo patirties. Jei žmonės turi blogos ankstesnės patirties, natūralu, kad jie tikrai turės klaidingų įsitikinimų. Klaidingos nuostatos paveikia ir elgesį. Ir savaime suprantama, kad toks elgesys sukels pasekmių. Labai svarbu sutelkti dėmesį į komandos atmosferą, atkreipti dėmesį į tikruosius komandos rezultatus, tikslus ir nuotaiką, su kuria įgyvendinate pokytį. Taigi, jei esate atsakingas už pokyčius / transformacijas, labai svarbu sukurti teigiamą patirtį. Toliau straipsnyje ir bus kalbama apie tai, kaip ją sukurti.
Visų pirma – KODĖL?
Natūralu, kad pradėti reikia nuo planavimo. O ką reiškia planuoti pokyčio kontekste? Visų pirma, labai svarbu pradėti nuo „kodėl“. Nustebtumėte, kaip dažnai, pradėjęs kalbėtis su įmone ir paklausęs „kodėl nutarėte (bandyti) taikyti Agile“?“, arba neišgirsti aiškaus atsakymo, arba geriausiu atveju atsakymas būna susijęs su komandos lygmens poreikiais, arba tai yra kas nors panašaus į „nes dabar daug kas taiko Agile“. Vis dėlto tai yra pati blogiausia priežastis pradėti diegti Agile. Ir ši priežastis labai dažnai yra neigiamos patirties pasekmė. Tai kaipgi išsiaiškinti esminį „kodėl“? Nustebsite, bet tai nėra taip sunku. Dažniausiai atsakymas „kodėl“ organizacijoje yra, tik jis būna pasimetęs tarp kasdieninių iššūkių ir skirtingų organizacijos lygmenų. Svarbu kalbėtis ir klausti tinkamų klausimų tiek kartų, kol rasite tą kertinį „kodėl“.
Antras žingsnis – KAIP?
Kitas žingsnis yra pasirinkti būdą „kaip“. Dažnai metodikos ir įrankiai pasirenkami atsitiktinai, net neklausiant, o kur link norime eiti. Pasitaiko, kad pasirinkimo priežastimi tampa: „nes kas nors šia metodika tiki“, „ apie šiuos įrankius esame daugiau girdėję nei apie kitus“, „nes dabar ši metodika yra populiari“. Toks pasirinkimo būdas taip pat gali sukelti problemų, lemti blogą patirtį. Gali būti ir taip, kad pats įrankis yra labai geras, tiesiog jis naudojamas netinkamoje vietoje. Ir kokia žmonių patirtis kuriama tokioje situacijoje? – „Tai nesąmonė! Kodėl turime daryti tai, kas neveikia?!”
Trečias žingsnis – TIKSLAS
Svarbiausias dalykas, į kurį reikia sutelkti dėmesį, yra tikslas. Idealiu atveju apie jį ir reikia konstruoti visą įmonės strategiją. Žinoma, darbuotojai turės savo asmenines užduotis ir tikslus, tačiau visi jie turėtų mąstyti „kaip aš galiu prisidėti pagrindinio įmonės tikslo?“, o jei atsiranda keletas tikslų, „kuris iš jų labiau prisideda prie pagrindinio galutinio rezultato?“ Toks mąstymas padeda užtikrinti skaidrumą. Norėdami sužinoti, ar visų pastangos sutelktos į pagrindinį organizacijos rezultatą, galite pasitelkti vizualizacijos įrankius. Žinoma, būna situacijų, kai sunku apsispręsti, tačiau tada galime parodyti, kokios yra fokusavimosi arba krypties keitimo pasekmės.
Transformacija – organizacijos ar komandos lygmuo?
Ne viena organizacija teigia atlikusi Agile transformaciją, tačiau pasižiūrėję atidžiau pastebime, kad visas pokytis atliktas komandos lygmeniu: įdiegtas Scrum, Kanban ar kt. ir teigiama, kad „viskas, mes Agile. Iš tiesų, pradėjusi naudoti vieną iš Agile metodų, kiekviena komanda pakeičia darbo būdą, randa vietų, kurias gali tobulinti. Bet tobulėja tik iki tam tikros ribos. Kodėl? Todėl, kad nesikeičiant visai organizacijai ateina riba, už kurios komandos tobulėti nebegali dėl išorinių veiksnių, reikalavimų ir organizacinės aplinkos. Esame susidūrę su tokiais pavyzdžiais:
- 9 žmonių komanda turi 9 vadovus, kurie turi skirtingus tikslus ir kiekvienas iš komandos reikalauja įvykdytų užduočių. Komanda taip pat turi daug papildomų darbų už savo ribų. Galimybės susitelkti, eksperimentuoti, tobulėti ir laiko „būti Agile“ nebelieka.
- Nors ir įgyvendinama Agile transformacija, biudžetas skiriamas ir ataskaitos teikiamos senuoju būdu, taigi komanda iš anksto turi suplanuoti darbus, pateikti aiškią projekto išleidimo datą ir biudžetą, kurie nesikeis. Kad būtų lengviau įsivaizduoti: projekto apimtis – maždaug metai. Ir kartu iš komandos reikalaujama būti Agile.
- Iš komandos reikalaujama, kad ji į produkciją paleistų kiekvieną dieną, nes juk, pavyzdžiui, „Amazon“ paleidžia į produkciją kas 11,6 sekundės. Tačiau dėl skaitmeninės sistemos architektūros, naudojamų įrankių, inžinerinių praktikų ar net logikos tai yra neįmanoma.
Agile nėra vien tik atskiri susitikimai, įrankiai ar praktikos. Tai yra kur kas kompleksiškiau, todėl įgyvendindami Agile transformaciją turite pagalvoti ir įvertinti daugybę dalykų. Jei įmonės pradės perorganizuoti komandas ir jų darbo būdą, bet likusi organizacija laikysis senos tvarkos, komandos pasieks savo maksimalų galimą rezultatą esamomis aplinkybėmis ir sustos. Kas tada vyksta su komandomis? O tada atsiranda demotyvacija, nes galimybės tobulėti ir didinti efektyvumą toliau nebėra dėl išorinių komandos apribojimų. Jei nenorime grįžti prie senųjų veiklos būdų, labai svarbu lygiagrečiai galvoti apie tuos kitus dalykus ir investuoti į žmones. Agile turėtų ateiti su besikeičiančia organizacijos kultūra ir mąstymu. Vykstant transformacijoms naują teigiamą patirtį jums padės kurti:
- keičiamas veiklos modelis,
- keičiama organizacijos struktūra,
- investavimas į žmones (mokymai, koučingas, mentorystė ir t. t.),
- keičiamos inžinerinės praktikos,
- tinkama, aiški komunikacija.
- kita.
Vadovavimas pokyčio kontekste
Yra sakoma, kad „kultūra valgo strategiją pusryčiams“, todėl įgyvendinant pokyčius svarbu sukurti naują vadovavimo patirtį. Kas kartais atsitinka? Iš mokymų vadovai grįžta motyvuoti, užsidegę būti „visai kitokie“ vadovai, pasirengę įgalinti žmones ir t. t. Ir kas tada nutinka? Praleidžiama svarbi dalis, kad komanda gali būti nepasirengusi perimti tą įgalinimą ir atsakomybę. O galbūt tai net ne komanda, o tiesiog grupė žmonių. Tokioje situacijoje staiga ir netikėtai grupė žmonių, gavusi užduotį priimti svarbų sprendimą, arba pradeda priešintis, arba kovoti tarpusavyje, arba tiesiog nutyla. Viskas baigiasi tuo, kad žmonės grįžta pas vadovą ir perleidžia sprendimo priėmimą jam. Kaip reaguoja vadovas? – „Mokymai buvo geri. Bet pas mus tai neveikia. Juk sakiau...“ Nors vadovai turi keistis, reikia nepamiršti, kad kitoje pusėje visada yra komanda. Svarbu suprasti, kad ji taip pat turi mokėti ir būti pasirengusi būti įgalinta ir prisiimti atsakomybę. Komandai taip pat reikia padėti išmokti tapti komanda. Priešingu atveju gali būti geriausias Scrum, bet jis neveiks.
Supraskite reiškinių ryšius
Dar viena išmoktų transformacijų pamokų: įgyvendinant pokyčius reikia suprasti reiškinių ryšius ir jų pasekmes. Ir tai yra tiesiogiai susiję su lyderio atsakomybe už transformaciją. Galite nusisamdyti geriausius konsultantus, išorinius gile trenerius ir liepti atlikti transformaciją. Tačiau nuėję pas organizacijos vadovus, kurie nėra įsitraukę, netiki pokyčiu ar neskiria tam laiko, jie dažniausiai sulaukia atsakymų: „šiuo metu mūsų prioritetai kiti“, „dabar neturime laiko šitiems jūsų Agile dalykams“, „galime skirti laiko vėliau, bet gal kokią vieną valandą per savaitę“ ir t. t. Paprašius ataskaitų apie transformacijos pažangą, nė vienas iš tų vadovų nepasirodo. Agile konsultantai savo ruožtu praneša, kaip transformacija (ne)vyksta. Bet juk vadovai neatsako už ją. Ir kas tada? Tada Agile diegimas pradeda trukdyti darbui. Ši situacija aiškiai parodo, kad vadovai turi būti tiesiogiai įtraukti ir jaustis atsakingi už pokyčio sėkmę. Kitu atveju vadovų elgesys ir reikalavimai užkerta kelią komandoms priimti pokyčius ir pokyčiai sustoja, prasideda atidėliojimas ir randama pretekstų, kodėl „ne dabar“. Jei jau nusprendžiame, kad norime pakeisti savo darbo būdą, svarbu suprasti, ko nebedarysime, kad nustotume pradėti ir pradėtume baigti. Toks sprendimas visada yra labai sunkus komandai, kuri patiria daugiausiai spaudimo, kai reikia sutelkti dėmesį ir nedaryti kelių darbų vienu metu. Su komanda reikia tinkamai tokią poziciją aptarti, o suinteresuotoms grupėms parodyti, ką tai iš tikrųjų reiškia.
Žinokite, ką matuojate
Jūs turite žinoti, ką matuojate. Dažniausiai visi nesutarimai dėl naujo darbo būdo kyla dėl nesaugumo. Jei nusprendžiate, kad bus vertinamas galutinis rezultatas, nustokite vertinti asmeninį ar vieno skyriaus rezultatą. Tokia situacija sukuria nesaugumo jausmą ir žmonės stengiasi parodyti asmeninį efektyvumą, o ne kurti galutinį bendrą rezultatą. Taigi labai svarbu nustoti matuoti netinkamoje vietoje.
Nepamirškite žmogiškojo faktoriaus
Agile tikima, kad žmonės gali viską išspręsti, jei bus draugiški, nuoširdūs, atvirai bendraus, pasitikės... Bet konfliktų vis tiek kyla. Ir niekas nežino, kas gali tai išspręsti. Žmonės daro klaidų, kyla nesutarimų, vyksta trintis, lieka nuoskaudų, kurios ilgainiui gali nuodyti komandos atmosferą ir tuomet vis tiek reikia žinoti, į ką kreiptis, norint išspręsti problemą. Taigi jūs turite labai aiškiai nustatyti problemų eskalavimo eigą, kad darbuotojai žinotų, kur kreiptis, jei negali išspręsti problemos patys, ir kas yra pagrindinis sprendimų priėmėjas, jei nesutarimas užtrunka.
Nėra vieno stebuklingo recepto
Pardavus įmonei pokyčio idėją, jums kaip vadovui ir idėjos autoriui labai norisi, kad pasisektų. Tai natūralu. Bet kas tada gali nutikti? Pasitaiko situacijų, kai užsidedami rožiniai akiniai ir teigiama, kad viskas yra gerai net tada, kai viskas sparčiai ritasi žemyn. Įgyvendinant pokytį svarbu suprasti, kad kartais eksperimentai nepavyksta. Vienoje vietoje modelis gali veikti, o kitoje jis visiškai nepasiteisina. Svarbu įvertinti daromus eksperimentus, atsirinkti ir išplėsti taikymą tik tų, kurie buvo sėkmingi ir pasiteisina konkrečioje jūsų situacijoje. Jei vis dėlto pastebėsite nepasisekusį, nebijokite keistis. Kartais išgirstame „su ta komanda kažkas ne taip“. Galbūt su jais viskas gerai, tiesiog ši komand pasirinktas būdas / metodas / įrankis netinka. Svarbu nebandyti vieno sprendimo priverstinai diegti visur, nes „tai veikė ten, ir čia turi veikti „pagal knygą“. Kartais pradėję Agile transformaciją patys sustabarėjame, o komanda jaučiasi nusivylusi ir nuleidžia rankas. Geriau tiesiog pakeiskite kryptį, paieškokite kito kelio ir pradėkite naują eksperimentą.
Apibendrinimas
Apibendrindami šiame straipsnyje aptartas patirtis galime teigti, kad transformacija yra imituojama, jei:
- Pradedame transformaciją vien todėl, kad „dabar Agile yra madingas žodis“ arba „kiti tai daro, padarykime ir mes“. Seniau transformacijos dažnai būdavo Agile vs Waterfall, paskui SAFe® vs LeSS ir pan. Vis dar egzistuoja „madinga – nemadinga“, „šaunu – nešaunu“, „kieta – nekieta“. Labai svarbu suprasti, kodėl tai darote, ir pagal tai matuoti pažangą.
- Neturite tikslo arba nematuojate rezultatų. Jei nežinote, ką matuojate – pagrindinį tikslą, kurį norite pasiekti, – yra blogai. Tada jūs nežinosite, kaip jį pasiekti, kokio darbuotojų įsitraukimo ir įsipareigojimo reikia. Ir jei žmonės nesupranta, kokio lygio įsipareigojimas turėtų būti, kaip jie gali patvirtinti savo ketinimus prisiimti atsakomybę įgyvendinant pokytį.
- Transformacija vyksta tik komandos lygmeniu. Norint įgyvendinti tikrą pokytį, reikia pakeisti kultūrą ir pristatyti Agile ne tik komandos, bet ir organizacijos lygmeniu. Agile gali būti įrankių rinkinys projektams valdyti komandos lygmeniu, bet tuomet nevadinkime to įmonės Agile transformacija. Tai sukelia klaidingus lūkesčius.
Be to, kas jau buvo aptarta, baigdami norime pasidalinti keletu praktinių Agile diegimo organizacijos mastu pastebėjimų:
- Mokėkite pamatuoti sėkmę.
- Darykite eksperimentus, mokykitės iš jų, vertinkite jų sėkmę ir plėskite tuos, kurie buvo sėkmingi. Ieškokite naujų būdų, keiskitės, jei matote, kad eksperimentas nepavyko.
- Parduokite savo idėjas visiems: nuo vadovų iki komandų.
- Supraskite, kad Agile nėra vaistas nuo visų ligų ir negali išspęsti asmeninių problemų, kartais nesprendžia santykių problemų, struktūros problemų ir t. t. Vien įrankių turėjimas savaime problemų nesprendžia, jei jos nėra sprendžiamos iš esmės.
- Padėkite komandoms išmokti būti komandomis. Mokymasis ir įgūdžių tobulinimas padeda išvengti klaidų ir nemalonios patirties.
- Dirbkite su žmonėmis, kurie tai jau patyrė ir tą darė anksčiau. Turėdami praktinės patirties, tokie žmonės gali anksčiau atpažinti pavojaus signalus, jus įspėti, suteikti paramą ir diskutuoti įvairiose situacijose.
Visą Alionos (Viršutienės) Sosunovos pristatymą, pagal kurį parengtas straipsnis, galite pamatyti čia: „Agile transformation: how business fake it and what it needs to make it“. Jei kyla klausimų dėl Jūsų organizacijos pokyčių diegimo, pasikalbėkime. Su mumis galite susisiekti el. paštu info@agilecoach.lt arba tel. +37061703001.