Agile nebo waterfall? A je to vůbec správná otázka?

Agile nebo waterfall (vodopád), dva velmi diskutované přístupy, které se snaží řešit to samé – řízení projektu, vývoj produktu, dodávku služby. Předmět zájmu je v podstatě shodný, liší se však způsob dosažení.

Velmi snadno lze zjistit, že vodopád znamená něco dodávat v rozsáhlejších krocích, fázích, a k tomu že existuje v podstatě standardní životní cyklus takového způsobu práce. Agile že kombinuje iterativní a inkrementální přístup a také existují nějaká pojetí životních cyklů, avšak tady je rozptyl možností o dost větší. Mezi další dobře patrné rozdíly patří i pojetí a rozdělení rolí (nebo jeho absence). Ale to je jen povrch… co je pod hladinou?

Diskuze ve firmách a v komunitě je poměrně ostrá. Existují zastánci obou táborů, kteří vidí v „tom druhém“ přístupu veškeré zlo světa. Někdy až dětinsky. Zastánci agilního přístupu často argumentují rychlejšími časy dodávek, spokojenějšími zákazníky i týmem a dalšími velmi zajímavými atributy. Kdo by to nechtěl, že? Je to však reálně dosažitelné? A na čem to vlastně závisí?
Pojďme si tedy alespoň ve zkratce probrat oba přístupy, nahlédnout pod povrch a hledat to, co je podstatné.

Agile nebo waterfall, každý přístup má svou doménu, své místo

Před časem jsem psal o rámci CYNEFIN, který vytvořil jistý Dave Snowden. Ve zkratce jsou definovány čtyři domény, do kterých lze rozdělit de facto všechny situace, se kterými se setkáváme.

Jednoduché

V jednoduché doméně se jedná o záležitosti s jasným požadovaným výsledkem a jasně daným postupem, jak tento výsledek dosáhnout. Např. založení dodavatele do systému. Jedná se o doménu známé nejlepší praxe, která je velmi často popsána pomocí procesů.

Komplikované

Komplikovaná doména hostí situace, ve kterých je potřeba danou záležitost nejprve analyzovat osobou s expertní znalostí. Na základě takovéto analýzy je vytvořen plán a ten je dále zrealizován.
Např. může jít o stavbu mostu z místa A na místo B. Nikde není k dispozici přesný návod, jak na daném místě v daném čase postavit ten správný most. Ale existuje dobrá praxe v podobě různých standardů a norem. A existuje i projektant, který je schopen podle těchto standardů vyprojektovat ten správný most. A od takového návrhu se už poté obvykle ve fázi realizace neustupuje. V našem kontextu se tedy jedná především o doménu vodopádových, waterfall projektů. Ať už jde o most, přesun výrobní linky nebo migraci uživatelů do nového IT systému.

Komplexní

Komplexní doména v sobě ukrývá mnohem více nejistoty. Již přestává být jasné, co by mohlo být správným výsledkem, a navíc dochází v průběhu času k celé řadě dynamických změn. Pokusy něco plánovat zde obvykle rychle selhávají, protože realita se zkrátka příliš rychle příliš odlišuje od takového plánu.

Pokud např. vyvíjím mobilní aplikaci pro několik skupin zákazníků, kteří ještě ani nevědí, co všechno by od ní mohly chtít a vedle toho se mi exponenciálně vyvíjí technologie, konkurence a další věci, nedává moc smysl dělat robustní analýzu, neb se to vše mění „pod rukama“. Smysl tedy má spíše iterativní přístup, založený na experimentu a zpětné vazbě v krátkých cyklech, a postupný rozvoj produktu dle vývoje kontextu. Pro naše potřeby by se to dalo zjednodušeně označit jako agilní přístup.

Chaos

Poslední CYNEFIN doména je chaos, myšlená jako velmi rozsáhlý a dynamický děj, jako např. nějaká rozsáhlá přírodní katastrofa. Není čas ani na nějaké experimenty, prostě se začne konat. A situace se postupem času rozpadne do předchozích tří domén.

Co nám CYNEFIN vlastně říká pro otázku agile nebo waterfall?

Tím podstatným, co je dobré si uvědomit, že v každé doméně zkrátka dobře funguje něco jiného. Třeba agile nebo waterfall. Stejně jako na hřebíky je dobré kladivo, na šroubky je dobrý šroubovák. A že snad v každé organizaci se budeme setkávat se situacemi z více domén. Nic není černobílé. I v super agilní IT firmě prostě zřejmě naleznete recepční, která pojede podle daných procesů. Nebo když se bude potřeba během jednoho týdne přestěhovat do nové budovy, zvolí se zřejmě nějaký waterfall přístup. Proč? Protože to prostě dává největší smysl.

Základní principy waterfallu

V oblasti vodopádu se snažíme ošetřit nejistotu a rizika důkladným promýšlením celého záměru a snahou předem vyřešit všechna možná „co kdyby“. Proč? Protože v komplikované CYNEFIN doméně je relativně jasný požadovaný výsledek a jsou známy osvědčené postupy pro jeho získání. „Stačí“ jen:

• dobře posbírat požadavky,
• vyvážit zájmy zainteresovaných stran,
• sestavit project charter a v něm dobře obsadit potřebné role,
• vše dobře promyslet a naplánovat, včetně možných rizik a „co kdyby“,
• zrealizovat vše podle plánu (a řešit odchylky od něj),
• předat výsledky,
• ukončit projekt a sepsat lessons learned.

Změny jsou v tomto kontextu spíše nežádoucím jevem, který nabourává a znehodnocuje vynaložené úsilí při tvorbě plánu.

A v dané doméně to je zřejmě nejlepší postup. Představme si, že by docházelo např. při výstavbě a zprovoznění nové výrobní haly k dynamickým změnám obsahu a rozsahu prováděného díla… A přitom je jasné datum, od kdy má výroba plně fungovat. Nebo kdyby jste na přepážky nějaké velké banky chtěli nasadit novou verzi informačního systému, která se ale každý měsíc mění… a přitom nestíháte ani školit příslušné pracovníky v půl roku staré verzi, která už neplatí. Ten zmatek, který by nastal.

Zkrátka, pokud chcete provést relativně jasnou změnu, která je však rozsáhlá, komplikovaná a potřebujete mít jistotu splění nějakého termínu, dává waterfall přístup k řešení smysl a pokud je správně prováděn(!), je i efektivním a hodnotným přístupem. A bylo jím dosaženo skvělých výsledků.

Korektní je samozřejmě také poznamenat, že alespoň z pohledu projektového řízení se komplikovaná doména dost zmenšuje a mnoho projektů začíná být spíše někde mezi komplikovanou a komplexní doménou.

Zřejmě i proto se nám do tréninku Projektové řízení krok za krokem postupně vplížily roadmapy, retrospektivy, kanbany a další agilní rekvizity, nástroje a postupy. V kontextu dnešních projektů je dává smysl používat.

Základní principy agilních přístupů

Agilní přístupy reagují na situace, které jsou již natolik komplexní a dynamické, že přestává dávat smysl snažit se mít vše předem promyšleno, protože prostě není v lidských silách „pochytat všechny volné konce“ (komplexní CYNEFIN doména). A my si to uvědomujeme, akceptujeme a postupujeme jinak.

Nejistota a riziko se v tomto případě řeší nejčastěji krátkými cykly a velmi častými body kontroly a zpětné vazby. A tím je myšlena nejen nejistota ohledně změn, ale i nejistota o vytvářených výsledcích.

Je na místě říct, že tato filosofie práce na nejasně definovaném výsledku je pro spoustu lidí, kteří vyrůstali v našem kulturním kontextu, značně nepřirozená, nepříjemná. Od základní školy jim byla vtloukána spíše filosofie spojená s vodopádem, tedy dvakrát měř, jednou řež.

