Agile transformácia očami vývojára (#2)

Lukáš je developer a Agile transformáciou si prešiel v dvoch rôznych firmách. Z prvej odišiel kvôli situácií po transformácií a v druhej naopak zostal a s novou organizáciou práce je spokojný. Ako vnímal transformáciu zo svojho pohľadu? Čo v danej situácií odporúčajú robiť Dušan Kocúrek a Roman Pieron, mentori zo ScrumDesku?

Scrum prvýkrát: frustrácia a odchod

L: „Pred pár rokmi som pracoval vo firme, kde chceli zaviesť Scrum. Celú organizáciu iniciálne nastavil konzultant a pomohol nám aj s rozvrhnutím do tímu. Oficiálne to firma ale nevolala Scrum, pretože sme nemali Scrum Mastra.“

ScrumDesk: Ľudia často lipnú na názvoch a nie zmysle. Ak neimplementovali celý Scrum rámec, alebo im chýba rola, tak nemôžu implementovať Scrum. Alebo ak nevytvárajú produkt, tak nemôžu mať rolu Product Ownera.

Nebojte sa mixovať prístupy ak to vo vašej situácií dáva zmysel.

L: „Ďalšou neštandardnou vecou bolo, že sme mali štyroch Product Ownerov. Ani jeden z nich nebol hlavný Product Owner, chceli to robiť spolu. To bola podľa mňa dosť veľká chyba, pretože sa často stávalo, že keď neboli spolu a dohodol si sa na niečom s jedným, na review to už neplatilo, lebo ostatní to chceli inak.”

SD: Na začiatku Agile transformácie nemáte vždy šancu nastaviť organizáciu ideálne. Vtedy sa stáva tento prípad. Jeden tím dodáva výsledky viacerým Product Ownerom. Ako riešiť túto situáciu?

1. Zorganizujte pravidelné priorizačné stretnutia pre Product Ownerov. Nech si dohodnú jednotné poradie položiek backlogu. Zvykne sa aj dohadovať mix kapacity, aby mal každý rovnakú šancu.

2. Iný prístup je definovať iba jedného produktového vlastníka a týchto štyroch vyhlásiť za Business Ownerov.

L: „Nemali sme nikoho, kto sa to snažil vyriešiť. Tak to aj dopadlo, z nášho tímu sme v priebehu pár mesiacov odišli všetci. Lebo na niečom sme sa dohodli, s niekým to prediskutovali a zrazu to chceli inak. Potom ešte prišla firma s tým, že nastavili KPI. Ak sa každému podarí vyriešiť 80% úloh do konca roka, budú bonusy.

To všetko viedlo k tomu, že sme boli naštvaní a frustrovaní. Všetko, čo sme urobili bolo nakoniec na nič.“

SD: Takto nastavené KPI nie je rozumné. 80% akýchkoľvek úloh? Neboli by ste radšej mať vyriešené hodnotnejšie vlastnosti? Podľa priority? KPI by mali podnecovať  dosiahnuť zmysel produktu, pomôcť používateľom a nielen si „odklepnúť“ štatistiku. Prečítajte si ako nastaviť KPI, ktoré dávajú zmysel.

Aspoň s niečím sme začali

L: „Na začiatku sme nevedeli, čo presne chceme. Videli sme, že máme nedostatky, ale nevedeli sme ako ich riešiť. Tak sme si zavolali externého konzultanta, aby rozobral náš proces. Mysleli sme si, že je to technický problém, možno viac unit testov, ale konzultant povedal, že v tom to nie je. Videl nedostatky v procesoch a navrhol nám Scrum. Povedal som šéfovi, že by sme to mali skúsiť, aby mal lepší prehľad a aby to proste lepšie fungovalo.“

SD: Častokrát problémy, ktoré vo firmách vidíme nie sú ani tak o procesoch ako o komunikácii v organizácii, o biznis cieľoch alebo o transparentnosti. Preto sa vždy snažíme spraviť analýzu skutočných príčin problémov (tzv. Root cause analýzu). Navrhnuté aktivity potom často riešia viac takýchto nedostatkov, ktoré identifikuje klient.

L: „Skúsili sme trojtýždňové sprinty, rozdelili sme sa do dvoch tímov, šéf robil Product Ownera a ja som popri programovaní robil Scrum Mastra. Po každom sprinte sme mali retrospektívu a niečo sme vylepšili, pár vecí úplne zmenili. Dôležité bolo, že sme niekde začali. Trvalo nám asi 6 – 7 sprintov, kým sme sa do toho dostali.“

SD: Je bežné, že zvyknúť si na novú situáciu nejaký čas trvá. Manažment zmeny pozná takéto dočasné zhoršenie ako Satirovej model zmeny. Ľudia očakávajú, že zmeny spôsobia okamžité zlepšenie, no adaptácia trvá nejaký čas. Vymenili ste v poslednej dobe svoj mobil? Spomínate si na prvý týždeň aké to bolo ho používať? Prechod z Android na iOS môže byť dokonca náročnejší. Satirovej model sú presne tie situácie keď ste stratení v iOS.

Konzultant zmení pár vecí a začne to fungovať

L: „Niekedy pomôže raz do roka zavolať super externého konzultanta. Mal by stáť veľa peňazí, aby to firmu bolelo, aby boli nútení niečo si z toho zobrať. Takýto človek nie je súčasťou firmy, vidí chyby, ktoré firma ani Scrum Master už sami  nevidia. Pomôže vybehnúť z rutiny.”

SD: Konzultant pomôže otvoriť oči a vidieť aktuálnu situáciu v inom svetle. Veľkú úlohu pri tom hrajú skúsenosti, vďaka ktorým vie konzultant hlbšie vniknúť do prvotných príčin problémov. My sa snažíme firmu spoznať a potom adaptovať techniky na potreby ľudí, produkty a organizačnú štruktúru.

L: „Toto robíme aj my, príde konzultant a dá nám 3-4 kritické otázky. Vždy to sú veľmi logické veci, že sa človek chytí za hlavu a nechápe prečo to nenapadlo aj niekomu od nás. Preto je taký dôležitý ten odstup. Niekedy stačí zmeniť pár vecí a bude to fungovať inak.

Napríklad nám poradil, že sprint review nemusí byť každé dva týždne, skrátka môžeme robiť aj také priebežné review. Ak je niečo hotové hneď na druhý deň po plánovaní, nečakáme dva týždne. Môžeme ísť za Product Ownerom a ukázať mu to hneď. Toto musím povedať, že je super vec, lebo už počas sprintu vieme veci odovzdať a vieme ich nasadiť. Na to by sme sami neprišli a pritom to nič nestojí a super to funguje.“

SD: V ScrumDesku radíme zájsť dokonca ešte ďalej. Nech aj Product Owner má svoju akceptáciu na tabuli pre každú položku sprintu. Dokončené položky sa potom snažte akceptovať najneskôr do 24 hodín. U nás to pomohlo pridať na rýchlosti dodávok.

Task „Akceptácia“ ako súčasť každej User story v ScrumDesku

Dnes sa na seba vieme spoľahnúť

L: „Po tej počiatočnej fáze je to fakt super, lebo sa vieš na ten tím spoľahnúť. Napríklad môj šéf už ani nevie, na čom sa presne pracuje, vie, že sa môže totálne spoľahnúť na svoj tím a Product Ownera. Venuje sa veciam ako stratégia firmy a podobne.“

SD: Vo firme vznikla transparentnosť, ľudia boli spokojní a vedeli, že sa na seba môžu spoľahnúť. A vďaka samaorganizácií sa ušetril predtým stratený čas. Aký bol z nášho pohľadu rozdiel medzi dvoma skúsenosťami, ktoré Lukáš opísal?

Vo flexibilite a pochopení o čom Scrum a Agile naozaj je. V druhom prípade mali ľudia prístup „niekde sme začali“ a každý sprint sa snažili niečo zlepšiť. Boli pripravení, že to nepôjde hneď a snažili sa prispôsobiť princípy svojej situácií, nie len prísne dodržiavať pravidlá, aj keď nedávajú zmysel. Snažili sa byť agilní a nie len robiť Agile.