Myšlenky
& postupy

Organizační struktura, nové role a procesní diagram ještě neznamenají, že bude nový způsob práce fungovat. Dobře připravená simulace dokáže během několika hodin odhalit nejasná rozhodnutí, skryté závislosti, fronty práce i rozdíl mezi deklarovanou a skutečnou pravomocí. Podívejte se, jak agilní transformaci otestovat nanečisto a převést zjištění do konkrétních experimentů.

LACE může mít plný backlog školení, metodik a transformačních aktivit, zatímco se způsob rozhodování a dodávání práce téměř nemění. Podívejte se, jak má transformační tým pracovat s reálnými překážkami, leadershipem, experimenty a měřením dopadu.

Spillover rate ukazuje, kolik naplánované práce tým ve sprintu nedokončil. Samotné číslo ale neřekne, zda je problém v plánování, velikosti stories, změnách priorit, vysokém WIP nebo závislostech. Podíváme se, jak metriku správně počítat, interpretovat a použít ke skutečnému zlepšení.

Container Feature může být užitečnou pomůckou pro řízení drobné, technické nebo provozní práce. Stejně snadno se z ní ale stane nekonečný kontejner na nesouvisející Stories, který obchází prioritizaci a vytváří falešný obraz o stavu dodávky. Jak oba případy rozlišit a jak nastavit pravidla, aby Container Feature nezakrývala nefunkční backlog?

Položka backlogu může mít popis, akceptační kritéria, odhad i stav Ready, a přesto ji tým nedokáže plynule dokončit. Praktický test pullability pomocí pěti otázek odhalí, zda je práce skutečně připravená, dostatečně malá, dokončitelná a zda má tým kapacitu i pravomoc ji převzít.

Firmy mají strategii, OKR i backlogy, přesto týmy často pracují na prioritách, které spolu nesouvisejí. Podívejte se, kde se vazba mezi cíli a delivery nejčastěji rozpadá a jak ji obnovit bez další vrstvy byrokracie.

PI Objectives často vzniknou během poslední hodiny PI Planningu, dostanou Business Value a poté na několik týdnů zmizí. Praktický návod ukazuje, jak cíle formulovat, průběžně kontrolovat a používat při rozhodování o prioritách, rozsahu a rizicích.

Mnoho organizací má v Jira pečlivě vytvořenou hierarchii Requirement, Feature a Story. Přesto se požadavky ztrácejí, týmy dostávají nejasná zadání a stejný text se kopíruje mezi několika tickety. Problém totiž obvykle není v konfiguraci Jira, ale v tom, že jednotlivé úrovně nemají jasný účel, vlastníka ani pravidla rozhodování.

Ne každý tým dokáže na začátku sprintu stabilizovat práci a vytvořit smysluplný Sprint Goal. To ale nemusí znamenat, že je málo agilní. Možná pouze potřebuje řídit práci jako flow. Jak poznat rozdíl mezi vědomým flow modelem, Scrumem doplněným o Kanban a obyčejným chaosem?

Neexistuje univerzální sada týmových KPIs. Jinou trojici metrik potřebuje tým s vysokým WIP, jinou tým s pravidelným spilloverem, jinou tým zahlcený supportem a jinou produktový tým, který řeší dopad. Praktický návod, jak vybrat tři metriky podle situace týmu.