Bezpečné prostředí

Termínu „bezpečné prostředí“ se věnuje v posledních letech stále větší pozornost, ať už jde o konference, knihy, TED talks nebo příspěvky na blozích. Je velmi těžké jej správně pochopit a následně aplikovat do prostředí firmy nebo na úrovní týmu. Otázka tedy zní, co ve skutečnosti znamenají slova „bezpečné prostředí“ a proč jsou tak důležitá? Jak mohou vedoucí, manažeři nebo kouči zajistit, aby měli lidé pocit „bezpečného prostředí“ každý jeden den, kdy jsou v práci?

Začněme nejprve s definicí na teoretické úrovni, pak se postupně přesuneme ke konkrétním příkladům. Článek zakončíme několika praktickými nástroji a nápady, které můžete vyzkoušet ve svých společnostech, týmech nebo odděleních.

Co je bezpečné prostředí?

Mít bezpečné prostředí ve společnosti znamená, že každý ve společnosti nebo v týmu může věnovat 100% pozornost samotné práci. Jednoduše řečeno, každý se může soustředit na něco hodnotného, být kreativní a produktivní. Úlohou lídrů je vytvořit takové prostředí, kde selhání je přijatelné a selhání je považováno za nejlepší způsob učení.

V tomto druhu prostředí se lidé cítí podporováni a opečováváni ve všech aspektech jejich práce. To znamená, že neexistuje nikdo, kdo by je pranýřoval za „špatné KPI“, a ani nedochází k tomu, že by lidé jako supi čekali až se uvolní pozice po kolegovi, kterou by mohli zaujmout.

Jinými slovy, neexistují žádné skryté agendy ani politikaření, každý může dělat jen to, co má rád a na co byl najatý.

Jak ho poznat?

Barometr je poměrně jednoduchý a lze jej shrnout do několika klíčových otázek, které si můžete položit jako člen týmu nebo lídr a zjistit, jak si váš tým v současné chvíli stojí.

1. Jak často lidé ve vašem týmu/společnosti přicházejí s novými nápady nebo experimentují s novými nástroji/postupy?

Je číslo blízké nule nebo jste realizovali tolik experimentů, že je už těžké je všechny sledovat?

2. Jak často lidé vyzývají “status quo”? (např. na schůzkách slyšíte „Ne“, „Nesouhlasím“ nebo „Mám lepší nápad“)

Jsou schůzky spíše pasivním sdílením informací, kde vedoucí/manažer komunikuje s ostatními bez jakékoliv reakce či protinávrhů, nebo jde o živou diskusi, kde se každý názor počítá?

3. Jak lidé reagují, když chce někdo měřit/sledovat trendy a čísla?

Zaznívá „Počkej, co se stane, když nebudu plnit stanovená čísla? Budu potrestán nebo dokonce vyhozen?“ nebo naopak slyšíte „To je skvělé! Další údaje, které nám pomohou se zlepšit a vidět věci/vzorce, které jsme dříve neviděli.“

4. Co se stane, když se nepodaří doručit Sprint nebo nějaký projekt nesplní termín?

Říkáte si „Čí je to chyba a jak je možné, že došlo k selhání?“ nebo naopak směřujete pozornost k tomu „Co můžeme udělat pro zlepšení?“

5. Jaká je úroveň transparentnosti ve společnosti?

Jsou všechna čísla spojená s řízením společnosti k dispozici pouze skupině vyvolených nebo jsou transparentně sdíleny napříč společností bez rozdílu?

Těchto pět klíčových otázek vám pomůže pochopit, jak se vám daří jako týmu/společnosti. Pokud byly vaše odpovědi většinou podobné výše uvedeným druhým možnostem, pak gratuluji, podělte se prosím o to, co děláte a co vám pomohlo se tam dostat, se zbytkem světa. Pokud je tomu naopak, pak je to pro vás signál, že se lidé necítí v práci bezpečně a další zřejmou otázkou je …

Co s tím můžete dělat?

Vzhledem k tomu, jak je toto téma široké, existují určité činnosti, které byste rozhodně měli vyzkoušet a které vás provedou k lepšímu a bezpečnějšímu prostředí nebo alespoň k lepšímu pochopení toho, jaký je základní problém, na který se musíte zaměřit.

Změňte se

Pokud jste lídrem, začněte nejprve s vlastní transformací, protože tato změna bude mít největší dopad na vaši společnost. Buďte přímější a pokuste se poskytnout více prostoru pro nápady a experimenty lidí s neznámými výsledky. Další tipy najdete v našem předchozím článku o Agilním leadershipu.

Udělejte si barometr/kontrolu stavu bezpečného prostředí

Pokud jste již slyšeli o kontrole stavu Spotify health check nebo Atlassian Health monitor, můžete v tomto případě použít stejné zásady. Zeptejte se vašich lidí, jak se cítí. Zaměření průzkumu by mělo být podobné výše uvedeným otázkám, jako například:

  1. Jak je pro vás příjemné dávat zpětnou vazbu vedoucímu týmu, manažerovi nebo komukoli z vedení společnosti? (Mohlo by být rozděleno na několik otázek, abychom získali lepší zpětnou vazbu)
  2. Máte pocit, že existuje vzájemná důvěra mezi vaším oddělením a ostatními částmi společnosti (např. Prodej, Vývoj, Produkt atd.)?
  3. Máte pocit, že ve své každodenní práci přebíráte iniciativu a rozhodujete se, aniž byste museli žádat o schválení nebo se obávat možných negativních důsledků?

