Potřebujete opravdu sprinty? Možná je pro vás vhodnější flow tým

Tým pracuje ve dvoutýdenních sprintech. Má Product Ownera, Scrum Mastera, Sprint Planning, Daily Scrum, Sprint Review i retrospektivu. Formálně tedy všechno vypadá správně.

Přesto se na konci téměř každého sprintu opakuje stejná debata. Několik položek zůstalo nedokončených, část práce se do sprintu přidala až v jeho průběhu a původní plán už po několika dnech neodpovídal realitě.

Product Owner vysvětluje, že nové požadavky nešlo odložit. Scrum Master upozorňuje na vysoký spillover. Management žádá lepší plánování a spolehlivější plnění závazků. Tým mezitím namítá, že pracoval naplno a ve skutečnosti dokončil poměrně hodně práce — jen ne přesně tu, která byla vybrána při Sprint Planningu.

První reakcí bývá snaha Scrum zpřísnit: lépe připravit backlog, přesněji odhadovat, důsledněji chránit sprint a formulovat silnější Sprint Goal.

Někdy je to správná cesta. Jindy ale řešíme špatný problém.

Co když tým nedělá Scrum špatně? Co když se jeho práce jednoduše nechová jako práce vhodná pro řízení ve sprintech?

Ne každý tým pracuje ve stejném typu prostředí

Scrum dobře funguje tam, kde tým rozvíjí jeden produkt, dokáže se soustředit na společný cíl a může významnou část práce na dobu sprintu stabilizovat. Sprint pak vytváří užitečný rámec: tým si vybere, čeho chce dosáhnout, několik dní na tom společně pracuje a následně výsledek zkontroluje se zákazníky nebo stakeholdery.

V praxi ale potkáváme také jiné týmy:

• platformní tým obsluhující několik produktových týmů,
• integrační tým připojující nové systémy nebo trhy,
• tým udržující zralý produkt, do kterého přichází velké množství menších změn,
• supportní tým řešící incidenty a servisní požadavky,
• analytický nebo enablement tým poskytující službu zbytku organizace,
• tým, který kombinuje produktový vývoj, provoz a podporu.

Práce těchto týmů často přichází průběžně. Jednotlivé položky spolu nemusí souviset, mají rozdílnou naléhavost a lze je dokončovat nezávisle. Některé čekají na stakeholdera, jiné na externí systém, testovací prostředí nebo rozhodnutí jiného týmu.

Takový tým může být součástí stejného ARTu nebo stejné delivery organizace jako klasické produktové týmy. To ale ještě neznamená, že musí používat úplně stejný provozní model.

Co je flow tým

Flow tým řídí práci primárně jako průběžný tok od přijetí požadavku po jeho dokončení. Nečeká nutně na začátek dalšího sprintu, aby mohl přijmout novou položku, ani na konec sprintu, aby ji mohl dodat.

Neznamená to ale, že pracuje bez pravidel nebo bez plánování.

Dobře fungující flow tým:

• vizualizuje skutečný postup práce,
• má jasná pravidla pro přijímání nových požadavků,
• omezuje množství rozpracované práce,
• aktivně řeší blokace a stárnoucí položky,
• pravidelně doplňuje a prioritizuje frontu práce,
• sleduje rychlost a stabilitu toku,
• udržuje pravidelné feedback loopy se stakeholdery,
• průběžně zlepšuje svůj způsob práce.

Důležitý je právě rozdíl mezi průběžným tokem práce a průběžným chaosem. Samotná skutečnost, že tým používá Kanban board a nemá pevný sprintový scope, z něj ještě flow tým nedělá.

Flow neznamená konec pravidelného rytmu

Někdy se flow popisuje jako protiklad iterací: buď tým pracuje ve sprintech, nebo nemá žádný rytmus. Takové rozdělení je příliš zjednodušené.

Flow tým může mít například:

• každodenní kontrolu toku práce,
• týdenní replenishment, při kterém vybírá další položky,
• dvoutýdenní review výsledků se stakeholdery,
• měsíční service delivery review,
• pravidelnou retrospektivu,
• čtvrtletní nebo PI plánování širších cílů a významných iniciativ.

Rozdíl spočívá v tom, že všechny tyto aktivity nemusí být uzavřeny do jednoho společného sprintového kontejneru. Dodávání může probíhat průběžně, zatímco plánování, zpětná vazba a zlepšování mají vlastní cadence.

