•  

Agilních firem a týmů přibývá. Čím více lidí se agilem, zejména Scrumem, zabývá, tím menší výhodou agile bude. Tak jako dříve bylo výhodou to, že jste zaměstnali lidi, kteří umí číst a psát, později lidi, kteří uměli používat počítač a dnes máte výhodu, že jste flexibilnější a učíte se rychleji, než konkurence.

První z věcí, ke které ještě nedošlo, je rozšíření mimo IT. Agilní výroba sice existuje, ale zdá se, že ji nikdo nedělá. Agilní marekting, agilní UX jsou spíš buzzwordy než skutečná praxe. Agilní produktový management je obvykle jen jiný název pro Lean startupy. To je řada oborů, které čekají na obsazení a na obsah samotný, na best practices, na úskalí a problémy, které bude potřeba překonat.

To ale nebude tak těžké, jako další změna.

Dnes změna představuje pro firmy problém. Změna provází období, kdy je ve firmě větší chaos, menší produktivita a poté, co je dosaženo změny, firma se dostává do stabilnějšího období, kdy ze změny těží tak dlouho, dokud se paradigma neposune o tolik, že firma musí zase posunout směr svého fungování.

Tak to ale nemůže fungovat v budoucnu. Tempo změn roste tolik, že v budoucnu budou firmy neustále uvnitř nějakých radikálních změn. Firmy se budou muset naučit měnit se a zároveň netrpět problémy spojenými se změnou. Změna bude konstantou a ten, kdo se nebude měnit, je na začátku konce. Už teď to platí, ale pořád platí, že firmy bez změn můžou přežít i několik let. Tohle tempo se v budoucnu mnohem zvýší.

To bude zasahovat do řady dalších oblastí, které bude potřeba vyřešit.

  • rozpočtování
  • procesy
  • zaškolování lidí
  • informační systémy
  • nabírání lidí
  • reakce na změny konkurence
  • pricing, kde se cena může měnit každou vteřinu
  • legislativní otázky, internetové firmy můžou vstupovat a zase opouštět desítky trhů v jednom dni

Mnoho gigantů padne. Informační systémy, v kterých se čeká na změnu týdny a měsíce zmizí a budou muset vzniknout mnohem flexibilnější systémy. Procesy se můžou změnit během jedné pracovní doby několikrát a zaměstnanci se musí naučit podle změn fungovat. Noví zaměstnanci budou zaškolováni do fungování firmy a než se stihnou vše naučit, firma se mnohokrát změní. Firmy v průběhu přijímacích řízení budou upravovat to, kolik lidí do různých odborností vlastně potřebují. Těch příkladů by se daly najít stovky.

Když se můžete změnit rychle a stát se prakticky čímkoliv, bude extrémně složité napozicovat se do nějaké unikátní pozice. Budete muset konkurovat tím, že víte víc než konkurence, víc než vaši zákazníci.

Závody ve změnách budou následovány závody v učení se. Firmy budou bojovat o všechny zdroje informací, které můžou získat. Budou tyto informace využívat k tomu, aby našly jakoukoliv tržní neefektivitu. Lidé budou propojovat obory, které se dnes spojují velmi vzácně a neuromarketing bude jen slabý odvar toho, kam až můžou firmy zajít.

Ve všech těchto oblastech, v učení, změnách, budou principy známé z agile součástí DNA podnikání budoucnosti a těžko už někdo bude říkat, že je něco agilní. Bude to jednoduše přirozené a těžko to bude moci někdo udělat jinak.


Agilní metodiky, jako je Scrum, jsou při přechodu na agile až druhá úroveň důležitosti. Nejdůležitější je samotný přechod na agilní způsob fungování. Pokud jste agilní, Scrum vám může pomoci, ale v principu už máte většinu výhod. Pokud nejste agilní, Scrum ve skutečnosti vůbec nepřinese výhody, které si od něj slibujete.

A tak jsem se rozhodl sepsat, jak poznáte, že jste skutečně agilní.

Lidé jsou ochotní ke změně. Nestává se, že někdo řekne: „už je moc pozdě, už to máme naprogramované takhle“, žádný odpor vůči změně se neděje a pokud, tak jen velmi krátký okamžik z organizačních důvodů (třeba 2 týdny na sprint). Není možné fungovat stylem: „U nás je to takhle a basta, u jiných ať si klidně dělají XXX, třeba je to lepší, ale my máme svůj způsob“.