Určitě najdete další otázky týkající se vaší společnosti a oboru, ve kterém se pohybujete. Tyto tři ukazují pouze základní principy a jak postupovat při návrhu.

Každá jednotlivá otázka by měla mít prostor, do nějž může kdokoli připsat své komentáře. Cílem je, abyste získali kromě statistik více kontextu. Budete překvapeni, kolik toho se dozvíte o potenciálních problémech a výzvách uvnitř vaší společnosti.

Dalším skvělým barometrem je například v nepovinné pole se jménem. Toto políčko vám řekne hodně o bezpečném prostředí ve vaší společnosti, protože pokud lidé nejsou ochotni se podepsat pod svou odpověď, znamená to, že existuje prostor pro zlepšení firemní kultury.

Zkuste firemní NPS průzkum

Velmi podobnou myšlenkou je provedení průzkumu NPS (Net Promoter Score) ve vaší společnosti. Obvykle se tento nástroj používá k pochopení toho, jak se zákazníci cítí ohledně produktu nebo služby, ale proč ho nepoužívat interně, že? Stačí jedna jednoduchá, ale velmi silná otázka:

“Jak byste na stupnici od 1 do 10 doporučili naši firmu vašemu příteli nebo známému?”

Přidejte také textové pole pro volnou odpověď, protože čísla vypráví pouze jednu část příběhu a vy potřebujete znát také podrobnosti, abyste se zlepšili. Navíc, jak jsem již zmínil dříve, volitelné pole se jménem/e-mailem může fungovat také jako dobrý barometr. Dělejte průzkum pravidelně (nejméně dvakrát ročně) a vždy systematicky pracujte s odpověďmi. Pokaždé řekněte vašim lidem, co se chystáte zlepšit do příštího průzkumu (a samozřejmě transparentně komunikujte!).

Jaké jsou další kroky?

Bez ohledu na to, kterou z možností si vyberete, jedná se jen o jeden z mnoha kroků k vytvoření lepší kultury a bezpečnějšího prostředí. Co se stane poté, je absolutně klíčové. V ideálním případě by se všichni lidé ve vedoucích pozicích měli podívat na výsledky a zjistit, na co by se měli v blízké budoucnosti zaměřit.

1. Přiznejte si, že vaše firemní kultura má před sebou dlouhou cestu

Zde je pomyslný první krok nejtěžší. Je velmi snadné zahodit zpětnou vazbu, kterou jste dostali a najít omluvu pro každou z odpovědí. Faktem je, že vaši lidé dostali hlas a vy jako lídři společnosti byste mu měli naslouchat. Někdy to znamená si připustit, že naše firemní kultura není na úrovni, na jaké jsme si mysleli. I toto je správný první krok.

2. Následné týmové schůzky a 1on1 setkání

Může existovat spousta věcí, které nebyly dobře komunikovány a lidé mohou být kvůli tomu frustrovaní. Takže si jen udělejte čas, abyste s nimi měli možnost promluvit jednotlivě nebo s celým týmem. Ukažte jim, že vám na nich záleží natolik, že si uděláte čas ve svém nabitém programu, abyste o věcech mohli diskutovat a poučili se z nich.

3. Sledujte trendy

Ať už si vyberete kteroukoli možnost, po několika iteracích se vždy zaměřte na trend. Odpovědělo více lidí? Nebo uvedlo více z nich své jméno, protože nyní cítí, že na jejich názoru záleží a cítí se bezpečně to bez anonymity říci? Nebo je to naopak? Trend vám v těchto případech vždy řekne, zda jdete správným způsobem z hlediska firemní kultury. Klíčem je pochopit, že nejde o to, kde začít, ale o to, kam chcete dojít a co se v procesu učíte. Počáteční výsledky nemusí být tak skvělé, ale cílem je postupné zlepšování, byť jsou to jen malé kroky.

Závěrem

Dosáhnout nebo vytvořit bezpečné prostředí ve společnosti je nesmírně obtížně. Jedná se však de facto jen o odvahu klást složité otázky, přiznat si, že existuje prostor pro zlepšení a pochopit, že je na lídrech firmy, aby se zlepšili a posunuli firemní kulturu na další úroveň.

Agile ve strojírenství

Agilita je dnes populární v mnoha průmyslových odvětvích. V IT, kde vznikla, je už de facto standardem. V mnoha bankách běží více či méně úspěšné Agilní transformace. Pojďme se však spolu podívat na příběh z Agilně netypického oboru strojírenství, konkrétně do společnosti REHAU.

Stručně o REHAU

Společnost Rehau byla založena v Německu a od roku 1948 působí v oblasti nábytku, průmyslu, stavebnictví a automobilového průmyslu. Nyní jsme globální společností s více než 20 000 zaměstnanci. Naše první spolupráce v automobilovém odvětví byla se společností VW Beetle, která je dodnes naším velkým zákazníkem. Krom toho jsme také dodavateli hlavních prémiových značek jako je Porsche, Audi, BMW nebo Daimler, přičemž dodáváme převážně venkovní díly s nátěrem na polymerní bázi. Dodáváme také nárazníky a další venkovní díly za pomocí logistických procesů Just In Time (JIT) a Just In Sequence (JIS) z 16 různých továren v Jihoafrické republice (RSA) napříč celou Evropou a USA. V České republice máme své vývojové středisko pro automobilový průmysl v Čestlicích a dále tři výrobní závody v Moravské Třebové, Jevíčku a Mladé Boleslavi.

