Měření agilní “mechaniky” je nejjednodušším a nejpřímočařejším měřením, které lze ve firmě zavést. Jednoduchost je vykoupena riziky, o kterých jsme se zmínili v úvodním článku.
⚠️ Před časem bychom tohle měření jako Agilní koučové zakázali. Důvodem je právě skutečnost, že tohle měření nejde po smyslu, ale pouze po mechanice provádění. Vznikají pak mylné představy typu: máme Stand-upy, děláme Sprinty a pravidelně se potkáváme na Retrospektivách = jsme Agilní…
Nyní říkáme, že s velkou opatrností a znalostí, proč a co děláme, lze měření mechaniky použít.
Prosím čtěte pozorně až do konce tohoto dílu.
V praxi se jedná o měření artefaktů, ceremonií či praktik, které vychází z konkrétní metodiky – typicky SCRUM nebo Kanban. Proto je toto měření jednoduché a využíváme ho hlavně na začátku při zavádění metodiky do týmu či organizace.
Měření Scrum
Stand-upy
Díváme se na četnost, délku, případně na průběh Stand-upů.
Review
Měříme, zda existuje a zda se účastní zákazník či Stakeholder, případně celý tým.
Retrospektiva
Hodnotíme, zda Retrospektivy probíhají po každém Sprintu, generují se akční kroky a plníme je.
Sprint
Zde revidujeme, zda jsou Sprinty časově ohraničené a mají stabilní délku (typicky 2 týdny), mírně pokročilé je kontrolovat, zda User stories nepřepadávají do dalších Sprintů či zda definujeme Sprint goals a máme Definiton of Done, případně Definition of Ready.
👉 Inspirací pro vás může být SCRUM checklist od Henrika Kniberga, který jsme popisovali v jednom z dřívějších článků: https://www.rainfellows.com/cs/scrum-checklist-seznam-scrum-praktik-od-henrika-kniberga/
Měření Kanban praktik
Jelikož je Kanban poněkud volnější v definici a pro některé mylně jednodušší, různí se i metriky, které se pro měření Kanban praktik používají. Mezi nejběžnější patří:
Kanban cadences
Kontrolujeme, které ze 7 cadences držíme (Kanban Meeting, Delivery Planning Meeting, Operations Review, Risk Review, Service Delivery Review, Strategy Review, Replenishment Meeting).
Kanban vizualizace
Měříme, zda existuje a je používána Kanbanová tabule minimálně se třemi používanými stavy (ToDo, In Progress, Done).
Kanban metriky
Hodnotíme, zda máme zavedeny Kanban metriky, jako je WIP limit (work in progress), Lead time, Cycle time.
Value stream mapping
Kontrolujeme, zda jsme s týmem vytvořili Value Stream Mapu, identifikovali potenciální ztráty (Wastes) a vygenerovali jsme kroky na jejich minimalizaci.
Rizika a co s nimi
Metriky uvedené výše je poměrně jednoduché měřit a vyhodnocovat. Nezaručují však samy o sobě Agilitu či posun k Agilnímu způsobu práce, ale plnění konkrétních kroků z konkrétní metodiky. Proč nezaručují Agilitu?
- Můžete mít krátké a pravidelné Stand-upy, které nevedou k cíli, a sice ke sladění týmu na posunu daného přírůstku práce.
- Můžete pracovat ve Sprintech a v nich dělat malé “Waterfally”.
- Můžete vizualizovat tasky na Kanban boardu, ale nevidět ztráty, protože jsou skryté v In Progress.
- Můžete plnit všechny akční body z Retrospektiv, ale nikam se neposouvat, protože jsou nesmyslné.
- Můžete…
Nehodnotíme totiž reálný dopad, smysl (outcome), ale provedení (output).
❓Proč tedy tuto možnost měření Agilní mechaniky uvádíme a dává vůbec někdy smysl?
👉Dává a sice jako pomůcka začínajících týmů či pro připomenutí po nějakém čase.
Pokud totiž tým nedělá Retrospektivy, pak je velká pravděpodobnost, že nepřemýšlí nad tím, zda je styl jejich práce efektivní a těžko něco zlepší. Pokud tým nemá vizualizaci postupu tasků v Kanban boardu, tak zřejmě velice těžko objeví ztráty či aplikuje Kaizen (drobná vylepšení) ke zlepšení efektivity práce.
Jedním z řešení, jak eliminovat rizika spojená s tímto způsobem měření, je nehodnotit pouhé provádění procesu, ale hodnotit chtěné chování, které odráží skutečný stav Agilní vyzrálosti (“Maturity”).
Ukážeme si to na dalším příkladě.
Team self-check
Na základě Retrospektivy či identifikace úzkých míst, které jsou mapované na příslušné praktiky/techniky, vytvoříme sadu tvrzení, která tým pravidelně hodnotí a sleduje, zda se posouvá z aktuální situace (Počáteční stav) až k cílovému stavu (Cíl).
Vše osvětlí konkrétní příklad:
Konkrétní tvrzení ve sloupečku Počáteční stav vychází z popisu aktuální situace. Cíl pak vychází z konkrétní Agilní praktiky či principu, který za danou praktikou je. Postačující je pak popis “dost dobrého stavu”, který může být kompromisem, který nám ale stačí pro zásadní zlepšení aktuálních problémů.
Tým následně hodnotí na škále 1-5 stylem Planning poker – tj. všichni najednou odhalí své hodnocení, a pokud není shoda, nebo je medián příliš nízký, pak dochází k diskuzi v týmu, sdílení různých pohledů a dohodě, co s tím.
Toto hodnocení probíhá pravidelně jako součást Retrospektiv a součástí je i generování akcí, které nás posunou k vyššímu hodnocení příště. Neboli tým si klade otázky:
- Na jakém stupni se chceme hodnotit příští Retro?
- Co k tomu potřebujeme udělat/změnit/zajistit → akce do Backlogu na příští cyklus.
Závěr
Měření Agilní mechaniky může být užitečné, obzvláště v počáteční fázi zavádění Agility. Je to však podmínka nutná, nikoli postačující. Proto rozhodně doporučujeme kombinovat s dalšími typy měření – např. sledovat chtěné chování.
Dalším možností je kombinovat Měřením Agilních principů, ale o tom si povíme v příštím článku.
Autoři článku: Marek Hersan a Roman Šmiřák