Vidíme to třeba i na našem Agile a SCRUM tréninku, kde i když to celé probereme a vysvětlíme, tak pak začneme hrát lego4scrum a účastníci teprve až když si to zažijí na vlastní kůži, začínají chápat, o co jde. A že je to těžká změna v úhlu pohledu na věc.

Nicméně jsme prostě v komplexní doméně, kde je těžké odhadnout, co bude správně (zatímco když stavím most, je celkem zřejmé o co jde a co bude dobře). Proto se většina agilních přístupů silně orientuje na vymezení „zákazníka“ a hledání hodnoty, kterou mu můžeme doručit.

Jaký je základní agilní postup?

Snažíme se co nejdříve dodat nějaké fungující části, které (snad) mají pro zákazníka vysokou hodnotu a získat na ně zpětnou vazbu. Co nejrychleji. Abychom věděli, kudy dál a že jsme nevyrazili nesprávným směrem.

To neznamená, že když pracuji agilně, tak nemám žádný středně, či dlouhodobý plán. Také máme nějakou vizi, product goal, roadmapu, kdy asi tak očekáváme nějaký významnější výsledek apod. (tedy pokud vyvíjíme nějaký konkrétní produkt, realizujeme projekt apod.).

Jen to není bráno jako dogma, ale jako aktuální představa o směru vývoje a bereme jako fakt, že se to může a bude měnit.

Tím pádem je i velký rozptyl, jak to kdo pojme, jaký si zvolí konkrétní životní cyklus, proces, rámec, nástroje (např. SCRUM, KANBAN, SCRUMBAN, XP,… pokud se bavíme o práci na úrovni týmu). Je to hodně individuální a závislé na kontextu (což je vzhledem k okolnostem jistě správné).

Univerzální agilní principy

To, co dané agilní přístupy spojuje jsou především principy a hodnoty. Obecně lze průřezově, přes různé rámce a metodiky, identifikovat asi tyto univerzální principy agility:

• Hodnota pro zákazníka (business value) je primárním zájmem;
• Spolupráce a co nejčastější komunikace na osobní bázi je zásadní;
• Akceptujeme proměnlivost prostředí a změny jako příležitost dodat lepší hodnotu;
• Rychlá zpětná vazba a transparentnost je pro správný postup nezbytná;
• Udržitelnost a stabilita musí být vědomě řízena;
• Jen skutečný tým podává excelentní výkon.

Pozn.: Více se o těchto principech dozvíte v tomto článku.

A tady to vlastně začíná být opravdu zajímavé. Zastavme se na chvilku u některých z popsaných principů. Většina agilních přístupů má např. ve své „DNA“ zakódovaný stabilní a nejlépe sebeorganizovaný či sebeřízený tým.

TO je jedna z věcí, kterou se tyto přístupy opravdu významně a na první pohled viditelně liší od světa „běžných“ firem a organizací, ve kterých je obvyklé na každý projekt sestavovat dočasnou organizační strukturu, ve které je nejčastěji většina lidí jen na omezený čas nebo omezenou část své kapacity.

Proč agile obecně „nechce“ takový tým? Proč třeba nemít na každou iteraci trošku jiné složení týmu?

Protože agile nebo waterfall není o konkrétním procesním rámci práce týmu. To jsou jen věci na povrchu, jestli pracuji po delších etapách nebo v krátkých iteracích. Důležité je, PROČ to dělám a co je „pod hladinou“, na první pohled skryté.

Za vším hledej LEAN

Ve své podstatě se v agilním přístupu aplikují LEAN principy, které vznikly v automobilce Toyota během posledních desítek let, jak v oblasti organizace práce jak ve výrobě, tak ve vývoji. Tedy i v aktivitách typu vývoj produktu, projekt apod.

