Agilní organizace – systémový pohled

| Jan Doležal

Agilní transformace

Co je Agilní organizace? Poměrně jednoduchá otázka s velmi komplexní odpovědí. Mnoho „definic“ uvádí, že to je organizace schopná rychle reagovat na změny. Lze se také dočíst, že se jedná o organizační uspořádání ve formě ploché organizační struktury, adaptivní sítě multifunkčních týmů. A další informace a postřehy, které však mají dohromady jeden společný nedostatek. Soustředí se vlastně jen na tu nejvíc adaptivní, agilní část a vůbec neřeší, že v organizaci jako celku probíhají i aktivity jiné povahy. Procesní, projektové.

Pokud si však chceme udělat realistickou představu reálně fungující agilní organziace, musíme zahrnout i tyto „obyčejné“ věci. Jinak nám v daném modelu bude vždy něco chybět. Pojďme tedy celou záležitost na chvíli uvažovat systémově, jako celek.

Agilní organizace není jen Scrum

Na tréninku Agile a SCRUM nebo na různých konferencích a odbroných fórech často slýchám povzdechy a poznámky typu, že Scrum je sice pěkný, ale vlastně vůbec neřeší, kde se vezmou ty požadavky ke zpracování, ani co se s nimi děje dál.

To jednak není zcela přesné, jednak to vytrhává věci z kontextu. Je přeci jasné, že Scrum tým (nebo jakýkoliv jiný tým) nevisí někde ve vzduchoprázdnu. Ale že za nějakým účelem vznikl a má nějaké okolí. Výjimkou mohou být startupy o velikosti jednoho týmu, ale to asi není většinový případ.

Navíc, agile, agilita či agilní organizace nerovná se Scrum (nebo Kanban, SAFe, LeSS, …). To je jen jeden z použitelných rámců pro agilní vývoj. Agilní organizace je mnohem širší pojem a zahrnuje prvky jako:

  • orientaci na hodnotu dodávanou konkrétním zákazníkům (customer centric, value driven),
  • komplexní situace jsou řešeny adekvátními přístupy (např. Scrumem, Kanbanem, apod.),
  • co možná nejplošší organizační struktura a vysokou míru sebeřízení a sebeorganizace,
  • vhodně zformulovaný a stanovený smysl činnosti, existence, který poskytuje lidem smysl jejich konání,
  • umožňuje motivaci lidí tím, že jim dává možnost autonomie, mistrovství a výše zmíněného smyslu (viz D. Pink a kniha Drive – Pohon),
  • management vytváří prostředí pro práci sebeřízených týmů místo toho, aby přímo velel,
  • pracuje se s hodnotami,
  • má vysokou úroveň kultury, ve které si lidé navzájem věří, jsou otevření a chyba není vnímána jako problém, ale jako příležitost se poučit,
  • atd.

Agilní organizace jako komplexní systém

Když se tedy na organizaci podíváme jako na systém, celek, tak (s respektem např. i ke CYNEFIN modelu) uvidíme několik základních proudů toku hodnoty organizací (viz Lean):

systém agilní organizace

Na obrázku je modelová situace, která se bude v různém kontextu více či méně lišit, pro náš účel ale věřím poslouží.

„Běžné“ aktivity

Určitá část aktivit dané organizace bude spočívat v běžné operativě. Je třeba zajistit účetnictví a další běžnou agendu, která je podle Leanu „nutným“ plýtváním. Musíme to udělat, i když to pro zákazníka nemá žádnou hodnotu.

Další částí je i „business as usual“, tedy běžný provoz, ve kterém jednotliví obchodníci prodávají třeba hypotéky, kurýři rozváží rohlíky nebo cokoliv jiného, administrativa likviduje pojistné události atd. Zkrátka vše co probíhá nějakým nastaveným procesem (v případě např. banky nebo pojišťovny to může být i většina aktivit celé organizace).

Samozřejmě i tyto oblasti by měly, pokud možno, generovat hodnotu bez zbytečného plýtvání. A tedy i zde lze uvažovat o stabilních, cross-functional týmech, sebeorganizaci a dalších Lean prvcích. Proč by ne? I když asi členové těchto týmů nebudou vyvíjet nový produkt pomocí Scrumu, stále mohou být vysoce sebeřízení, s plochou organziační strukturou a vyspělou týmovou kulturou. To není otázka použitého rámce.

Změny a nové věci – těžiště agilní organizace

Další aktivity agilní organizace jsou jistě o změnách a nových věcech. Na „vstupu“ jsou různé podněty a myšlenky, které buď vzniknou zcela nově nebo se jedná o nápady a upřesnění vzniklé díky zpětné vazbě. Interně nebo od zákazníků.

Ať už vznikly jakkoliv, měly by tyto podněty projít nějakým vstupním „posouzením“. Buď bude jasné, že ANO, nebo jasné, že NE, případně bude potřeba provést nějakou vstupní, ověřovací analýzu.