Počátek agilní transformace

Skupina REHAU začala s Agilní transformací v roce 2018, aby se stala flexibilnější, rychlejší a získala větší důvěru mezi zákazníky a jednotlivými týmy REHAU. Lukáš Kalal (vedoucí Engineering Design & Services CZ/IN v Praze – Čestlicích) se zúčastnil Agilního školení v USA a to v něm probudilo touhu začlenit některé Agilní principy do každodenní práce v našem závodě. Po tomto inspirativním školení jsme hledali partnera, který by nás mohl provést problematikou agility. Dostali jsme jasné doporučení, že firma RainFellows by měla být naší první volbou.

První krok

Jakákoliv organizační změna vyžaduje, aby lidé změnili své návyky – ty vytvářejí skutečné procesy společnosti. Zní to jednoduše, ale ve skutečnosti musíte čelit mnoha různým vrstvám odporu. Přestože jsme si většinou dobře vědomi různých problémů, máme tendenci vymýšlet si nespočet důvodů, proč se musíme držet našich starých dobrých zvyků a způsobů práce. A že všechno ostatní může být pro cíl změny nebezpečné. Je to naše vnitřní přesvědčení, které vytváří silný strach ze změn, a tím silný odpor, který se promítá do naší řeči například následovně:

  • „Nové věci nevydrží a mohou být nebezpečné!“
  • „Tohle u nás nikdy nebude fungovat, protože naše práce je specifická! (Nejsme IT, jsme velká společnost, naši zákazníci jsou zkostnatělí, máme distribuované týmy atd.)“ 
  • „To jsme zkusili již v minulosti a nefungovalo to… Pojmenujte jednu společnost, kde Agile funguje!“

Takové reakce slyšíme často.

Něco změnit stojí energii a přináší menší stabilitu. Lidé se neznámých věcí a změn bojí. Často však zapomínáme, že náš úspěch je založen na naší schopnosti přizpůsobit se.

Změnit jakékoliv návyky či procesy vyžaduje nejprve uvědomit si jejich negativní dopad a postupně lidi nechat, aby změnili svá základní přesvědčení. To v důsledku minimalizuje úroveň strachu a odporu.

Abychom vytvořili vhodné prostředí pro takovéto uvažování a získali agilní zkušenosti z první ruky, uspořádali jsme celodenní workshop. Zahrnoval půldenní (!) simulování tradičního projektu a vznik Agile. Protože to byla jen „simulace“ a sami účastníci dokonce do jisté míry vymýšleli agilní způsoby práce (od té chvíle se stali jejich vlastníky!), všichni se nakonec cítili uvolněnější a otevřenější změnám. Samotný workshop umožnil účastníkům uvědomit si současné návyky (tzn. procesy), jejich negativní dopad, potřebu změny a nechal je bezpečně změnit svá základní přesvědčení (např. „je to nová věc a je to nebezpečné“). Jakmile jsme tohoto dosáhli, mohla nastat skutečná změna v naší organizaci.

Výhody úvodního workshopu:

  • Účastníci získali praktické agilní zkušenosti v bezpečném prostředí, které jim umožnilo poučit se ze svých chyb;
  • Odpovědi na důležité otázky od důvěryhodných odborníků a znalosti, jak jiné společnosti implementovaly Agile;
  • Postoj odporu se změnil z „nebude fungovat“ na „zkusme to“;
  • Vlastnictví změny se přesunulo na lidi;
  • Energie a vzrušení pro změnu.

Kaizen workshop 

Poté, co jsme týmu umožnili zpracovat zkušenosti z prvního workshopu, nastal čas na další. Cíle druhého workshopu byly: 

  1. Zmapovat stávající procesy;
  2. Identifikovat hlavní problémy a úzká místa;
  3. Najít lepší možné způsoby práce;
  4. Vytvořit si implementační plán.

Zúčastnil se celý tým a každý mohl říct svůj názor. Tím se vytvořil pocit vlastnictví společného nového způsobu práce. Bylo opravdu skvělé vidět tu energii a vzrušení a jak všichni přispívají. Vzhledem k povaze naší práce (Engineering) jsme se rozhodli použít techniku ​​Kanban namísto dnes tak populárního Scrumu. Díky celodenní týmové práci jsme přišli s návrhem, jak bude vypadat nový proces – Kanban Board s lístečky na něm.

Proč Kanban:

  • Přesné specifikace požadavků od našich klientů;
  • Čtrnáctidenní sprinty by znamenaly pouze umělé milníky, bez přidané hodnoty;
  • Potřeba vizualizace celého procesu;
  • Malá změna od současného způsobu práce.

Jako poslední krok jsme se dohodli na implementačním plánu:

  • Připravena fyzická tabule a prezentace týmu (dva týdny po workshopu) – sběr zpětné vazby, potvrzení konečné změny;
  • První použití pilotu (po jednom týdnu);
  • Retrospektiva a vylepšení (po jednom měsíci používání);
  • Retrospektiva a vylepšení s RainFellows (po 6 měsících).

Implementace Kanban, denní stand-up a retrospektivy

