Blog | O konci Scrumu

O konci Scrumu

Ještě jsem nečetl nikdy opravdu fundovanou kritiku Scrumu, kterou by člověk znající Scrum do posledního puntíku a který ho viděl v desítkách firem, nerozsekal na prach.

A já vám dnes ten Scrum rozbiju.

Prozačátek musím říct, že Scrum je super. Pomohl úplně každé firmě, kterou jsem kdy viděl a v které jsem Scrum zaváděl.

Obecně platí, že Scrum zlepší tyto věci:

  • mnohem lepší naplánovatelnost práce
  • u spousty firem i vyšší flexibilita
  • lepší disciplína – tím, že Scrum říká, že na konci sprintu má být něco hotovo, lidi to kolikrát vybičuje a donutí dodržet to, co si předsevzali a co by jinak nedokázali
  • větší přehled – jeden z nečekaných a i mnou samotným ne úplně probádaným aspektem Scrumu je to, že je mnohem lepší přehled o tom, kolik se toho stíhá, kde jsou problémy, kdo dělá nekvalitně a komu to trvá, kdo se zasekává

Ještě jednou zopakuju, že Scrum pomohl každé firmě, v které jsem ho zavedl. Bez jediné výjimky za těch snad 5 let!

Ale není jen Scrum.

i eXtreme Programming má své aspekty a výhody. Má věci, které řeší líp než Scrum, má věci, které řeší hůř. Víc vybičuje vývojáře k tomu, aby odevzdával naprosto perfektní výsledek. Software Craftmanům musí některé aspekty XP připadat velmi atraktivní. Na druhou stranu má XP proti Scrumu blbě vyřešené alokace, ultrablbě vyřešené odhadování, nepropracovanou prioritizaci, nerozpadají úkoly na nejmenší možné User Stories, ale vzdávají to a sekají na engineering tasks, takže vzdávají denní akceptaci zákazníkem.

Každá metodika je zachycením stavu, který někdy někomu dobře fungoval v podmínkách a znalostech, jaké byly v té době.

Scrum i XP i cokoliv dalšího.

A každá firma, která nějakou metodiku nasadí, si ji nutně upraví a upravuje ji průběžně. Nasazení Scrumu není stav, kterého je dosaženo a hotovo, ale je to bod, kterým se projde na cestě k metodice, která firmě bude vyhovovat nejvíc.

Jenže já se začal zabývat tím bodem, kterým se má projít. Ano, je pravda, že Scrum je dobrý bod, je to bod vepředu a pomohl každému. Ale já se začal dostávat do stavu, kdy už jsem ve firmách viděl úpravy, které firmy udělají tak jako tak. Viděl jsem směr, kterým se vydají tak jako tak. A pochopil jsem, že umím vytvořit pro tu firmu metodiku na míru, která bude mnohem blíž optimu. Že dokážu tu firmu posunout o dva roky dopředu a rovnou u nich nasadit něco, kam by se dostali o 50 retrospektiv dál. Nebo by se tam lidi nedostali nikdy. Jednoduše proto, že občas začnou lidi z toho Scrumu místo hledání globálního extrému optimalizovat své lokální maximum.

Nejen, že dnes Scrum už není vrcholem toho, co je nejlepší v agile, má i problémy v praktickém nasazení.

Za vrchol agility je dnes považováno Spotify. A jejich metodika. Vnitrofiremní komuniky, volné prolínání lidí, plně autonomní týmy, koučing, cloud témat místo kariérní cesty.

Ano, Spotify je mnohem dál než většina IT firem a týmů. Ale Spotify se dostalo ke svému extrému. Ten je mnohem dál, než mají jiné firmy. Ale pořád si myslím, že oni cílí na něco a jen slepě zkopírovat Spotify, by byla chyba. Nicméně neinspirovat se u nich by byla chyba taky.

Pak jsou tu problémy Scrumu bez ohledu na Spotify.

Role Scrumu

Ve Scrumu je Product Owner, Scrum Master, člen týmu a stakeholder. Hotovo.

Jenže to je extrémní zjednodušení.

V jedné z implementací Scrumu bylo prostředí tak složité, že role Product Ownera byla rozseknuta do mnoha podrolí. Board, který prioritizoval, vlastníci, kteří chodili s iniciativami, business a sys analytici, kteří zadávali User Stories, business testeři, kteří dělali akceptaci. Role Scrum Mastera byla rozdělena taky. Existovali tradiční Scrum Masteři, ale k nim byli ještě Release manageři, kteří zodpovídali za nasazení. Produkt se pohyboval v silně heterogenní infrastruktuře se spoustou dat (na která navíc byla spousta regulací a legislativních omezení) na hromadě (2000?) serverů.

