Listopad 2020 to ważny moment w historii Scruma, być może najbardziej popularnego frameworka pomagającego w sprawnej realizacji projektów. To właśnie w listopadzie opublikowano nową wersję Scrum Guide, a w styczniu tego roku zaktualizowane zostały również egzaminy. Dlatego chcielibyśmy przejść przez najważniejsze zmiany, które pojawiły się w nowej wersji.
Co warto wspomnieć, tak jak wielokrotnie zaznaczają to twórcy tego podejścia, Scrum to wciąż Scrum. Skąd więc zmiany?
Najważniejszym powodem jest to, że Scrum, który pierwotnie miał zastosowanie przede wszystkim w IT, jest teraz stosowany właściwie wszędzie i zdobywa coraz większą popularność. Coś co do tej pory było domeną produktów informatycznych, teraz znajduje miejsce w restauracjach, agencjach marketingowych czy projektach festiwalowych. Stąd nowa wersja oficjalnego poradnika jest mocno uproszczona, dając korzystającym znacznie większe możliwości w dostosowaniu tego systemu do swoich potrzeb.
Drugim istotnym powodem jest chęć doprecyzowania pewnych niejasności i położenia nacisku na pewne elementy Scrum, które są bardzo istotne, a nie zawsze były rozumiane poprawnie.
Zacznijmy od najważniejszych zmian:
1. Commitmenty
Commitmenty czyli inaczej zobowiązania, to nowy element Scruma, odpowiedni dla każdego z artefaktów. W nowym poradniku znajdziemy zdefiniowane trzy takie elementy:
Product Goal
Pierwszym zobowiązaniem powiązanym z Product Backlog jest Product Goal, czyli cel, dla którego tworzymy produkt. Choć wydaje się to coś oczywistego, dodanie konkretnego celu do którego mamy dążyć pozwala na znacznie większą przejrzystość w trakcie zarówno budowania backlogu jak i refinementów.
Scrum Guide nie opisuje jak dokładnie ma wyglądać cel produktu. Ważne jest to aby był to jeden, konkretny cel, opisujący to do czego dążymy. Product Goal musi być w jakiś sposób mierzalny, tak żebyśmy mogli dokładnie stwierdzić kiedy został on osiągnięty. Takim celem może być np. pozyskanie konkretnej liczby nowych użytkowników, czy opublikowanie aplikacji mobilnej w Apple Store i Google Play Store.
Sprint Goal
Drugim zobowiązaniem, powiązanym ze Sprint Backlogiem jest Sprint Goal. Podobnie jak poprzednio omawiany cel produktu, tak i w tym wypadku mówimy o celu, tym razem celu danego sprintu. Tutaj również powinien być to jeden, konkretny punkt docelowy, a wszystkie zadania w Sprint Backlogu powinny służyć jego realizacji.
Warto wspomnieć tutaj o kolejnym dodatku w nowej wersji Scruma, czyli trzech pytaniasz, na które mamy odpowiedzieć w trakcie planowania Sprintu: “Dlaczego?”, “Co?” i “Jak?”.
W momencie, w którym elementy Backlogu wybrane dla danego sprintu odpowiadają nam na pytanie “Co?”, a plan na dowiezienie tych elementów odpowiada nam na pytanie “Jak?”, to właśnie Sprint Goal ma nam odpowiedzieć na pytanie “Dlaczego?” i to od niego powinniśmy zacząć.
Co ciekawe, jeśli chodzi o pytanie “Jak?”, nowa wersja Scrum Guide nie opisuje dokładnie w jaki sposób mamy na nie odpowiedzieć. Planowanie tego co należy zrobić żeby wykonać pracę nowy przewodnik pozostawia zupełnie w naszych rękach.
Definition of Done
Ostatnim Commitmentem jest znane już z poprzednich wersji Definition of Done, czyli ustalane przez Scrum Team warunki, które są wymagane aby daną część pracy przekształcić w increment.
Zobacz nasze szkolenia Scrum!
2. Uproszczenia
Tak jak wspominaliśmy na samym początku, Scrum Guide 2020 to dużo uproszczeń. Nowa wersja ma dawać wystarczające minimum żeby działać i zachęca do dodawania własnych elementów, które będą odpowiednie dla Waszej branży.
Kilka rzeczy, których nie znajdziecie w najnowszej wersji to:
- usunięte zostały pytania, które powinny pojawić się w daily scrumie – zamiast tego znajdziemy ogólny opis tego czemu służyć mają te codziennie spotkania
- we wstępie usunięte zostały wzmianki o IT
- usunięte zostały konkretne przykłady zastosowania Scruma
- nowy Scrum Guide nie zakłada już konkretnej liczby członków Scrum Teamu, zamiast tego znajdziemy zalecenie aby było ich wystarczająco dużo aby efektywnie realizować projekt, a jednocześnie wystarczająco mało aby działać zwinnie. Zalecana wielkość zespołu to do 10 osób
- Definicja retrospektywy została uproszczona i określona jako planowanie sposobów na polepszenie jakości i wydajności pracy zespołu
3. Przejrzystość
Nowy Scrum Guide stara się również doprecyzować pewne elementy, a w innych miejscach stara się położyć na znane już rzeczy większy nacisk.
Najbardziej zauważalną zmianą jest to, że Development Team został zastąpiony Developerami. Czemu służy ta zmiana?
Po pierwsze Development Team mógł sugerować, że developerzy stanowią podzespół wewnątrz większego Scrum Teamu. Nowa wersja nie pozostawia wątpliwości – developerzy są integralną częścią Zespołu Scrum. Są to wszyscy ludzie, którzy pracują nad produktem w ramach sprintów, co oznacza, że zarówno osoba odpowiedzialna za bycie Scrum Masterem czy Product Ownerem może jednocześnie być developerem.
Powyższy akapit otwiera kolejny temat, którym jest właśnie odpowiedzialność. Trudno wyjaśnić to w języku polskim, ponieważ nowy Scrum Guide zmienił słowo “responsibility” na “accountability”, a oba znaczą w naszym języku właśnie odpowiedzialność. Podobnie zastąpiona została “rola”.
W praktyce zmiana ta oznacza, że Scrum Master czy Product Owner jest odpowiedzialny za pewne elementy Scruma, ale nie musi wykonywać ich wyłącznie własnymi rękoma. Dzięki temu nie mamy już niejasności jeśli chodzi o to kto może budować Product Backlog. Chociaż to Product Owner jest za niego odpowiedzialny, może budować go razem z całym development teamem.
Jeśli chodzi o “role”, nowy Scrum Guide zaznacza, że accountabilities takie jak Scrum Master czy Product Owner nie muszą (ale mogą) pokrywać się ze stanowiskiem w firmie, po raz kolejny dając nam więcej swobody w tworzeniu własnego Zespołu Scrum.
Z mniejszych zmian:
- Servant Leader został zastąpiony określeniem “Leader who serve”, co nie zmienia wiele znaczeniowo, ale kładzie nacisk na to, że chociaż lider ma “służyć”, to wciąż jest przede wszystkim liderem
- Zaznaczone zostało, że Scrum powinien być w pełni transparentny nie tylko dla Zespołu Scrum, ale również dla interesariuszy
- Postawiony został większy nacisk na to, że każdy Sprint powinien zawierać w backlogu przynajmniej jedno usprawnienie z ostatniej retrospektywy
- Określenie Development Teamu jako “Self-Organized” zostało zmienione na określenie całego Scrum Teamu jako “Self-Magaging”. Samo Self-Managing oznacza, że to Zespół Scrum wewnętrznie decyduje o tym kto robi co, w jaki sposób i kiedy
Podsumowując, chociaż Scrum ma już ponad 25 lat, jak widać wciąż się rozwija i adaptuje, zgodnie z własnymi założeniami, stając się jeszcze bardziej dostępny. Jeśli chcecie zobaczyć najnowszą wersję Scrum Guide, znajdziecie ją na https://www.scrumguides.org/scrum-guide.html
Chcesz dowiedzieć się więcej o Scrum? Kliknij poniżej i czytaj dalej!
