Tag: korporace

Jaké to je když vám vyjde kniha

První pocit? Překvapení. Přijde tlustý balíček se třemi autorskými výtisky. Jen tak, z ničeho nic. Jeeeee už je to tady! Ta je pěkná 🙂 a pak se vám začne honit hlavou, jak to celé bylo. Já v podstatě knihu psala v nejrůznějších koutech světa. Doma prostě nebyl čas se zastavit a přemýšlet. Proto tak ráda cestuju. Je to osvěžující. Kde to celé začalo? Já myslím, že v Indii. Seděli jsme u bazénu při konferenci a říkali si, že by bylo fajn napsat knihu. A vymysleli osnovu. A pak osnova pak dlouho ležela u ledu… A pak jsme začali pomalu psát. Kousek po kousku. Ale jak říkám doma mi to moc nešlo. Psát knihu je děsně práce. Trvá to nekonečně dlouho. Pořád to není hotové.

A tak jsem se rozhodla s tím pohnout a první rozumně velký kus jsem napsala v Indonésii. Bangka Island. Každý den po odpoledním ponoru, až do večeře. Jsou tam úžasné soft korály. Jedny z nejhezčích na světě. To je stejně můj sen, pracovat někde pod palmičkou. Pak bylo po dovolené. Pak další části vznikaly v letadlech a při čekání na letištích do Kalifornie – v San Fransicsu je úžasně, taky je tam moře. Pak cestou do Kieva, Rigy, Barcelony, Talinu, Kodaně, Krakova, Moskvy, New Yorku, v Las Vegas – nic jsem v casinech nevyhrála. Škoda, pár miliónů by se mi ke splnění snu sedět pod palmičku hodilo.

Další velký kus jsem napsala na Filipínách. Zase potápění. Odpolední dvě hodinky po ponorech na Moalboalu, pak v thajské restauraci na pláži v Boholu a finální části v Coronu, kde mají Japonské vraky plné podmořského života. Nádhera. Ale pořád to tak nějak nebylo hotové. Už mi to začínalo vadit, nemám ráda dlouho nekonečnou práci… a tak jsem poslední kusy dopsala ve Vietnamu v Saigonu nebo Ho Chi Minh City chcete-li. Hodina taxíkem do práce, hodina zpět do hotelu. Tam jsem ve finále četla i celou knihu ještě jednou v rámci finálního review. To si teprve uvědomíte, kolik jste toho napsali. To už bylo povzbudivé. Skoro hotovo. A jsem moc ráda, že jsem na knihu nebyla sama. Vždycky je daleko větší zábava s někým spolupracovat.

A pak nastal ten největší problém, kde sehnat vydavatele. Nakonec to šlo celkem snadno. A tak děkujeme nakladatelství Computer Press za vydání naší knihy “Agilní metody řízení projektů“ a doufáme, že se vám bude líbit. Co se dočtete?

„Snažili jsme se čtivou formou popsat všechna možná zákoutí a nástrahy, které vás při přechodu na Agilní metody mohou potkat. Kniha nepopisuje jen teorii, co to Agilní metody jsou, jak funguje Scrum Proces a Kanban, a jak by jednotlivé artefakty těchto procesů měly správně vypadat, ale primárně se snaží vysvětlit filozofii Agilního přístupu a zaměřit se na vysvětlení, proč jednotlivé metody fungují. Součástí textu jsou praktické příklady a doporučení co dělat a čeho se naopak vyvarovat.

Kniha se zabývá Agilními metodikami vývoje software v různých typech společností, od malých firem až po nadnárodní korporace. V první části knihy jsou popsány základní stavební prvky Agilního vývoje, od vlastní definice procesu až po ukázky z praxe. Čtenář se dozví všechny potřebné informace k adopci Agilních metodik, kulturní odlišnosti Agilních firem a další základní stavební kameny nutné pro úspěšnou adopci Agilních principů. Kniha dále obsahuje podrobný popis rolí, které se typicky vyskytují v Agilně řízených firmách. Vedle těchto popisů obsahuje kniha i “kuchařky”, resp. doporučené postupy adopce agilního řízení pro různé velikosti a typy firem.“

Dejte nám prosím vědět, jak se vám kniha líbila, co vás zaujalo, nebo co byste viděli příště raději jinak. Hezké čtení. Naší knihu Agilní metody řízení projektů můžete získat zde.

Může být velká korporace agilní?

A co to vlastně to agilní je… Když za agilní považujeme prostředí, kde je jeden tým, jeden Scrum Master a jeden Product Owner, asi se jiné odpovědi než že ne, nedobereme. Moje výhoda je, že na rozdíl od spousty mých českých kolegů jsem se Scrum a Agile neučila z knihy ani v malé firmě, ale ve velké nadnárodní korporaci v Americe, která má přes 50% světového trhu svých produktů, a k tomu operuje v takzvaném life critical segmentu, tedy prostředí významně regulovaném normami a předpisy, kde se za eventuální chybu platí až lidskými životy. A tak mi tyhle žabomyší spory o to co je a není agilní, ne nepodobné náboženským třenicím o universální pravdu, poněkud unikají…

Ono na tom modelu jeden tým, jeden Scrum Master a jeden Product Owner není nic špatného. Naopak. Je to takový základní stavební kámen, kterému musíme do detailu porozumět, než se pustíme do něčeho většího. Taková “mateřská školka”. Když ale zavádíme takovou změnu v korporaci, chce to schopnosti a zkušenosti z “vysoké školy”. Tedy o tři stupně víc. Když jste v garážovce, asi si s tímto modelem i vystačíte. Když ale jste součástí korporace, často narážíte na zcela drobné překážky. Nemáte pod kontrolou HR strategii. Vypsat novou pozici je náročná věc. Nemáte na ní headcount. Musíte vygenerovat mračna směrnic, a hlavně vysvětlit HR podstatu změny, kterou nasazujete. Změnit styl ohodnocování je většinou zcela mimo vaši kontrolu. Často nemáte ani možnost vyhodit některé nepřizpůsobivé jedince, tzv. trafikanty, co si za dlouhá léta zvykli nic nedělat a každé změně se zuby nehty brání. Obvykle nemáte pod kontrolou celou organizaci, a ostatní její departmenty často vaše nadšení nesdílí, ba právě naopak. Chrání si status quo. Každá změna pro ně znamená potenciální riziko, nebo alespoň více práce. A korporace jsou plné přepracovaných lidí, co kdysi možná měli ideály a chtěli změnit svět, ale časem se unavili, a spokojili se s tím, že chodí z meetingu na meeting a že to, co dělají, v rámci možností funguje. No, a v neposlední řadě je tu procesní mašinérie plná metodik, kterými se stejně nikdo neřídí, ale chcete-li změnu prosadit, musíte je změnit nebo rozšířit. A někde tady se rodí přesvědčení, že korporace agilní stejně nikdy nebudou. Budou, ale stojí to výrazně více úsilí než v garážovce. Asi tak jako projít mateřskou školou a úspěšně dokončit vysokou.

Stačí se podívat kolem sebe – tedy do světa – a agilních korporací najdete spousty. Dříve byly také hierarchicky řízené, svázané mašinérií nesmyslných nařízení, které samy neznaly a nedodržovaly. Na lidi se dívaly jako na zdroje a iniciativa byla vnímána jako špatná. Upřednostňovali samostatnou práci jednotlivců, které micromanagovali do posledního detailu. Alokovali lidi na různé projekty na měsíce dopředu a na hodinu přesně. Pak se ale něco změnilo a firma, aby přežila, musela se změnit. A agile je jednou z cest, jak přežít v dnešním hekticky se měnícím světě. Jak se přizpůsobit. Jak být dostatečně flexibilní.

Takže až zjistíte, že ten základní koncept sice chápete, ale že vůbec nevíte jak jej škálovat na více týmů nebo na celou organizaci, nevzdávejte to. Lidí, co mají s transformací takových organizací zkušenosti je ve světě dost, a soudě podle mě, často je taková práce i víc baví. Je to větší challenge, je to náročnější, je v tom větší riziko. Ale když se to povede, přináší to i větší uspokojení a výraznější výsledek. Divizi, ve které jsem poprvé byla součástí takové velké transformace, agile umožnil provést výrazný upgrade produktů a technologie, a v dlouhodobém horizontu zvýšil efektivitu více než dvojnásobně. O spokojenosti zaměstnanců a jejich nasazení ani nemluvě. U vás to bude jiné. Ale určitě bude výsledek stát za vynaloženou energii. A škarohlídům, co říkají, že korporace nikdy agilní nebude, nevěřte. Obvykle zjistíte, že vlastně v žádné větší firmě nikdy nepracovali, a tedy si ji neumí ani představit. Natož mít představu, jak ji transformovat.

Jak si vyzkoušet Scrum v korporaci která není agilní

Zavádět agilní metody ve velké korporaci je těžší. Přinejmenším musíte pro agilní přístup nadchnout větší množství lidí, což dá více práce. V podstatě máte dvě možnosti. Buď svoláte velký meeting a na něm oznámíte, že od teď je vaše firma agilní a vše tlačíte silou, nebo budete agilní metody stavět od jednotlivých týmů a necháte lidi, aby si sami vybrali, jakou metodikou projekty chtějí řídit. Ze zkušenosti se dá říct, že fungují oba přístupy, což ale neříká, že oba budou fungovat pro každou firmu. Nakonec stejně časem zvolíte jistý mix obou krajních variant. Příkaz a rychlou změnu celé organizace na agilní si asi můžete dovolit, jen když jste si sami jisti výrazným přínosem takové změny a také když víte jak. Většina firmem si ale přechod na agilní organizaci moc představit neumí, takže začíná spíše opatrně.

