W środę popołudniem miał miejsce webinar, na którym przy okazji 25-lecia Scruma Ken Schwaber i Jeff Sutherland przedstawili poprawki do Scrum Guide’a. Zgodnie z wcześniejszymi zapowiedziami zmiany były wynikiem przemyśleń obu panów oraz wniosków wielu doświadczonych praktyków. Scrum Guide miał stać się bardziej przejrzysty, prostszy, konkretniejszy, tak by również praktycy z innych domen i branży mogli z niego skorzystać, a jednocześnie miał ponownie stać się bardziej przewodnikiem niż podręcznikiem.
A jak wyszło? Gorąco zachęcamy was do przeczytania nowego Scrum Guide’a, żeby samodzielnie wyrobić sobie zdanie – teraz to tylko 13 stron. A u nas kilka słów komentarza od redakcji, bo podoba nam się kierunek zmian. Najlepsze zespoły pracowały już w podobny sposób od dawna — inspirowały się lean’em, realizowały Sprinty, aby realizować cele produktowe i brały odpowiedzialność za wytwarzany produkt. Natomiast nadal największym wyzwaniem pozostaje praktyczne wykorzystanie tej wiedzy w praktyce. Scrum stał się z jednej strony prostszy, z drugiej trudniejszy do zrealizowania w realiach organizacyjnych. A zatem, przed wami lista zmian:
- Jeszcze mniej normatywny Z czasem Przewodnik po Scrumie stawał się coraz bardziej normatywny. Wersja z 2020 roku miała na celu przywrócenie Scruma jako minimalnie wystarczających ram postępowania, a uczyniono to poprzez rezygnację z nakazów bądź ich złagodzenie, usunięto między innymi pytania z Daily Scrum, sformułowania odnoszące się do elementów Product Backlogu zostały złagodzone, mniej nakazowe stały się też sformułowania dotyczące włączania wniosków ze Sprint Retrospective do Sprint Backlogu, skrócono część mówiącą o przerywaniu Sprintu.
Komentarz agile247: Ponieważ często o Scrum Guide mówi się w kontekście przewodnika, wskazówek, odbieramy to jako powrót do korzeni. Znów mamy ramy postępowania, w obrębie których zespół może dowolnie kształtować swoje procesy pracy.
- Jeden zespół skupiony na jednym produkcie Celem było wyeliminowanie koncepcji odrębnego zespołu w ramach całego zespołu, co powodowało brak bezpośredniej wymiany informacji lub zachowania typu „my i oni” pomiędzy Product Ownerem a Zespołem Deweloperskim. Obecnie mamy tylko Scrum Team skupiony na jednym celu, a w jego ramach trzy różne zakresy odpowiedzialności: Product Ownera, Scrum Mastera oraz Developerów.
Komentarz agile247: Trochę smuci konieczność podkreślania tego, że PO i SM są częścią zespołu Scrumowego i wspólnie z Developerami stanowią całość i jedność. Dla nas było to zawsze jasne i jakkolwiek rozumiemy konieczność stawiania wyzwań i zadań przed Developerami przez Właściciela Produktu, tak nigdy nie sądziliśmy, że konieczne będzie wskazywanie, że grają do jednej bramki i są wspólnie odpowiedzialni za dostarczane rezultaty.
- Wprowadzenie Celu Produktu W Przewodniku po Scrumie z 2020 roku wprowadzono koncepcję Celu Produktu, aby zapewnić, że Scrum Team skupia się na większym, wartościowym zamierzeniu. Każdy Sprint powinien przybliżać produkt do osiągnięcia Celu Produktu.
Komentarz agile247: To chyba najbardziej niespodziewany element, który pojawił się w Scrum Guide. Czy było to konieczne? Pracując na co dzień z zespołami, uwrażliwiamy je na obowiązek zadawania sobie pytań, dla kogo robimy nasz produkt, po co go robimy, co jest długofalowym celem dla tego produktu, więc ten element jest dla nas nierozłącznie związany z klientem i agilem. Rozumiemy jednak, że podkreślenie tego w Scrum Guide może pomóc początkującym Scrum Masterom skupić się szybciej na właściwym spojrzeniu na pracę zespołu i pomóc im odpowiedzieć sobie na właściwe pytania, by zacząć pracować nad właściwymi rzeczami.
- Nowe miejsce dla Celu Sprintu, Definicji Ukończenia oraz Celu Produktu Poprzednie wersje Przewodnika po Scrumie opisywały Cel Sprintu, Definicję Ukończenia, nie precyzując, czym tak naprawdę są. Nie były wprawdzie artefaktami, ale w pewien sposób były z nimi powiązane. Dzięki dodaniu Celu Produktu wersja z 2020 roku bardziej to porządkuje. Każdy z trzech artefaktów ma obecnie przypisane “zobowiązanie”. Dla Product Backlogu to Cel Produktu, dla Sprint Backlogu to Cel Sprintu, a dla Incrementu to Definicja Ukończenia (teraz już bez cudzysłowu). Istnieją po to, by zapewniać przejrzystość i skupienie na postępach dla każdego z artefaktów.
Komentarz agile247: Nie da się ukryć, że takie rozróżnienie faktycznie pomaga uporządkować artefakty i ich znaczenie.
- Samozarządzanie ponad samoorganizacją Poprzednie wersje Przewodnika po Scrumie określały Zespoły Deweloperskie jako samoorganizujące się w takim sensie, że samodzielnie decydowały o tym, kto i jak wykonuje pracę. Jako że w wersji z 2020 roku większy nacisk położono na cały Scrum Team, podkreślona została cecha samozarządzania zespołu, który decyduje o tym, kto i jak wykona pracę oraz o tym, nad czym pracować.
Komentarz agile247: Na pozór subtelna różnica w słownictwie kryje za sobą większy impakt, bo w nowej wersji Scrum Guide cały Scrum Team, czyli również PO i SM mają możliwość zabrania głosu i wraz z Developerami decydowania o tym, czym zespół będzie się zajmował i jak rozdzieli prace. Wcześniej mocno podkreślano, że PO nie powinien wpływać na to, jak Developerzy się w sprincie zorganizują, bo to oni odpowiadają za Sprint Backlog. To zmiana na lepsze, bo stawia znak równości pomiędzy wszystkimi rolami, co jest istotne w świetle traktowania wszystkich ról jako jednego zespołu.
- Trzy tematy na Sprint Planning Do tematów odnoszących się do tego, “co” oraz “jak” wykonać poruszanych na Sprint Planningu, w wersji Przewodnika po Scrumie z 2020 roku dodano także trzeci temat, czyli pytanie „po co” wykonywać pracę, dotyczące Celu Sprintu.
Komentarz agile247: Pytanie to często Scrum Masterzy i Agile Coachowie zadawali sami z siebie, widząc zespoły planujące prace nie wiadomo dla kogo i po co. Z jednej strony zatem cieszymy się, że Scrum Guide bezpośrednio podkreśla tu wagę wykonywania właściwych prac, a z drugiej smucimy, że po 25 latach promowania zwinności takie rzeczy nie są oczywistością.
- Uproszczenie języka dla szerszego grona odbiorców W Przewodniku po Scrumie z 2020 roku położono nacisk na wyeliminowanie zbędnych lub złożonych zdań, jak również o usunięcie jakichkolwiek odniesień sektora IT (np. testowanie, system, projekt, wymaganie itd.). Obecnie Przewodnik po Scrumie liczy niespełna 13 stron.
Komentarz agile247: Trochę rozbawiło nas stwierdzenie w trakcie webinaru, że usunięcie odniesień do IT spowoduje, że więcej branż łatwiej zrozumie i zaakceptuje Scruma. Tutaj bliższa jest nam zasłyszana propozycja, by w Agile Manifesto zastąpić słowo software słowem produkt i w ten sposób u źródła wszystkich zwinnych metod pracy wskazać, że nie chodzi tylko sektor IT.
A patrząc na sam webinar to trudno nie mieć smutnej refleksji, że sposób zachowania słuchaczy na chacie podsumowywał dość dobrze 25 lat Scruma. Z jednej strony mieliśmy entuzjastów, ekspertów i osoby, które chciały jak najwięcej skorzystać z możliwości wymiany myśli na bieżąco wraz z postępem rozmowy, a z drugiej grono spamerów (bo inaczej nie można tego nazwać), którzy albo reklamowali swoje usługi, albo szukali atencji (np. reklama webinaru Scrum is dead), albo zapraszali do klikania się na linkedinie. I ciężko przez te pseudoscrumowe treści było się przebić głosom z wartościowymi opiniami.
O aktualizacji Scrum Guide’a posłuchaj też w #051 odcinku podcastu Porządny Agile. Kliknij tutaj.