W listopadzie ubiegłego roku Ken Schwaber i Jeff Sutherland opublikowali kolejną, szóstą już edycję Scrum Guide. O tym jak na przestrzeni lat zmieniał się przewodnik po Scrumie możecie przeczytać więcej w naszych poprzednich publikacjach (Scrum ewolucja I, Scrum ewolucja II, Scrum ewolucja III). Tymczasem, gdy opadły już pierwsze emocje i burze w social mediach dotyczące zmian, postanowiłam pochylić się nad najnowszą wersją biblii Scruma. Nowy Scrum Guide obfituje w zmiany, nie chcę od razu mówić o każdej z nich, za to postaram się podzielić refleksjami na temat samego celu przewodnika.
Zacznijmy od początku
Struktura Scrum Guide nie uległa szczególnie dużej zmianie i być może niektórzy z Was znając jego poprzednie wersje postanowiło pominąć pierwszy rozdział. Ja poświęciłam mu sporo uwagi już przy pierwszym czytaniu. Wstęp zmienił się z zaledwie kilku zadań do aż czterech akapitów. Opisuje on nie tylko sam cel, ale również nawiązuje do historii i wprowadzonych zmian. Na samym początku autorzy podkreślają, że mimo, iż od pierwszej wersji minęło 11 lat, ich współpraca zaczęła się znacznie wcześniej. I co najważniejsze, Ken Schwaber i Jeff Sutherland dalej wspólnie dokonują inspekcji i adaptacji przewodnika.
Kolejnym ważnym aspektem jest nawiązanie do stwierdzenia „Scrum nie działa”. Często bowiem nie działa, ponieważ pracujemy wykorzystując tylko niektóre jego elementy. Autorzy podkreślają, że w swojej prostocie framework nie powinien ulegać modyfikacjom, można do niego dodawać, ale nie odejmować. Na trzynastu stronach nowej wersji Scrum Guidea jest wszystko to czym powinniśmy się kierować, żeby móc w pełni powiedzieć „pracujemy w Scrumie”.
Wspólnie go opracowaliśmy i wspólnie ponosimy za niego odpowiedzialność.
Scrum Guide, listopad 2020
Popularność i ekspansja
Dostrzegamy rosnącą popularność Scruma w coraz bardziej złożonym świecie. […] Wraz z coraz szerszym zastosowaniem Scruma, swoją pracę wykonują deweloperzy, badacze, analitycy, naukowcy i inni specjaliści.
Scrum Guide, listopad 2020
Kolejny ważny akapit dotyczy rosnącej pozycji Scruma nie tylko w świecie IT, ale i też poza nim. Framework ten jest stosowany w szkolnictwie, wśród naukowców i innych specjalistów. W związku z rosnącą popularnością autorzy postanowili dokonać dwóch ważnych zmian. Pierwsza z nich dotyczy rezygnacji z podzespołów w Scrum Teamie – w nowym Scrum Guide nie znajdziemy już Zespołu Deweloperskiego. Myślę, że to szalenie ważna zmiana, która skupia cały Scrum Team na celu i wizji produktu, bez podziału na „my&oni”. Naturalną konsekwencją rezygnacji z wyróżniania podzespołów jest też zmiana nazewnictwa, od teraz zamiast Zespołu Deweloperskiego mamy Deweloperów. Zmiana ta spowodowała szereg dyskusji – dlaczego skoro idziemy w stronę Scruma poza IT autorzy nie zaproponowali innego określenia? Ken i Jeff odpowiedzieli na to pytanie podczas wydarzenia inauguracyjnego promującego nowy Scrum Guide, jak i w samym przewodniku:
Używamy słowa „deweloperzy” w Scrumie nie po to, by kogokolwiek wykluczać, lecz by upraszczać.
Scrum Guide, listopad 2020
Szukanie bardziej uniwersalnej nazwy mogłoby spowodować większą konsternację i zamieszanie. Tymczasem mamy do czynienia z osobami, które zobowiązane są do wytworzenia każdego aspektu użytecznego Incrementu w Sprincie. Czyli każdy kto zajmuje się tworzeniem i budowaniem produktu jest uznawany za Dewelopera. Dzięki takiemu podkreśleniu nie ma już wątpliwości czy Analityk Biznesowy może być częścią Scrum Teamu, czy UX Designer powinien pracować z nami w Sprincie, etc. Nazwy naszych stanowisk w pracy mówią jedynie o konkretnych kompetencjach, umiejętnościach jakie możemy wnieść do Scrum Teamu jako Deweloperzy.
Stosowanie podstaw kluczem do sukcesu
I ostatni akapit, mocno powiązany z powyższymi. W związku z ekspansją Scruma poza IT i zmianami wprowadzonymi w całym przewodniku autorzy jeszcze raz podkreślają, że Scrum stanowi jedynie fundament. Fundament, żeby był solidny, nie powinien być zmieniany. Podstawa, w zależności od kontekstu i specyfiki produktu, może być uzupełniana o kolejne elementy procesu, które staną się naszym standardem pracy. Można do nich zaliczyć szereg tak zwanych dobrych praktyk, a wśród nich:
- Sprint Retrospective przeprowadzane według struktury zaproponowanej przez Esther Derby i Diany Larsen;
- Definition of Ready – czyli zdefiniowanie informacji i struktury potrzebnych w poszczególnych typach elementów Product Backlogu do tego by móc zacząć nad nimi pracę;
- WIP limits – stosowanie limitów pracy w toku, zaczerpniętego z Kanbanu;
- I wiele innych.
Podsumowanie pierwszego rozdziału Nowego Scrum Guide
Jeden, krótki rozdział, a tak wiele informacji! Mam nadzieję, że jeżeli go nie pominęliście, a jeżeli tak, to że moje refleksję pokazały, że warto czytać od początku do końca. 🙂 Jako kwintesencję pierwszego rozdziału można wskazać empiryczne podejście Kena i Jeffa do Scruma, którzy wspólnie, jako zespół, dokonali kolejnej inspekcji i adaptacji przewodnika, który po raz pierwszy pojawił się w 2010 roku. Nowy Scrum Guide zawiera znacznie więcej zmian, spodziewajcie się więc kolejnych artykułów na ten temat.
PS. Czy zauważyliście, że nie wszędzie używam polskich odpowiedników angielskich nazw? Niektóre z nazw objęte zostały specyficznymi regułami tłumaczenia i można powiedzieć, że stały się nazwami własnymi.
Sprawdź nasze ostatnie wpisy:
