Sprint Retrospektiva je událost, která končí každým Sprintem. A zároveň je to jedno z nejtěžších setkání Scrum týmu. Nejčastější chyby během Sprint Retrospektivy zahrnují vyhýbání se rozhovorům o citlivých tématech, stejně jako nedostatek konkrétních závazků vedoucích k vyřešení již diagnostikovaných problémů.
Časté chyby během Sprint Retrospektivy – obsah:
- Úvod
- Nedostatečná transparentnost
- Zaměření na jednorázové problémy nebo úspěchy
- Nadměrné zastoupení Product Ownera
- Problémy se sebedohledem
- Příliš mnoho závazků
- Časté chyby během Sprint Retrospektivy – shrnutí
Úvod
Chyby během Sprint Retrospektivy jsou bohužel velmi časté. Je to proto, že je to jedno z nejtěžších setkání, které je třeba úspěšně provést, protože vyžaduje od týmu velkou zralost. Proto stojí za to podívat se na problémy, které se vyskytují nejčastěji v jiných týmech, abyste mohli snáze rozpoznat jejich symptomy při provádění Sprint Retrospektivy ve vašem Scrum týmu.
Nedostatečná transparentnost
Podle Scrum Guide je každý člen Scrum týmu povinen být upřímný a odvážný při vyjadřování obav a vyjádřit svůj názor během Sprint Retrospektivy. V praxi je však závazek k transparentnosti velmi náročný. Z tohoto důvodu se členové Scrum týmu často snaží jej obejít.
Jedním z problémů, které je obtížné rozpoznat a vyřešit, je vyhýbání se diskusi o pozorovaných nedostatcích v práci Scrum týmu. To může vést k mnohem vážnějším problémům v dlouhodobém horizontu.
Úkolem Scrum Mastera je proto pečlivě sledovat situaci v týmu a povzbudit všechny členy týmu, aby byli proaktivní od samého začátku Sprint Retrospektivy.
Zaměření na jednorázové problémy nebo úspěchy
Dalším problémem, který může během Sprint Retrospektivy vzniknout, je nedostatečná pozornost věnovaná cyklickému a opakujícímu se chování týmu a jejich dopadu na efektivitu týmu.
Vždy je dobré poblahopřát členům Scrum týmu, pokud dosáhli výjimečného úspěchu. Nicméně, Sprint Review by nemělo být věnováno oslavě tohoto úspěchu. Totéž platí pro neúspěchy. Pokud něco selhalo z náhodných důvodů nebo z již diagnostikované chyby, není třeba událost během Sprint Review příliš analyzovat.
Někdy však tým věnuje velkou část Sprint Retrospektivy takovým událostem. Mějte však na paměti, že cílem Sprint Retrospektivy je hledat způsoby, jak zlepšit každodenní práci týmu. Proto by se setkání nemělo točit kolem jednorázových úspěchů nebo problémů, které se s vysokou pravděpodobností nebudou opakovat.
Nadměrné zastoupení Product Ownera
V mnoha organizacích je pozice Product Ownera ztotožňována s pozicí Product Managera. Product Owner je pak často považován za dozorčího Scrum týmu. Z tohoto důvodu se stává, že vývojový tým nechce hovořit o problémech v týmové spolupráci v jeho přítomnosti.
Proto je tak důležité budovat vzájemnou důvěru mezi vývojovým týmem a Product Ownerem. Bohužel, proces budování důvěry je obtížný a zdlouhavý. Proto je někdy dobré, aby se Product Owner vzdal účasti na celé nebo části Sprint Retrospektivy, aby nechal prostor pro zbytek týmu, aby mohl volně diskutovat.
Problémy se sebedohledem
Sebedohled znamená, že členové Scrum týmu se sami rozhodují, kdo z nich vykoná určité úkoly, kdy a jak. Během Sprint Retrospektivy tým diskutuje o lidech, jejich interakcích a týmových praktikách. Poté se rozhoduje, jaké problémy je třeba vyřešit v nadcházejícím Sprintu, jak to udělat společně a kdo ponese odpovědnost za provedení opatření.
Pokud se v sebedohledném týmu objeví vážnější problémy, může v Scrum týmu vzniknout pokušení se vzdát odpovědnosti.
Občas se členové týmu nechtějí účastnit diskuse a snaží se přenést odpovědnost za řízení na někoho jiného. Aby se tomu předešlo, je nesmírně důležité pravidelně diskutovat i o malých problémech, aby se předešlo jejich hromadění.
Příliš mnoho závazků
Aktivní Scrum tým, který pracuje podle tří pilířů empirismu: transparentnost, inspekce a adaptace, se může setkat s problémem, že se najednou zaváže k příliš mnoha závazkům.
Pokud je závazků, které Scrum tým učiní během Sprint Retrospektivy, příliš mnoho, existuje značné riziko, že:
- žádný z závazků nebude správně realizován
- některé závazky nebudou realizovány vůbec
- prováděné změny nebudou trvalé
Proto je dobrým zvykem podniknout maximálně čtyři zlepšení v každém Sprintu. To umožňuje postupné, ale efektivní zlepšení výkonu týmu.
Časté chyby během Sprint Retrospektivy – shrnutí
Protože Sprint Retrospektiva je náročná událost, během jejího provádění často vznikají problémy. Abychom se s nimi lépe vyrovnali, stojí za to si poznamenat ty, které se vyskytují nejčastěji. Časté chyby během Sprint Retrospektivy jsou:
- nedostatečná transparentnost – když členové Scrum týmu nedokážou čelit upřímnosti v obtížnějších týmových situacích
- zaměření na jednorázové problémy nebo úspěchy – když se členové Scrum týmu zaměřují na diskusi o úspěších a neúspěších, místo aby diskutovali o dlouhodobé efektivitě práce týmu
- nadměrné zastoupení Product Ownera – když členové Scrum týmu zacházejí s Product Ownerem s omezenou důvěrou, jako by byl někdo zvenčí nebo dozorčí
- problémy se sebedohledem – když se členové Scrum týmu snaží přenést odpovědnost za problémy a rozhodování.
Pokud se vám náš obsah líbí, připojte se k naší komunitě pilných včel na Facebooku, Twitteru, LinkedInu, Instagramu, YouTube, Pinterestu.
Caroline Becker
Jako projektová manažerka je Caroline odbornicí na hledání nových metod, jak navrhnout nejlepší pracovní postupy a optimalizovat procesy. Její organizační dovednosti a schopnost pracovat pod časovým tlakem z ní činí nejlepší osobu, která dokáže složité projekty přetavit ve skutečnost.
Scrum Guide:
- Slovník základních pojmů, rolí a představ
- Co je Scrum?
- Hodnoty Scrumu
- Jak implementovat Scrum ve vaší společnosti?
- Scrum tým - co to je a jak to funguje?
- Kdo je Product Owner?
- Nejčastější chyby Product Ownera
- Kdo je Scrum Master?
- Nejčastější chyby Scrum Mastera
- Jaké statistiky a metriky by měl Scrum Master sledovat?
- Vývojový tým ve Scrumu
- Nejčastější chyby vývojářů
- Scrum artefakty
- Škálování Scrumu
- Sprint Backlog
- Co je to Product Backlog?
- Co jsou uživatelské příběhy?
- Vytváření nejlepší uživatelské příběhu s INVEST
- Nejčastější chyby v uživatelských příbězích
- Kritéria přijetí uživatelského příběhu
- Odhad a příběhové body ve Scrumu
- Plánovací poker
- Hra o odhadování týmu
- Definování přírůstku
- Scrum události
- Co je to burndown chart?
- Výhody a nevýhody burndown grafu
- Kanbanové tabule ve Scrumu a Scrumbanu
- Rychlost v Scrum - Rychlost vývojového týmu
- Denní Scrum
- Plánování sprintu
- Sprintová revize
- Co je to Sprint Retrospektiva?
- Běžné chyby během retrospektivy sprintu
- Péče o produktový backlog
- Jak vytvořit a interpretovat burndown chart?