Za všechno může Scrum!!!

Konference, příspěvky, meetupy i komentáře na sociálních sítích více a více zmiňují, jak je Scrum příčinou mnoha problémů ve vývoji SW produktů, jak může za to a ono, jak je špatný a vlastně nefunguje a je třeba dělat něco jiné. Asi je to prostě trend a je třeba se dnes vůči Scrumu vymezit, protože všichni už dnes podle Scrumu jedou (hahaha :)). Scrum je holt obětí své jednoduchosti, kterou hodně lidí zaměňuje za úplnost. Tak už jsem se neudržel a opět zkusím pár těchto mýtů vyvrátit a nyní se postavit na stranu obstřelovaného Scrumu.

O mýtech a nepochopení v Agile, i o možných rizicích Scrumu jsem psal před 7mi lety a zrovna první článek na tomto blogu 🙂 takže si můžete udělat obrázek, co se od té doby změnilo v agilní komunitě i u mě. No a co běží v hejtovacím éteru aktuálně? Za co všechno může Scrum v dnešní době? Pojďme si to shrnout:

  • „Scrum po nás chce zbytečné detailní plánování a analýzu/grooming a to nám žere celkově moc času, který jsme mohli věnovat vývoji.“
  • „Naše Scrum ceremonie trvají moc dlouho a jsou neproduktivní, je to zbytečná byrokracie.“
  • „Lidé se na retrospektivě stejně nezapojují a navíc nám ani retrospektiva nijak nepomáhá. Prostě ji nepotřebujeme.“
  • „Zákazník se dema stejně neúčastnil, tak jsme je zrušili, byl to jen další zbytečný meeting.“
  • „Máme nevhodně obsazené role nevhodnými lidmi, kteří mají své talenty jinde.“
  • „Scrum nutí dělat lidi věci, v kterých nejsou silní a brání jim dělat věci, kde dobří jsou.“
  • … doplňte si svůj oblíbený hejt…

Ano, toto vše je prý chyba a vina Scrumu…

Ono je jednoduché vinit bicykl z toho, že nemá motor a korbu a blbě se na něm vozí cement a trubky, ale on je navržený na něco jiné a my jsme navíc ti, kdo se ho snaží použít na stavbě, i když na to nění primárně dělaný.

Pojďme si tedy říct, co to vlastně Scrum je a kde mohou být příčiny výše zmíněných  problémů a nepravd.

Ne vše řešící proces, ale procesní framework bez inženýrských praktik!

Scrum je definovaný jako (1) Agilní framework pro doručování komplexních nových a inovativních projektů. A klíčová věc je jeho (2) opěvovaná jednoduchost, díky které je tak efektivní a dobrý pro začátek, ale díky které je také tak silně a často nepochopený. Scrum je tedy primárně framework pro řízení projektů a rychlé doručování hodnoty v méně známých nových doménách a inovativnějších projektech.

Ad bod (1): Zdůrazním zde pojmy „méně známá doména“ a „nové produkty“, kde se potřeby a požadavky docela rychle mění, tak jak poznáváme doménu a potřeby uživatelů a rychleji se mění (nebo se teprve ustálují) také samotné potřeby a zvyky uživatelů. Zde má Scrum největší výhodu díky schopnosti rychlé reakce na tyto změny.

Je ale nutné nahlas také říct, že v konzervativních, jen pomalu se měnících doménách a také v maintenance, kde je produkt i doména známá a stabilní a tým malý a dlouho spolu, může efektivněji fungovat vodopád a dokonce i ad hoc přístup. Nemusíte navíc nikoho ze zkušených 50+ IT borců na tomto produktu přemlouvat na hry a blbosti s lístečky při plánování a ušetřenou nátlakovou energii dát právě do dynamičtějších produktů, které ji ocení víc. Pomoci i v těchto typech projektů mohou různé praktiky ze Scrumu, například retrospektiva může přispět k vyšší efektivitě práce a zlepšit kvalitu a dostat do projektu více tvořivých činností.

