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íň.