Scrum Team powinien składać się z maksymalnie dziesięciu osób. Co jednak zrobić w sytuacji gdy nad jednym projektem musi pracować większa grupa specjalistów? Albo jeśli organizacja chce w całości przejść na zwinny sposób zarządzania? Aby rozwiązać ten problem, twórcy Scrum zaproponowali [email protected] Jest to bezskalowa architektura umożliwiająca organizowanie całych zespołów według zasad Scruma.

Skalowanie Scruma – omówione zagadnienia:

  1. Wprowadzenie
  2. [email protected]
  3. Scrum of Scrums
  4. Dalsze skalowanie i problemy [email protected]
  5. Podsumowanie

Wprowadzenie

W miarę jak organizacja rośnie, mogą pojawiać się coraz większe problemy z jej efektywnością. Są one spowodowane skomplikowaną strukturą wewnętrzną, utrudnionym podejmowaniem decyzji, czy wyznaczaniem kierunków działania. Dlatego firmy, które działają zwinnie na poziomie małych zespołów projektowych, często szukają możliwości ich skalowania.

W wielu organizacjach skalowanie Scruma nie jest potrzebne. Nawet jeśli działa w nich równocześnie wiele Scrum Teams, ich działanie nie musi być koordynowane. W organizacji działa wtedy po prostu wiele niezależnych Scrum Teams. Nie oznacza to jednak, że jest to Scrum wielozespołowy. Potrzeba skalowania pojawia się dopiero, jeśli większa część organizacji pracuje nad jednym produktem. Zaś działania wielu Scrum Teams wymagają synchronizacji.

Większość organizacji, które stosują zwinne metody zarządzania na dużą skalę wybiera model SAFe, czyli Scaled Agile Framework. Dziś przyjrzymy się jednak temu, jak skalowany jest Scrum. Według 15th State of Agile report, w 2021 roku drugim w kolejności wyborem jest bowiem [email protected]

[email protected]

W 1996 roku twórcy Scruma, Jeff Sutherland i Ken Schwaber, pracowali nad dużym projektem. W trakcie jego realizacji borykali się z problemem synchronizacji mniejszych zespołów pracujących w Scrumie. Wymyślili wtedy sposób jego skalowania, który finalnie nazwali [email protected]

Analogicznie do oficjalnego Przewodnika po Scrumie powstał Przewodnik po [email protected], który definiuje ten sposób skalowania pracy jako:

Framework w ramach, którego sieci Zespołów Scrumowych działające zgodnie z Przewodnikiem po Scrumie mogą rozwiązywać złożone adaptacyjne problemy, kreatywnie dostarczając produkty o możliwie największej wartości.

Podstawowym założeniem [email protected] jest prostota i wydajność. Dlatego jego działanie oparte jest o bezskalową architekturę. Innymi słowy, wykorzystuje on Scruma do skalowania Scruma. W ten sposób Scrum Team złożony z pojedynczych osób pełniących role Product Ownera, Scrum Mastera czy Developera staje się Scrum of Scrums: zespołem złożonym z zespołów.

Scrum of Scrums

Scrum of Scrums jest to Scrum Team, w którym znajdziemy osoby pełniące zwyczajne role Scrum. Jednak w związku z tym, że zadaniem Scrum of Scrums jest integracja wyników pracy kilku Scrum Teams, potrzebne są w nim dodatkowe role oraz grupy:

  • Product Owner Team– grupa Product Ownerów spotykająca się w celu uzgodnienia priorytetów i stworzenia spójnej wizji produktu
  • Chief Product Owner– może być Product Ownerem jednego ze Scrum Teams, albo osobą zajmującą się wyłącznie Scrum of Scrums
  • Scrum of Scrums Master – jego zadaniem jest praca nad efektywnością Scrum of Scrums.

Spotykają się oni na takich samych Wydarzeniach Scrumowych i używają zbliżonych Artefaktów.

Scaling Scrum

Dalsze skalowanie i problemy [email protected]

Bezskalowa architektura [email protected] sprawia, że może on być skalowany nie tylko raz. Jeśli organizacji potrzebna jest koordynacja zespołów na jeszcze większą skalę, może zostać utworzony Scrum of Scrums of Scrums.

Skalowanie Scruma może jednak rodzić problemy. A także zwielokrotniać te, które pojawiały się w podstawowych Scrum Teams. Dlatego polecane jest dopracowanie szczegółów współpracy wewnątrz każdego Scrum Team przed rozpoczęciem wdrażania Scruma na szerszą skalę. Oraz podejmowanie decyzji o skalowaniu Scruma jedynie w przypadku doświadczonych zespołów, które dobrze znają i rozumieją sposób działania i wartości Scruma.

Podsumowanie

Skalowanie Scruma nie jest łatwym zadaniem. Wymaga od Scrum Teams bardzo sprawnego stosowania zasad Scruma i synchronizacji wykonywanych zadań z innymi Scrum Teams. Dlatego podstawowe pytanie, na jakie należy odpowiedzieć brzmi: Czy skalowanie jest potrzebne?. To, że w organizacji działa wiele Scrum Teams nie oznacza automatycznie, że ich koordynacja przyniesie lepsze wyniki.

Jeśli organizacja zdecyduje się na powiększanie Scruma, zyskuje bezskalową architekturę, która może być z powodzeniem powiększana dalej. Każdemu powiększeniu towarzyszy jednak zwiększenie poziomu skomplikowania, z którym muszą sobie radzić Product Owner Team, Chief Product Owner oraz Scrum of Scrums Master.

Zapoznaj się z kolejnym wpisem dotyczącym Scruma: Co to jest Backlog Sprintu?

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 16. Skalowanie Scruma caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?