V minulém díle jsme popsali měření Agilní mechaniky i rizika, která tento způsob přináší. V tomto díle si popíšeme, jakými cestami jsme se v praxi pokusili tyto rizika eliminovat. 

První způsob spočíval v tom, že jsme vzali ceremonie a artefakty z Agilní mechaniky a obohatili je o principy, které za nimi stojí. Při hodnocení jsme se tedy místo jejich provádění zaměřili na naplňování jejich smyslu.

Pojďme si to ilustrovat na dvou příkladech ceremonií ze SCRUMu – Stand-upu a Retrospektivě.

Stand-up

Zkuste si v týmu položit jednoduchou otázku – proč vlastně Stand-up děláme? Slyšet můžete odpovědi jako:

• Abychom si řekli, co jsme dělali včera, co budu dělat dnes a zda mám nějaké překážky
• Abychom si zkontrolovali, kolik toho kdo udělal

Tyto odpovědi jsou poměrně běžné a přesto ani jedno není smyslem Stand-upu. První je knižní popis toho, co je Stand-up, a druhé je něco, kam Stand-up často sklouzne v případě micro-managementu.

👉Smyslem Stand-upu je společné sladění na aktuálním přírůstku, jestli postupujeme tak, jak jsme předpokládali a zda něco třeba nemáme změnit. Například vypomoci si na náročném úkolu, změnit prioritu či přeuspořádat aktuální práci, abychom dosáhli našeho cíle.

V praxi to poznáte např. podle následující diskuse:

Člen týmu 1: ”Včera jsem začal implementaci toho výpočtu provizí, dneska bych to do oběda dal.”

Člen týmu 2: ”Super, tak já to napojím v aplikaci, cca kolem 13:00 to bude na testovacím prostředí.”

Člen týmu 3: ”Tak já to odpoledne otestuji, takže by ta funkcionalita Zobrazení nápočtu provizí mohla být dnes celá hotová.”

Takto nějak může vypadat Stand-up týmu, který má smysl. Poznáte to například i tak, že dané členy nemusíte o smyslu Stand-upu přesvědčovat, vědí ho sami.

Další příklad naplněného smyslu Stand-upu a zároveň vyspělosti týmu:

Člen týmu 1: “Týme, dnes toho na mně fakt není moc, mám práci tak na 2 hoďky.”

Člen týmu 2: “Super, to bys mi mohl/mohla pomoci s…”

Další příklady toho, co pozorovat pro vyhodnocení úrovně Stand-upu nebo tipy jak Stand-up dělat smysluplně, naleznete v našem předchozím článku Mistrovství v Daily Standupech. 

Retrospektiva

Stejně jako v případě Stand-upů si můžeme položit otázku – proč děláme Retrospektivu? Typické odpovědi bývají:

• Abychom si řekli, co šlo dobře, co šlo špatně a vydefinovali si akční kroky
• Protože je dobré se občas zastavit a podívat se jak fungujeme

Ano, ale proč? Co tím chceme získat? 

👉Chceme se příští Sprint posunou nejen k našemu cíli (přírůstek hodnoty, např. funkcionality), ale i ve způsobu, jak se k tomuto cíli dostáváme (např. Way of Working – způsob práce v týmu, stav prostředí, ve kterém pracujeme, vztahy, které máme mezi sebou a vztahy s okolím, překážky na naší cestě a obecně neefektivita, která nás zpomaluje.) 

Příklad smysluplné debaty během Retrospektivy:

Člen týmu 1: “Posledně jsme na Retrospektivě řešili testovací prostředí – ví někdo, kam se to hnulo?”

Člen týmu 2: “Řeší se to, mluvil jsem s Jirkou a příští měsíc se nakoupí nová železa a kluci už mají otestovaný auto deployment. V pondělí budu vědět, kdy s tím můžeme počítat.”

Smysluplné Retrospektivy vypadají tak, že se členové týmu zapojují do konkrétních akcí / řešení a nečekají, že to za ně někdo vyřeší. Zároveň se tým k těmto akcím vrací a vyhodnocuje jejich dopad – přineslo nám to výsledek, které jsme potřebovali?

Jeden z dalších projevů vyspělých Retrospektiv je experimentování s různými formáty. Nikde není řečeno, že Retrospektiva má jediný správný formát (např. klasické 1. Co šlo dobře a 2. Co chceme zlepšit). V praxi se nám potvrdil opak – rutina zabíjí zlepšování a různé formáty nabízí nové podněty. Inspirovat se pro nové formáty Retrospektiv můžete v článku Rozpalte vaše retrospektivy! Oblíbeným zdrojem inspirace pro Retrospektivy mohou být také internetové portály jako je např. Retromat.