Asi ideální je zlatý střed. Vybrat produkt, který bychom zkusili řídit agilně, najít vhodného Product Ownera a Scrum Mastera, vyčlenit ze standardní organizace vývojáře, analytiky a testery které plně alokujeme do pilotního Scrum týmu. Vyplatí se vysvětlit jim v 1-2 denním workshopu jak fungují agilní metody, na čem stojí, že je to spíše filosofie a změna myšlení než striktní proces. Aby to nebyla jen teorie, ale věděli i proč jednotlivé praktiky děláme. Když se tým již od počátku zapojí do vytváření Scrum procesu, přijde si sám na to jak proces adaptovat na své podmínky.

Když je i tohle pro vás nepředstavitelné, dosáhli jste správné úrovně klasického korporátu. Je zajímavé, že i drobná agilní změna zanesená do vašeho zaběhnutého systému může přinést ohromné výsledky. Většině týmů schází napojení na business, a protože pro ně není ze začátku snadné v korporaci udělat stabilní Scrum tým se vším všudy, začne standupy. Na začátek tam chodí jen členové IT týmu. I to je přínosné. Když se tým zaběhne, začne jim víc a víc vadit, že nemají přístup k nikomu za business a že zástupci businessu se standupů neúčastní. Tak je pozvou a oni po větším či menším protestování že na to nemají čas, začnou chodit. Obvykle je ale standup rozvleklý a technicky orientovaný, takže to naše zástupce businessu moc nebaví a brblají, že je to pro ně ztráta času. Z tohoto stavu obvykle vedou dvě změny. Vizualizovat lépe stav práce na přehledné tabuli a připomenout že standup je hlavně o commitmentu, tedy o tom co se dokončilo. A abychom mohli mít commitment kterému business rozumí, je dobře dělit práci na nějaké funkční celky které za nějaké fixní období – tedy Sprint dokončíme. Co se udělá, by se měl domluvit tým s businessem a ne si o tom rozhodovat sám jako doposud.

Je zajímavé, že i takováhle agilní ochutnávka stačí k tomu, aby tým začal fungovat výrazně lépe a vzbudilo to v jeho členech chuť zkusit další věci. Sami se ptají jak že se to ve Scrumu plánuje, jak se ohodnocuje, co je to UserStory, začnou dělat retrospektivu, hledat rovnováhu mezi tradičními projektovými funkcemi a nově definovaným rolemi a zkoušejí si, jak by Scrum v jejich prostředí mohl vypadat. Po nějakém čase je v organizaci dostatečně positivní atmosféra pro postavení plného pilotního Scrum týmu. A to je následně začátek přerodu v agilní organizaci.

Je Scrum jen pro male firmy?

Jak se poslední dobou pohybuji ve větších firmách, setkávám se často s názorem, že Scrum je jen pro malé firmy. Tak se pojďme podívat, co se tím v reálu myslí. V korporátech se často objevuje pojem “ideální Scrum“, čímž je míněno prostředí kde je jeden tým, jeden Scrum Master, jeden Product Owner a žádné závislosti. Všichni plně alokovaní, pracují na něčem, co ideálně vytváříme od nuly a co s ničím dalším nesouvisí. Takové jednoduché. A druhým dechem dodávají, že to my v naší organizaci nemáme, my máme ty velké integrační projekty a na nás se agilní metody nehodí. No ostatně každý důvod se hodí, když se chceme bránit změně. Začínala jsem se učit Scrum ve velké korporaci, která měla několik divizí, IT v řádu jednotek tisíců, outsourcing/offshoring a distribuované týmy. A viděla, co se stalo po transformaci na agile a Scrum. Výrazný nárůst efektivity, kvality, zastupitelnosti. A to vše ve velice komplexním prostředí mnoha souvisejících produktů a specifických technologií napojených na vlastní HW. Nebyly to žádné malé internetové projektíky. Proto tomuto argumentu českých firem moc nerozumím.

Ale pojďme se podívat, proč by v prostředí velké korporace mohl být Scrum a agilní metody prospěšné. Takovéhle velké firmy často dokonvergují k zajímavé organizační struktuře. Mají oddělené IT a business. Moc spolu nemluví, moc se nemají rádi. Business dává velice volně definované požadavky – slovy IT neví, co chce – a to IT má na jejich řešení málo kapacit a nestíhá. Všechno je pozdě. A ještě často dodá něco jiného. Takové firmy se snaží tuto nefunkčnost různě házet jeden na druhého. Ti co se na to dokáží dívat s nadhledem, často říkají “Máme velký problém v IT, který ale neleží v IT.“

Jak je business hodně daleko a nemá obvykle příliš motivaci se do projektů zapojovat, tak se týmy obklopí armádou business analytiků, kteří se snaží požadavky businessu dodefinovat a interpretovat IT světu tak, aby pro ně byly srozumitelné. A protože oni za úspěšnost projektu nenesou žádnou zodpovědnost, tak požadavky nijak neořezávají, ba právě naopak. Oni jen plní přání businessu. A rozmýšlí, jak by se taková věc mohla chovat. A tak IT roste a roste a překvapivě pořád nestíhá tu spoustu požadavků businessu zpracovávat. A kdyby mohlo, sedí ve všech budovách a kancelářích po celém městě.

Agilní metody a Scrum proces se snaží organizovat týmy po produktech, ne po technologiích. Základní výhodou potom je, že to co se dělá, není rozhodováno IT nebo analytiky, ale businessem který u každé funkcionality zvažuje, jestli se jim vyplatí do ní investovat energii týmu/peníze. U každé funkcionality se zamyslí nad tím jaký má očekávaný přínos a jakou “pokutu“ bychom ev. platili za její absenci a jestli nám to celé stojí za to. Na to se hodí koncept User Stories (určitě si vzpomenete na zkratku INVEST která je v tomto kontextu docela výstižná). Tohle je tedy kromě lepší komunikace mezi IT a businessem, vyšší motivací a vyšší zastupitelností asi hlavním důvodem pro vyzkoušení agilního přístupu. Říká se, že firmy, které takto řídí svojí funkcionalitu, mohou ušetřit až 80% effortu. Určitě to neplatí plošně, ale podívejte se kolem sebe. Kolik funkcionality se opravdu použije a vyplatí? Kolik toho všeho na čem pracujete, by šlo zjednodušit, kdybychom rozuměli tomu, proč to vůbec děláme. A co by šlo v konečném důsledku úplně nahradit…

Řekněme tedy, že jste mi uvěřili, že by to mohlo mít smysl. Co dál? Jak zformovat stabilní tým v prostředí stovky integrovaných systémů, kde se IT skládá z mnoha isolovaných úzkých specialistů a systémy tvoří chobotnici vzájemně provázaných funkcionalit s množstvím legacy kódu, kterému již nikdo nerozumí? Kupodivu to jde snáze než byste si mysleli. V reálu obvykle dojdete k tomu, že tím, že se začnete na systémy dívat z pohledu businessu, uděláte v podstatě vertikální strukturu proti současné horizontální. Je to jiný pohled. Některé produkty spojíte, jiné rozdělíte, ale ve finále se vždy přijde na to, že systém jde relativně snadno rozřezat na funkční logické produkty, kde je možné stanovit Product Ownera, který má zodpovědnost za návratnost a úspěšnost produktu. Není na to sám, pomáhají mu ostatní kolegové z businessu, business analytici a IT architekti jako doposud, ale je tu někdo, kdo je stabilně zodpovědný za produktovou linii. Dělá jen to co má smysl. Co se vyplatí v dlouhodobém horizontu. To je první část úkolu. Druhá část sestává z definování stabilních Scrum týmů. I to není tak složité, jak by se mohlo zdát. Tým musím obsahovat znalosti klíčových technologií, systémů a architektury. Ale když to zkusíte, zjistíte, že vaše současná chobotnice složená z nenahraditelných a nezastupitelných částeček jde obvykle rozdělit na týmy o cca 7-10 lidech, které jsou schopny většinu práce na nově definovaném produktu udělat sami. Co zbyde, si buď objednají zvenku, nebo se naučí. Větší produkty budou implementovat skupiny 1-4 stabilních týmů, menší projekty se dají sdružit pod jednoho Product Ownera, který má jeden takový tým. Zní to jako utopie, ale zkuste to. Zatím jsem nepotkala firmu, ve které by to nešlo.

Co je na tom nejtěžší? Uvěřit, že i v takto složité a komplexní firmě je to možné. Uvěřit, že by nám taková změna mohla výrazně pomoct. Začít budovat kulturu zodpovědnosti, posílit důvěru, a podpořit transparentní komunikaci v rámci celého systému. Zní to jako fráze, ale funguje to. Je to těžká a zdlouhavé práce. Příjemné je, že jakmile začnete, vaše snaha velice rychle přinese své ovoce a lidem se po prvotní vlně odporu nový proces zalíbí. V ten moment začne být vaše snaha o změnu nakažlivá a vy máte o kousek práce míň.