Tag: Daily Scrum

Scrum Eventy: Daily Scrum

Daily Scrum je nejkratší Scrum event který máme. Funguje jako zpětná vazba na spolupráci v týmu a probíhá každý den. Často se mu říká Standup nebo Daily. Aby fungoval musíte mít tým co má společný cíl, ne jen skupinu jednotlivců, co si rozdá úlohy a pak na nich samostatně pracuje.

Cíl: Cílem Daily Scrumu je podívat se, jak jsme pokročili vzhledem ke Sprint Goalu.

Délka: Jestliže vám Daily Scrum pravidelně trvá víc než 5 min, pravděpodobně tam řešíte věci, které na Daily Scrum nepatří.

Jak: Daily Scrum je reflexí týmu na self-management. I když jde vše dobře, je dobré se čas od času zastavit a podívat se, jestli vše ještě stihneme podle plánu anebo se musíme zorganizovat jinak.

  • Daily Scrum by měl být každý den ve stejný čas. Tedy nikde není řečeno, že by měl být ráno.
  • Sprint Goal není status jednotlivce a ani by neměl sklouznout k detailním konverzacím o řešení.
  • S problémy by členové týmu neměli čekat až na Daily Scrum, ale měli by je řešit v průběhu Sprintu.
  • Daily Scrum by neměl být jedinou příležitostí kdy se tým vidí. Scrum tým musí aktivně spolupracovat v průběhu celého Sprintu.
  • Daily Scrum je dobrou příležitostí se na chvíli zastavit a přeorganizovat, jak spolupracujeme.
  • Daily Scrum je pro Developery, nikoliv pro ScrumMastera nebo Product Ownera.
  • Jednotlivé položky Sprint Backlogu nevlastní jednotlivci, ale vždy celý tým.
  • V průběhu Sprintu je vhodné minimalizovat work in progress, tedy jako tým pracovat jen na jedné položce Sprint Backlogu v jeden čas, a dokončovat je tak postupně (Swarming). Tým pak má větší focus, pocit vlastnictví, a také zodpovědnost za dokončení.
  • Je doporučené nejen v rámci týmu spolupracovat na jedné položce backlogu ale i na jednotlivých táskách (Pairing, Mobbing).
  • Daily Scrum je nejen o reflexi ale i pomáhání si navzájem. Jednotlivé tásky nikomu nepatří, a tedy se často přesouvají mezi jednotlivými členy, aby tým optimalizoval práci, která je potřeba dokončit.

Jak na Scrum Eventy

Když to řeknu jednou větou, Scrum je iterativní a inkrementální styl práce, zaměřený na týmovou spolupráci a maximalizaci business hodnoty. Nic složitého. To ale neznamená že ho organizace hned napoprvé implementují správně. Scrum totiž mění poměrně hodně zažitých věcí. Tentokrát bych se chtěla podívat na eventy. A jen tak mimochodem, neříkáme jim ani “ceremonie“ (které týmy dělají jen tak naoko, protože Scrum říká že se to musí), ani “meetingy“ které někdo pro tým musí zorganizovat. Event je bližší slovu “happening“. Tedy něčemu, co se děje skoro by se dalo říct samo od sebe, protože všichni chtějí, aby se to dělo. Nikde se nic nemusí plánovat, všichni vědí, kde a kdy event je a účastní se, protože jim to připadá užitečné a smysluplné.

Eventů je ve Scrumu pět a se dějí pravidelně. Mají sice definovanou maximální délku, ale je dobré vědět že pro kratší Sprinty eventy trvají významně kratší dobu. Důležitá je hlavně pravidelnost. Tím, že se dějí pravidelně, pomáhají týmu ale i zákazníkům si na iterativní styl práce zvyknout a lépe plánovat, připravovat se, a vědět co se děje.

Asi nejčastější problém je, že se týmy snaží aplikovat Scrum na jednotlivce místo na tým a že v Product Backlogu mají nahodilé tásky, nikoliv položky backlogu definující business hodnotu. V takovém prostředí většina eventů nefunguje, protože jsou založené na týmové spolupráci a dodávání hodnoty. Ze Sprint Planningu se stane alokace práce pro jednotlivce, z Daily Scrumu se stává micromanagerský otravný meeting, Sprint Review ukazujeme jen tak sami sobě, protože drobné činnosti vlastně nikoho nezajímají, a na Retrospektivě si postěžujeme, jak nám ten Scrum nefunguje. Nic, co byste chtěli zažít. A nemá ani moc cenu nutit jednotlivce Scrum eventy vykonávat, dokud místo skupiny jednotlivců nemáte tým a dokud v Product Backlogu nemáte opravdové položky backlogu zaměřené na hodnotu. V momentě, kdy se tyto dvě věci spraví, dějí se eventy vlastně samy od sebe, protože týmu pomáhají se lépe zorganizovat a dosahovat větší hodnoty pro zákazníka.

Když budete mít tým a relevantní Product Backlog, zbývá už jen vysvětlit k čemu jednotlivé Scrum eventy jsou a jak by měly vypadat. A na to se podíváme v následujících příspěvcích: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Retrospektiva.

Nejčastější nepochopení Scrumu

Scrum je velmi jednoduchý framework. Bohužel ale není vůbec snadný aplikovat. Je to velká změna myšlení, přístupu, hodnot. Když se půjdete do běžné firmy podívat, tohle asi budou nejčastější nedorozumění, a nepochopení, na které narazíte:

Scrum

Daily Scrum jako status meeting

Daily Scrum alias Standup meeting je tak triviální věc, že by jeden řekl že se snad ani nedá zkazit. Chyba lávky. 80% firem ho bere jako status meeting, kde každý jednotlivec referuje (managerovi, ScrumMasterovi, nebo ostatním členům týmu) co dělal. A kosmetické změny ScrumGuidu, které se snaží vysvětlit, že je to celé o synchronizaci týmu, jejich diskusi, jak dosáhnou cíle Sprintu (Sprint Goal), zůstávají bez povšimnutí. Kde jinde bychom ty líné vývojáře kontrolovali a řídili, vždyť jinak nebudou nic dělat.

“Cílem Daily Scrumu je synchronizace členů týmu a jejich dohoda, jak budou dále pracovat na dosáhnutí cíle Sprintu, tedy Sprint Goalu.“

Sprint Backlog se nesmí měnit, je klíčový

Když už jsem zmínila Sprint Goal, pojďme u něj zůstat. Většina firem žádné Sprint Goaly nepoužívá. Vystačí si se Sprint Backlogem, který navíc mylně vnímá jako neměnnou specifikaci, která do detailu popisuje, co přesně má tým (rozuměj ‘coding monkeys‘) naimplementovat. Sprint Backlog je ale jen rámcovou dohodou, jak chceme dosáhnout cíle Sprintu. Klíčovým artefaktem je Sprint Goal, který definuje, čeho z pohledu business value chceme dosáhnout. Ten by se měnit neměl, protože to je to do čeho v rámci Sprintu investujete. Sprint Backlog se naopak v závislosti na situaci a dohodě týmu klidně měnit může. V podstatě s tím, jak se ve Scrumu začal Sprint Goal více používat, přestal být Sprint Backlog téměř potřeba, natož aby byl neměnný.

“Sprint Goal definuje smysl Sprintu, čeho chceme z pohledu business value dosáhnout. Sprint Backlog nám pouze pomáhá udělat dohodu ‘jak’ toho chceme dosáhnout. “

Sprint Review je o akceptaci

A do třetice všeho dobrého, nebo spíš zlého :), takové běžné Sprint Review alias Demo velmi často skončí jako prezentace technických scénářů Product Ownerovi. Proč prezentujeme něco někomu, kdo měl být celou dobu přitom, je mi záhadou. Někde prezentujeme Product Ownerovi proto, že nikoho jiného technické scénáře nezajímají, jinde protože se bojíme členy týmu komukoli ukázat, aby neudělali ostudu, jinde ani Product Owner nechodí a děláme to jen protože Scrum. Sprint Review je klíčovým prvkem Scrumu, protože právě tady získáváme zpětnou vazbu na doručený Sprint Goal, tedy funkční inkrement produktu, nebo jinak řečeno dodanou business hodnotu. Jdeme správným směrem? Je tohle opravdu business hodnota? Dosáhli jsme očekávaného impactu? To jsou otázky, které je dobré si v rámci Sprint Review položit.

“Cílem Sprint Review je získat zpětnou vazbu od zákazníků, stakeholderů, uživatelů abyste se na jejím základě mohli adaptovat. Je to klíčovým prvkem a by vám fungoval proncip Inspect and Adapt.“

 

Jestli jste se ve výše zmíněných příkladech nepoznali, dobrá zpráva. Asi jste se už vymanili z područí ‘Technického Scrumu’, nebo ’Dark Scrumu’ a jste o krok blíže změně mindsetu. Jen tak dál 🙂

Dnešní změna Scrum Guidu

Dnes proběhla další z dlouho očekávaných změn Scrum Guidu – tedy popisu Scrumu, který všechny kvalitní Scrum certifikační organizace společně uznávají jako základní dokument definující Scrum. Tak se pojďme podívat na změny, které tento update přinesl. Tak v první řadě dobrá zpráva je, že Scrum jako takový se mění v podstatě jen drobně. Většina změn cílí na lepší vysvětlení toho, co je Scrum a kde se používá, případně napravuje nejčastější chyby jeho pochopení.

Nově Scrum Guide definuje kontexty, kde se Scrum používá, což je zajímavý krok k tomu zbavit se nálepky “Jen pro geeky“ a ukazuje výrazný posun k “Jsme tu pro všechny činnosti, které děláte“, což je dlouhodobý trend, který je na Agile a Scrum v posledních pár letech viditelný. Pár příkladů kontextů, kde Scrum Můžete použít:

  • Research a identifikace trhu, produktu a funkcionality (tedy Scrum jde použít na věci o kterých ještě nevíme, co jsou zač a jak mají vypadat a chceme to zjistit),
  • Vývoj produktů a jejich vylepšení (tedy vytvoření něčeho o čem víme, jak má vypadat),
  • Release produktů a jejich zlepšení i několikrát denně (tedy dodávání klidně i v módu Continuous Delivery),
  • Vývoj a údržba Cloudů a jiných podobných prostředí (tedy operations a v podstatě vše co se skrývá pod buzzwordem DevOps),
  • Sustaining, maintanance a podobně.

A dodává výčet prostředí v dnes tolik skloňovaném “Scrum mimo IT” jako je například hardware, embedded software, síťová řešení, autonomní řízení, školství, státní instituce, marketing, řízení organizací a vlastně vše, co děláme v našem běžném životě.

Jako další bod nový Scrum Guide explicitněji vysvětluje ScrumMastera jako servant leadera, který se podílí na transformaci celé organizace, což je příjemná změna, která je naprosto v souladu s tím, jak roli vysvětluji na kurzech a ve své knize The Great ScrumMaster: #ScrumMasterWay.

Ale to asi nejlepší ze všech změn je, že jsme se konečně zbavili “těch třech otázek“ co všichni měli na každém Daily Scrum meetingu zvaném Standup správně používat. Co mi to vždy dalo práce lidem vysvětlit, že standup tu není kvůli hlídání individuálnímu statusu jednotlivců ani micro-managementu, ale abychom si domluvili, co budeme jako tým dělat, abychom dosáhli cíle Sprintu (Sprint Goal). Tři otázky nezmizely úplně, tedy nemusíte se bát, že jste doposud dělali všechno špatně, jen se staly jedním z doporučení jak Daily Scrum  dělat.

Jediné, co vnímám jako zvláštně nekoncepční změnu (tedy něco co odporuje trendu, že Scrum nedefinuje praktiky JAK věci máte dělat, ale CÍL kterého máte dosáhnout) je to, že Sprint Backlog má obsahovat Action steps z Retrospektivy. Chápu, že to některým týmům může pomoci, ale proč to nemáme jen jako doporučení v sekci o Retrospektivě, mi není úplně jasné. Ale třeba to časem nějak vstřebám. Ostatně, třeba to pomůže Sprint Backlogu, který po minulé změně posilující důležitost Sprint Goalu na úkor Sprint Backlogu ztratil na důležitosti, a touhle změnou zase získá zpět svůj význam.

Suma sumárum je to dobrá sada změn a přestože některé věci, které bych ráda viděla jinak, zůstávají, je Scrum Guide dobrou definicí Scrumu, která se tímto updatem stala ještě o trošinku lepší.