Přijít se Scrumem, říct, tohle tady vyškolíme a příští týden jedete, to prostě nemůže fungovat.

Fixní iterace

Fixní iterace mají ve Scrumu velmi dobrý důvod.

Bez neměnných iterací s fixní délkou by Scrum nedosáhl takové úrovně spolehlivosti. Ale stává se, že nejvyšší prioritou je něco jiného. Třeba spolehlivost (tam míří eXtreme Programming). Nebo dobré vztahy se zákazníkem a jeho vnitřní fungování. Nebo nějaké jiné aspekty (někdy napíšu víc o tom, jak se krásně neslučují fixní iterace a vývoj hardware).

Existují alternativy. Dělat iterace dlouhé podle dohody se zákazníkem, nebo jet po úkolech, které patří do jednoho milníku a až to bude, tam to bude (tam zas musím říct, že ten Scrum občas zafunguje tak, že dovede lidi k výkonu, kterého by jinak nebyli schopni). Nebo fungovat formou toku úkolů. Nebo mezi formami přepínat podle nějaké podmínky. Všechno tohle jsem zažil jako nejlepší řešení.

Neumí mikrotýmy

Scrum sází na odhadnutelnost. Pro odhadnutelnost je nejlepší takový tým, který nemění své složení. Ostatně opačný extrém, kdy dáte dokupy jen partu lidí, to není žádný tým. To je jen halda jednotlivců, kterým se přihodilo pracovat pohromadě. Mít tým znamená být zvyklý a znát klady i zápory každého člověka v týmu.

A tak Scrum došel ke svému lokálnímu extrému. A v mnoha případech i globálnímu. Ale v některých firmách se lidi znají i mimo týmy, mají pracovní zkušenosti a znají ty klady a zápory.

A tam je hloupé omezovat se v tom, abych se s někým nespojil jen pro vyřešení nějakého úkolu, udělal ho a ten maličký tým (mikrotým) zase rozpustil. Scrum tohle neumí a nikdy umět nebude. Není to v jeho DNA. Mikrotýmy totiž hážou vidle do účetnictví, které si každý tým ve Scrumu dělá. Mikrotýmy rozmazávají velocity a to je pro Scrum prostě špatně.

Neumí maintenance

Scrum je vývojová metodika. Není pro maintenance. Údržba se obchází tak, že se vymezí určité množství času (třeba 20 %) a tam se jede jinou metodikou.

Pokud se ten objem maintenance moc nemění, Scrum funguje dobře. Pokud dochází odchýlkám – které jsou běžné např. u firem s velkými releasy (většinou antipattern, někdy ne) nebo u sezónních businessů (třeba e-shopy), tak Scrum naráží a neumí na to zareagovat. Matematika s výpočtem velocity přestane vycházet a to těžce.

Next Step

K tomu, abych firmám ušetřil roky hledání a statisíce utracené za retrospektivy, miliony ztracené tím, že týmy nemají takovou efektivitu jsem se dostal postupně a přirozeně. Tím, že jsem hledal to nejlepší.

Nikdy jsem nepotřeboval být nejlepším lektorem Scrumu (a přesto věřím, že jím jsem), ani nejlepším lektorem GTD (a taky věřím, že jím jsem). Chci být největším odborníkem na organizaci práce a na tom pracuju.

S tím, že mám za sebou víc jak 100 firem, u kterých jsem se nespokojil s šablonou, ale vyptával se, upravoval, hledal, mýlil se a učil, nacházel, přícházím s tím, že dělám metodiky na míru. Metodiky, kde si kladu otázku: „Jaká je nejlepší metodika pro lidi, kteří umí to, co umíte vy, pro zákazníky, kteří chtějí to, co vaši zákazníci a pro projekty a technologie, kterými žijete.“

Pojďme si povídat. O tom, jak pracovat. Jak udělat víc. Jak způsobit, že zákazníci, kolegové i majitelé budou spokojenější.

Napište na jiri@flexiana.com a pojďme si povídat o tom, jak vyváznout z lokálního extrému. Za to, abysme si začali povídat, nic nedáte a můžete jen získat.

Předejte zkušenosti i dalším a sdílejte tento článek!

Předchozí článek


Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích