Scrum tým by měl mít až deset lidí. Co však dělat, když větší skupina specialistů potřebuje pracovat na jednom projektu? Nebo pokud se organizace rozhodne následovat agilní způsob řízení? K vyřešení tohoto problému navrhli vývojáři Scrum Scrum@Scale. Je to architektura bez měřítka pro organizaci celých týmů podle principů Scrum.
Škálování Scrumu – obsah:
Úvod
Jakmile organizace roste, objevují se nové druhy problémů. Například pokles efektivity zaměstnanců způsobený složitou vnitřní strukturou, obtížným rozhodováním nebo nastavováním směru. Společnosti, které fungují agilně na úrovni malých projektových týmů, často hledají způsob, jak se rozšířit.
Mnoho podniků se bez škálování Scrumu obejde. I když mnoho Scrum týmů běží současně, nepotřebují koordinaci, protože skupiny fungují nezávisle. To však neznamená, že se jedná o multi-týmový Scrum. Potřeba škálování se objevuje pouze tehdy, když většina organizace pracuje na jednom produktu a může efektivně synchronizovat své více Scrum týmy.
Většina organizací, které přijímají agilní metody řízení ve velkém měřítku, volí model SAFE, nebo Scaled Agile Framework. Dnes se však nebudeme soustředit na SAFE, ale budeme diskutovat o jiném modelu nazvaném Scrum@Scale, protože podle 15. zprávy o stavu agility z roku 2021 je to druhá nejlepší volba mezi podniky, které se rozhodly pro agilní přístup.
Scrum@Scale
V roce 1996 pracovali tvůrci Scrumu, Jeff Sutherland a Ken Schwaber, na velkém projektu. Při jeho realizaci měli potíže udržet menší týmy pracující v Scrumu v synchronizaci. Přišli s způsobem, jak to škálovat, který nakonec nazvali Scrum@Scale.
Analogicky k oficiálnímu Scrum Guide existoval Scrum@Scale Guide, který definuje tento způsob škálování práce jako:
Rámec, v rámci kterého sítě Scrum týmů fungují podle Scrum Guide k řešení složitých adaptivních problémů a kreativnímu dodávání produktů s co největší hodnotou.
Základní premisou Scrum@Scale je jednoduchost a efektivita. Proto je jeho fungování založeno na architektuře bez měřítka. Jinými slovy, používá Scrum k tomu, aby škáloval Scrum. Tímto způsobem se scrum tým složený z jednotlivců jednajících jako Product Owner, Scrum Master nebo Developer stává Scrum of Scrums: tým složený z týmů.
Scrum of Scrums
Scrum of Scrums je scrum tým s lidmi, kteří zastávají tradiční role Scrumu. Nicméně, protože úkolem Scrum of Scrums je integrovat výsledky práce několika Scrum týmů, potřebuje další pozice:
- Product Owner Team – skupina Product Ownerů, kteří se scházejí, aby se dohodli na prioritách a vytvořili soudržnou vizi produktu
- Chief Product Owner – Product Owner Scrum týmu nebo osoba, která se výhradně zabývá Scrum of Scrums
- Scrum of Scrums Master – osoba, která dohlíží na efektivitu Scrum of Scrums.
Scházejí se na stejných Scrum událostech a používají podobné artefakty.

Další škálování a problémy Scrum@Scale
Architektura bez měřítka Scrum@Scale znamená, že umožňuje škálování více než jen jednou. Pokud organizace potřebuje koordinovat týmy na ještě větším měřítku, může zřídit Scrum of Scrums.
Nicméně, škálování Scrumu, jako jakákoli jiná metodologie řízení, má své nedostatky, a v tomto případě jsou podobné těm základním Scrum týmům, pouze jsou proporcionálně větší. Proto doporučujeme vypracovat detaily spolupráce v rámci každého Scrum týmu před zahájením Scrumu ve větším měřítku. Navrhujeme škálovat Scrum pro zkušené týmy, které mají dobrou znalost a porozumění hodnotám a fungování Scrumu.

Škálování Scrumu – shrnutí
Škálování Scrumu není dětská hra. Vyžaduje, aby Scrum týmy dovedně aplikovaly principy Scrumu a synchronizovaly své úkoly s ostatními Scrum týmy. Proto je základní otázkou, na kterou je třeba odpovědět: Je škálování potřebné? Jen proto, že v organizaci existuje mnoho Scrum týmů, automaticky neznamená, že jejich koordinace přinese lepší výsledky.
Pokud se organizace rozhodne rozšířit Scrum, získává architekturu bez měřítka, kterou lze úspěšně dále rozšiřovat. Nicméně každé rozšíření je spojeno se zvýšením úrovně složitosti, s níž se musí vyrovnat Product Owner Team, Chief Product Owner a Scrum of Scrums Master.
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?
- Co je Sprint v Scrum?
- Spolupráce mezi Product Ownerem a Scrum Masterem
- Závazky Scrum týmu - Cíl produktu, Cíl sprintu a Definice dokončení
- Charakteristiky dobrého Scrum Mastera