Taková vstupní analýza samozřejmě dává smysl spíše pro větší nové věci, např. nový produkt, plugin apod. A v takovém případě může dojít na různé formy použití technik a nástrojů jako „design thinking“, „product vision board“, „business model canvas“, „elevator statement“ apod. Bude vznikat množství prototypů a bude se hodně experimentovat.  O tom by tato fáze měla být, o upřesnění a validaci směru vývoje. O naučení se kudy ano a kudy ne co nejdříve.

Výsledkem pak může být i NE, nemá smysl se tím dále zabývat, nebo ANO, v takové a takové základní podobě to dává smysl.

Souhrnná ROADMAP – hlavní nádraží

Pokud je výsledek posouzení kladný, celá záležitost se dostane do souhrnné „Roadmap vývoje“. Aktuální představě o tom, co by kdy asi tak mohlo probíhat. Ať už tomu budeme říkat souhrnná roadmap, overall backlog nebo jakkoliv jinak, jde o to mít ty schválené věci na jednom místě, kde je můžeme vidět vedle sebe a to, jak se navzájem ovlivňují. Berme to vždy jako vizualizaci aktuální představy, ne nějaký striktní plán nebo definitivní to do list. Určitě se to bude průběžně měnit.

Vedle toho může (a nemusí) být vyčleněn seznam nějakých drobnějších úprav v rozsahu několika čld, které mnohdy ani nevyžadují celý tým, ale třeba i jen jednoho člověka. Může jít o různé customizace, věci související s implementací u konkrétního zákazníka atp.

Nesmíme zapomenout ani na opravy chyb, které se prostě z různých důvodů budou vyskytovat.

Koordinace

Položky ze všech vstupních seznamů (nebo jednoho globálního) by pak zřejmě měly projít nějakou formou koordinace, prioritizace. Tak, aby  bylo možné rozhodnout, co přistane u některého z týmů „ryzího“ agilního vývoje (představme si jeden až N stabilních, cross-functional sebeorganizovaných týmů), co přistane u týmu (týmů) drobných úprav (které budou mít třeba své Kanbany) a co proběhne prediktivním způsobem (s týmem, týmy či externími subjekty určenými k tomuto druhu aktivit).

Ideálně nějakým lean „pull“ systémem.

Opravy chyb by pak měly být také předmětem dělení a měla by na ně být vědomě vyhrazena určitá kapacita všech týmů (podle velikosti buglogu).

Synchronizační aktivity

Vzájemná koordinace během práce je důležitá jednak z důvodu, že může být výjimečně potřeba, aby nějakou drobnou věc udělal třeba i ryze vývojový tým (např. z historických důvodů, zkušenosti atd.), aby bylo jasné, který tým si vezme co, nebo aby se nevědomky více týmů nepustilo do úprav stejné funkcionality (byť z různých stran a na základě různých podnětů) atd. Zkrátka, aby levá noha věděla, co dělá pravá.

Podle situace a potřeby může probíhat celková koordinace buď pro každou iteraci (sprint) nebo jednou za několik iterací. Každopádně pravidelně a tak, aby vše hladce probíhalo.

Hodnota

U prediktivních aktivit je hodnota většinou uvolněna až na konci. U průběžného odbavování průběžně a u „ryzího“ agilního vývoje může být hodnota podle kontextu uvolňována průběžně nebo na konci iterace, kde by také mělo vždy docházet ke zpětné vazbě (a tím se cyklus vývoje uzavírá).

Je pak ještě samozřejmě otázkou, jestli uvolněná hodnota vyžaduje nějaké další zpracování. Např. týmem, který se stará o provoz atp. To už se bude asi v různých situacích výrazně lišit. V ideálním případě by uvolněná hodnota žádné další zpracování neměla vyžadovat (hotovo je, když je hotovo). To však bývá v praxi spíše obtížně dosažitelné. I tento aspekt je tedy třeba zvážit a v rámci systému neopomenout.

Stejně jako koordinace, tak by i zpětná vazba a retrospektiva měla probíhat v rámci všech základních proudů hodnoty, ideálně ve vzájemné synchronizaci.

Můžeme nastavit třeba měsíční makrocyklus, na jehož začátku proběhne celková koordinace. Poté prediktivní a průběžný proud probíhají svým způsobem. Ryzí vývoj si otočí čtyři týdenní iterace a na konci měsíce se všechny tři proudy sejdou a vyhodnotí, jak to proběhlo atd.

To neznamená, že by neprobíhala komunikace a koordinace i průběžně. když to ale dobře navrhneme a vzájemné vazby budou minimalizovány, tak by to nemělo být tak moc potřeba. Cílem je, aby jednotlivé týmy měly dostatečný prostor se soustředit na svou práci.

Project team canvas

Ne vše co teče je vodopád 😉

