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.

Poznámka: Článok bol pôvodne uverejnený na blogu autora a s jeho súhlasom aj na našom blogu.
Obrázok http://www.scrum-tips.com.