Nejprve jsme vytvořili prostředí, které nezastaví nadšení lidí tím, že nebude fungovat nebo tím, že bude chybět vybavení. Rychle jsme koupili magnetické tabule a pomocí pásky jsme definovali dohodnuté rozvržení procesu. Tabule byla vybavena lepicími lístečky různých barev a magnety. Nejdůležitější bylo začít co nejdříve po workshopu. Věděli jsme, že první návrh tabule není optimální, ale všichni si byli vědomi, že se bude vyvíjet a my ji budeme optimalizovat za běhu.

Byli jsme rádi, že jsme udělali pilotní tým pro změnu. Pilotní tým měl ukázat cestu ostatním týmům. Někteří to zpočátku nepřijali a považovali to za ztrátu času, ale čas ukázal opak.

Nyní každý sdílí stejnou úroveň informací a získává úplný přehled o všech projektech. Rychlost rozhodování přesvědčila i ty skeptické. A teď dokonce pomáháme ostatním oddělením založit jejich vlastní Kanban Board.

Výhody, které pozorujeme:

  • Po několika měsících jsme provedli průzkum. Výsledek nás všechny překvapil – bylo to velmi pozitivní! 
  • „Přehled“ byl jmenován každým jako hlavní přínos. Stejná úroveň informací, dokonce i pracovní zátěž sdílená všemi v týmu; 
  • “Snadnější spolupráce” a “svoboda výběru úkolu” byly další běžné odpovědi týmu; 
  • Z vnějšího hlediska týmový duch zvyšuje transparentnost a úroveň sdílení informací mezi lidmi; 
  • Kromě toho tým přirozeně fungoval v samoorganizačním režimu bez jakýchkoli zvláštních kroků.

Implementace nástroje Jira 

Měli jsme dobrý důvod přestěhovat se z fyzických tabulí do Jira. Museli jsme zlepšit spolupráci s naší kanceláří v Detroitu a naší novou kanceláří v Indii. Koordinace kapacity na vzdálených místech bez sdílené platformy stojí spoustu komunikace.

Stejně jako u fyzické tabule jsme vytvořili prostředí, které fungovalo bez přerušení od začátku. Prostudovali jsme Jira a otestovali si základní funkčnost, jako jsou filtry a různá uspořádání karet s úkoly pro lepší organizaci práce.

Indický tým jsme našli jako optimální pilot pro Jira. Šlo o zcela nový malý tým, který si právě nastavoval způsoby práce. Proč jim tedy hned neukázat nový proces? Přijali to jako součást standardních procesů, ne jako změnu. V Indii jsme jim poskytli týdenní osobní podporu a nechali tým otestovat Jira. Po tomto úspěšném testu jsme uspořádali úvodní setkání v Praze. Abychom zachovali možnost osobních schůzek, rozhodli jsme se použít projektor vedle fyzické tabule a použít jej jako paralelní vizuální podporu našich denních schůzek. Na druhém setkání jsme odhalili, že se každý díval na projektor místo fyzické tabule s kanbanem, takže od té doby používáme už pouze Jira.

Práce z domova 

Naštěstí jsme začali pracovat s Jira před dobou nucené práce z domova. Ve skutečnosti to bylo jen dva týdny před pandemií. Takže to byla spíše adaptace na situaci. Naše setkání jsou nyní delší, místo 5 minut to trvá 30 minut. Hlavně proto, že musíme kompenzovat izolaci a lidé rádi mluví i o jiných věcech, než jen o problémech nebo kapacitách.

Výhody Jira:

  • Možnost přidat informace přímo na pracovní kartu. Mít vše na jednom místě a dosažitelné pro všechny členy týmu;
  • Nedokážeme si představit, jak by se současná situace řešila s něčím jiným než s touto platformou a sdílenými informacemi;
  • Digitální Kanban Board otevírá možnost statistik a ukazuje oblasti, kde se můžeme zlepšit.

Plány do budoucna

Stále jsme na začátku a je toho ještě hodně co dělat. Musíme studovat Jira ještě hlouběji a také požádat tým o zpětnou vazbu.

Kromě toho bychom chtěli zahájit takovouto Jira-spolupráci i s našimi kolegy v Německu a tímto způsobem spolupráce pomoci ostatním útvarům v celé společnosti. Později by bylo skvělé, kdybychom bez e-mailů použili Jira pro sdílení všech informací o projektech, takže úplné informace by byly vedeny již pouze v Jira-úkolech. Když se podíváme do budoucna, rádi bychom např. sledovali hodiny a kontrolovali rozpočet podle reportů z Jira nebo realizovali projekty s našimi zákazníky v Jira.

Závěr

Agile byl původně vynalezen v oblasti IT pro úspěšné řízení projektů ve vysoce turbulentním prostředí. Mnoho nápadů však vzniklo ve vývoji produktů Toyota, v dílnách slavného českého podnikatele Tomáše Bati a mnoha dalších. V současné době naše globální ekonomika vstupuje do nebývalé situace. Můžeme očekávat, že v důsledku toho dojde k neočekávaným událostem a změnám. Agile je tedy logickým nástrojem k úspěšné plavbě vysokými vlnami neznáma.

V REHAU jsme zažili to, že se týmy během transformace změnily: jsou „svěžejší“, aktivní, samosprávné a rychleji reagují.

Spoluautoři