Ad bod (2): Scrum je minimalistický framework, to znamená, že musíte použít všechno, co říká. Tudíž „děláme Scrum, ale nemáme to či ono“ je tedy již z definice nesmysl a blábol, protože když nemáte implementovaný fungující základní set, pak NEMÁTE Scrum, ale jeho pouhou praktiku (což není špatně). Scrum má i nepovinnou část jako třeba Impediment backlog a tam už si vybrat můžete, zda tyto praktiky implementovat chcete či ne. Pokud ale neděláte vše Scrumem předepsané, nemůžete o Scrum u vás hovořit. Teda můžete říkat cokoliv, ale pak lžete 🙂

No a aby mohl být Scrum minimalistický, musel něco vypustit. A co vypustil? Přesně to, jak software vlastně dělat! Jinými slovy vypustil téměř všechny inženýrské praktiky, protože říká, že to si do frameworku doplní ZKUŠENÍ vývojáři sami (prostě vědí, co a jak má kdo při vývoji dělat). Jedná se namátkou o následující:

  • jak analyzovat potřeby trhu (empatie, discovery)?
  • kdo a jak má předat/popsat tyto potřeby vývojářům a v jaké formě (požadavky, user stories, use cases, prototypy)?
  • jak analyzovat doménu a požadavky (analýza) a promítnout to vše na technologické řešení (návrh)?
  • jakou vhodnou architekturu vybrat, aby nejlépe odpovídala těmto potřebám?
  • kdy a jak začít vytvářet test ideas a test cases a v jaké formě?
  • co vše má smysl testovat? jaké typy testů vytvářet? co automatizovat?

Takových pár nepodstatných drobností, co musí vývojový tým znát, dělat a snad i doplnit do procesu vývoje fungujícího softwarového řešení, co říkáte? Přesně proto, že Scrum o tomto nic neříká, může zůstat tak pekelně jednoduchý. A přesně toto je jedna z hlavních příčin NEPOCHOPENÍ, která se kolem Scrumu rojí a která jsem zmínil výše.

Scrum vizualizuje to, co vám ve vývoji a spolupráci s jinými týmy/odděleními nefunguje. Neefektivní meetingy, nedoručený produkt či vysoká chybovost je tedy způsobena vaší kulturou a zvyky. Scrum je pouze odhalil a upozorňuje na ně.

Scrum vs. lidé a jejich silné stránky: A poslední je ona lidská stránka, typologie lidí vs. Scrum. Scrum že něčemu brání a nutí lidi dělat něco, co nechtějí? Ale kdeže! Vždyť to má být self-managed tým, tak jaképak nucení 😉 A že jsou meetingy dlouhé? Není problém spíše:

  • špatná facilitace a vedení meetingu,
  • neschopnost shody mezi lidmi,
  • trvání na konsensu za každou cenu i tam kde není třeba,
  • falešná harmonie nebo pouze destruktivní konflikty (ty konstruktivní chybí),
  • nedostatek nutných informací k rozhodnutí,
  • nulová příprava lidí na schůzky apod?

Bohudík, ani zde není Scrum na vině. Když máte v roli Scrum Mastera člověka, pro kterého jsou blízká a důležitá pravidla a jejich dodržování, tak místo podpory týmu, starání se, komunikace s jinými týmy a zlepšování, trvá spíše na vynucování a dodržování těchto pravidel, což je naprosto logické. Toto je ale jen důsledek vaší práce s lidmi a výběru do týmů, tudíž (ne)managementu a (ne)HR, kdy nemáte na daném místě vhodného kandidáta s vhodným profilem. Scrum zase pouze tuto skutečnost odhalil.

  • Víte vůbec jaké silné stránky mají vaši lidé?
  • Vědí to oni sami?
  • Pracujete s nimi? Jak?
  • Jak inzerujete či obsazujete nové pozice?
  • Máte napsaný inzerát tak, aby přitahoval správný typ lidí?
  • Máte vůbec interní shodu, koho na danou pozici chcete?
  • Není chyba již zde?
  • A vysvětlujete nevhodným uchazečům, proč pro ně toto místo není (třeba i oni nechápou danou roli)?

Takže, prosím, opět neházet vaše neduhy v kultuře a managementu firmy na Scrum, on je pouze zviditelnil.

Je Scrum agilní jedináček?

