Od příštího kvartálu budete agilní! Aneb jak (ne)zavádět Agile

Martinu Bártů, která pracuje jako Scrum Master v docela velké IT firmě, inspiroval můj pohled na nefungující agilní implementace Za všechno může Scrum!!! k jejímu článku. Doporučuji přečíst zvlášť pokud s Agile teprve začínáte.

Ve svém článku Martina shrnuje situaci, kdy firma zavádí Agile a dojde do bodu, když už sice nějakou dobu (měsíce, roky) praktikuje některou z metodik (typicky Scrum), ale stále se jí nedaří být opravdu agilní. Kromě popisu několika typických situací, ve kterých se možná shlédnete a možná se nad nimi i pousmějete, se dozvíte také možnosti, jak z toho ven. Pokud se Agile teprve chystáte zavést, máte jedinečnou možnost se popisovaných chyb vyvarovat. Takže, jdeme na to.

Dovolte mi hned na úvod citovat jedenáctý z dvanácti agilních principů:

„The best architectures, requirements, and designs emerge from self-organizing teams.“

Zjednodušeně řečeno, Agile má naprostou důvěru v tým, věří, že ten se skládá z profesionálů ve svém oboru, kteří své práci nejlépe rozumějí, a tudíž jsou schopni si ji řídit sami a dosahovat tak nejlepších možných výsledků. A jak samoorganizující se týmy často fungují v praxi?

Začátek agilní transformace

Management, zpravidla v IT oddělení, se v dobré víře rozhodne, že své týmy transformuje na Agile. Nejčastěji Scrum. Promíchá developery a testery (je přeci třeba vytvořit cross-functional týmy), do každého týmu dá Scrum Mastera, který je většinou zároveň napůl tester nebo developer. V lepším případě všichni dostanou základní školení na „ideální“ Scrum, naprosto vytržené z kontextu dané firmy. Horší případ, že nedostanou školení žádné, teď neuvažujeme, ale i to se děje. Tedy, všem nebo alespoň většině se po zmíněném školení honí v hlavách otázky typu:

  • To se nám moc líbí, bylo by super, kdyby to takto fungovalo, ale jak toto zavést u nás, když teď fungujeme jinak?
  • A co uděláme s projektovými manažery, když ve Scrumu žádní nejsou? A co budou dělat team leadeři?
  • A jak uděláme z testerů developery a z developerů testery, když ve Scrumu mají umět všichni všechno?
  • A jak přesvědčíme byznys, aby přistoupil na nové podmínky našeho fungování a dal Product Ownerovi pravomoc rozhodovat o prioritách?
  • Atd.

Jak to pokračuje dál?

Management pravděpodobně chápe, že to nepůjde úplně samo a pozve agilního kouče, který týmům radí, jak dělat (pozor: nikoli být) Agile. A ten samý management pro jistotu dohlíží na týmy, jestli dělají každodenní synchronizační mítinky (daily scrum), retrospektivu, estimují podle plánovacího pokeru atd. Na vyšších úrovních se raději dohodne, že týmy nebudou estimovat ve story pointech, jak Scrum hlásá, ale pěkně jednotně budou estimovat v člověkodnech (man days), ať je v tom pořádek.

Mezitím je zbytek společnosti velmi málo nebo vůbec zapojen. Projektoví manažeři se zdaleka nevzdali svých Gantt chartů a stále si alokují „své“ zdroje (myšleno lidi z development týmů). Každý den přiběhnou za týmy a ptají se, kdy to budou mít hotové a proč to nemají hotové, když byla story naceněna na 3 člověkodny (man days) a už je pátý den sprintu (pozn. o nesnázích estimací v absolutních časových jednotkách mluví např. Mike Cohn ve svém videu Agile Estimating ve 34.-37. minutě)? Do toho lidé z byznysu, rozumějte zadavatele požadavků, aniž by se hlouběji zajímali nebo se nechali proškolit, zaslechli o agilní transformaci a v hlavách jim utkvělo: Agile, výborně, to znamená, že můžeme měnit požadavky, jak chceme a týmy nám budou vycházet vstříc. A vzhledem k tomu, že v Agilu není žádná dokumentace (pozn. nesprávné pochopení agilního manifestu), nemusíme psát zadání a týmy to nějak naimplementují. A nepotřebujeme to vidět, stačí nám to vidět až hotové. Každopádně, už v tento okamžik víme, že to chceme mít hotové tehdy a tehdy. Product Owner/projektový manažer vše odkýve, aniž by se týmů zeptal, zda je to reálné, a termín releasu je na světě. Odlehčeně obdobnou situaci znázorňuje tento Dilbert.

Kdo se ptal týmů na názor?