Lukáš Kálal, Head of Engineering Design & Services CZ/IN, REHAU

Jakub Gurecký, Internal Agile Coach, REHAU

Vzkaz všem, kteří se pustili do Agilní transformace

Agilita byla v posledních letech velkým tématem. Mnoho firem se pustilo do Agilní transformace. Ponechme na chvíli stranou důvody proč. Aktuálně je ale mnoho z nich v situaci, kdy mají za sebou strukturální změny (nová organizace, role), ale zdaleka nemají všechny principy a znalosti zakořeněné a funkční. 

S příchodem koronaviru jsme se úplně všichni octli v bezprecedentní situaci. Ze dne na den většina z nás zůstala dlouhodobě doma na home office a s ostatními nás pojí pouze telefon a počítač. Na tuto situaci se dá reagovat dvěmi způsoby:

  1. Považovat aktuální situaci za krizi a vrátit původní role manažerů, kteří mají dohlížet na plnění všech úkolů svého týmu. Pro spoustu manažerů to otevírá nové téma: jak mít pod kontrolou tým, který nesedí v kanceláři a na který “nevidím”? Za takovým rozhodnutím stojí přetrvávající přesvědčení, že lidem nemůžu důvěřovat, nebo že nejsou dostatečně kompetentní.    
  2. Uplatnit právě teď Agilitu – Agilní metody byly vytvořeny právě pro turbulentní prostředí. Což je právě to, čím procházíme. Agilita stojí na opačném přesvědčení – důvěra a dovednosti. Posiluji tedy vzájemnou důvěru a posiluji dovednosti týmu. 

Kdy a jak se tak děje:

Daily stand-up

“Stand-upy jsou zbytečné, protože si ty důležité věci řekneme v kanceláři.” Tahle častá námitka proti Daily stand-upům v dnešní situaci neplatí. Po celém dni v “izolaci” je prostě fajn spojit se s ostatními a probrat, kdo a jak na tom jsme. Je to důležitý sociální kontakt, který nám všem prospívá. 

Zároveň je to společné místo, kde se dá včas zachytit nepochopení zadání úlohy, chybná domněnka v řešení, chybějící proaktivní (včasná) komunikace o problémech. Pokud jako manažer vstupuji na meeting s přesvědčením “jsem tu, abych zkontroloval, zda se někdo nefláká”, ostatní mě budou vnímat jako kontrolního policajta, kritizujícího otce, se kterým se ostatní cítí jako “provinilé děti”. Otevřenost a upřímnost je rázem pryč. Kde je pocit viny, tam není vyspělý, sebevědomý přístup. 

Když na meeting naopak vstupuji s přesvědčením “jdeme odchytit možné nedorozumění nebo chyby bez ohledu na to, kde a kdy vznikly”, stávám se partnerem, který je tam pro ostatní a společná platforma meetingu je bezpečným prostorem pro řešení mých problémů.

Kromě klasických stand-upů doporučujeme 1x týdně neformální video meeting, který nemusí mít agendu, jen prostě pokecat, jak se kdo má, příp. si společně zahrát nějakou hru – např. “která barva, zvíře, věc reprezentuje to, jak jsem se v poslední době cítil?”  

Sprinty nebo Kanban board a vizualizace

Stand-up není místo, kde se rozděluje práce a určují priority. Takovým místem je Board (např. Kanban / Sprint v nástroji jako Jira nebo Trello) se všemi klíčovými KPIs. Zde všichni aktuálně vidí, jak na tom jsme: doručíme včas? Plníme všechna SLA?

Jednoduchá vizualizace výkonu týmu by měla být dostupná všem a každý člen týmu by jí měl umět interpretovat: “Jak mám dnes efektivně organizovat svou práci? Co jsou aktuální priority? A směřujeme k cíli?” K tomu slouží plán Sprintu, příp. pro servisní týmy pak Kanban board. Jako podporující manažer bych si měl dát za cíl u všech vytvořit dovednost takto s Boardem pracovat, spíše než práci přímo rozdělovat. Pokud se na mě stále tým obrací s tím, abych věci rozhodnul, první co bych se měl ptát – jak u nich vybudovat dovednost a u sebe důvěru, že to zvládnou?

Retrospektiva

Zlepšování a efektivita jsou často první věcí, kterou v krizi opouštíme. Jsme 100% reaktivní a jdeme cestou prvního řešení, které nás napadne. Což často způsobuje řetězec chybných rozhodnutí. Největší krize a fatální dopady jsou málokdy způsobeny jednou událostí – často je to řetězec chybných, reaktivních, rozhodnutí. 

“Slow down to speed up”. Bitvy vyhrávají stratégové. Právě v momentu krize je třeba se nadechnout, vymanit se z reaktivního kolečka. Získat odstup a přemýšlet o tom, co musíme změnit, zlepšit, zefektivnit. Často ty největší “poklady” nestojí velké množství času a peněz, kterých se nám v krizi nedostává.     

Agilita má na to nástroj v podobě Retrospektivy alias Kaizen. V aktuální situaci doporučujeme retrospektivu na bázi týdne / čtrnácti dnů. Pokud vnímám, že tým není sám schopen “úzká” a problematická místa sám identifikovat, jako manažer přináším tento kontext právě na společnou Retrospektivu.

Efektivita online meetingů

