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

 


Zuzana Šochová - The Great ScrumMaster:#ScrumMasterWayNaučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay nebo Agilní Metody Řízení Projektů.


 

7 thoughts on “Je Scrum jen pro male firmy?”

  1. Odkazu se na odstavec “Základní výhodou potom je, … v konečném důsledku úplně nahradit…”

    To vse prece plati obecne, to jeste nic nerika o scrumu: Business pozadavky jsou zaklad, AC – akceptacni kriteria jejich nutna formulace. Nejdrive je potreba vedet “CO” a “PROC”, jakekoli dalsi pokusy o FuncSpec jsou uz jen nasledne “JAK”.

    Projekt udelate klidne i bez FS, ale bez AC ho pak nejde odevzdat: Ne hladce.

  2. Rozebira se tu prechod velkych spolecnosti (na agilnost). Ale co naopak malinke projektiky/produktiky? Nez aby se jednou veci zabyval cely tym, bezne se setkavam s tim, ze je zadani jen jednopuchodove: Tady ho mas a delej.

    Sice neustale volam po reviews, aby se meli i ostatni moznost vyjadrit, aby developeri nebyli pouhymi busici, ale aby mohli prevzit zodpovednost…

    Ale dokud bude obchodnikum za zakaznika predavat/komunikovat zadani – zadavat programatorskou praci jen zakaznikova “IT neznala sekretarka, ktera dostala budget a ma to mit hodove”, veskery scrum mechanismus mi naopak prijde nedostatecne agilni:

    Aneb “za tyhle nase tanecky nam zakaznik nezaplati, za tyden uz to ma byt nasazene.” Anebo “navrhujes to hezky, ale to bych propalil cely budget, a nemeli bychom napsanou ani carku SW.” “S takovym pristupem nestihnem termin a zakaznik uz nam priste nic nezada.”

    Oponuji mi projektaci, obchodnici, product-owneri: “Chlape nezdrzuj, zakaznikovi jde hlavne o termin, zacatek kampane uz nelze zmenit.”

  3. Jasne, ze se maji urcit jednotliva AC, ty se zakaznikem zprioritizovat (tim urcit backlog) a pak udelat tu caru definujici aktualni scope, ale to je prave ta potiz, se kterou neustale zapasim: Pred realizaci musi byt “predprojektova faze”, kde se toto dohodne. Protoze dourcovavat si AC az kdyz uz firma podepsala zavazek na kompletni tojimperativ budget-scope-deadline, to je vzdycky na infarkt.

  4. Versina agilnich metod je common sence… ale presto, projekty se tak neridi …

    pisu si do todo ze mam napsat neco o vyse popsanem “zakaznickem” prostredi kde jde jen o deadline. 🙂

  5. Potiz/otazka, kterou v praxi pozoruji, pak nestoji, zda WaterFall, nebo Scrum (nebo ScrumFall), ale jestli se projekty vubec delaji jakkoli systematicky: Jakmile se totiz ma dodrzovat nejaky proces, jakykoli, musi se tento dodrzovat na vsech projektech, a ne ne jen na dvou ze tri.

    Zkatka v malych firmach to pak casto dopada stylem “quick & dirty”.

    A pokud navic jde o maly projekt, kde neni budget ani na samostatneho projektaka, tedy projektik musi byt rizen samotnym obchodakem, zkuste pak jim vysvetlovat, ze v IT oddeleni maji nejake procesy… Protlacit IT procesy i do hlav obchodaku, v tom vidim jadro pudla.

    Zkratka interni vzdelavani: A to neco stoji.

  6. @zuzi: Velmi trefné. Základní problém je armáda business analytiků (a já dodávám i architektů a dalších) kdo nenese žádnou přímou odpovědnost za úspěch nebo neúspěch projektu, avšak často mají velkou rozhodovací pravomoc. Hodně takových lidí se samozřejmě bude bránit přechodu na jakýkoliv systém, který jim zvýší odpovědnost a sníží pravomoci, ať je tento systém jakkoliv efektivnější.

    @oashi: Problém v malé firmě je, že SCRUM mohou těžko dělat jen developeři sami, SCRUM musí dělat celá firma. Tedy obchoďák musí dovnitř firmy hrát product ownera, k zákazníkovi, který nerozumí SCRUM, pak stále hraje obchoďáka. I když máš větší firmu, s projekťákem a nějakými těmi procesy typu WaterFall, tak problémy jsou stále stejné, jak popisuje zuzi.

  7. My pracujeme v týmu a neobejdeme se bez telekomunikace. Výhodou je rychlejší přenos informací.

Comments are closed.