Pozor, aby nedošlo ke zkreslení, výše popsané není jinak nakreslený vodopád! U mnoha podnětů jde na začátku pouze o globální Ano/Ne rozhodnutí, zda budou zařazeny do „backlogu“ nebo ne. Nejedná se v tomto kroku o nějakou detailní specifikaci apod.

Až na úrovni týmu pak bude probíhat prioritizace vůči dalším položkám na seznamu. A je možné, že na některou tak jako tak nedojde. A až v týmu budeme řešit jejich podrobnější popis, volbu způsobu realizace atp.

V případě, že půjde o rozsáhlejší podnět a vyžádá si to úvodní „product development“ fázi, tak ani tato ze sebe nevyprodukuje nějaké kompletní, fixní zadání. Účel je jiný – definovat vizi produktu a jeho základní rysy tak, aby tým věděl, kudy má vůbec vykročit.

A to platí i pro prediktivní zadání, kdy si můžeme jako výsledek této úvodní fáze představit něco jako „business case“ či „studii proveditelnosti“.

Výše uvedené řešení odpovídá např. konceptu „Dual track agile“ nebo přístupu popsanému v „Disciplined agile delivery“.

Organizační aspekty

Uvedený způsob tvorby hodnoty bude mít samozřejmě dopad i na vhodnou organziační strukturu naší agilní organizace. Na různé části toku hodnoty mohou být vytvořeny různé, de facto dedikované týmy. Lze uvažovat např.:

  • Expertní tým na provádění úvodních posouzení (product development, může být stabilní),
  • Scrum tým (jeden nebo více, podle počtu produktů atp., stabilní),
  • Kanban tým (jeden nebo více, podle množství a typu práce, může být i zcela stabilní),
  • Projektový tým (jeden nebo více, zde zřejmě bude největší „pohyb“ co se složení týče, ale i zde může jít o jistý typ „jednotky rychlého nasazení“),

Cílem je vytvořit takové týmy, které budou co nejstabilnější a nebudou potřebovat intenzivní součinnost od ostatních (což dost záleží na naší schopnosti zmapovat toky hodnoty a na dobré koordinaci, komu co dát).

U Scrum týmů půjde o asi nejsevřenější uskupení, které v krátkých sprintech vytváří přírůstky hodnoty.

Kanban tým (jeden nebo více) bude možná o něco více seskupením jednotlivců, kteří odbavují své položky a podle potřeby se více či méně shlukují a přesýpají.

Projektové týmy budou vznikat především podle potřeb daného projektu a nejspíš z velké části i s externími subjekty. Interně by na práci v projektech měli být vyhrazeni jiní vývojáři, než ti alokovaní ve scrum či kanban týmech, jinak jim budeme narušovat jejich stabilitu.

Co je zodpovědnost vedení agilní organizace?

Někdo musí dělat úvodní ANO/NE rozhodnutí, určovat celkové priority a vizi celé organizace, zastřešovat koordinaci , vytvářet prostor pro sebeřízené týmy, podporovat jejich kulturu, sebeřízení atd.

V případě, že přijde nápad na dobrý nový produkt, musí někdo říct, že se toho ujme některý ze stávajících týmů nebo že vytvoří nový. Samozřejmě, i toto můžete v některých případech přenechat na týmy. A nebo že některý z produktů bude z nějakého důvodu ukončen, to je velmi „byznys“ rozhodnutí.

Krom vhodného prostředí pro vývojové týmy se musí někdo starat i o prostředí a kulturu týmů běžného provozu, podle jejich konkrétních toků hodnoty.

A v neposlední řadě, někdo se musí postarat i o tu běžnou administrativu a operativní agendu, nutné zlo.

Je toho tedy poměrně mnoho. Nicméně vynaložené úsilí se vyplatí a dává smysl usilovat o větší adaptivitu organziace. Jako prostředku ke splnění odvážných vizí a cílů.

Vždy je však potřeba uvažovat věci jako celek, komplexní systém s různými aspekty, postupovat při změnách obezřetně a vyhnout se slepým uličkám.

O autorovi článku

Jan Doležal

Jan Doležal

V současné době se zabývá především agilitou v organizacích, Managementem 3.0 a vývojem simulačních her sloužících jako trénink projektového řízení, včetně Agile.

Dříve mimo jiné zastával pozici vedoucího projektové kanceláře a řídil velké mezinárodní projekty (Evropa, Jižní Amerika).

Má zkušenosti především s projekty z IT, strojírenství nebo elektrotechniky. Projektovému řízení se aktivně věnuje od roku 2001. Disponuje certifikací PMI PMP, IPMA B a CSPO – Certified SCRUM Product Owner a CSP-SM – Certified SCRUM Professional – SCRUM Master od SCRUM Alliance. Další podrobnosti čtěte zde.

Další zdroje informací

Komentáře (0)

Zatím žádný komentář.

Přidejte váš komentář

Vaše e-mailová adresa nebude zveřejněna. Pole označená hvězdičkou (*) jsou povinná.