Výrobní a vývojový systém Toyoty se snaží napodobit výrobní firmy po celém světě, protože má prokazatelné výhody a výsledky. Ve světě projektů a vývoje různých produktů (nejen softwarových) se to odráží právě v agilních přístupech, které se snaží LEAN aplikovat do své oblasti.

LEAN je postaven na dvou základních pilířích, neustálém zlepšování a respektu k lidem. Od toho je odvozeno mnoho dalších podrobnějších vodítek, principů a nástrojů, které se ale vždy snaží především o následování základních zásad. Ty jsou vždy na prvním místě. Pěkný přehled o LEANu je např. zde.

3M – tři zdroje zla (nehlědě zda agile nebo waterfall)

Mezi LEAN praktiky a principy (kterých je opravdu mnoho) patří mimo jiné i snaha o eliminaci tří „zdrojů zla“, 3M (s jistou firmou to, pokud vím, nemá nic společného), které způsobují plýtvání a neefektivitu:

• MUDA – plýtvání, marnost, zbytečnost,
• MURA – nerovnoměrnost, nevyváženost, nedostatek jednotnosti, nepřirozenost,
• MURI – přetěžování zdrojů, nepřiměřenost, přílišná obtížnost.

Koncept 3M pochází z bojových umění, odkud si to Toyota vypůjčila (více čtěte zde). A jsou to opět spíše vodítka, principy. Je třeba si v daném kontextu uvědomit, jak se 3M projevuje a následně se snažit tyto zla vypudit. Jak se nám bude 3M projevovat např. v kontextu týmu a týmové práce?

MUDA – plýtvání, marnost, zbytečnost

Sem patří tzv. 7 LEAN druhů plýtvání (odpadu): Transport; Zbytečné pohyby; Čekání; Nadbytečné zpracování; Vady a opravování; Zásoby; Nadprodukce.

To se nám může v týmech při vývoji produktu nebo realizaci projektů projevovat např. jako:

• Členové týmu, kteří jsou alokováni i na jiných projektech, si musí vždy znovu „načíst kontext“, nejsou soustředění na jednu věc. (To se mimo jiné řešilo už v rámci TOC – teorie kritického řetězu pro plánování projektů.)
• Ve chvíli, kdy potřebujete součinnost jiného člena týmu, tak zrovna dělá na nějakém jiném úkolu z jiného projektu a vy musíte zkrátka počkat, až na vás dojde řada. Obzvláště v prostředí s nejasnými prioritami toto způsobuje veliká zpoždění a zmatky.
• Když se vám neustále mění kontext a lidé okolo, není dost času na ustálení spolupráce a zvyšování její efektivity (více o tomto aspektu zde).
• Špatná komunikace a nedorozumění.
• Produkce vlastností, výstupů a dokumentů, které nemají zákazníka.
• Atd.

Proto je většina agilních postupů založena na stabilním týmu. Pokud zkrátka nejsme schopni zajistit, aby se stabilní, nezávislý tým soustředil na svou práci, jeden projekt či produkt a jeho hodnotu, mrháme kapacitou a potenciálem těchto lidí a vytváříme prostor pro mnoho plýtvání.

MURA – nerovnoměrnost, nevyváženost, nedostatek jednotnosti, nepřirozenost

Sem patří např. nerovnoměrné rozložení pracovní zátěže, nepravidelný pracovní rytmus, nerovnoměrná kvalita. Pokud je např. termín ještě daleko, je obvykle úplně jiná úroveň nasazení a stresu, než když je deadline za dva týdny (studentský syndrom – taktéž řešen již v TOC).

Jedním ze směrů řešení tohoto zla, je zavedení vhodného, stabilního rytmu (LEAN používá slovo takt).

Proto má např. SCRUM stabilně dlouhé sprinty a i další události s vymezeným časem – timeboxem. A nebo v KANBAN přístupu k vývoji se omezuje počet rozpracovaných položek (WIP), což je jiný způsob boje s nerovnoměrností.

