Proč Kanban funguje – a jak poznat, že je na něj váš tým připravený

Většina týmů přijme Kanban proto, že někdo přečetl článek na blogu. Chytřejší otázka zní, zda problémy, které Kanban řeší, jsou skutečně problémy vašeho týmu.

Většina týmů zná ten okamžik, obvykle když jich je víc než osm nebo devět. Práce se dělá – e-maily odcházejí, funkce se dodávají, klienti jsou obslouženi – ale nikdo nemá jasnou představu, co dělají ostatní. Projekty se hromadí. Něco se slíbí a pak to tiše upadne v zapomnění. Před každou poradou strávíte dvacet minut zjišťováním, kde vlastně nějaká práce je. Odpověď je obvykle „někde“.

To je problém, který měl Kanban řešit. Ne problém stanovení strategie, najímání správných lidí nebo budování kultury, ale konkrétní, vleklý provozní problém: vědět, na čem tým pracuje a co mu v tom brání.

Na nástroj, který přitáhl tolik pozornosti, je překvapivě skromný. Kanban netvrdí, že napraví vaši organizaci. Jen zviditelní práci. A ukazuje se, že viditelnost, uplatňovaná důsledně, mění překvapivě mnoho věcí v dalším řetězci.

Odkud se Kanban vlastně vzal

Slovo je japonské – znamená „štítek“ nebo „tabule“ – a systém vyvinula Toyota na konci čtyřicátých let jako způsob řízení zásob ve svých továrnách. Myšlenka byla jednoduchá: místo výroby dílů podle pevného plánu je továrna vyráběla jen tehdy, když navazující stanoviště signalizovalo, že je potřebuje. Fyzická karta – kanban – putovala zpět po lince jako požadavek. Nic se nevyrábělo do zásoby. Nic se zbytečně nehromadilo.

Poznatek, který měla Toyota a který si později půjčily softwarové týmy, zní: většina neefektivity v systému nevzniká tím, že lidé pracují příliš pomalu, ale tím, že se dělá špatná práce ve špatný čas. Příliš mnoho věcí rozdělaných najednou. Úzká místa, kterých si nikdo nevšimne, dokud není pozdě. Práce, která leží hotová na jednom místě, zatímco další krok se jinde topí.

Softwaroví vývojáři, zejména ve firmách jako Microsoft na počátku nového tisíciletí, začali tyto myšlenky přizpůsobovat znalostní práci. Karty se staly úkoly. Výrobní stanoviště se staly fázemi pracovního postupu. A tabule se stala nástěnkou – nejprve fyzickou, pak digitální – na které kdokoli z týmu na první pohled vidí, co se řeší, co čeká a co je hotovo.

Co vám Kanban nástěnka vlastně ukazuje

Základní Kanban nástěnka má tři sloupce: K řešení, Rozpracováno a Hotovo. Pro mnoho malých týmů to stačí a je to dobrý začátek. Skutečná hodnota se ale objeví, když tyto fáze upravíte podle toho, jak vaše práce skutečně teče – ne podle toho, jak byste si přáli, aby tekla.

Obsahový tým může použít: Nápad, Zadání, Rozepsáno, Revize, Naplánováno, Publikováno. Softwarový tým může „Rozpracováno“ rozdělit na samostatné sloupce pro vývoj, code review a QA. Poradenský tým může sledovat Průzkum, Nabídka, Probíhá, Čeká na klienta a Uzavřeno. Fáze by měly odrážet skutečná předání a skutečné čekací doby – místa, kde práce mění ruce nebo kde leží, dokud se něco jiného nestane.

Všimněte si karty v prostředním sloupci – zpráva o auditu skladu, osmý den, označená jako blokovaná. V systému bez nástěnky by ten úkol mohl ležet další dva týdny, než si někdo uvědomí, že se nehýbe. Někdo čeká na třetí stranu. Nebo je potřeba rozhodnutí manažera, který neví, že je tou překážkou. Nástěnka blokaci zviditelní. A to je většina práce.

Pravidlo, díky kterému to funguje: limity WIP

Pokud existuje jeden koncept, který odlišuje týmy používající Kanban správně od týmů, které mají jen hezčí seznam úkolů, jsou to limity rozpracované práce – zkráceně limity WIP. Myšlenka je, že každý sloupec má maximální počet položek, které v něm mohou být najednou. Když je sloupec plný, nemůžete přidat další práci, dokud se něco neposune dál.

Zní to proti intuici. Jistě když můžeme rozdělat víc úkolů, uděláme víc? Neuděláme. Když lidé pracují na příliš mnoha věcech současně, všechno trvá déle. Přepínání kontextu je drahé. Napůl hotová práce vytváří režii na koordinaci. A když je „rozpracováno“ deset věcí, je velmi těžké poznat, které se skutečně hýbou a které jen vězí, aniž by to bylo vidět.

Limit WIP nastavený na tři ve sloupci Rozpracováno znamená, že když na něčí stůl přijde čtvrtá věc, musí někdo v týmu rozhodnout: který stávající úkol se dokončí první? Nutí to stanovit priority. Nutí to mluvit spolu. A zpravidla to vede k rychlejšímu dokončování jednotlivých položek, i když se tempo zahajování nových zpomalí.

Kanban versus Scrum: otázka, kterou si týmy kladou vždy

Pokud jste se pohybovali kolem softwarových týmů nebo moderního řízení provozu, pravděpodobně jste narazili na Scrum – rámec, který organizuje práci do pevných dvoutýdenních sprintů s plánováním, retrospektivami a definovanými rolemi jako Scrum Master a Product Owner. Mnoho týmů bere Scrum a Kanban jako konkurenční metodiky a cítí, že si musí vybrat. Rozdíl je ve skutečnosti jednodušší.

Mnoho týmů – zejména těch, které nejsou čistě softwarově inženýrské – shledává, že Scrum je zatížený rituály a jeho pevná struktura sprintů se nehodí na průběžnou provozní práci. Marketingové týmy, týmy zákaznického úspěchu, provozní týmy i zakladatelé, kteří řeší všechno najednou, mají jen zřídka práci, která by hladce zapadla do dvoutýdenních cyklů. Kontinuální model toku v Kanbanu jim zpravidla sedí lépe.

Mnoho týmů ovšem obojí kombinuje. Pro vývoj produktu používají plánovací cykly ve stylu sprintů a zároveň vedou Kanban nástěnku pro provozní a podpůrnou práci, která přichází bez ohledu na to, v jakém sprintu právě jste. To je naprosto rozumný hybrid.

Tři otázky, na které by vaše nástěnka měla odpovědět do třiceti sekund

Kanban nástěnka je nejužitečnější, když se na ni podíváte a bez rozhovoru s kýmkoli rychle odpovíte na tyto tři otázky: Na čem tým právě teď pracuje? Kde se práce zasekává? Je něco, co by se mělo dělat, a ještě to nezačalo?

Pokud nedokážete odpovědět na všechny tři do třiceti sekund od pohledu na nástěnku, pravděpodobně není správně udržovaná. Nejčastější selhání je nástěnka, na které se úkoly zakládají, ale nikdy nepřesouvají – stane se hřbitovem dobrých úmyslů místo živé mapy skutečné práce. Neaktuální nástěnka je horší než žádná, protože vytváří falešný pocit přehledu.

Disciplína potřebná k udržování nástěnky je skutečná. Úkoly se musí posouvat, když se posouvá práce. Zablokované položky je třeba označit ve chvíli, kdy uvíznou, ne o dva týdny později. Karty musí mít jasné vlastníky a vlastníci musí své karty aktualizovat. Nic z toho nevyžaduje mnoho času – dobře vedená praxe Kanbanu může zabrat pět až deset minut na člověka denně – ale vyžaduje to důslednost. Nejvíc z Kanbanu těží týmy, které nástěnku berou jako zdroj pravdy, ne jako doplňkové vedení záznamů.

Co Kanban nedělá

Kanban není nástroj pro strategii. Nepomůže vám zjistit, na čem pracovat – jen vám pomůže řídit to, o čem jste už rozhodli. Pokud má vaše organizace problém s určováním priorit, nejasným mandátem nebo problém „začínáme příliš mnoho projektů, než dokončíme staré“, který pramení z chování vedení, a ne z procesu, Kanban nástěnka tyto problémy odhalí, ale nevyřeší.

Také nenahrazuje dobré řízení. Nástěnka nenahradí individuální rozhovory, promyšlené delegování ani jasnou komunikaci o tom, proč určitá práce záleží. Týmy někdy zavedou procesní nástroje v naději, že proces udělá vztahovou a organizační práci, která je ve skutečnosti úkolem manažera. Neudělá.

Co udělá, je, že sníží všudypřítomnou nejistotu, která většinu týmů zpomaluje. Otázky „kdo na čem pracuje“, „je tohle hotové“ a „co si mám vzít příště“ vytvářejí v organizacích bez sdíleného viditelného systému obrovské množství komunikace s nízkou hodnotou. Kanban většinu tohoto šumu odstraní. A u týmů, kde je tento šum hlavním problémem, je rozdíl výrazný.

Jak začít – bez třídenního workshopu

Nejlepší implementace Kanbanu, jaké jsem viděl, začaly v malém a vyvíjely se. Nejhorší zahrnovaly konzultanta, dvoudenní offsite a krásně navrženou nástěnku, kterou ve třetím týdnu už nikdo nepoužíval.

Začněte s týmem, jaký skutečně je, a s prací, kterou skutečně máte. Vytvořte tři sloupce: Backlog, Rozpracováno, Hotovo. Strávte s týmem třicet minut tím, že každou současnou položku práce dáte na kartu. Dohodněte se na jednom pravidlu: když něco začnete, jde to na nástěnku. Když se to posune, posunete kartu. Dva týdny nedělejte nic jiného.

Po dvou týdnech se na nástěnku podívejte společně. Kde se věci hromadily? Co zůstalo v backlogu, ačkoli všichni říkali, že je to priorita? Co se pohnulo rychleji, než se čekalo? Co uvízlo a proč? Využijte pozorování k vylepšení sloupců a upřesnění. Možná je třeba rozdělit „Rozpracováno“ na „Rozpracováno“ a „Čeká na externí stranu“. Možná potřebujete sloupec „V revizi“, protože tento krok se pořád ztrácí. Nechte nástěnku vyvíjet se podle toho, co odhalí vaše skutečná práce, ne podle toho, jak má podle knihy o metodice vypadat.

Dlouhodobější pohled: metriky toku

Jakmile Kanban systém běží, generuje data, která většina týmů nikdy nevyužije. Nejdůležitější je průběžná doba (lead time) – celková doba od založení úkolu po jeho dokončení. Pokud je vaše průměrná průběžná doba typického úkolu dvanáct dní a chcete, aby činila pět dní, máte nyní číslo, ke kterému se můžete přibližovat, a nástěnku, která ukáže, kam těch sedm dní navíc mizí.

Doba zpracování (cycle time) měří jen aktivní pracovní období, bez času, kdy úkol leží v backlogu. Propustnost (throughput) měří, kolik položek váš tým dokončí za týden. Žádná z těchto metrik nevyžaduje speciální software, pokud důsledně zaznamenáváte, kdy se karty zakládají a kdy uzavírají. A dohromady dávají mnohem poctivější obraz kapacity vašeho týmu než jakékoli plánování založené na odhadech.

Většina malých a středních týmů se sem nikdy nedostane. Používají Kanban jako nástroj viditelnosti – což je samo o sobě cenné – a dál nejdou. To je v pořádku. Ale pokud zjistíte, že chcete zainteresovaným stranám přislíbit, kdy bude něco hotové, nebo chcete pochopit, proč některá práce trvá třikrát déle, než se čekalo, metriky tu jsou, až je budete potřebovat.