19 nápadů, jak na KPIs agilních týmů, a příklady, jak je nedělat

Na přelomu let opět nastal ve firmách čas pohovorů. Oblíbené zhodnocení práce za poslední rok a návrh nových cílů spolu s jejich KPIs (Key performance indicators).

V té době to pro mě bylo téma týdne. A byly to věru zajímavé KPIs:

• Tvým cílem je udělat roční pohovory s podřízenými i příští rok. Huh? Jasné, však jsem tým lídr, ne?
• Požadavky musíš mít připravené na 100 %. Huh? A co výzkumná témata, chyby, strategický rozvoj produktu?
• Musíte dodat, co jste slíbili na začátku sprintu. Vždyť právě proto děláte Scrum. Huh? A co když klient chce změnu během sprintu?
• Vaše velocity musí růst. Huh? A co takhle stabilizovat se, abychom uměli lépe plánovat a slíbit, co se dá?
• Vaše velocity musí být nejméně 46 story points. Huh???
• Musíte využívat kapacitu týmu na 100 %. Huh? A víš, jak vypadá dálnice zaplněná na 100 %?
• Musíte naplnit cíle produktu, tedy vydělat víc. Huh? Ale já jsem vývojář, ne prodejce.
• Storypointy jsou fajn, ale prodáváme hodiny.
• Upřesnit estimaci. Upřesnit!
• 100 % platu dostaneš, když se budeš snažit. Huh? Takže budu táhnout přesčasy, abych dostal to, co mi bylo slíbeno? Možná mi stačí makat na 80 % a přesto mám dost. Kašlu na to. Alespoň budu mít čas na jiné věci.
• QA, nesmíte nic pustit v prvním kole. Určitě ne tolik chyb (tohle miluji!).
• QA, musíte najít chyby! Miluji na druhou.

A tak místo toho, abyste pomocí KPIs motivovali k dosažení funkčního výsledku, učíte lidi odrbávat statistiky.

Protože velocity lze zvýšit tak, že jednoduše všechny storypointy vynásobíme dvěma. Bum. 200% ečívment.

Protože požadavky vám odklepne tým, který je na vás naštvaný za systém, který vám Product owner nepomůže připravit je správně. A readiness je najednou green.

Nebo pokud vás nezajímá velocity, tak dostanete hodiny. Zapomeňte však na předvídatelnost a spolupráci.

Kapacita na 100 %? Ok, ani jeden sprint však nebude dokončen. Nebo typicky Velocity < Kapacita. A raději méně dokončit a dodat, než hodně rozpracovat a přesouvat mezi sprinty.

Upřesnit odhady? Aha, storypointy nejsou přesné, proto hodiny. Proto dlouhé mítinky pro stanovení odhadů. A proto ztráta části života.

Musíš najít chyby? Vždy se najde něco na okraji propasti. A když ta reálně nenastane v praxi, k čemu to testovat? A tak tým opravuje zbytečnosti.

Definujte si správné cíle s pomocí OKR

Vše ve firmě by mělo směřovat ke společné vizi. Tu je třeba rozbít na několik menších a dosažitelných cílů, následně identifikovat očekávané výsledky a potom aktivity vedoucí k cílům. A měřit. Pomoci vám může i OKR (Objectives and Key Results) metoda.

Identifikujte skutečné příčiny problémů, ne symptomy

Root Cause Analýza je přesně tím nástrojem, který vám s tím pomůže. Existuje několik metod pro RCA, zmiňme například. 5 Why, Pareto diagram nebo Causal Loops Diagram.

Příklad níže je jednoduchým znázorněním brainstormingu, během něhož jsme se s klientem pokusili hlouběji pochopit nespokojenost jeho zákazníků a možné příčiny.

Diagram byl nakreslený v ScrumDesk Start! RCADesk.

Jak tedy nastavit KPIs

Aktivity by měly propojit cíle s problémy a lidmi. KPIs by tedy měly měřit tuhost propojení lidí, produktů a firmy.

Možná právě proto má větší smysl:

1. Identifikovat problémy a jejich root cause příčiny. Nastavit KPI pro měření jejich odstraňování.
2. Nejprve si ujasnit cíle firmy.
3. Potom nastavit cíle produktů, aby podpořily cíle firmy.
4. Pak nastavit cíle týmu, aby podpořily cíle produktu, spolupráci v týmu, péči a podporu členů týmu navzájem, komunikaci.
5. Pracujte na vlastnostech, které nejsou waste.
6. Měřit výstup celku, ne člena týmu.
7. Výsledek musí naplňovat dohody. Měřte, jak se dohody dodržují.
8. Nezapomínejte na Kaizen. Jak se kontinuálně sbírají, vyhodnocují a realizují zlepšení.
9. Je důležitý throughput, time to market nebo dodaná hodnota?
10. Navažte KPIs týmu na hodnocení produktu klienty, uživateli (např. přes Net Promoter Score).
11. QA musí odpovídat za stejné parametry jako tým. Hmm, vlastně v Agile by QA oddělení ani nemělo existovat, vždyť jsou součást týmu. Nebo ne?
12. Product owner je člen týmu. Nemůže táhnout jiným směrem kvůli svým KPI.
13. To samé stakeholdeři. Nesmějí mezi sebou bojovat kvůli svým osobním cílům, ale cílům firmy. Musí se spolupodílet na výsledku firmy. Jinak tým roztrhají v malých válkách.
14. Kvalita na prvním místě. Proto odstraňte odpad.
15. Vyhodnocujte odstraňování problémů identifikovaných v root cause analýze.
16. Podporujete vzdělávání a komunikaci v týmu.
17. Nastavte si cíle členů týmů tak, aby se z nich stal interdisciplinary tým.
18. Nastavte cíle tak, aby se tým neuzavřel do sebe, ale aby tým trápila dodávka celého řešení i v případě, že se na něm podílí více týmů.
19. Častost dodávek. Neboť často znamená rychleji, obratněji, automatizovaně, otestovaně, průběžně akceptováno.