Výše uvádím jen několik příkladových „antiagilních“ situací, které se běžně při transformaci dějí. Lépe řečeno se dějí či děly mně, nebo mým kolegům z agilní komunity. Určitě byste vymysleli celou řadu dalších, ale pro ilustraci nám to takto stačí. Podívejme se teď na to, jaký vliv má takto realizovaná transformace na týmy samotné. Pozor, na samoorganizující se týmy, které nám jaksi v procesu zatím příliš nefigurovali.

  • Kdo se jich ptal na názor, jak jim vyhovuje estimovat? Jestli v man days, story pointech nebo snad nenaceňovat vůbec?
  • Kdo se jich ptal, do kdy jsou schopni něco dodat, ještě než „se“ stanovil termín vydání (release), přes který takzvaně nejede vlak?
  • Kdo jim dal prostor zformulovat vlastní Definition of Done nebo učit se z vlastních chyb, experimentovat, nebát se, že když se něco nepovede, nebudou muset absolvovat sérii meetingů, kde budou muset vysvětlovat, co se stalo, místo aby se ocenila jejich odvaha, získalo se ze situace maximální poučení a jelo se dál?
  • Kam se poděla důvěra v to, že jsou schopni sami svou práci organizovat, protože jí rozumí nejlépe (viz 11. agilní princip zmíněný na začátku)?

No, v podstatě tam tato důvěra nikdy nebyla, protože se opravdová agilní transformace nikdy neuskutečnila. A to už „jede“ firma ve Scrumu několikátým rokem a všude o tom hlásá. Taky už jste to zažili? Já několikrát.

A jak to tedy vidí týmy? V kalendářích jim přibyly nové mítinky, které z jejich pohledu žerou spoustu času a jsou nudné (nikdo totiž moc neví, jak je vést a proč se dějí). Scrum Master a management po nich vyžaduje, aby je bez výjimky praktikovaly, takže se s tím týmy prostě smíří, aby měly klid. Nejraději by neestimovaly, daily scrum by vynechaly, hlavně, aby už konečně mohly programovat a testovat. Jinými slovy v tom nevidí přínos pro jejich práci a mají pocit, že je to akorát zdržuje. Ve snaze vyhovět byznysu se snaží dodat za každou cenu ve slíbeném velmi pravděpodobně nereálném termínu stanoveném několik měsíců dopředu. Dělají ústupky z Definition of Done (pokud nějaké mají) a kvalita trpí. Postupem času většina z nich pozapomene, co se naučili na nedávném Scrum školení, protože vlastně nikdy neviděli jeho skutečnou aplikaci do praxe. Spirála anti-agilních vzorců chování se roztáčí a vede to některé k názoru, že Scrum nefunguje, a vybudují si averzi. Jenže, to není Scrum, co nefunguje, ten tam v podstatě nikdy nebyl.

Co se stalo?

Krásně výše uvedený stav ozřejmuje obrázek z článku Simona Powerse What is Agile?, na který se budu v tomto odstavci odkazovat, takže na něj mrkněte. Firma se totiž zasekla na úrovni nástrojů a procesů (Tools and Processes), nejmenší ovál, příkazem zavedla nějaké praktiky (Practices), druhý nejmenší ovál, a pochopila některé principy (Principles), prostřední ovál. Ale pravděpodobně se dál nedostala, protože nikdy neproběhla změna struktury a celofiremní kultury, a nikdy se jí nepodařilo žít podle agilních hodnot (Values) a vzbudit v lidech agilní smýšlení (Mindset). Pravděpodobně se ani nepodařilo rozšířit povědomí o Agilu mimo software development týmy, takže ty, ač se snaží praktikovat předepsané ceremonie a postupy, narážejí na okolní neagilní svět.

Znovu se zeptám: Je vám to povědomé? Ale jak z toho ven? Jak týmy a celou organizaci naučit to nejdůležitější, a to změnu v myšlení? Rozhodně nemám v rukávu patent a osvědčené řešení účinné pro všechny případy, ale k čemu jsem během své praxe došla shrnuji níže.

Co s tím?

  1. Úplně nejdůležitější je mít konkrétní pádné důvody, proč Agile zavést. Co konkrétně chce organizace transformací řešit a získat? Společná vize a cíle budou to, co bude všem připomínat smysl veškerého jejich snažení a bude je popohánět na jejich agilní cestě. Na tyto důvody je samozřejmě nezbytné mít namapované kvalitní metriky, aby bylo možné průběžně vyhodnocovat, jak se transformace daří a jestli přináší chtěné ovoce. Pokud zatím nic takového nemáte, nezapoměňte, že nikdy není pozdě začít.
  2. Od teď už najímejte pouze lidi, kteří mají Agile v krvi nebo mají potenciál se s jeho hodnotami a principy ztotožnit. Mnohde se dočtete, že Agile není pro každého a je to svatá pravda. Člověk, který nechce dělat věci dobře, nechce aktivně vzít svůj pracovní život do vlastních rukou, chce se jen zašívat, hledá jen důvody, proč něco nejde a je v tom nepoučitelný nebo by raději pracoval sám vzdáleně místo v týmu atd., bude vaše týmy jenom brzdit a demotivovat.
  3. Velmi také pomůže najmout zkušené Scrum Mastery, Product Ownery, projektové a jiné manažery, kteří už vědí, jak má opravdu agilní firma vypadat a dokážou změnu posouvat na všech úrovních. Věřte, že se pak věci začnou hýbat mnohem rychleji, když už to někdo bude dobře umět.
  4. Dejte týmům prostor objevovat a experimentovat. Nechte je na chvíli přestat dělat to, co jim nedává smysl a nechat je naopak dělat to, co jim smysl dává, aby se mohly konečně samy organizovat. Vysvětlujte jim zároveň, co a hlavně proč Agile doporučuje. Jsou to přeci shrnuté desítky let praxe těch nejlepších z nejlepších, tak to musí fungovat. Ale dejte jim prostor, ať si na to přijdou sami.
  5. Zkuste se přestat soustředit pouze na scrumové procesy, role, ceremonie… a začít klást důraz i na ostatní vzdělávání, které Scrum neřeší a přitom efektivní fungování týmů vyžaduje jejich znalost. Např. vzdělávání development týmů po technické stránce (test driven development, pair programming, devops, continuous integration…) a stránce měkkých dovedností (týmová spolupráce, umění a moc zpětné vazby, asertivita, efektivní komunikace, osobní vize a motivace…).
  6. Nechte projektové manažery proškolit o novodobých agilních způsobech řízení projektů, aby dokázali být týmům prospěšní i v agilním prostředí a nesnažili se je jen hlídat a nevědomky jim házet klacky pod nohy v podobě nesplnitelných termínů.
  7. Nechte proškolit i byznys, ať mají přehled o tom, jak development týmy fungují, co od nich mohou očekávat a co se očekává od nich.
  8. Buďte rovnocennými partnery byznysu. Je důležité se zástupci zadavatele opravdu jednat jako rovný s rovným a ne skákat tak, jako oni pískají. Oni mají zájem na tom, abyste dodávali co nejlépe dokážete, takže je v Agilu vychovávejte a nenechte si od nich příliš mluvit do práce. Vždy jim ale vysvětlete proč něco je a nebo není reálné a jaké jsou konkrétní možnosti.
  9. Prohlubte spolupráci mezi Scrum Mastery, jednotlivými development týmy i jednotlivými odděleními, aniž tomu říkáte Scrum, ke kterému už možná někteří stihli získat averzi. Prostě se spolu normálně lidsky domlouvejte, spolupracujte a sdílejte své know how.
  10. V neposlední řadě udělejte všechno pro to, aby Scrum týmy uměly byznysu a managementu dokázat, že díky dodržování agilních principů, praktik a smýšlení opravdu dokážou být více efektivní a doručit lepší produkt a tím i přispět k větší výdělečnosti byznysu. A že dokážou lépe vycházet i po lidské stránce a vytvořit tak prostředí, kde se lidem dobře pracuje, práce jim dává smysl, jsou motivovaní, nebojí se využít své kreativní já a do práce chodí rádi.
  11. A úplně nejvíc dokonalé je, když vám k tomu všemu dá podporu (a budget) někdo shora (CEO, CTO, CIO…), prostě nějaký klíčový decision-maker, který je schopný a ochotný agilní transformaci šířit po celé organizaci. Provádět změnu pouze zdola je určitě také možné a nenechte se od toho odradit, ale je to pomalejší a dá to více práce. Ve vaší snaze vám může pomoci Katy Sherman se svým článkem The Dirty Secret of Corporate Politics: Use It to Get All You Want.

A to je vše, přátelé. Těmito slovy svůj článek ukončím a budu se těšit na vaše komentáře o tom, jak řešíte podobné výzvy u vás ve firmách vy, jak se vám to daří, co se vám osvědčilo a co ne a klidně můžete i s něčím řečeným konstruktivně nesouhlasit, máte na to plné právo. A děkuji, že jste dočetli až sem 🙂

Text neprošel profesionální korekturou, takže případné jazykové nedokonalosti, prosím, omluvte.

Příspěvek byl publikován v rubrice Články se štítky , , , . Můžete si uložit jeho odkaz mezi své oblíbené záložky.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *