Organizace měla připravený nový způsob práce. Byly popsané role, nakreslená struktura týmů, vytvořená hierarchie backlogu a v Jira čekala nová workflow. Leadership schválil cílový model a transformační tým naplánoval školení.
Na papíře vše dávalo smysl.
Pak jsme během workshopu vzali jeden konkrétní požadavek a zkusili jej navrženým systémem protáhnout od strategického rozhodnutí až k práci týmů.
Během několika minut se objevily otázky:
- Kdo rozhodne, zda se požadavkem vůbec budeme zabývat?
- Kdo jej přeloží do položek backlogu?
- Kdy se mají zapojit vývojové týmy?
- Kdo vyřeší konflikt mezi dvěma prioritami?
- Co se stane, když jeden tým potřebuje kapacitu jiného týmu?
- Kdo smí změnit scope, když už práce běží?
Žádná z těchto otázek nebyla v transformačních prezentacích vidět. Ne proto, že by byly prezentace špatné. Statický model jednoduše neukazuje, jak se organizace zachová ve chvíli, kdy do ní vstoupí skutečná práce, omezená kapacita, závislosti a změny priorit.
Právě proto může být dobře připravená simulace agilní transformace užitečnější než další kolo připomínkování organizačního diagramu.
Organizační model na slidu ještě není fungující systém
Při agilních transformacích často vzniká velké množství statických artefaktů:
- organizační schémata,
- popisy rolí,
- procesní mapy,
- RACI tabulky,
- hierarchie backlogu,
- governance modely,
- seznamy meetingů a jejich účastníků.
Tyto materiály mají svůj smysl. Pomáhají vytvořit společný jazyk a vysvětlit základní návrh. Problém nastává, když je začneme považovat za důkaz, že nový systém bude fungovat.
Organizační diagram například ukáže, že Product Management stojí mezi strategií a týmy. Neřekne ale, zda Product Management může skutečně odmítnout požadavek důležitého stakeholdera.
Procesní mapa ukáže, že požadavek prochází analýzou. Neřekne, kolik požadavků současně čeká na omezenou kapacitu business analytiků.
RACI tabulka určí, kdo je za rozhodnutí accountable. Neřekne, zda má tento člověk informace, čas a pravomoc rozhodnout ve chvíli, kdy je to potřeba.
Skutečný systém se projeví teprve v pohybu. Ve chvíli, kdy do něj vstoupí práce a lidé musí podle navržených pravidel jednat.
Školení ověří porozumění. Neověří fungování systému
Dobré školení může lidem vysvětlit role, principy, události nebo artefakty. Účastník může správně popsat, co dělá Product Owner, jak funguje pull systém nebo jaký je smysl společného plánování.
Z toho ale ještě neplyne, že organizace dokáže:
- rychle rozhodnout mezi konkurenčními prioritami,
- omezit množství zahájené práce,
- řešit závislosti napříč týmy,
- převést strategický záměr do realizovatelné změny,
- reagovat na urgentní požadavek bez rozpadu celého plánu.
Znalost modelu a schopnost podle něj společně jednat jsou dvě odlišné věci.
Co je simulace agilní transformace
Simulace je zjednodušený model fungování budoucí organizace. Účastníci v něm nepoužívají pouze teorii, ale musí řešit konkrétní situace:
- přijmout požadavek,
- pochopit očekávaný výsledek,
- rozhodnout o jeho prioritě,
- přeložit jej do práce týmů,
- naplánovat postup,
- vyřešit závislosti,
- reagovat na změnu,
- dokončit výsledek a ověřit jeho přínos.
Nejde přitom nutně o složitou několikadenní akci. Dobře ohraničená simulace může trvat dvě až čtyři hodiny. Důležitější než délka je kvalita otázky, kterou má pomoci zodpovědět.
Simulace nemá potvrdit, že jsme transformační model navrhli správně. Má vytvořit dostatečně bezpečné podmínky pro to, abychom zjistili, kde se pravděpodobně mýlíme.
Není to hra jen pro pobavení
Pod slovem simulace si lidé často představí stavění věží, skládání papírových letadel nebo přesouvání barevných kartiček. Takové hry mohou dobře vysvětlit jeden princip, například práci v malých dávkách, zpětnou vazbu nebo omezení rozpracovanosti.
Transformační simulace ale potřebuje jít dál. Má být dostatečně podobná reálnému prostředí, aby účastníci dokázali získané poznatky převést do vlastní práce.
Proto je vhodné použít:
- typy požadavků, se kterými organizace skutečně pracuje,
- reálné nebo věrohodně zjednodušené role,
- omezenou kapacitu,
- typické závislosti,
- rozhodovací situace známé z běžného provozu,
- neočekávanou změnu priority nebo kapacity.
Nemusíme používat citlivé projekty ani skutečná obchodní data. Scénář může být anonymizovaný nebo syntetický. Musí však zachovat podstatnou dynamiku reálného systému.
Co simulace odhalí lépe než další workshop
1. Nejasné rozhodovací pravomoci
Jedním z nejčastějších zjištění není chybějící proces, ale chybějící rozhodnutí.
Typický příklad: Product Owner má být odpovědný za backlog. Během simulace se ale ukáže, že nemůže změnit prioritu bez souhlasu několika stakeholderů. Současně se od něj očekává, že ochrání tým před změnami a zajistí předvídatelnou dodávku.
Formálně vlastní backlog. Prakticky nevlastní rozhodnutí, která jeho obsah určují.
Simulace podobné rozpory rychle zviditelní, protože práce se jednoduše zastaví. Někdo musí rozhodnout, ale nikdo si není jistý kdo.
2. Fronty, čekání a skryté handoffy
Na procesním diagramu může práce plynule přecházet od strategie přes analýzu do realizace. V simulaci se však začne hromadit před jedním schválením, analytickou rolí nebo sdíleným specialistou.
Najednou je vidět, že:
- požadavky čekají na doplnění informací,
- analýza začíná příliš pozdě,
- týmy dostávají práci až ve chvíli, kdy už není prostor ovlivnit řešení,
- každý předávací bod vytváří další čekání,
- formálně připravená práce není pro tým skutečně převzatelná.
Právě rozdíl mezi položkou označenou jako „Ready“ a prací, kterou může tým reálně převzít a dokončit, rozebíráme také v článku Pullability: jednoduchý test, jestli si tým může práci opravdu vzít.
3. Závislosti, které existují jen jako čára v plánu
Organizace často ví, že mezi týmy existují závislosti. Nakreslí je do plánu, zapíše do nástroje a přiřadí jim vlastníka.
To ale ještě neznamená, že je umí řídit.
Při simulaci lze například dát třem týmům společný výsledek. Jeden tým přitom potřebuje komponentu od druhého a třetí tým má omezenou kapacitu specialisty, kterého potřebují všichni.
Brzy se ukáže:
- zda týmy plánují každý sám za sebe, nebo podle společného výsledku,
- kdo může změnit pořadí práce,
- zda se závislost pouze eviduje, nebo skutečně řeší,
- jestli lokální cíle týmů podporují výsledek celku,
- zda společné plánování vede k rozhodnutím, nebo jen k lepší dokumentaci problémů.
Pokud se závislosti stávají hlavní brzdou toku práce, bývá potřeba řešit jejich příčiny, nikoliv pouze zpřesnit evidenci. Na tuto situaci se zaměřuje také služba Dependency Detox.
4. Rozdíl mezi deklarovanou a skutečnou autonomií
V mnoha transformačních modelech jsou týmy označené jako autonomní nebo cross-functional. Během simulace ale zjistí, že pro téměř každou položku potřebují:
- rozhodnutí externího architekta,
- kapacitu jiného týmu,
- schválení managementu,
- samostatné testovací oddělení,
- release okno řízené mimo tým.
Samotný název týmu tedy nezměnil jeho schopnost dodat výsledek. Simulace umožní tuto skutečnost pojmenovat bez dlouhé abstraktní debaty o tom, zda jsou týmy „dostatečně agilní“.
5. Chování systému při změně priority
Bez neočekávané změny bude téměř každý model vypadat funkčně.
Proto je užitečné ve druhé části simulace přidat nový urgentní požadavek. Nemusí jít o uměle vytvořenou katastrofu. Stačí situace známá z běžného provozu:
- nová regulatorní povinnost,
- požadavek významného zákazníka,
- produkční incident,
- změna strategické priority,
- výpadek důležité kapacity.
Klíčová otázka nezní jen: „Dokážeme nový požadavek přijmout?“
Podstatnější je:
- Kdo posoudí jeho skutečnou naléhavost?
- Kdo rozhodne o trade-offu?
- Kterou již zahájenou práci zastavíme nebo odložíme?
- Jak změnu promítneme do očekávání stakeholderů?
Pokud se nová priorita pouze přidá k rozpracované práci, systém nereagoval agilně. Jen zvýšil množství paralelně otevřených závazků.
Praktický příklad: od strategického cíle k práci týmů
Představme si organizaci, která chce ověřit nový způsob propojení strategie, produktového řízení a několika delivery týmů.
Pro simulaci připraví:
- jeden strategický cíl,
- šest různě hodnotných požadavků,
- tři týmy s omezenou kapacitou,
- dvě významné závislosti,
- jednu nejasně definovanou položku,
- jeden urgentní požadavek, který přijde později.
Účastníci zastupují leadership, product, business analýzu, architekturu a týmy. Dostanou základní pravidla navrženého operating modelu a mají připravit realistický plán dodávky.
První kolo: postupujeme podle navrženého modelu
V prvním kole facilitátor do práce příliš nezasahuje. Sleduje, co se skutečně děje:
- Kdo se ujme prvního rozhodnutí?
- Kolik položek se začne připravovat současně?
- Kdy se zapojí týmy?
- Kde se čeká?
- Které informace chybějí?
- Kdo řeší konflikt priorit?
- Jak jsou zohledněny závislosti?
V jedné podobné simulaci například leadership předal několik priorit produktovým rolím. Product Management je následně všechny poslal k rozpracování, protože žádnou nechtěl předčasně odmítnout. Analytické role začaly paralelně připravovat vše. Týmy se zapojily až později a zjistily, že několik návrhů vyžaduje stejnou technickou kapacitu.
Problém nebyl v tom, že by lidé neznali správné pojmy. Systém neobsahoval dostatečně silný mechanismus, který by nutil organizaci udělat skutečné prioritizační rozhodnutí.
Podobný problém vzniká i tehdy, když je strategie formálně popsána pomocí cílů, ale nedokáže se promítnout do konkrétních rozhodnutí v backlogu. Tématu se podrobněji věnujeme v článku Od OKR k backlogu: kde se ve firmách ztrácí strategie.
Retrospektiva systému, ne hodnocení lidí
Po prvním kole by neměla přijít diskuse o tom, kdo co udělal špatně. Účastníci jednali v podmínkách, které jim systém vytvořil.
Užitečnější otázky jsou:
- Které rozhodnutí nemělo jasného vlastníka?
- Kde odpovědnost neodpovídala pravomoci?
- Kde práce čekala a proč?
- Co nás vedlo k zahájení další práce místo dokončení rozpracované?
- Která pravidla jsme interpretovali rozdílně?
- Který předpoklad navrženého modelu se nepotvrdil?
Cílem není najít viníka. Cílem je porozumět chování systému.
Druhé kolo: měníme jednu podmínku
Ve druhém kole je vhodné otestovat jednu nebo dvě konkrétní změny. Například:
- omezit počet současně připravovaných požadavků,
- zavést společné prioritizační rozhodnutí,
- zapojit týmy dříve,
- definovat pravidlo pro urgentní práci,
- odstranit jeden schvalovací krok,
- jasně určit, kdo rozhoduje o trade-offu.
Není vhodné kompletně předělat celý model. Pokud změníme vše najednou, neuvidíme, která změna přinesla rozdíl.
Simulace se tak stává malým experimentem: upravíme jednu systémovou podmínku, sledujeme dopad a rozhodneme, zda má smysl změnu ověřit v reálném pilotu.
Co během simulace sledovat
Simulace nemusí vytvářet složitý dashboard. Stačí několik kategorií pozorování.
Tok práce
- Kolik položek bylo zahájeno?
- Kolik jich bylo dokončeno?
- Kde se práce hromadila?
- Kolikrát se vrátila zpět?
- Kde čekala na rozhodnutí, informaci nebo kapacitu?
Rozhodování
- Která rozhodnutí byla potřeba?
- Kdo je mohl učinit?
- Která rozhodnutí byla eskalována?
- Kde lidé čekali na souhlas, který neměl jasnou přidanou hodnotu?
Připravenost práce
- Bylo jasné, jaký výsledek očekáváme?
- Byla práce dostatečně malá?
- Byly známé hlavní závislosti?
- Mohl si tým práci skutečně převzít?
Reakce na změnu
- Co se stalo po příchodu nové priority?
- Byla zastavena jiná práce?
- Kdo rozhodl o změně?
- Byl viditelný dopad na původní plán?
Výsledek
- Dokončili jsme skutečný zákaznický nebo business výsledek?
- Nebo jsme pouze přesunuli položky do posledního sloupce?
- Bylo jasné, jak bychom ověřili přínos dodané změny?
Přístup Kanban Method doporučuje začínat současným způsobem práce, používat explicitní pravidla, zpětné vazby a zlepšovat systém evolučně pomocí řízených experimentů. Simulace může být jedním z prvních bezpečných experimentů před tím, než změnu ověříme v reálném provozu. Více najdete v oficiálním průvodci Kanban Method.
Typické chyby transformačních simulací
Simulace nemá jasnou otázku
Organizace chce „udělat agilní simulaci“, ale není jasné, co se má naučit nebo ověřit. Výsledkem bývá zajímavý workshop a dlouhý seznam obecných postřehů.
Lepší začátek představuje konkrétní otázka:
- Dokážeme převést strategickou prioritu do práce týmů?
- Je jasné rozhodování o prioritách?
- Dokážeme řídit hlavní cross-team závislosti?
- Jsme připraveni na první společné plánování?
Scénář je příliš obecný
Čím abstraktnější hra je, tím obtížnější bývá přenos poznatků do reality. Účastníci mohou pochopit význam malých dávek při výrobě papírových produktů, ale nemusí si jej spojit s několikaměsíční přípravou vlastních požadavků.
Scénář by měl používat podobné typy práce, omezení a rozhodnutí, jaké organizace skutečně řeší.
Simulace potvrzuje předem vybraný framework
Simulace někdy slouží jako nácvik toho, jak správně provést předepsané role, meetingy a artefakty. To může být užitečné před první konkrétní událostí, například společným plánováním.
Nemělo by se to ale zaměňovat za test fungování organizace. Cílem transformační simulace není potvrdit správnost Scrum, Kanban, SAFe nebo jiného přístupu. Cílem je ověřit, zda zvolená kombinace principů a praktik funguje v daném kontextu.
Také Scrum stojí na empirickém přístupu, transparentnosti, inspekci a adaptaci, nikoliv na představě, že samotné zavedení událostí automaticky vyřeší komplexní problém. Základní definici a principy lze dohledat v oficiálním Scrum Guide.
Chybí omezení a změna
Pokud mají všechny role dostatek času, informací a kapacity, bude fungovat téměř každý proces. Reálný systém se projeví až pod tlakem omezení.
Do scénáře proto patří alespoň jeden realistický problém:
- omezená kapacita,
- konfliktní priority,
- nejasné zadání,
- závislost,
- neočekávaná změna.
Debrief hodnotí lidi místo systému
„Product Owner měl rozhodnout rychleji.“ „Týmy měly dříve komunikovat.“ „Management neměl zasahovat.“
Takové závěry mohou být pravdivé, ale samy o sobě příliš nepomohou. Je potřeba se ptát, proč bylo dané chování v systému logické.
Měl Product Owner potřebné pravomoci? Viděly týmy závislost včas? Existovalo pravidlo, podle kterého měl management rozhodnout?
Simulace končí seznamem „aha momentů“
Dobrá atmosféra a silné uvědomění nestačí. Zjištění je potřeba převést do konkrétního transformačního backlogu.
Každá důležitá položka by měla obsahovat:
- pozorování,
- pravděpodobnou příčinu,
- dopad,
- hypotézu změny,
- další experiment,
- vlastníka,
- způsob ověření.
Úspěšná simulace je považována za důkaz připravenosti
I dobře proběhlá simulace je pouze zjednodušený model. Neobsahuje skutečnou technickou složitost, dlouhodobé politické tlaky, únavu lidí ani všechny provozní výjimky.
Simulace tedy neslouží jako certifikace nového operating modelu. Snižuje nejistotu a pomáhá vybrat bezpečnější pilot.
Jak začít v praxi
1. Vyberte jeden konkrétní problém
Nesnažte se během jednoho workshopu simulovat celou organizaci. Vyberte jeden důležitý průchod nebo rozhodovací situaci.
Například:
- od strategické priority k backlogu,
- od požadavku k práci týmu,
- práci s prioritami během plánovacího období,
- řešení cross-team závislostí,
- reakci na urgentní práci,
- první plánování nového ARTu nebo Tribe.
2. Formulujte hypotézu
Hypotéza může znít například:
Předpokládáme, že Product Management dokáže rozhodnout o prioritách bez další eskalace na leadership.
Nebo:
Předpokládáme, že týmy dokážou během společného plánování identifikovat hlavní závislosti a upravit podle nich svůj plán.
Hypotéza pomůže určit scénář, účastníky i to, co má facilitátor pozorovat.
3. Připravte několik realistických položek práce
Pro první simulaci obvykle stačí pět až deset položek. Měly by se lišit hodnotou, velikostí, připraveností a závislostmi.
Jedna položka může být nejasná. Dvě mohou soutěžit o stejnou kapacitu. Jedna může mít vysokou hodnotu, ale dlouhou dobu realizace. Jiná může být malá, ale regulatorně povinná.
Pokud používáte více úrovní backlogu, nesimulujte je pouze jako formální hierarchii. Každá úroveň musí mít jasný účel a vlastní rozhodovací okamžik. Více o tomto problému popisujeme v článku Requirement, Feature, Story: proč nestačí mít hierarchii v Jira.
4. Stanovte role, kapacitu a základní pravidla
Nepřipravujte dvacetistránkovou metodiku. Účastníci potřebují pouze pravidla, která skutečně testujete:
- kdo může prioritizovat,
- jak se práce dostává do systému,
- kolik práce lze zahájit,
- kdy se zapojují týmy,
- jak se řeší změna,
- co znamená dokončení.
5. Spusťte první kolo bez přílišné pomoci
Facilitátor by neměl okamžitě opravovat každé nedorozumění. Právě rozdílná interpretace pravidel je důležitým zjištěním.
Jeho úkolem je pozorovat, zaznamenávat a podle potřeby připomínat čas nebo omezení scénáře.
6. Proveďte strukturovaný debrief
Debrief může mít čtyři kroky:
- Co se stalo? Popisujeme pozorovatelná fakta.
- Proč se to stalo? Hledáme podmínky a pravidla systému.
- Co jsme předpokládali? Pojmenujeme nepotvrzené hypotézy.
- Co změníme a ověříme? Vybereme jeden další experiment.
7. Pokračujte pilotem v reálném prostředí
Rozumná posloupnost není:
návrh → plošná implementace.
Bezpečnější cesta vypadá spíše takto:
návrh → simulace → úprava → malý pilot → měření → další adaptace.
Pokud připravujete nový ART, Tribe nebo první společné plánování více týmů, simulace může odhalit problémy s rolemi, backlogem a závislostmi ještě před ostrým startem. Podobné situace řeší služba ART / Tribe Launch & PI Planning.
Simulace není konec transformace. Je to první bezpečný test
Dobře připravená simulace nedokáže zaručit úspěch transformace. Neodhalí všechny technické komplikace, dlouhodobé mocenské vztahy ani každou situaci, která nastane v reálném provozu.
Dokáže ale velmi rychle ukázat, zda:
- lidé stejně rozumějí navrženým rolím,
- odpovědnost odpovídá rozhodovací pravomoci,
- práce dokáže projít systémem bez zbytečného čekání,
- týmy umějí spolupracovat na společném výsledku,
- organizace skutečně prioritizuje,
- nový model zvládne změnu bez nekontrolovaného růstu rozpracovanosti.
Největší hodnotou simulace často není hotová odpověď. Je jí společná zkušenost leadershipu, produktových rolí a týmů. Místo abstraktní diskuse o tom, jak by měl systém fungovat, mohou mluvit o konkrétní situaci, kterou právě společně zažili.
Organizační diagram ukáže, kdo kam patří. Simulace ukáže, zda spolu tito lidé dokážou učinit rozhodnutí a dokončit hodnotný výsledek.
Čím větší zásah do rolí, týmů, prioritizace a rozhodování připravujete, tím méně byste se měli spoléhat na to, že všechny důležité problémy objeví až ostrý provoz.
Nejste si jisti, co přesně potřebujete otestovat?
Pokud leadership, produktové role a týmy popisují současný problém každý jinak, nemusí být simulace úplně prvním krokem. Nejdříve může být potřeba sjednotit pohled na realitu, pojmenovat hlavní systémové překážky a vybrat hypotézu s největší pákou.
K tomu slouží například Agile Reality Check, který propojuje dostupná data, rozhovory, pozorování a společný workshop do prioritizovaného backlogu zlepšení. Simulace pak může být jedním z nástrojů pro ověření vybraného návrhu.
Chcete si agilní principy vyzkoušet v bezpečném prostředí?
V Agile Brothers Academy postupně zveřejňujeme praktické simulace, mikrokurzy, toolkity a taháky pro situace, které se v týmech a transformacích opakují.