Komunikace je ústní a je jí spíš více než dřív a bourají se komunikační bariéry, každý může mluvit s každým.

Týmy jsou autonomní, můžou si upravit své procesy a dokud doručují podle slibů, nelze jim v tom bránit. Tyto týmy jsou obvykle multidisciplinární a schopné doručit široké spektrum služeb.

Všichni neustále vylepšují, procesy nepřichází výhradně zvenčí a pokud, jsou pouze startovní bod, inovuje každý. Fungují pravidelné retrospektivy, při kterých se lidé zabývají tím, jak vylepšit fungování.

Hledá se zpětná vazba. Při vývoji nemusí být vše správně hned napoprvé, software nemusí být univerzální, obecný a vysoce konfigurovatelný. Release je vždy nedaleko, tak se dá upravit směr. Pokud si nejsem jist, udělám experiment (třeba prototyp) a něco se naučím a tyto informace využiju pro další iteraci.

Platí, že tyto body musí být splněny všechny, nebo se o agilní prostředí nejedná.


Autonomní týmy

  • 4.8.2015

Jedním z přístupů, jak stavět firmu, je princip hierarchické struktury, ve které každý někoho vede a v podstatě stromovou strukturou se dostanete až k CEO, který se zodpovídá akcionářům.

Pak máte štábní přístup, kdy je firma rozdělena po určitých funkcích, které jsou víceméně nezávislé a mají nastavený model komunikace. I v takové situaci existuje hierarchie, ale není shora dolů v jednom stromu, ale má několik nezávislých stromů.

Takto můžeme pokračovat a postupně přidávat, až se dostaneme k v firmě, ve které všichni pracují v týmech, které vnitřně nemají žádnou hierarchii a hierarchie se odehrává na vyšší úrovni (týmy zadávají práci a jiné týmy práci dělají). V takovou chvíli je běžné, že se vytvoří určitá komunikační rozhraní (formáty zadání úkolů, místa, kde se úkoly hromadí, procesy kontroly práce).

Čímž se dostáváme k autonomním týmům.

Autonomní tým je takový, který si sám určuje, jakým způsobem práci doručí a má svěřenou odpovědnost a má určitý způsob komunikace se zbytkem firmy/organizace.

Když se budeme bavit o agilním managementu, zjistíte, že téma autonomních týmů patří v tomto odvětví k velmi důležitým. Ale toto není jen specifikum agilních firem, mnoho principů autonomie najdete u štíhlých firem, u svobodných firem, u startupů.

Proč byste měli zvážit ve firmě menší hierarchii a více autonomie?

  • usnadníte řízení práce, necháte lidi, ať se domluví
  • zajistíte si akceschopnost týmů i v extrémních situacích, na které nemáte dostatek krizových manažerů
  • lidé mají silnější pocit, že mají situaci v rukou
  • manažersky je řízení autonomního týmu méně náročně
  • členové týmu jsou šťastnější

Kdy se autonomní týmy nehodí:

  • autonomie přináší odpovědnost, musíte mít zaměstnance, kterým věříte
  • autonomie nemusí přinést výhody v prostředí, které je vysoce standardizované (ale existují výjimky, např. štíhle řízené továrny), až zbyrokratizované (ale autonomie může sloužit jako lék proti nadměrné byrokracii)
  • nemáte možnost nechat jeden tým fungovat dlouhodoběji, aby se začal identifikovat jako jednotka s odpovědností

Jak se autonomní týmy zavádějí?

Potřebujete následující mechanismy:

  • týmy s přesně vymezenými odpovědnostmi
  • pro každý tým model předávání práce, model zpětné vazby (zda byla služba poskytnuta v potřebné kvalitě, zda jsou ostatní týmy spokojené)
  • vnitrotýmový způsob zorganizování se
  • velkou míru disciplíny, abyste znovu nezačali zavádět hierarchii

Všechny tyto konkrétní činnosti lze pokazit.

První z chyb je nepokrytí všech situací, které nastávají. Pak máte řadu týmů, které umí leccos vyřešit, ale občas se vyskytne situace, kdy žádný tým nezodpovídá za vyřešení, nebo naopak dva různé týmy mají pocit, že by měly problém vyřešit.

Další je použítí nevhodných nástrojů komunikace. Nadměrná standardizace povede k tomu, že komunikace mezi týmy bude pomalá, neefektivní, nejdůležitější úkoly se neřeší první.

Může se stát, že tým nebude fungovat dobře a v autonomním prostředí nebude existovat mechanismus, jak tým kritizovat, ovlivnit, případně rozpustit.