Rozhodně není! Jeden minimalistický proces nemůže naplnit zcela rozličné potřeby malých, středních, komplexních projektů s různě zkušenými a typologicky odlišnými lidmi pro různé trhy, s různými specifiky. Mnoho zkušených týmů se stejně časem pohne směrem ke Continuous Delivery a vydává několikrát denně, další ke Kanbanu s prvky Scrumu a XP, protože mají přibližně stejně velké kusy práce, které neustále plynou, další… Mnoho také zůstane se svým Scrum BUT a i to jim už může pomoci zásadně zlepšit schopnost doručovat a také rozhýbat tým. Jen to opravdu není Scrum 😉

Pokud vás zajímá, kam se jako tým můžete posunout, pokud už máte Scrum zvládnutý a výše popsané neřešíte, pak pro vás může být inspirací například Disciplined Agile Delivery framework Scotta Amblera (více také v rozhovoru s ním), kanban, extrémní programování, nebo OpenUP.

Scrum je tedy vlastně obětí své jednoduchosti a úspěchu. Když něco ve Scrum týmech nefunguje, hodíme to na něj a vrátíme se k našim starým dobrým praktikám, které nám (ne)fungovaly 🙂 Pamatujte, paměť je selektivní a tvořivá, vytlačí to nepěkné a vždy vytvoří takový obrázek, který je pro daného člověka příjemný.

Snad vám tento pohled pomohl vyjasnit některé nejasnosti kolem Scrumu a nakopnul vás směrem k řešení vnímaných problémů jinou cestou než opuštěním Scrumu.

Příspěvek byl publikován v rubrice Články se štítky , , , . Můžete si uložit jeho odkaz mezi své oblíbené záložky.

6 komentářů u Za všechno může Scrum!!!

  1. Jaromir Skrivan napsal:

    Ahoj Jarku, nevypublikoval bys tento clanek i v anglictine? 🙂
    Jinak clanek naprosto super!
    Diky moc, Jeremy

  2. Jarek napsal:

    Díky. Začal sem to psát česky a už se mi to v půlce nechtělo překládat 🙂 ale asi se na to vrhnu no… 😉

  3. Miroslav Zebrak napsal:

    Ahoj Jarku, moje osobní zkušenost je, že Scrum je možné zabít dvojím způsobem, špatným Scrum masterem a špatným managementem. V obou případech tedy selhávají lidé, nikoli nefunkční framework. Ale pravda je, že pro některé týmy je prostě lépe vyhovující waterfall nebo kanban. Prostě se to musí vyzkoušet.
    Mirek

  4. Jarek napsal:

    Jj Mirku, přesně to říká článek, že to není vina frameworku, ale lidí, jejich postoje, kultury a managementu 😉 takže se shodneme.

  5. Martina Bártů napsal:

    Co já mám zkušenost, tak problém bývá i v tom, že někdo „shora“ přeorganizuje týmy, v lepším případě je pošle na školení o základech scrumu (které ovšem neříkají, jak ho krok po kroku aplikovat do prostředí konkrétní firmy), předepíše jim ceremonie a ještě je u toho kontroluje, jestli ten scrum opravdu dělají. Týmům přibydou meetingy, které předtím neměly, aniž by jim kdo vysvětlil, proč to všechno dělají a jak to mají dělat, aby to bylo efektivní, business si jede „postaru“, protože se ho přece transformace netýká a bojí se, že ztratí nad projekty kontrolu. A hlavně nenechají své tzv. samoorganizující se „scrum“ týmy, aby si sami přicházeli na to, jak se jim nejlépe pracuje. Aby vypustili to, co jim zatím nedává smysl atd. Výsledkem je, že takové týmy stále jen poslouchají příkazy a k agilnímu přístupu mají daleko. Ale už 3 roky jedou ve „scrumu“ 🙂 A co teď s tím, když do takového prostředí přijde nový SM zvenku?

  6. Jarek napsal:

    Souhlas Martino, i toto se docela často děje… Já zde určitě nepopsal všechny příčiny selhání Scrum implementací. Jen jsem si vzal na mušku pár z nich, které se poslední dobou v éteru vyrojily. Tento tvůj komentář si rozhodně zaslouží další celý blog post 😉 Nechceš ho napsat?

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *