Vysvětlení největších chyb při transformaci doručení na agilní

Jak společnosti přecházejí se softwarovými řešeními z on-premise do cloudu, často si kladou za cíl stát se „agilnějšími“. To by se často mělo ideálně týkat všeho na mezipodnikové úrovni. A samozřejmě zároveň všude.

Transformace procesů by mohla být snadno možná, alespoň teoreticky. Můžete definovat scrum ceremonie a přeřadit lidi do nových rolí (jako jsou scrum master, vlastníci produktů, manažeři doručení a scrum týmy).

Můžete si přinést nástroje jako Jira, Azure ADO a desky Miro a nastavit je jako povinné. Ale co procesy spojující nástroje dohromady? A co proměna myslí, chování a způsobů práce lidí? Je jasné, že se nepromění hladce a ani rychle neskončí. Nyní se podívejme proč.

Co je to iniciativa pro transformaci dodávek a proč ji společnosti dělají?

Obrovská část společností dnes stále funguje podle vodopádového doručovacího modelu. To znamená, že:

Nejprve si naplánujte, co chcete udělat jako konečný výsledek/produkt a kolik to může zhruba stát.

Zahajte proces shromažďování požadavků, kde důkladně prodiskutujete všechny podrobnosti o konečném produktu, vznesete námitky, zpochybníte, odsouhlasíte, znovu projednáte a nakonec potvrdíte.

Odhadněte celou věc a potvrďte rozpočtové očekávání.

Navrhněte řešení. Uspořádejte několik setkání se zúčastněnými stranami. Vytvářejte různé dokumenty a nechte je zkontrolovat zúčastněnými stranami. Potvrdit a schválit finální funkční a technický návrh.

Implementujte řešení na základě návrhu. Zde vyvíjíte kompletní konečný produkt.

Vstupte do testovací fáze a provádějte různé druhy testů: unit testy, systémové testy, funkční testy, integrační testy, výkonnostní testy, regresní testy, uživatelské akceptační testy a potenciálně mnoho dalších (v závislosti na kultuře společnosti). Vše zdokumentujte a nechte zúčastněné strany, aby to přezkoumali a schválili.

Nasaďte řešení do produkčního prostředí. Zde začínají cíloví uživatelé používat konečný a kompletní produkt.

Naplánujte si nějakou fázi podpory, během níž vývojový tým opraví případné chyby řešení.

Celý tento proces může trvat několik měsíců až několik let, a jak můžete vidět, uživatelé uvidí výsledky až na konci tohoto procesu. Po dlouhém čekání tedy přichází okamžik pravdy (nebo neúspěchu).

Pokud se během té dlouhé doby něco změní a konečný produkt by měl vypadat trochu jinak, jedná se o situaci, která se nazývá žádost o změnu. Návrh musí být znovu otevřen, přepracován a znovu schválen. Prodlužuje celý časový harmonogram o další část.

Je jasné, že to v žádném případě není agilní. Každá změna vyžaduje restart celého procesu předtím.

Přechod na Agile

Jak se tedy z této situace dostat a změnit ji tak, aby se stala agilní? Lidé pracují v nastavení vodopádu po mnoho let nebo dokonce staletí. Mají role a povinnosti, které jim vyhovují, a nechtějí měnit status quo. Hlavním důvodem je to, že provedení této změny v konečném důsledku znamená ztrátu části moci, kterou dosud měli.

To je hlavní důvod, proč taková změna získává z lidí nejsilnější úroveň odporu, kterou můžete vytvořit.

#1. Restrukturalizace týmu

První a relativně nejjednodušší je restrukturalizovat lidi do scrum týmů. Rozdělte je na základě funkčních oblastí nebo jakéhokoli jiného logického rozdělení, které dává smysl.

Rozdělení obvykle probíhá hladce; problém začíná, když si uvědomíte, že lidé jsou stále vázáni na původní struktury. I když už jsou součástí nových scrum týmů, prakticky nejsou. Stále pracují na tom starém nastavení, protože stále mají povinnosti, které nebyly ukončeny společně s procesem restrukturalizace týmu (protože proč by tomu tak bylo – vedení se moc nestará o to, co je třeba dokončit, ale hlavně o to, co je třeba začít).

Takže prakticky skončíte se scrum týmem, který není plně oddaným scrum týmem. Je to skupina lidí, která má nyní prostě více práce. Na práci uvnitř scrum týmu není tolik času, jak vedení očekává.

Zároveň se očekává, že lidé dokončí své původní aktivity i toto nové očekávání uvnitř scrum týmů. Je to nastavení rozhodnuté selhat hned na začátku.

#2. Plánování ceremonií Scrum

Nařídit týmům, aby naplánovaly několik pravidelných hovorů (sprintových ceremoniálů), je snadné definovat a začít. Alespoň za předpokladu, že se vaše scrum týmy neskládají z lidí ze 3+ časových pásem (což je často případ).

Problém začíná, když se lidé nebudou pravidelně účastnit obřadů. V závislosti na tom, kdo chybí a jak často, se to může vyvinout v různé druhy problémů. Například:

• Pokud se produktoví vlastníci nezúčastní plánovacích a zdokonalovacích obřadů, tým nemá žádné nové příběhy, na kterých by mohl pracovat. Nebo je popis příběhů tak chabý, že na nich zbytek týmu nemůže začít pracovat.
• Pokud na hovorech chybí mistři scrumu, týmu chybí základní orchestrace scrumu a časem se může ztratit.
• Pokud členové týmu vývojového týmu často chybí, nemohou se vzájemně synchronizovat a komunikace uvnitř týmu je mnohem těžší. K dohnání je také potřeba více schůzek, což týmu ubírá další čas.

Nakonec to není nutně chyba lidí, že obřady promeškají. Jenom nastavení jim nedovolí být na hovorech (viz výše o paralelních předchozích přiřazeních).

#3. Stabilita týmu

Můžete mít scrum tým se strukturou a ceremoniemi, ale pokud tento tým není stabilní po delší dobu – řekněme alespoň půl roku ideálně, rok stability by byl můj osobní minimální požadavek – pak takový tým může se opravdu nevyvíjejí a nezlepšují.

Dále pravděpodobně nikdy nedosáhnete plně nezávislého scrum týmu, který bude sprinty zvládat jako obvykle. A konečně, budete muset neustále vzdělávat a učit lidi uvnitř týmu, aby pochopili způsob myšlení a procesy scrumu. Je to vyčerpávající problém.

Jedná se o velmi podceňovaný problém, konkrétně ze strany vedení či managementu společnosti. Nazývat týmy lidí jen „zdroji“ a plánovat jejich „využití“ od čtvrtletí ke čtvrtletí je okamžitá cesta do pekel.

#4. Nové role pro stejné lidi

Další překážkou, kterou je třeba překonat, je přeřazení stávajících lidí do různých nových rolí. Ti, kteří dříve řídili týmy s maximální mocí, se nyní mohou stát například vlastníky produktů. Jedná se o silnou pozici ve scrum týmu, ale lze ji vnímat jako slabší roli ve vztahu ke stávajícímu nastavení.

Najednou se musí vlastníci produktu synchronizovat se scrum masterem nebo programovými manažery. Jsou stále zodpovědní za obsah, ale ne tolik za procesy doručení. Tato situace vyžaduje vzdát se některých povinností, které lidé dříve měli, a proto je těžké je spolknout.

#5. Způsoby práce

Tohle je zajímavé a slýchám to tu a tam docela často – potřebujeme se naučit nové způsoby práce, abychom se stali relevantními na vyvíjejícím se trhu, kde je agilita základním očekáváním. Ale co přesně tyto způsoby práce znamenají?

Pokud se mě ptáte, je jasné, co tím management myslí – dosáhnout (mnohem) více za kratší čas. Po sestavení scrum týmů se očekává, že každý člen týmu náhle ze dne na den dosáhne nějakých zdokumentovaných přírůstkových výsledků. Pokud tomu tak není, vedení se začne ptát, proč agilní proces nefunguje dobře.

Vedení z ničeho nic očekává, že se bude počítat každá hodina a že scrum týmy nemají v podstatě žádný čas nečinnosti, jen proto, že na to pravděpodobně není prostor, budou všechny procesy scrumu fungovat. A to je v kostce definice „nových způsobů práce“ z pohledu vedení.

Toto očekávání samozřejmě není postaveno na ověření reality. Je iluzorní očekávat, že lidé ve firmě začnou pracovat více ve stejném období, jen proto, že se změní některé každodenní procesy. Myslím, že někteří z nich by mohli, i když jen menšina. I tato skupina je však dále redukována zahlcováním více úkolů současně.

Rozdíl mezi cílem a realitou

Není pochyb o tom, že popis konečného cíle je často dobrý a dává velký smysl. Jde kolem následujících zásad:

• Stabilizované scrumové týmy pracující na nezávislých backlogech s jasnými KPI a OKR.
• Vlastníci produktů, aby vytvořili pevné cestovní mapy a naplánovali prioritní obsah, který bude doručován podle konkrétních časových plánů.
• Definovaný obsah nevyřízených položek s relevantními funkcemi, které byly podrobně popsány před zahájením práce.
• Spolehlivé testovací procesy prováděné spolu s běžnou prací na vývoji sprintu.
• Pravidelné uvolňování do výroby – alespoň jednou za měsíc, ale ideálně po každém dokončení sprintu.
• Sledování rizik a problémů a komunikace mezi různými scrum týmy v případě závislostí.

Když pak dojde na realitu, mohu říci, že žádného z výše uvedených bodů není snadné dosáhnout.

• Tvoříte scrum týmy, které se ale neustále mění (od čtvrtiny ke čtvrtině). Investujete čas, abyste tým naučili procesy scrumu, a jakmile to konečně začnou akceptovat a změní své způsoby práce, reorganizujete týmy na další období. Cestovní mapy jsou upraveny, posunuty nebo zrušeny.
• Vlastníci produktů nemají žádné skutečné ponětí o podrobnostech plánu a (právě proto, že takové zvyky měli dříve), zadají své úkoly týkající se vytváření obsahu nevyřízených záležitostí přímo týmu. Výsledkem je, že tým nemá čas na vývoj obsahu, protože nejprve musí zjistit, co vyvinout.
• Testovací procesy jsou pouze manuální a vyžadují mnoho dílčích kroků a schvalování a složitých procesů, které je třeba dodržet. To znamená, že neexistuje způsob, jak by testování mohlo skončit ve stejném sprintu jako vývoj.
• V důsledku toho se vydání do výroby o několik sprintů opožďuje.
• Komunikace mezi různými scrum týmy je chaotická a neefektivní, protože každý tým musí v každém sprintu splnit spoustu aktivit. Vlastníci produktů mají ve skutečnosti tendenci přidělovat týmu příliš mnoho obsahu na každý sprint. Tým nemá šanci to všechno dokončit, takže je neustále ve stresu z termínu.

Oprava chyb

Po zkušenostech z několika projektů agilní transformace bych rád shrnul některé z největších chyb, které jsem zažil, a uvedl několik subjektivních názorů na jejich případné překonání.

#1. Správná odpovědnost za správné role

Pokud se pokusíte ohýbat definici a rozdělovat odpovědnosti jiným způsobem, než by měl být skrumáží/agilní, celou iniciativu zahazujete.

