Když podniky přecházejí se svými softwarovými řešeními z lokálních systémů do cloudového prostředí, často si kladou za cíl zvýšit svou „agilitu“. Tento posun by se ideálně měl projevit ve všech aspektech mezifiremních procesů, a to napříč celou organizací.
Transformace procesů by mohla být v podstatě snadná, alespoň teoreticky. Lze definovat scrumové rituály a přerozdělit pracovníky do nových rolí, jako jsou scrum master, produktoví vlastníci, vedoucí dodávek a scrumové týmy.
Je možné implementovat nástroje jako Jira, Azure ADO a Miro a stanovit je jako povinné. Avšak, jak postupovat s procesy, které tyto nástroje propojují? A co transformace myšlení, chování a způsobů práce lidí? Je zřejmé, že tento proces nebude probíhat hladce ani rychle. Nyní se zaměříme na důvody, proč tomu tak je.
Co je to iniciativa pro transformaci dodávek a proč ji firmy realizují?
Velká část firem dnes stále operuje podle vodopádového modelu dodávek. To znamená, že:
- Nejprve se naplánuje, čeho má být dosaženo jako finálního produktu a jaké jsou přibližné náklady.
- Následuje fáze sběru požadavků, kde se detailně diskutují všechny aspekty finálního produktu, vznášejí se námitky, analyzují se, schvalují, opětovně projednávají a nakonec potvrzují.
- Celý projekt se odhadne a potvrdí se rozpočtové limity.
- Navrhne se řešení. Uspořádá se série schůzek se zúčastněnými stranami. Vytvoří se různé dokumenty, které zúčastněné strany zkontrolují. Potvrdí se a schválí finální funkční a technický návrh.
- Řešení se implementuje na základě návrhu. Zde se vyvíjí celý finální produkt.
- Začne testovací fáze, během které se provádějí různé typy testů: jednotkové 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 firemní kultuře). Veškeré testování se zdokumentuje a nechá zúčastněné strany zkontrolovat a schválit.
- Řešení se nasadí do produkčního prostředí. Zde začínají cíloví uživatelé pracovat s kompletním finálním produktem.
- Naplánuje se fáze podpory, během které vývojový tým opravuje případné chyby v řešení.
Celý tento proces může trvat několik měsíců až několik let, a jak je vidět, uživatelé spatří výsledky až na jeho konci. Po dlouhém čekání tak nastává okamžik pravdy, nebo neúspěchu.
Pokud se během tohoto dlouhého období něco změní a finální produkt by měl vypadat mírně odlišně, jedná se o situaci, kterou nazýváme žádost o změnu. Návrh musí být znovu otevřen, přepracován a znovu schválen. Tím se celkový časový rámec prodlužuje o další období.
Je jasné, že toto v žádném případě není agilní přístup. Každá změna vyžaduje restart celého procesu.
Přechod k agilnímu přístupu
Jak tedy tuto situaci změnit a přejít k agilnímu modelu? Lidé pracovali v prostředí vodopádového modelu po dlouhou dobu, dokonce staletí. Mají role a povinnosti, které jim vyhovují, a nechtějí měnit zavedený stav. Hlavním důvodem je, že tato změna ve finále znamená ztrátu části moci, kterou dosud měli.
To je hlavní příčinou, proč takovýto posun vyvolává u lidí silný odpor.
#1. Restrukturalizace týmu
Prvním a relativně nejjednodušším krokem je restrukturalizace pracovníků do scrumových týmů. Rozdělte je na základě funkčních oblastí nebo jiného logického rozdělení.
Rozdělení obvykle probíhá bez větších problémů; potíže nastávají, když si uvědomíme, že lidé jsou stále svázáni s původními strukturami. I když jsou součástí nových scrumových týmů, prakticky jimi nejsou. Nadále pracují podle starého 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 především o to, co je třeba začít).
Takže nakonec máte scrumový tým, který není plně oddaný scrumový tým. Jedná se o skupinu lidí, kteří mají nyní jednoduše více práce. Na práci v rámci scrumového týmu není tolik času, kolik vedení očekává.
Zároveň se očekává, že lidé dokončí své stávající aktivity a také toto nové nasazení v rámci scrumových týmů. Je to nastavení odsouzené k neúspěchu již od počátku.
#2. Plánování scrumových rituálů
Nařídit týmům, aby si naplánovaly několik pravidelných schůzek (sprintových rituálů), je snadné definovat a začít. Alespoň za předpokladu, že se vaše scrumové týmy neskládají z pracovníků z 3+ časových pásem (což je běžný případ).
Problém nastává, když se lidé nebudou pravidelně účastnit rituálů. V závislosti na tom, kdo chybí a jak často, se to může vyvinout v různé typy komplikací. Například:
- Pokud se produktoví vlastníci neúčastní plánovacích a zdokonalovacích rituálů, 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 schůzkách chybí scrum masteři, týmu chybí základní orchestrace scrumu a časem se může ztratit.
- Pokud členové vývojového týmu často chybí, nemohou se navzájem synchronizovat a komunikace v rámci týmu je mnohem obtížnější. Pro dohnání zameškaného je potřeba více schůzek, což týmu ubírá další čas.
Nakonec to není nezbytně vina pracovníků, že rituály zanedbávají. Jenom nastavení jim neumožní být na schůzkách (viz výše o paralelních předchozích úkolech).
#3. Stabilita týmu
Můžete mít scrumový tým se strukturou a rituály, 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 se takový tým nemůže opravdu rozvíjet a zlepšovat.
Dále pravděpodobně nikdy nedosáhnete plně nezávislého scrumového týmu, který bude spravovat sprinty jako obvykle. A konečně, budete muset neustále vzdělávat a trénovat lidi v týmu, aby pochopili způsob myšlení a procesy scrumu. Je to vyčerpávající záležitost.
Jedná se o velmi podceňovaný problém, zejména ze strany vedení či managementu společnosti. Nazývat týmy lidí pouze „zdroji“ a plánovat jejich „využití“ od čtvrtletí ke čtvrtletí je rychlá cesta do záhuby.
#4. Nové role pro stejné lidi
Další překážkou, kterou je třeba překonat, je přeřazení stávajících pracovníků 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 produktovými vlastníky. Jedná se o vlivnou pozici v rámci scrumového týmu, ale může být vnímána jako slabší role ve vztahu ke stávajícímu nastavení.
Produktoví vlastníci se najednou musí synchronizovat se scrum masterem nebo s programovými manažery. Jsou stále zodpovědní za obsah, ale ne tolik za procesy dodávek. Tato situace vyžaduje vzdát se některých povinností, které lidé dříve měli, což je těžké přijmout.
#5. Způsoby práce
Tohle je zajímavé a slýchám to docela často – musíme se naučit nové způsoby práce, abychom byli relevantní na rozví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í?
Z mého pohledu je jasné, co tím management myslí – dosáhnout (mnohem) více za kratší čas. Po sestavení scrumových týmů se očekává, že každý člen týmu najednou ze dne na den dosáhne zdokumentovaných přírůstkových výsledků. Pokud tomu tak není, vedení se začne ptát, proč agilní proces nefunguje efektivně.
Vedení z ničeho nic očekává, že se bude počítat každá hodina a že scrumové týmy nebudou mít v podstatě žádný čas nečinnosti, jenom proto, že na to pravděpodobně není prostor, že všechny procesy scrumu budou 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í, jenom 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 ale 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. Opírá se o následující zásady:
- Stabilizované scrumové týmy pracující na nezávislých nevyřízených položkách s jasnými KPI a OKR.
- Produktoví vlastníci, kteří vytvářejí pevné plány a stanovují priority obsahu, který bude dodává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é současně s běžnou prací na vývoji sprintu.
- Pravidelné nasazování do produkce – alespoň jednou za měsíc, ale ideálně po každém dokončení sprintu.
- Monitorování rizik a problémů a komunikace mezi různými scrumovými 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 scrumové týmy, které se ale neustále mění (od čtvrtletí ke čtvrtletí). Investujete čas, abyste tým naučili procesy scrumu, a jakmile to konečně začnou akceptovat a měnit své způsoby práce, reorganizujete týmy na další období. Plány jsou upraveny, posunuty nebo zrušeny.
- Produktoví vlastníci nemají žádné skutečné znalosti detailů plánu a (protože takové praktiky měli v minulosti), zadávají své úkoly týkající se tvorby obsahu pro nevyřízené položky přímo týmu. Výsledkem je, že tým nemá čas na vývoj obsahu, protože musí nejprve zjistit, co vyvíjet.
- 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 produkce opožďuje o několik sprintů.
- Komunikace mezi různými scrumovými týmy je chaotická a neefektivní, protože každý tým musí v každém sprintu zvládnout spoustu aktivit. Produktoví vlastníci mají tendenci přidělovat týmu příliš mnoho obsahu na každý sprint. Tým nemá šanci všechno dokončit, takže je neustále ve stresu z termínů.
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 pohledů na jejich případné překonání.
#1. Správné odpovědnosti pro správné role
Pokud se pokusíte ohýbat definici a rozdělovat odpovědnosti jiným způsobem, než jak by měly být v rámci scrumu/agilního přístupu, celou iniciativu tím znehodnocujete.
- Produktoví vlastníci musí spravovat obsah a udržovat seznam nevyřízených položek. Jsou zodpovědní za nevyřízené příběhy a pokud nejsou příběhy dobře definovány, je jejich odpovědností jednat a napravit to. Na druhou stranu by neměli mít žádný vliv na přidělování pracovníků do scrumového týmu nebo rozhodování o rozpočtu projektu.
- Scrum masteři nenesou žádnou odpovědnost za obsah nevyřízených položek. Jsou v týmu, aby organizovali rituály a vzdělávali tým v agilním způsobu práce. Neměli by být sekretářkami pro produktové vlastníky. Naopak, budou chránit vývojový tým před produktovým vlastníkem a externími zúčastněnými stranami.
- Každý scrumový tým musí mít přiděleného vedoucího dodávky. Tato osoba propojuje PO, SM a vývojový tým do funkčního celku, definuje procesy dodávek a ř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á rozhoduje 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 může každý podávat co nejlepší výkony.
- Odpovědností vývojového týmu je vyvíjet příběhy z nevyřízených položek. Mohou pomoci PO vytvořit obsah pro některé příběhy (zejména ty, které jsou velmi technické), ale nejsou primárně odpovědní, a dokonce by ani neměli být 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í být realizována v rychlém tempu. Nechat tyto znalosti odcházet každých několik měsíců je pro všechny jen ztráta času.
Prvních pět sprintů můžete využít jako období pro učení týmu, aby se seznámil a vyzkoušel základní scrumové aktivity. Jakmile budou jasné pro celý tým, může začít proces neustálého zlepšování scrumového týmu. Pokud se ale pracovníci uvnitř týmu pravidelně střídají, ocitnete se v neustálé smyčce předávání znalostí a školení.
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 tým dříve (před agilní transformací) efektivnější, než se zdá nyní.
Sestavte tým, investujte do znalostí, a jakmile si tým bude jistý novými procesy, nechte ho pracovat a rozvíjet se dále. Odtud začíná neustálá cesta k dokonalosti.
#3. Matice RACI
Je dobré 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 nejasností 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ě se lidé začnou ptát, kdo by měl co dělat v jaké situaci, zejména v těch, které nebyly výslovně řešeny prostřednictvím komunikace týmu.
Následuje příklad matice RACI pro některé odpovědnosti. Váš projekt může mít jinou sadu. Důležité je zachytit ty relevantní.
| Úkol | Žadatel | Vedoucí dodávky | Produktový vlastník | Scrum Master | Vývojový tým |
| Plánování sprintu | C/I | C/I | A | R | I |
| Dodání vydané verze | N/A | I | A/I | C/I | R |
| Sprint Review | C/I | I | R | I | C/I |
| Retrospektiva sprintu | I | I | A/I | R | C/I |
| Zdokonalování nevyřízených položek | I | A/I | R | C/I | I |
Závěr
Ještě by bylo o čem psát, protože cest a míst, kde může agilní proměna selhat, je spousta. Účelem bylo zdůraznit některé problémy, které považuji za často se opakující.
Samotná iniciativa je dobrý nápad. Pokud však nebudou dodržována některá základní pravidla, může se rychle stát noční můrou všech účastníků. Zvýraznil jsem některé z nich, ale používejte zdravý úsudek a budete v pořádku. 🙂
Dále se podívejte na dobré zdroje pro výuku a získání certifikace Agile.