Patří sem také zlo v podobě práce postupem, který lidem nevyhovuje, je jim nepřirozený (nejde jim to „pod ruku“). Soustředění se na to JAK jsou věci prováděny, ve kterém nástroji, podle jakého podrobného procesu. Proto jsou agilní týmy tzv. sebeorganizované. Soustředíte se na výsledky, hodnotu, dopad jejich činnosti a necháváte jim volnost v tom, jak toho bude dosaženo.

MURI – přetěžování zdrojů, nepřiměřenost, přílišná obtížnost

Toto zlo se projevuje především jako přesčasová práce, rutina (která může být mentálně únavná), nadměrný stres, nedostatečný trénink a tedy kompetence, faktory vedoucí k vyhoření, atd.

Lze zde vidět i věci jako neudržitelné tempo vývoje, příliš ambiciózní KPI, nereálné termíny, nedostatek „údržby“, nevhodné pracovní podmínky, nezájem o názor, atd.

Tato bestie, MURI, nám v čilé spolupráci s předchozími dvěma, velmi často vytváří demotivaci, neangažované kolegy, vyhořelé kolegy a celkově tíživou atmosféru bez tvůrčí energie.

Především zde je důležitý respekt a úcta k lidem, oproti konceptu většiny korporací 20. století, které prostě chtěly ze svých lidí dostat co nejvyšší výkon za každou cenu.

Což nás dostává ke konceptům jako je Motivace 3.0, Management 3.0, TEAL organizace atd. Proto mívají  agilní organizace velmi plochou organizační strukturu, založenou na již zmíněných sebeorganizovaných týmech (což je prostě jeden aspekt z mnoha).

Pozn.: To vše neznamená, že nejde o vysokou efektivitu práce. Jen jsou místo cukru a biče používány jiné přístupy, více respektující lidskou přirozenost.

 

Co to znamená pro diskuzi, jestli agile nebo waterfall přístup?

Agile nebo waterfall je vlastně špatně formulovaná otázka. Do značné míry srovnáváme nesrovnatelné. Agile je celkově snaha o aplikaci LEAN principů. Není to „jednoduchý“ rámec, životní cyklus nebo proces. Je to mnohem komplexnější a ucelenější filosofie přístupu k fungování celé organizace, kdy technika používaná na úrovni týmu je jen špička ledovce. Rozhodně to není např. o „ipmlementaci SCRUM procesu“. To většinou končí velmi špatně (více zde).

Waterfall je naproti tomu vlastně poměrně jednoduchý koncept, jak řešit určité změny v určitém kontextu (komplikované CYNEFIN domény). A úplně klidně můžeme používat tento přístup i v ploché organizační struktuře s respektem k LEAN principům.

I v tzv. TEAL organizaci (psal jsem o ní zde), která je minimálně u části profesní komunity jistým ideálem, mohou bez jakýchkoliv problémů probíhat waterfall aktivity a když je to dobře provedeno ve správném kontextu, tak na tom není nic špatného. Když se tým sebeorganizovaně rozhodne, že chce něco řídit jako waterfall projekt, je to jejich rozhodnutí a zřejmě jim dává smysl a hodnotu.

Důležité je si uvědomit, že waterfall není roven hierarchickému command and control managementu (byť to tak mnozí vykreslují a dávají k tomu rovnítko, většinou v případě, že vědí klasickém projektovém řízení… tužku). Je to jen životní cyklus a sada nástrojů. A je otázkou, kdo a v jakém prostředí jimi vládne.

Kde je podstata?

Přístupy různých projektových manažerů se mohou i zásadně lišit a jsou často spíše odrazem celkového fungování organizace. Pokud se jedná o hierarchickou korporaci založenou na principech cukru a biče, je velmi pravděpodobné, že bude takto řízen i projekt.

