Každá akce, která přivádí společnost blíže k jejímu cíli, je produktivní. Každá akce, která společnost blíže k cíli nepřivádí, je neproduktivní. […] Produktivita je bez významu, pokud nevíte co je váš cíl.

Pokud chcete opravdu do hloubky pochopit Kanban, následujte mého příkladu a přečtěte si knihu The Goal od Eliyahu Goldratta. Je to šťavnaté čtení, které vás přinutí k zamyšlení.

Pokud jste četli The Phoenix Project, tak vás nepřekvapí styl. Je to napínavý román, kde se hlavní hrdina snaží zachránit továrnu na pokraji krachu. Je to čtivé, ale hlavně jsou tam neuvěřitelně názorné příklady, díky nimž pochopíte z čeho vznikla touha omezovat rozpracovanou práci (WIP), zkracovat stories a podobně. Myslel jsem si že to chápu už před přečtením této knihy, ale nebyla to pravda.

Celé se to točí kolem teorie omezení (theory of constraints (TOC)). Ač to zní vznešeně tak je to jednoduché. Každý netriviální výrobní proces se skládá z více navzájem závislých kroků. Když to převedu na vývoj software, tak mám analýzu, implementaci, vývoj, testování a nasazení. Je evidentní, že každá z těchto fází má jinou kapacitu. Jinými slovy, vždy bude jeden z těchto kroků nejpomalejší. Je jedno který, ale kapacita celého řetězce je shora omezena kapacitou tohoto úzkého hrdla. Takže pokud například vaši testeři dokáží otestovat 2 stories za týden, tak víc než 2 stories za týden nedodáte, ani kdyby se analytici a vývojáři rozkrájeli.

Je to samozřejmé, že? Tak se zamyslete a řekněte mi, co je vaše úzké hrdlo a jaká je jeho kapacita. Víte to? Pokud ano tak gratuluji. Pokud ne, tak to zkuste zjistit. Bez toho totiž nemůžete zvýšit kapacitu celého procesu. Ta se dá totiž zvýšit jenom tehdy, když se věnujete tomuto omezení. Nemá smysl se zaměřovat na cokoliv jiného. Když jsou vaším úzkým hrdlem testeři, tak zvýšeným výkonem při vývoji zvýšíte jenom hromadu práce čekající na testování.

Z TOC plyne také jeden zajímavý důsledek. Pokud máte řetězec závislých činností, tak ty, které nejsou úzkým hrdlem, musejí mít nadbytečnou kapacitu. Jinými slovy, musejí se flákat. Pokud se je budete snažit vytížit na sto procent, tak jenom zvýšíte tlak na úzké hrdlo.

Co s tím? Samozřejmě je potřeba se věnovat vašemu největšímu omezení a buď zvýšit jeho kapacitu, ubrat mu práce, nebo ho obejít. Jednoduché, že?

Musím upozornit, že kniha se nevěnuje vývoji software. Byla napsána před 25 lety, kdy se software ještě tolik neřešil. Je ale zajímavé cvičení porovnávat problémy továrny s našimi problémy a zkoumat, jestli to pasuje. U továrny je například jednodušší poznat co vede k cíli. Když vyrábí něco, co se prodá, tak je to dobře. Když vyrobí něco jenom na sklad, tak to nezvyšuje zisk a je to špatně. Co ale u nás? Jak poznám jestli kód který jsem vyvinul, otestoval a nasadil něčemu pomůže nebo je jenom „na sklad“? Na druhou stranu, u software nehrozí nedostatek poptávky. Backlog bývá obvykle nekonečný. V software také nemusíme řešit materiál. Obvykle pálíme jenom čas, takže nám štosy rozpracovaných výrobků uvnitř „továrny“ vadí z jiných důvodů.

Už musím končit. Knihu vřele doporučuji všem, kteří se zajímají o Lean a Kanban, rozšíří vám obzory. Rozloučím se banálním citátem.

…chceme umět odpovědět na tyto tři otázky: Co změnit? Na co to změnit? Jak tu změnu zařídit? … Pokud manažer nezná odpověď na tyto otázky, má právo se nazývat manažerem?