Scrum vám zblbnul mozky

Scrum je braný jako metoda jak prediktabilně dlouhodobě dodávat value (pojďme o tom mít diskuzi, shape up ehm ehm), ale také je to skvělý způsob jak lidi přetvořit v nemyslící roboty. Hlavně díky tomu, jak je aplikován a jakým se stal dogma.

Disclaimer: na trhu jsou firmy, které to chápou a hledají co nejvhodnější způsob práce vzhledem k situaci, ve které se firma nebo cíl nachází. Jestli v takové makáš, buď za to happy :)

Scrum je fajn kamarád když existují jasně definované úkoly. Jednou za 2 týdny si sednete, nagroomujete je, naplánujete, pak furt děláte status updaty a za 2 týdny možná hitnete sprint goal. Je to taková delivery popculture.

Tenhle model je zakořeněný skutečně hodně a produkťákům dělá z práce občas naprosté peklo, ale o tom jindy. Projekťáci to ale milujou, protože pocit kontroly > outcome.

Problém se Scrumem nastane když je potřeba vrhnout se do neprobádaného prostředí. U startupů nebo scaleupů se objevují příležitosti, po kterých chce firma adhoc skočit, protože z nich může potenciálně velmi těžit.

Projekt s neurčitým scopem. Marketingový event, pro který by bylo super mít nějakou funkcionalitu. Sales může dotáhnout ultimátního klienta, který vám odemkne dveře.

Ať už je cílem PRko nebo skutečná hodnota pro uživatele, dostane to prioritu a rozjede se lavina s jasným deadlinem. Tým se snaží utíkat tak rychle jak to jen jde. Groomingy nemají připravené věci, protože produkťáci se snaží psát zadání za chodu tak jak se jim daří zjišťovat kontext. “Ale tak to přece nebylo na groomingu, to nemůžem dělat“ zaznívá. Do sprintu se hrnou rozdělané úkoly, věci se musí předělávat, vývojáři jsou naštvaní, že to “přece má mít produkťák definované!”

Scrum se rozpadá, hází vám klacky pod nohy a vy v něm přesto dál pokračujete. Planningy vypadají tak, že se jen posouvá sprint goal. Všichni jsou z toho nervózní, naštvaní, unavení. Produkťáci i vývojáři.

Máte vygumované mozky Scrumem. Procesem, který byl do firmy nasazený protože tak se to přece všude dělá. Procesem, který naprosto nemusí být vhodný ke splnění cíle.

Týmy zapomínají na to, že jejich cílem není dodávat tasky, ale řešení. A to nejvhodnější cestou dané situaci. Občas je to o tom že musí ošulit kód. Jindy vizuál. Jindy musí produkťák sesekat scope na minimum. A jindy musí tým změnit taktiku celého vývoje a přemýšlení.

Už se nepluje po klidné řece, teď vás čekají peřeje a jezy. Najednou je z té řeky s výhledem zatáčkovitá horská říčka plná nástrah. Nevíte co je za zatáčkou. A vy (celé RnD týmy) do toho musíte umět přepnout. Musíte být skutečně agilní a kreativní v řešení problémů.

Proto když přistane nějaká nestandardní akce, tak se všichni v týmu (primárně ale určitě leadership trio Produkťák/Techlead/Designer) pobavte:

• Zvažte kolik toho o dané situaci skutečně víte (známo vs neznámo, prediktabilní vs neprediktabilní vývoj)
• Řekněte si, jestli bude aktuální formát práce ten správný (sprinty? Kanban? Něco jiného?)
• Připravte lidi v týmu na to, že se některé věci budou měnit za pochodu a že se kupříkladu komunikace zintenzivní (a to pro všechny strany — nikdo teď jistě neví, jaké je správné řešení)
• Připravte lidi v týmu na to, že teď možná nebude čas psát hezký bezchybný kód (ale měli by mít později prostor pro to ho rekultivovat)
• Připravte důležité stakeholdery na to, že budete vyžadovat jiné tempo spolupráce
• Produkťák musí extrémně pečlivě zvažovat nice to have a really must have věci

A po nějaké době si udělejte retro. A když to nefunguje, tak to změňte. A když na to nemáte prostředí, tak to změňte.

Není to o ničem jiném než o get shit done.