Agile kelionė arba 6 sesijos produkto vystymo komandai pagal tikrą „SEB Global Services“ istoriją

Atnaujinta: prieš 6 dienas

Įsivaizduokite situaciją: esate vadovas, skrendate lėktuvu ir nerimaujate. Žinote, kad Agile yra puikus kelias, jūsų įmonė ir komanda palaiko jus. Visa komanda ką tik dalyvavo intensyvioje Agile stovykloje. Turite keturias komandas, bet dėl vienos iš jų jums vis tiek neramu. Kodėl taip jaučiatės? Na, vienas produkto šeimininkas kažkodėl nepatenkintas, kūrimo komanda nusivylusi, susierzinusi. Jaučiate, kad kažkas yra negerai. Lėktuvui nusileidus, turite priimti sprendimą. Galų gale, tai Agile problema. Taigi, jei tai Agile problema, gal verta šešioms savaitėms pasamdyti išorinius Agile konsultantus (angl. Agile coach) ir pažiūrėti, ką jie gali rasti, o galbūt net išspręsti.

Šiandien su jumis pasidalinsiu pirmosiomis keturiomis šio iššūkio, kurį priėmiau, savaitėmis. Tikiuosi, mano pasakojimas suteiks jums idėjų šešioms sesijoms, atskleis, kaip jos susijusios tarpusavyje ir kaip gali sukurti pagrindą jūsų komandos ėjimui į priekį.




Kontekstas




Atvejis susijęs su „SEB Global Services“ – viena iš kelių naudojamų CRM sistemų. Tai nėra naujas projektas. Iki man prisijungiant, jis jau buvo vystomas dvejus metus. CRM sistema irgi nebuvo kuo nors labai ypatinga. Komandą sudaro 12 žmonių – verslo padalinių Stokholme darbuotojai ir kūrimo komanda Vilniuje. Jie naudojo Scrum ir TFS įrankį produkto darbų sąrašui valdyti. Iteracijos truko 1 mėnesį. Šiuo atveju tai gerai, nes kiekvienos iteracijos pabaigoje komanda turėdavo įdiegti parengtą produkto prieaugį.

Žvelgiant iš šono, viskas atrodo gana gražiai. Agile stovykla buvo tikrai puiki. Produkto šeimininkas surenka ir pateikia klientų atsiliepimus, visi Scrum vaidmenys yra atlikti, žmonės kompetentingi atlikti savo darbą, produkto darbų sąrašas geras, iteracijos ir visa kita taip pat atrodė gražiai. Tiesą pasakius, jų turima autonomija maloniai nustebino. Kodėl jiems vis dėlto reikia samdytis išorinį Agile konsultantą?

Šiuo atveju buvo tikimasi, kad išorinis Agile konsultantas pateiks nešališką požiūrį į situaciją. Labai daug visko vyko ir įsigilinti į visa tai buvo gana sudėtinga. Taip pat buvo tikimasi išorinių praktikų – to, kas veikia kitur. Vadovas, turėjęs priimti sprendimą, ir taip turėjo daug atsakomybių ir darbų, todėl niekaip negalėjo sutelkti dėmesio tik į vieną komandą ir pats išspręsti šią situaciją.


Kelionė


Prisijungus prie naujos komandos ir pradėjus su ja dirbti, tikrai siūlau apsvarstyti galutinį tikslą. Būdamas Agile konsultantas žinote, kad keisite darbo būdą (angl. way of work). Kaip manote, kaip į tai reaguos žmonės, su kuriais dirbsite? Pasipriešinimas – tikriausiai vienas iš žodžių, kurie pirmiausia ateina jums į galvą. Iš tikrųjų gerai yra tai, kad „pasipriešinimas pokyčiams neegzistuoja – egzistuoja protinga reakcija į kvailus metodus“ (Nielsas Pflaegingas) ir į žmones, kurie, tiksliai nežinodami konteksto, ima daryti beprotiškus dalykus ir pan.

Nenorėjau daryti tų beprotiškų dalykų, todėl pradėjau nuo asmeninių (1:1) susitikimų su beveik visais dalyviais. Negaliu neigti, tai užtruko. Bet tikrai džiaugiausi taip pasielgęs. Susitikimuose stengiausi ne mokyti ar duoti konkrečius nurodymus. Jų tikslas buvo išklausyti ir išgirsti. Norėjau įsiklausyti, kas trukdo žmonėms, ir, žinoma, atsakyti į jų klausimus. Juk komandoje esate naujokas, todėl turite kaip nors prisistatyti. Taigi kalbėdami viską vizualizavome ir daug dirbome su piešimo lenta. Vienas pokalbis trukdavo nuo 1 iki 2 valandų. Nors vizualizavimas atrodė netvarkingas, vis dėlto jis leido mums įsigilinti ir išvengti vaikščiojimo ratais. Džiaugiuosi gana greitai priėjęs prie pirmosios išvados: apie Agile jie žinojo daug, todėl visai nereikėjo mokyti teorijos ar pagrindų. Dabar galiu tik įsivaizduoti, kaip būtų atrodę juokingai, jei per asmeninius susitikimus pradėčiau juos mokyti Agile.


1 sesija. Sprinto ilgis (angl. sprint length)




Per pirmąją sesiją „Sprinto ilgis“ pradėjome mesti iššūkį apribojimams. Su naujomis komandomis darau tai dažnai. Tikslas – mesti iššūkį sprinto trukmei, nesvarbu, kokia ji yra. Taigi dažniausiai užduodu klausimą „Kas trukdo sprinto trukmę sumažinti perpus?“ Ir tai itin įdomus klausimas, nes žmonės ima įsivaizduoti ir svarstyti visokius beprotiškus dalykus, kurie neveiks. Jie pateikia visus tuos dalykus lentoje ir šiek tiek juos aptariame. Nesiekiame išspręsti ko nors konkretaus. Šiuo atveju tikslas – nustatyti dalykus, kurių negalėsite pakeisti.


2 sesija. Darbo procesas (angl. way of work arba WoW)


Kitas dalykas, kurį padarėme, – pradėjome vizualizuoti darbą. Tai įprasta praktika norint suprasti, kaip juda elementai. Norėdami išvengti dominavimo (kai pora ar keli aktyvesni dalyviai savo nuomonėmis užgožia visos komandos diskusiją), pasidalijome į dvi komandas ir pabandėme tiksliai nupiešti, kaip ankstyvos stadijos elementas (pvz., idėja) juda per visus etapus, kol patenka į gamybą. Tada sutelkėme dėmesį į tai, kokie yra komandos susitikimai ar kitos Scrum ceremonijos. Siekėme išvengti klausimo, kas už ką atsakingas. Šis klausimas dažniausiai išprovokuoja vienas kito kaltinimus ir neduoda nieko gero.

Keletą kartų pakartojome šią procedūrą ir komandos pateikė savo matymą, kaip atliekamas darbas. Komandos pristatė tai viena kitai, o paskui vyko gera diskusija. Šios užduoties tikslas buvo padaryti tam tikras išvadas ir tęsti vizualizaciją. Taigi išvados buvo tokios:

· Darbo būdas yra gana standartinis ir niekuo neišsiskiriantis.

· Iššūkiai, su kuriais susidūrė komandos, taip pat buvo gana įprastiniai.

· Neaiškus „àtlikta“ apibrėžimas (nebuvo visiškai aišku, ką iš tiesų reiškia „atliktas darbas“). Ką reiškia būti viename ar kitame užduoties atlikimo etape?

· Kartais komanda painiojo traukimo ir stūmimo (angl. pull and push) taikymo atvejus. Dėl to, pavyzdžiui, analizės etape kaupėsi daugybė elementų, nes į analizę jie buvo įstumiami, o ne įtraukiami.

Taigi pradėjome dirbti su vizualizacijų lenta. Šią praktiką renkuosi dažniausiai, nes kiekvienas tai gali lengvai suprasti ir nėra sunku sukurti. Pradėjome piešti remdamiesi ankstesnės sesijos išvadomis. Paskui dar šiek tiek piešėme, kol pagaliau buvome patenkinti. Sukūrėme visą proceso srautą nuo idėjos iki gamybos. Scrum – tik dalis viso proceso. Dar kartą peržiūrėjome elementus, kad įsitikintume, ar yra tikrai taip ir ar taip veikia.


3 sesija. Apibrėžimas, kas yra „àtlikta“ (angl. definition of ready)



Prieš dedant visus elementus ant lentos, reikia susitarti dėl vieno dalyko – ką reiškia būti tam tikrame etape? (Pavyzdžiui, ką reiškia „parengtas kurti“? Ar reikia turėti priėmimo kriterijus? Ar reikia maketų? Ar užtenka aprašytos vartotojo istorijos?)

Ši sesija buvo labai įdomi ne todėl, kad dėl ko nors susitarėme. Turėjome tikslą pradėti kalbėti apie tai, kokie iš tikrųjų yra lūkesčiai (pavyzdžiui, „Ko aš, kaip kūrėjas, tikiuosi iš verslo analitiko?“, „Ko aš, kaip verslo analitikas, tikiuosi iš produkto šeimininko?“).