• Vlastníci produktu musí vlastnit obsah a udržovat nevyřízené položky. Jsou zodpovědní za nevyřízené příběhy, a pokud nejsou nevyřízené příběhy dobře definovány, je na nich, aby přijali opatření a opravili to. Na druhou stranu by neměli mít žádný vliv na přiřazení lidí do scrum týmu nebo rozhodování o rozpočtu projektu.
• Scrum mistři nenesou žádnou odpovědnost za obsah nevyřízených položek. Jsou v týmu, aby organizovali obřady a vychovávali tým v agilním způsobu práce. Neměli by být sekretářkou pro vlastníky produktů. Naopak budou chránit vývojový tým před vlastníkem produktu a externími zainteresovanými stranami.
• Každý scrum tým musí mít přiděleného vedoucího dodávky. Tato osoba propojí PO, SM a vývojový tým do funkčního nastavení, definuje procesy dodání a vyřeší všechna potenciální rizika, problémy nebo konflikty, které tým může mít. Vedoucí dodávky je tou správnou osobou, která rozhodne o personálních a rozpočtových otázkách projektu. Tato osoba se bude snažit vybudovat pro tým prostředí, kde každý může podávat nejlepší výkony.
• Odpovědností vývojového týmu je vyvinout příběhy z nevyřízených věcí. Mohou pomoci PO vytvořit obsah pro některé příběhy (hlavně ty, které jsou příliš technické), ale nejsou zodpovědné, nebo dokonce nejsou odpovědné za příběhy vytvářející obsah plánu.

#2. Stabilní tým

Investice do agilního vzdělávání týmu je důležitá a musí jít o rychlý proces. Nechat tyto znalosti každých pár měsíců odejít je pro všechny jen ztráta času.

Prvních pět sprintů můžete použít jako učební křivku pro tým, abyste poznali a procvičili základní scrumové aktivity. Jakmile budou jasné pro celý tým, může začít proces neustálého zlepšování scrum týmu. Pokud se ale lidé uvnitř týmu pravidelně mění, ocitnete se v neustálé smyčce předávání znalostí a vzdělávání.

Takový tým pravděpodobně nikdy nedosáhne plného výkonnostního potenciálu a vedoucí tým se bude nadále divit, proč byl dříve (před agilní transformací) efektivnější, než se nyní zdá.

Vybudujte tým, investujte znalosti, a jakmile si tým bude jistý novými procesy, nechte ho tak, jak je, a rozvíjejte se dále. Odtud začíná neustálá cesta k dokonalosti.

#3. Matice RACI

Je dobrým zvykem vytvořit a dohodnout se na matici RACI (odpovědný, odpovědný, konzultovaný, informovaný) mezi všemi týmy těsně před zahájením skutečné práce. To může potenciálně odstranit spoustu zmatků hned na začátku.

Je to velmi důležité, zejména v raných fázích transformačních iniciativ. V opačném případě začnou lidé klást otázky, kdo by měl co dělat v jaké situaci, zejména v těch, které nebyly explicitně řešeny prostřednictvím komunikace týmu.

Zde je příklad takové matice RACI pro některé odpovědnosti. Váš projekt může mít jinou sadu. Důležité je zachytit ty relevantní.

TaskRequestorDelivery LeadProduct OwnerScrum MasterDev TeamSprint Plánování relacíC/ICA/IRC/IDeliver Release IncrementN/AIA/IC/IRSprint ReviewC/IIRICSprint RetrospektivaIIA/IRC/IRefinujte BacklogIA/IRAC/I

Závěr

Ještě by bylo o čem psát, protože cest a míst, kde může agilní proměna vést mimo trať, je mnoho. Účelem bylo poukázat na některé problémy, které považuji za často se opakující.

Samotná iniciativa je dobrý nápad. Pokud však dodržíte některá základní pravidla, může se rychle stát noční můrou všech účastníků. Zdůraznil jsem několik z nich, ale používejte zdravý rozum a budete v pořádku. 🙂

Dále se podívejte na dobré výukové zdroje pro Agile certifikaci.