Může se stávat, že se tým nezcelí, lidé si nesednou a tým nikdy nezačne fungovat efektivně.

Může se stát, že tým nemá potřebné vybavení nebo know-how pro naplnění odpovědností.

Může se stát, že přijde krize a vedení místo toho, aby důvěřovalo týmům, začne s micromanagementem podle tvrdé hierarchické struktury. Když krize pomine, důvěra zasažených týmů už je navždy narušena.

Jak vidíte, problematika není bez problémů. Jako každá změna, je potřeba ji provést s neustálým sledováním, zda nedochází k nějakým excesům.

Jak se uspořádává firma řízení podle autonomních týmů?

Strategický management je jeden tým. Vstupují různá data o firmě, výstupem jsou strategické cíle. Podobně funguje např. obchod, vstupují cíle, výstupem jsou přivedení zákazníci, potřeby smluv, faktur atd. Toto všechno prochází firmou a jednotlivá oddělení přebírají úkoly a vyřizují je.

Jakmile je potřeba zvýšit výkon, dá se posilovat buď přímo dané oddělení, nebo se dá i škálovat na úrovni celých týmů, přidáváte týmy, které očekávají stejné vstupy, mají stejné výstupy a naplňují stejné odpovědnosti.

Osobně očekávám, že autonomních týmů bude přibývat ve všech oblastech podnikání.


Jakmile se velká firma pokusí přejít na agilní vývoj, narazí na několik problémů. Tyto problémy nebývá snadné překonat, zejména proto, že si lidé ve firmě často tyto problémy neuvědomují u jejich skutečných příčin. Podívejme se na některé z těchto problémů.

Plánování, rozpočování

Firmy při přechodu obvykle už mají nějaké procesy, výkazy, způsoby reportování. Vše, co je potřebné, už v agile má své náhrady. Jenže problém nastává při průběžném přechodu na agile, že staré reporty přestávají dávat smysl a nedávají čísla, podle kterých by se dalo něco řídit nebo vyhodnocovat.

Proto je potřeba promyslet, zda má daný report smysl a jak ho případně nahradit.

Totéž platí o rozpočtech. Agile je sice schopné fungovat ve světě fixních rozpočtů na rok dopředu, ale není to stoprocentně ono. Lépe funguje v prostředí, ve kterém firma hledá, jak nejefektivněji investovat své prostředky a v průběhu roku je rozpočet upravován.

Viz příklad u jednoho zákazníka, kde byli lidé hodnoceni podle toho, jestli stíhají objem práce, který si převzali. Jenže Scrum automaticky upravuje velocity, takže ten report jen ukáže, jestli lidé sami nastavují velocity podle nastavené rychlosti.

Už samotná změna reportování a rozpočtování je zásadní pro řadu velkých firem. A to ještě nekončíme.

Podniková kultura

Dalším specifikem velkých firem je to, že mají často kulturu postavenou na kontrole, certifikacích (software se certifikuje a už se na něj nesahá), strmé hierarchii. Nic z toho se v agile moc nenosí, tam je běžná spíš důvěra, místo certifikace experimenty a rychlé iterace (když se to rozbije, brzo bude další release) a autonomních týmech.

Přechod na agile bez změny kultury je nemožný. Doslova bych řekl, že je to zásadní brzda při zavedení agile a jeden z nejdůležitějších důvodů, proč agilní implementace selhává.

Změna kultury vyžaduje porozumění a jití příkladem u všech leaderů ve firmě. Jakmile je část managementu proti, může to celou implementaci otrávit. Nechci vytahovat konkrétní příklady, ale byl sem toho svědkem a vedlo to k nepěknému vnitřnímu rozdělení firmy na dvě části, kde si lidé svých kolegů navzájem dvakrát nevážili.

Spolupráce s dalším subjektem

Další zásadní problém nastává, pokud má vývoj spolupracovat s další stranou, ať už uvnitř firmy nebo mimo ni. A pokud ta druhá strana není agilní, budete vy mít neustále problém. Budete čekat a bude vás to zdržovat.

Následkem pak je, že agilní partner ve spolupráci musí doplňovat své backlogy dalšími úkoly mimo pořadí, protože neagilní partner je pomalý a nereaguje flexibilně. V takové situaci, byť bylo agile implementováno správně a funguje, nepřináší tolik výhod a navíc způsobuje stres.

Je to jako mít sprintera a lenocha a sprinter vždy uteče a pak musí počkat, než ho lenoch dojde, protože v cíli stejně musí být spolu. Sice si sprinter své splnil a mohl by být spokojen, ale stejně nemá z běhu takovou satisfakci.

Nevyužití výhod

Další důležitá věc je, že agile přináší spoustu výhod, ale firmy jich třeba nevyužijí. Scrum vám umožňuje vydat se novým směrem každý týden, dva. Ale firmy dělají roadmapy na měsíce dopředu a plány moc nemění. Agile umožňuje rychle prototypovat, zkoušet varianty. Velké firmy často dělají zbytečně velká, složitá řešení, která jsou konfigurovatelná do tisíců podob (a pak jejich vývoj trvá násobně dlouho). Agile pomáhá při zavádění Continuous Delivery, přesto velké firmy často dělají dva, tři releasy ročně.

Opět pro lidi, kteří rozumí agile a možnosti si uvědomují, je to frustrující.


No jo, ale co teď? Znamená to, že se do velkých firem agile nehodí?

Ne, samozřejmě, že hodí. Dává velkým firmám ohebnost startupům a možnost reagovat znovu pružně, jako když byly firmy mnohem menší. Ale je potřeba zamakat na okolí, využívat pořádně výhody, vybudovat dobrou kulturu, spolupracovat správně s partnery a motivovat je, aby se stali taky agilními, pracovat víc stylem, kdy se dostávají nové věci ven, jsou menší a hned se vyhodnocují a vylepšují. To může být dlouhá a složitá cesta, ale výsledek za to stojí.


Jedna z velmi důležitých aktivit ve Scrumu je i review, při kterém tým vyhodnocuje své výsledky a posun, který učinil za poslední sprint.

Mě se ustálil proces, který vám popíšu níže. Reaguje na vše, na co jsme ve firmách, kde jsem zaváděl Scrum, narazili.

Má tyto fáze:

  • vyhodnocení navržených změn z minula
  • řešení průběhu sprintu
  • návrhy možných vylepšení
  • řešení problémů s kvalitou
  • shrnutí plánu, co se změní
  • určení dat, kdy budou změny vyhodnoceny

Zlepšovací proces, který používám, funguje procesem – vytvoř hypotézu, urči plán, urči kritéria, zrealizuj plán, vyhodnoť kritéria, znovu uprav svůj způsob fungování.

Má Sprint review (někdy nazývám review, někdy retrospektivy) začínaji vždy vyhodnocením kritérií. V průběhu vyhodnocení tým rozhodne, jestli dříve navržené změny přináší užitek a jestli plní stanovený účel. Poté se rozhodne, zda v rozhodnurí pomračovat, posílit ho, nebo opustit, vylepšit apod. Pokud se změna nestihla zrealizovat, řeší se, zda je dostatečně důležitá. Jestliže ano, je úkolu zvýšena priorita.

Dále se probírá, jak dopadl poslední sprint. Tento bod vidím nejčastěji ve firmách uchopený naprosto špatně, tak, že buď dochází k obviňování těch, kteří se zasekli na úkolu, nebo ke zbrklému zavádění procesů tam, kde neexistuje žádný opakující se vzorec. Tento bod slouží pro dořešení, jestli se něco nezapomenulo komunikovat (třeba i zákazníkovi), jestli se vše stíhá, jak dopadl release, jestli nejsou nové vzorce v okolí.

Poté následuje proces hledání dalšich zlepšení. Mám procesy jak na vygenerování dalších nápadů, tak i na určení priorit. Popíšu je zde jindy. Poté je určen výběr úkolů, které se zrealizují a vytvoří se plán. Úkoly jsou vloženy do Sprint Backlogu (to je další téma na článek – jestli vkládat úkoly pro vývoj do Sprint Backlogu, nebo mimo do separátního týmového backlogu).

Dále je zde kvalita. Ta si zaslouží samostatné téma, protože kvalita je jeden z ústředních problemů ve vývoji software. Schopnost releasovat sw bez velkých průserů je v agile esenciální. V tuto chvíli se řeší, jaké chyby byly nalezeny, kde vznikly, proč nebyly odhaleny, co by je odhalilo a opravilo, co udělat pro prevenci.

Ke konci dojde k vyhodnocení, určení plánu realizace, rozdělení povinností, termínů a kritérií, která budou ověřena.

Takový je můj proces sprint review. Postupně ho upravuju, ale tak, jak jsem ho napsal, mi už teď funguje výborně. Co byte změnili vy?