Obohacení o smysl má větší vypovídací hodnotu, ale je náročnější

Vzít jednotlivé ceremonie (Standup, Retrospektiva, Refinement, Planning, Review) a obohatit jejich hodnocení nám dává mnohem lepší obraz o úrovni Agility a zároveň je mnohem lépe vnímán na straně týmu – více se bavíme o tom proč se daná schůzka / aktivita děje než že se má prostě dít. Sledování smyslu nás ale něco stojí. V praxi to totiž vyžaduje:

• Čas, neboť vyhodnotit si smysl zabere několikanásobně více času, než prostá kontrola existence meetingu nebo záznamu v Jiře.
• Senioritu člověka, typicky Agilního kouče či Scrum Mastera – ten má zažito dost na to, aby byl schopen z prosté diskuse v týmu vyhodnotit naplnění smyslu dané ceremonie.
• Senioritu týmu a okolí – jestliže seniorní Agilní kouč vyžaduje naplňování smyslu, ne jen prosté mechanické provádění schůzek, musí mu tým rozumět – být na podobné úrovni seniority.

Pro juniornější týmy a Agilní kouče pak existuje cesta v podobě Self-checku, který jsme popsali v minulém díle. Tento Self-check připraví zkušení Agilní koučové. Do něj je možné promítnou “senioritu” v tom, jaké chování chceme u týmu pozorovat.

Krom potřeby seniority a časové náročnosti nás zásadně limitovala svázanost s konkrétní metodikou – viz příklady ze SCRUMu výše. Důsledkem bylo, že jsme nemohli použít stejný způsob hodnocení napříč týmy, které používaly jinou metodiku než SCRUM a přesto byly Agilní. 

Hodnocení principů z Agilního manifesta

Šli jsme tedy v úvahách zpět ke kořenům. Kde je definováno, co je to Agilita? V Agilním manifestu (https://agilemanifesto.org/.) Zde je definováno 12 principů (https://agilemanifesto.org/principles.html), které musí splňovat jakákoliv metodika, procesní rámec, ať už je to SCRUM, Kanban, či cokoliv dalšího.

Vzali jsme tedy těchto základních 12 principů z Agilního manifesta a postavili na nich měření Agile maturity následujícím způsobem:

1. Principy jsme přepsali do srozumitelné formy s velkým citem pro to, abychom nezaměnili a neohnuli smysl principu v něco jiného.
2. Spustili jsme pilot na části firmy a na základě zpětné vazby (srozumitelnosti) jsme udělali úpravy.
3. Rozšířili jsme na celou firmu s pravidelným vyhodnocováním.

Konkrétně v T-Mobile a Slovak Telekom jsme vytvořili následující přepis Agilních principů:

Tuto tabulku pravidelně vyplňují Agilní koučové se svými týmy podobně, jako jsme v minulém díle popsali u Self-checku. Nosné jsou hlavně diskuse, které tato hodnocení spouští a sledování trendu. Koučové také dbají na to, aby všichni pochopili, že jde o nástroj, který má sloužit hlavně týmu a že výsledky jsou mezi týmy neporovnatelné. Stávají se garanty bezpečného prostoru, aby takové hodnocení vůbec mohlo probíhat.

Výhody a nevýhody sledování Agilních principů 

Způsob sledování Agilních principů nám umožnil zaměřit se na to podstatné za Agilní mechanikou a díky tomu, že se tento způsob neopírá o konkrétní metodiku, jsme schopni toto měření aplikovat na všechny týmy. 

Dále se nám v praxi ukázalo, že tento způsob oproti sledování prosté mechaniky:

• Vyžaduje vyšší senioritu v pochopení těchto principů jak koučů tak v týmu – hodně úsilí se tak musí věnovat zkompetentňování koučů a týmů (stejně jako v předchozím sledování smyslu.)
• Poskytuje výstupy na úrovni systémového fungování – např. se nám během hodnocení v týmech ukázala přetíženost lidí díky bodu 8., jinde zase zcela chybělo zastoupení byznysu v týmech díky bodu 4. – což je podstata Agility.
• Má smysl vyhodnocovat spíše v delším časovém horizontu – měsíční či kratší frekvence se nám zatím moc neosvědčila (po chvíli se z toho stává rutina bez přidané hodnoty); optimum může být kvartál či půlrok.

V dalším článku se podíváme na poslední způsob, jak sledovat Agilitu – a to naplňování (business) cílů.