Efektivita meetingů je velkým tématem – má dopad na manažerské rozhodnutí, jak pracovat s týmem. Proto dříve než zahodíte výše uvedené schůzky, doporučujeme se nejprve zamyslet nad jejich efektivitou. Dnes máme nespočet online nástrojů, které jde využít ve stávající “home office” situaci: Google Meet, Skype, Zoom, Webex. Jak se dá zvýšit jejich efektivita:

  1. Počet lidí na meetingu – pokud vyžadujete zapojení od všech zúčastněných, mějte počet do 5 (max 7) lidí, což je ideální Agilní tým. Jinak vás čeká neefektivita jako např.: dva lidé začnou mluvit přes sebe a následujících 5 minut si dávají přednost. Pokud máte týmy větší, rozdělte je do malých skupin po 3-5 lidech. Zástupci z každé skupiny se následně setkají na následném “velkém” meetingu, kde si sdílí klíčové věci z každé skupiny.
  2. Vizuální podklad – ať již stand-up nebo plánování, vše by se mělo odehrávat v kontextu Boardu. Sdílet obrazovku, zobrazit souhrnné slajdy. Nebo můžeme využít nástroj jako např. Jamboard od Google a vidíme virtuální lístečky před sebou.
  3. Moderátor – také pomáhá, pokud jeden člověk (nemusí být vždy stejný) sdílí obrazovku, uděluje slovo, dělá závěry. Na začátku to je typicky Agilní coach / Scrum Master, později si tuto roli ideálně zažije každý.
  4. Mám vypnutý mikrofon, pokud nehovořím – drobnost, která dělá hodně. Citlivost některých mikrofonů dokáže udělat z míchání čaje totální rambajs na druhé straně. V tu chvíli se “utlumí” ten, kdo zrovna hovoří, neboť systém si myslí, že má přenést do popředí silnější zvuk a nerozlišuje randál od smysluplné věty. Všichni povinně vypnout mikrofony a pouze jeden hovořící má mikrofon zapnutý. 

Kultura důvěry a partnerství

Kultura, která stojí na jednom kompetentním manažerovi, který dohlíží na víceméně “nekompetentní” podřízené, se velmi těžko realizuje v aktuálních podmínkách “home office”. 

Agilita stojí na otevřené kultuře partnerství. Pokud jste stihli transformaci směrem k této kultuře, máte “doma” členy týmu, kteří 1) mají potřebné dovednosti – umí společně komunikovat o problémech a proaktivně je řešit, orientovat se v aktuálních cílech a prioritách a efektivně směřovat k jejich naplnění, 2) jsou motivovaní – cítí odpovědnost za výsledek, mají vnitřní chuť a sílu překonávat problémy a věnovat potřebný čas řešení úkolů. K tomu je důležitá důvěra ve své dovednosti a důvěra manažera směrem k týmu.

Vybudovat takovou kulturu ovšem stojí nějaký čas. Pokud v této kultuře ještě nejste, využijte aktuální situace jako akcelerátoru této transformace – co jiného vám zbývá?

  1. Rychlá zpětná vazba – rychlá zpětná vazba je nutnost, pokud chceme u někoho budovat dovednosti. Pokud tým nebo kterýkoliv člen “selhává” – tj. udělá chybné rozhodnutí, žije v sebeklamu (pracuji málo, pracuji hodně, apod.), neidentifikuje včas prioritní problém, musí dostat rychlou a srozumitelnou zpětnou vazbu. Ideálně automaticky, systémově. Slouží k tomu např. to, když společně plánujeme, setkáváme se na daily stand-upech a vedeme všechny úkoly v nástrojích jako Jira nebo Trello.
  2. Důvěra – pokud nemůžu mít 100% kontrolu, můžu mít k lidem alespoň důvěru; pokud systematicky pracujete na bodu 1) z postoje důvěry, budujete systém, který je nápomocný, nikoliv restriktivní a ryze kontrolní. Pokud totiž vím, že na mě někdo dozírá jako policista nebo úředník finančního úřadu, většinu své energie vyplýtvám na to, aby vše “vypadalo podle očekávání”.

Příležitost

Každá krize je příležitostí. Až situace kolem koronaviru pomine, máme šanci probudit se ve světě, kde Agilitu, resp. firemní kulturu, neděláme kvůli “rozhodnutí managementu”, ale protože nám to pomohlo v krizovém momentě. A pomůže i do budoucna.

Fixní kontrakt a vývoj? Recept na selhání

Někdy se stane, že projekt selže. A to navzdory všemu možnému, co pro jeho úspěch uděláme. Třeba i aplikování toho nejlepšího z osvědčených postupů. Ať už jste dodavatel nebo zákazník, takzvané fixní (fixed price) kontrakty nejspíše udělají z vašeho vysněného projektu noční můru.

Zdroj napětí

Zákazník potřebuje fungující a kvalitní produkt nebo službu. Dodavatel chce takový vyvinout. Ale ve většině případů se to nepovede. A je v podstatě jedno o jaké odvětví se jedná.

Tvoříte pro klienta novou marketingovou strategii? Vyvíjíte nové senzory pro měření stavu počasí? Nebo software? Zbystřete – váš projekt má statisticky velmi malou šanci na úspěch.