Pokud se jedná o spíše plošší organizační strukturu, kde je manažer (obecně) vnímán nikoliv jako autoritativní vládce, ale jako někdo, kdo pomáhá odstraňovat překážky, přenese se to i do projektu. PM je pak vnímán jako člen týmu, jehož role spočívá v koordinaci a komunikaci uvnitř i vně projektu, v podpoře „technických“ kolegů při jejich práci (a kteří vidí v činnosti PM hodnotu).

A taky v rámci waterfallu není např. nikde „zakázán“ stabilní sebeorganizovaný tým. Je to naopak již dlouhá léta jedna z best practice možností pro organizační strukturu projektu (autonomní org. struktura).

Na druhé straně jsou samozřejmě vidět i pokusy o „dělání agilu“ v silně hierarchické, command and control korporaci, kde to natolik hoří na výše zmiňovaných principech, že to prostě nemá šanci fungovat. Ne vše, co je tak nazýváno, je agilní (v daném slova smyslu).

Znám spoustu projektových manažerů, kteří jsou skutečnými servant leadery svých týmů a organizací. A vůbec by neměli problém dobře dělat scrum mastery, product ownery, agilní kouče atp.

A také znám „scrum mastery“, kteří úkolují svůj tým a kontrolují, jestli to udělali dobře. Nebo také evangelisty a kleriky, kteří ve chvíli, kdy řeknete slovo projekt započnou kázání, že jste zhřešili a že vaše agilní víra není dostatečně pevná, a proto to nefunguje (tedy krom toho, že jaksi není product owner, nejsou jasné priority, není zpětná vazba od zákazníka a product backlog obsahuje položky jako „migrace databáze“).

Důležitý není konkrétní rámec, přístup, ale spíše jde o to, jaká je v organizaci kultura (v jakém typu kmene se nacházíme) a co kdo umí a neumí, jaké má kompetence.

A tak tedy agile nebo waterfall?

Pokud tedy chcete lepší produkty, spokojenější zákazníky, produkty rychleji na trhu, spokojenější tým atd., tak to není agile nebo waterfall, jestli pojedete ve SCRUMu, KANBANU nebo IPMA či PMI projektovém životním cyklu. To je spíš diskuze, ve které CYNEFIN doméně se nachází vaše záležitost k řešení a co vám víc sedne. A třeba to nebude ani projekt, ani SCRUM, ale něco docela jiného.

Není to ani o implementaci procesu nebo jiné organizační struktuře. Je to o kultuře, hodnotách a principech v podstatě celé vaší organizace nebo její významné části. Uvažované systémově, celostně, ve vazbách. TO je ta otázka, která se schovává za diskuzí agile nebo waterfall.

A tak je třeba brát i případnou agilní transformaci (pokud se k ní po důkladném zvážení i zde zmíněných aspektů rozhodnete). Je to rozhodnutí zavést do organizace LEAN principy jako systémově provázaný celek. Odshora dolů, zleva doprava.

Nikdo neříká, že to je ta jediná správná cesta. Pokud se však pro ni rozhodnete, tak někde to bude relativně snadné, protože už třeba celá řada takových věcí u Vás přirozeně funguje a jen se teď dozvídáte, že tomu kdesi v Japonsku říkají LEAN, popřípadě agile, a že je to teď celkem trend. A protože je vám vlastní se zlepšovat a experimentovat, zřejmě začnete zkoušet i ty věci, které zatím nemáte.

Jinde to bude možná složitější a o to víc bude vhodné si položit otázku, jestli to dělat nebo ne… Ovšem celá řada skutečností napovídá, že jistou míru agility (klidně i v řízení waterfall projektů 😉) bude zřejmě potřeba nabrat, ať chcete nebo ne.

Pozn.: Rozhodně se ale vyhněte nějakému „hybridnímu“ řešení, kdy rezignujete na vytváření realistického plánu (z jakýchkoliv důvodů) na jedné straně, ale zároveň nezavedete ani „agilní“ kontrolní mechanismy častých iterací a zpětné vazby. To není ani jeden z popisovaných přístupů, ale… totální zmatek.

Doporučení na závěr

Pokud jste dočetli až sem, zřejmě vás dané koncepty zajímají a chcete se posouvat. Výborně. Zkuste se tedy zamyslet nad níže uvedenými body a zvážit, kam až chcete směrem k „teal“ či „lean“ nebo „agile“ organizaci dojít a co můžete v dané oblasti udělat (ne nutně v daném pořadí):

• Jaký je smysl konání vaší organizace. Co je jejím primárním účelem? Kam vlastně chcete celkově směřovat? Je to něco, pro co se můžete vy i vaši kolegové nadchnout? Co i jim bude dávat smysl jejich konání?
• Reflektuje vaše práce vaše hodnoty? Můžete být právem hrdí na to, jakým způsobem jsou věci prováděny?
• Jak je vlastně ve vaší organizaci vytvářena hodnota? Co jsou vstupy, jak jsou postupně proměňovány na něco, co je pro vaše zákazníky užitečné a jsou za to ochotni platit. Říká se tomu value stream mapping či vytváření tzv. customer journey map.
• Pokud máte zmapováno, zamyslete se nad 3M… v kontextu vašeho organizačního uspořádání, procesů, nástrojů atd. Krmíte ty zmíněné M potvory? Nebo je vyháníte? Např. se můžete pokusit přeskládat organizační strukturu tak, aby vznikly stabilní (sebeorganizované, cross-functional) týmy, které budou zajišťovat některý konkrétní hodnotový tok nebo jeho vymezenou část. Jakýmkoliv dříve zmíněným přístupem.
• Jak můžete organizační strukturu co nejvíce zploštit?
• Chcete ty nejlepší kolegy? Lidé, kteří jsou angažovaní, motivovaní a skvělí v tom, co dělají, chtějí dnes většinou to, aby jim jejich práce dávala smysl, rozvíjela jejich schopnosti a bylo možné „si ji dělat po svém“. Command and control prostředí toto neumožňuje, plochá organizační struktura s vysokou mírou autonomie ano. S kým tedy chcete pracovat? S těmi nejlepšími? Nebo s těmi, kdo na vás „zbydou“?
• V jaké doméně CYNEFIN se nachází již „vyladěná“ řešení jednotlivých toků hodnoty? Které kroky jsou jednoduché, komplikované a komplexní? Podle toho… nechte své sebeorganizované týmy zvolit adekvátní přístup a vytvořte jim podmínky, ve kterých mohou dobře fungovat. A ať svůj přístup třeba formou retrospektiv dál ladí. Už jim do toho nevstupujte ;).

Ale není to úplně jednoduché…

Je pochopitelně jasné, že takové věci asi nebude moudré dělat nějakým velkým třeskem. Pokud „to“ lidi neumí. Viz třetí M potvora, MURI, která má v bojovém umění podobu snahy používat techniky, na které nejste dostatečně připraveni.

Budete muset postupně své kolegy učit přebírat zodpovědnost, dělat svá rozhodnutí a nést jejich následky. Je to běh na delší trať, pokud má být úspěšný. Měníte mindset, kulturu, přesvědčení. A je také pravděpodobné, že se s tím někteří lidé neztotožní a odejdou. Že vám (dočasně) poklesne produktivita a budou nějaké nezdary, než si vše sedne. Proto je ale také vhodné začít včas, dokud na to máte prostor a nečekat, až se třeba vaše organizace dostane do existenční krize. Pak už moc prostoru nezbývá.

Nic z výše uvedeného nesnímá z managementu organizace zodpovědnost za vytváření prostředí a pravidel hry, ve kterých se budou ostatní pohybovat. Ty organizace, které jsou dnes skvělé, dosáhly svého úspěchu díky inspirativnímu leadreshipu a schopnostem svých vrcholových manažerů. Lídrů, nikoliv mikromanažerů či despotů.

Tak ať se vám to daří! A budu rád, když mi popíšete své zkušenosti, jak se vám ve vašem úsilí vede.