Flow tým není tým bez rytmu. Je to tým, který odděluje rytmus řízení od umělé hranice, přes kterou se musí přelévat veškerá práce.

Jak poznat, že sprinty týmu příliš nepomáhají

1. Významná část práce přichází v průběhu sprintu

Produkční incidenty, malé požadavky zákazníků, onboarding nového trhu nebo technická podpora jiných týmů často nemohou dva týdny čekat. Jestliže tým pravidelně přijímá novou práci bez vědomého rozhodnutí, co ze sprintu naopak odejde, vzniká sprint overcommitment.

Jednorázová změna sprintu není důvodem opouštět Scrum. Jestliže je však průběžný příchod práce stabilní vlastností systému, má smysl položit si otázku, zda sprint skutečně řídí práci, nebo ji pouze dodatečně reportuje.

2. Sprint Goal je pokaždé obecný nebo umělý

„Zpracovat prioritní požadavky“, „pokračovat v onboardingu trhů“ nebo „dodat co nejvíce připravených položek“ nejsou příliš užitečné cíle sprintu. Spíše popisují běžnou službu, kterou tým poskytuje.

Neznamená to, že tým nemá mít směr. Může mít produktové cíle, servisní očekávání nebo výsledky plánované pro celé PI. Jednotlivé položky dokončené během dvou týdnů ale nemusí vždy tvořit jeden společný produktový inkrement.

3. Položky lze dokončovat a validovat nezávisle

Představme si tým, který připojuje jednotlivé trhy k centrální službě. Každý onboarding má vlastní stakeholdery, technická omezení a termín. Dokončení jednoho trhu není závislé na dokončení ostatních.

V takovém prostředí často dává větší smysl průběžně dokončovat nejdůležitější položky než je seskupovat do umělých dvoutýdenních balíčků.

4. Největším problémem je čekání, nikoli nedostatek práce

Mnoho týmů není pomalých kvůli tomu, že by jejich členové málo pracovali. Práce je pomalá proto, že čeká:

• na doplnění požadavku,
• na code review,
• na testovací prostředí,
• na externí tým,
• na rozhodnutí Product Ownera,
• na reakci stakeholdera.

Podrobnější plánování dalšího sprintu takový problém nevyřeší. Tým potřebuje zviditelnit skutečný workflow, omezit rozpracovanost a aktivně řídit stáří a blokace položek.

Kdy Scrum stále dává větší smysl

Bylo by chybou z předchozích příkladů vyvodit, že sprinty jsou přežitek. Pro mnoho produktových týmů jsou velmi užitečným mechanismem fokusu a zpětné vazby.

Scrum zpravidla dává smysl, pokud:

• tým rozvíjí jeden produkt nebo jasně vymezenou produktovou oblast,
• dokáže formulovat smysluplný Sprint Goal,
• většinu práce lze na dobu sprintu stabilizovat,
• členové týmu společně vytvářejí jeden výsledek,
• Sprint Review poskytuje relevantní produktovou zpětnou vazbu,
• největším rizikem je roztříštěnost a ztráta společného cíle.

Scrum navíc nemusíte opouštět jen proto, že tým trápí vysoký WIP nebo dlouhý cycle time. Kanban Guide for Scrum Teams ukazuje, jak lze kanbanové praktiky využít ke zlepšení flow uvnitř Scrumu. Tým může zachovat Sprint Goal, review a retrospektivu a současně zavést WIP limity, aktivní řízení položek a flow metriky.

Taková varianta bývá často lepší než rychlý přechod na nový model. Problém totiž nemusí být ve sprintech samotných, ale ve způsobu, jakým tým uvnitř sprintu pracuje.

Tři rozumné modely fungování týmu

Model 1: Scrum tým s lepším řízením flow

Tým má smysluplný produktový cíl a většinu práce dokáže plánovat. Trápí ho ale příliš mnoho paralelně rozpracovaných stories, dlouhé čekání a spillover.

V takovém případě dává smysl zachovat Scrum a doplnit:

• realistický workflow,
• WIP limity,
• sledování blokovaných a stárnoucích položek,
• cycle time a throughput,
• větší důraz na dokončování než na zahajování práce.

Model 2: Flow tým s pravidelnými cadencemi

Tým poskytuje službu, práce přichází průběžně a jednotlivé položky jsou relativně nezávislé. Sprintový scope nemá velkou řídicí sílu.

Tým proto řídí:

• jednu prioritizovanou vstupní frontu,
• pravidla replenishmentu,
• WIP limity,
• classes of service,
• stárnutí a blokace položek,
• pravidelné review výsledků a potřeb zákazníků.

Takový model odpovídá principům Kanban Method, která pracuje s vizualizací práce, omezením WIP, řízením flow a explicitními pravidly. Nejde tedy jen o používání tabule se sloupci To Do, In Progress a Done. Více popisuje oficiální průvodce Kanban Method.

Model 3: Hybrid podle typů práce

Řada týmů současně rozvíjí produkt, řeší incidenty a obsluhuje menší požadavky. Čistý Scrum ani čistý flow model pak nemusí stačit.

Tým může například:

• držet Sprint Goal pro hlavní produktovou změnu,
• rezervovat část kapacity na support,
• mít samostatnou expedite lane pro skutečně kritické incidenty,
• stanovit jasná pravidla pro změnu sprintového scope,
• sledovat podíl plánované a neplánované práce.

Hybridní model ale potřebuje explicitní pravidla. Jinak se z něj rychle stane systém, ve kterém je všechno prioritní, všichni pracují na několika věcech a žádný plán není důvěryhodný.

Flow tým uvnitř ARTu

Téma bývá citlivé hlavně ve větších agilních organizacích. ART potřebuje společný rytmus, plánování a transparentnost. Z toho ale nevyplývá, že všechny týmy musejí každodenní práci řídit totožným způsobem.

Flow tým se může během PI Planningu zavázat k:

• hlavním outcomes nebo PI Objectives,
• významným features,
• servisním očekáváním,
• řešení klíčových závislostí,
• rezervované kapacitě pro určité typy práce,
• zlepšení konkrétní flow nebo quality metriky.

Menší operativní položky pak může vybírat průběžně podle aktuální priority a dostupné kapacity. Také SAFe pracuje s týmovým backlogem jako s Kanban systémem pro správu stories a enablerů. Společný plánovací rytmus tedy nemusí vylučovat průběžné řízení toku práce.

Důležité je rozlišit úroveň investičního rozhodnutí, delivery a konkrétního inkrementu. Více se tomuto rozdílu věnujeme v článku Tři úrovně řízení práce bez frameworku: investice → doručení → inkrement.

Co by měl flow tým měřit

Jestliže tým opustí hodnocení podle plnění sprintového scope, potřebuje jiný způsob, jak rozpoznat, zda jeho systém funguje lépe.

Na začátku obvykle stačí čtyři základní metriky:

• WIP – kolik položek je právě rozpracovaných,
• throughput – kolik položek tým dokončí za určité období,
• cycle time – jak dlouho trvá dokončení položky od zahájení práce,
• work item age – jak dlouho jsou aktuálně rozpracované položky otevřené.

Podle problému lze doplnit podíl blokované práce, množství neplánovaných požadavků, rework nebo produkční chyby. Podrobnější vysvětlení najdete v článku Flow metriky: co měřit, jak číst čísla a co z toho vyplývá.

Metriky by přitom neměly sloužit k hodnocení jednotlivců ani k vytváření žebříčků týmů. Jejich účelem je pomoci odhalit přetížení, čekání a nestabilitu systému. Právě nevhodné použití čísel je jedním z důvodů, proč se agilní týmy metrik často obávají.

Typické chyby

Přejmenovat chaos na Kanban

Tým zruší Sprint Planning, cíle a review, ale nezavede WIP limity, replenishment ani pravidla prioritizace. Nové požadavky se zadávají přímo jednotlivým specialistům a board obsahuje desítky položek ve stavu In Progress.

To není flow. Tým pouze odstranil původní kontrolní mechanismy, aniž by je nahradil jinými.

Používat Kanban board bez omezení WIP

Vizualizace práce je užitečná, ale sama o sobě nezmění chování systému. Pokud může každý zahájit další položku bez ohledu na aktuální rozpracovanost, práce se bude dál hromadit.

Měřit vytížení místo toku

Snaha udržet každého specialistu neustále vytíženého obvykle zvyšuje počet rozpracovaných položek a prodlužuje čekání. Cílem není, aby byl každý člověk každou minutu zaneprázdněný. Cílem je, aby důležitá práce spolehlivě procházela systémem až do dokončení.

Nechat všechny požadavky vstupovat stejnou cestou

Produkční incident, běžný požadavek zákazníka a několikaměsíční produktová změna nepotřebují stejný způsob řízení. Tým musí rozpoznat typy práce a určit pro ně odpovídající pravidla.

Oddělit tým od produktových a organizačních cílů

Flow není omluva pro fungování jako anonymní ticket factory. Tým stále potřebuje rozumět tomu, komu poskytuje hodnotu, jaké výsledky podporuje a podle čeho se rozhoduje o prioritách.

Rozhodnout o frameworku před diagnostikou problému

Debata „Scrum, nebo Kanban?“ často začne příliš brzy. Nejdříve je potřeba pochopit typ poptávky, zdroje variability, skutečný workflow, blokace a způsob rozhodování. Teprve potom lze vybrat vhodný model.

Jak začít v praxi

Není nutné hned rušit sprinty ani měnit role. Mnohem bezpečnější je spustit krátký diagnostický experiment.

1. Zmapujte skutečné typy práce

Vezměte položky dokončené za poslední dva až tři měsíce a rozdělte je například na:

• produktové změny,
• požadavky zákazníků nebo trhů,
• support,
• incidenty a bugy,
• technický dluh,
• enablement jiných týmů.

Podívejte se, které typy práce dominují, jak často přicházejí a zda je lze předem plánovat.

2. Nakreslete reálný workflow

Nepřebírejte automaticky stavy z Jira. Popište, co se s prací skutečně děje od prvního požadavku až po použitelný výsledek. Zahrňte i čekání na analýzu, rozhodnutí, review, testování a externí závislosti.

3. Změřte výchozí stav

Pro začátek zjistěte:

• aktuální WIP,
• orientační cycle time,
• počet blokovaných položek,
• podíl práce přidané až během sprintu,
• stáří nejstarších rozpracovaných položek.

4. Nastavte jeden nebo dva WIP limity

Nesnažte se hned navrhnout dokonalý systém. Začněte například omezením počtu položek ve vývoji a v review. Jakmile je limit naplněn, tým nezačíná další práci, ale pomáhá dokončit nebo odblokovat to, co už běží.

5. Změňte otázky na denní synchronizaci

Místo postupného reportování jednotlivců se ptejte:

• Co dnes dokážeme dokončit?
• Která položka je nejstarší?
• Co je blokované?
• Kde jsme překročili WIP limit?
• Potřebuje někdo pomoc, aby se práce posunula?

6. Po čtyřech týdnech experiment vyhodnoťte

Porovnejte WIP, cycle time, stáří položek, počet dokončených výstupů a kvalitu. Zeptejte se také týmu a stakeholderů, zda je systém transparentnější a zda se priority řeší vědoměji.

Teprve na základě těchto poznatků rozhodněte, zda:

• zachovat Scrum a doplnit flow praktiky,
• přejít na flow model s vlastními cadencemi,
• nebo vytvořit řízený hybrid podle typů práce.

Nezačínejte otázkou „Máme používat Scrum, nebo Kanban?“ Začněte otázkou „Jaký problém má náš systém práce vyřešit?“

Závěrečné shrnutí

Ne každý agilní tým potřebuje řídit veškerou práci prostřednictvím sprintů. Některým týmům iterace poskytují důležitý fokus, společný cíl a pravidelnou produktovou zpětnou vazbu. Jiné týmy obsluhují průběžný tok relativně nezávislých požadavků a větší užitek jim přinese řízení WIP, priorit, blokací a rychlosti dokončování.

Rozhodující není, zda se tým označuje jako Scrum nebo Kanban tým. Podstatné je, zda má vědomě navržený systém práce, který odpovídá jeho realitě.

Zdravý flow tým není méně disciplinovaný než Scrum tým. Potřebuje jasný vstup práce, explicitní pravidla, omezenou rozpracovanost, pravidelnou zpětnou vazbu a data pro zlepšování. Bez nich se z flow stane pouze pohodlný název pro chaos.

Stejně tak ale nemá smysl nutit všechny týmy do stejného sprintového modelu jen proto, aby se dobře vešly do jednotného reportingu.

Agilita se nepozná podle kalendáře ceremonií. Pozná se podle toho, zda tým dokáže soustředit kapacitu, rychle získávat zpětnou vazbu a spolehlivě dokončovat hodnotnou práci.