Samozřejmě existuje mnoho faktorů, které přispívají k tomuto selhání, ale jednou z hlavních příčin bývá kontrakt – formální spojení mezi zákazníkem a dodavatelem. S kontraktem vše začíná a také obvykle končí, protože v případě problémů je to právě kontrakt, co nakonec rozhoduje. Podívejme se, jaká rizika typické fixní kontrakty přinášejí a jak se jim vyhnout.

Většina vývojových (R&D) projektů selže

Podívejme se v detailu na vývoj software, protože tam všechny nevýhody a rizika dobře vynikají. Pravděpodobnost úspěchu softwarového projektu (SwP) je asi jen 37% [Standish Group – Chaos report 2010, 2012, 2014, 2017]. To je docela alarmující, navíc se to s léty nijak nelepší. Znamená to, že by lidé v IT byli hloupí nebo neschopní? Ne, problémem je, že pro budování software používáme nevhodné modely spolupráce a postupy. Většina zákazníků totiž přistupuje k vývoji software na zakázku stejně jako k nákupu produktů (automobily, telefony, počítače, domy). Ale pravdou je, že tyto dva případy nejsou stejné. Podívejme se proč.

SWD CZ

Jak vidíte na obrázku výše, šance na opakovatelnost úspěchu a opětovné využití znalostí v případě návrhu unikátního software na zakázku je mnohem nižší, než v případě výroby např. automobilu.

Použití stejného přístupu bychom mohli přirovnat k realizaci programu Apollo (člověk na Měsíci), plného nezbytného výzkumu a vývoje nových technologií, pomocí tzv. vodopádového modelu – popsat do detailu cíl, navrhnout najednou celé řešení, postavit napoprvé funkční raketu s příslušenstvím a v předem daném datu odpálit posádku k měsíci. Jsem přesvědčen, že by se jednalo o jednu velikou katastrofu. Byla to až 11. mise Apollo, která nakonec přistála na měsíci. A představte si kolik miliónu cyklů pokus-omyl bylo třeba provést se všemi prototypy a podsystémy před tím, než bylo vůbec možné uspět.

Úspěch v těchto kreativních/inovativních oborech, kam SwP nepochybně patří, vyžaduje četné krátké cykly učení. Jen tak je možné vytvořit něco tak složitého, jako je software naplňující neurčité potřeby zákazníka. Problémem je, že k takovým projektům přistupujeme s domněnkou, že jsou předvídatelné. Snažíme se vše zafixovat do kontraktu v okamžiku, kdy vlastně o celém projektu a problému, který řeší, víme nejméně. Kdy ještě neznáme kritické informace, které vyplynou až v průběhu realizace.

Dům snů

house of dreamsPokud jste někdy stáli na straně zákazníka, určitě víte, jak těžké je formulovat požadavky. Kde začít? Jak celý problém uchopit? Často se stává, že ty nejdůležitější požadavky dokonce chybí.

Když se zeptáme lidí na našich workshopech: “Představte si svůj dům snů… všechno je možné… jaký by byl?”. Obvykle dostaneme odpověď jako že bude mít bazén, velikou televizi, obří obývák, sám se bude uklízet atd. Ale nikdo obvykle neřekne že bude mít okna, dveře, zdi a střechu. Proč? Protože to je “jasné”, že každý dům je má. Každý architekt by to měl vědět, ne? A teď si představte zákazníka odmítajícího převzít software, protože je jasné, že každý bankovní systém řeší i pravidelné posílání měsíčních výpisů z účtu, které samozřejmě ani nebylo součástí požadavků. Analytik to přeci měl vědět…

Mary měla malé jehňátko

mary had a little lambA to není všechno. I kdybychom byli schopni všechny požadavky popsat, stále bude obtížné je přesně pochopit. Znáte říkanku “Mary měla malé jehňátko”? (Mary had a little lamb) Pokud ji vytrhneme z kontextu – stejně jako to děláme s požadavky – co ta věta znamená? Jak jí rozumíte?

  • Starala se Mary o svého mazlíčka jehňátko?

  • Nebo snědla malé jehně?

  • Nebo snědla malou porci velkého jehněte?

  • Porodila jehně?

  • Měla s ním sex?

  • Napálila nějakého naivu, aniž by za to nesla následky? (z hantýrky burzovních makléřů)

Jak vidíte, jediná věta v požadavcích může být interpretována mnoha různými způsoby. Dokonce takovými, které by nikdo ani nehádal – třeba ten s tím naivou. A teď si představte tisíce vět ve specifikaci požadavků, z nichž každá podléhá tomuto takzvanému Mary had a little lamb syndromu. Vidí čtenář požadavků budoucí software stejně jako ten, kdo tuto specifikaci píše?

Proč tedy uzavíráme fixní kontrakty?

Takže pokud…

  • se potřebujeme adaptovat na měnící se požadavky po celou dobu projektu
  • nedokážeme předem definovat všechny detailní požadavky
  • nedokážeme jim jednoznačně rozumět
  • a tím pádem ani odhadnout jejich pracnost

…proč tedy stále tyto fixní kontrakty používáme a snažíme se vše odhadnout a zafixovat předem? Obsah projektu, čas doručení a cenu? Předpokládám, že tomu tak je, protože lidé podpisující tyto kontrakty si neuvědomují specifika vývojových R&D projektů nebo prostě neví o žádné rozumnější alternativě. Ale takový omezující kontrakt má pak velmi negativní důsledky.

cage bars lock closed fixed contract birdPředstavte si sami sebe jako dodavatele svázaného takovýmto kontraktem, který penalizuje jakékoliv porušení některého z rohů pomyslného trojúhelníku požadavky, datum doručení a cena. Představte si, že se objeví nějaká komplikace, což se velmi pravděpodobně stane. Zvolíte risk a doručíte to, co zákazník opravdu potřebuje, anebo budete hrát bezpečně a doručíte to, co je doslovně napsáno v kontraktu? Mnohdy zákazník ani nechce nebo nemůže zmíněné komplkace řešit. Co uděláte? Většina lidí volí “bezpečnou” variantu a doručí to, co je kontraktováno. A pak je to tady – prohra na obou stranách. Zákazník nedostane to, co pro svůj byznys skutečně potřebuje a dodavatel je za to obviňován. Přepracování produktu a oprava chyb pak násobí cenu celého řešení.

Nedokážeme předvídat budoucnost (nevíme, co nevíme) a v ní a v realizačních detailech jsou ukryta ta nejhorší překvapení. Jako například změny potřeb zákazníka, technické problémy, neplatné předpoklady, legislativní změny… Nejvíce překvapení zažijeme, když jsou odhady pracnosti a kontrakt vynuceny velmi brzy, kdy nemáme příliš mnoho informací. Ze zkušenosti také víme, že tato omezení vyplývající z kontraktu vytvářejí bariéru mezi zákazníkem a dodavatelem, která jim pak brání v aplikování praktiky, která by mohla celou situaci zlepšit – tzv. trvalého zlepšování (continuous improvement). Bariéry prodlužují nebo znemožňují nezbytné cykly učení.

Agile/Lean kontrakt

air freedom options mountains sky free people man person

Co bychom tedy měli udělat? Jednoduše řečeno – nedávat do kontraktu detailní popis výsledného produktu, ale raději se v něm zaměřit na to, jak mají dodavatel a zákazník spolupracovat, aby dosáhli společně nejlepšího možného výsledku. Zdá se to být kacířská myšlenka, protože selský rozum říká: “Pokud jsme tentokrát nedostali, co jsme chtěli, musíme být příště mnohem více striktnější a definovat vše ještě detailněji”. To ale, jak jsme si řekli dříve, neřeší příčinu a situaci v konečném důsledku ještě zhorší.

Co by tedy mělo být napsáno v takovém kontraktu? Určitě popis postupu/procesu, jakým způsobem dodavatel společně se zákazníkem vytvoří nejlepší možný výsledek. Vložíme tam osvědčené postupy a praktiky, které empiricky fungují. Co to znamená? Krátce řečeno, kontrakt by měl obsahovat následující:

Postup/proces tvorby výsledného produktu/služby založený na učících se cyklech (iteracích) a jednotlivé fáze projektu

  • Příprava projektu – vize, byznys cíle, hlavní akceptační kritéria, vysokoúrovňové testy, které musí projít, aby řešení pomáhalo byznysu
  • Tvorba řešení – iterace a jejich akceptace
  • Doručení řešení – termíny a finální akceptace

Odpovědnosti dodavatele

  • Spolupracovat se zákazníkem na tvorbě požadavků, pomoci mu definovat je z pohledu uživatele, ne systému.
  • Před každou iterací se zavázat k tvorbě jejího obsahu a mít připravený funkční výsledek pro následnou demonstraci hodnoty na jejím konci.

Odpovědnosti zákazníka, kdy musí být přítomen nebo k dispozici a na jak dlouho

  • Pomoci připravit detaily k požadavkům před začátkem iterace
  • Být k dispozici k otázkám vývojářů během iterace
  • Účastnit se dema, být na něm schopen akceptovat/odmítnout předváděnou a dohodnutou hodnotu

Učící se cykly

  • Kdy a jak proběhnou společné retrospektivy, aby se předcházelo problémům a spolupráce se neustále zlepšovala
  • V případě, že iterace selže, nebo zákazník není spokojen s výstupem, je automaticky provedena zvláštní společná retrospektiva a jsou přijata opatření, aby se situace neopakovala

Důsledky porušení dohodnutého způsobu spolupráce

  • Zákazník se nedostaví na demo? Všechna funkcionalita je automaticky akceptována, každá další změna je řešena jako nový požadavek.
  • Objevily se chyby? Musí být opraveny dodavatelem v následující iteraci.

Obchodní model

  • Na základě čeho se počítá cena? (rezervovaná kapacita, cena za iteraci, za požadavek, za jeden StoryPoint, …)
  • Bonusy a pokuty

Jak je vidět, takový typ kontraktu je vždy unikátní, protože odráží konkrétní možnosti a omezení obou partnerů. Takže jeden vzor kontraktu určitě nebude sedět na všechny projekty. Ale jsou zde části, které se obvykle dají znovu použít. Tak jako tak, práce věnována takovému kontraktu se později mnohonásobně vrátí.

Nám se povedlo dostat několik takovýchto kontraktů do praxe s různými zákazníky naších klientů. A podle výsledků a zpětné vazby tento přístup opravdu funguje! Výsledky jsme již několikrát prezentovali na mezinárodních konferencích (Leanest 2012, 2013 konference ve Stockholmu a v Praze).

Pokud byste chtěli vědět více, ozvěte se nám. Rádi nasdílíme vše, co jsme se za posledních 10 let v této oblasti naučili.

Sledujte nás na