Scrum Guide 2020 – najważniejsze zmiany!

Udoskonalony Scrum Guide 2020 – opublikowany 18 listopada – zawiera kilka małych, ale istotnych zmian. Współtwórcy, dr Jeff Sutherland i Ken Schwaber, podkreślają wymienione poniżej zmiany między wersjami z 2017 i 2020 roku.

Nasza perspektywa na zaktualizowany Scrum Guide

Ogólnie z zadowoleniem przyjmujemy te zmiany. Uważamy, że przywracają przewodnikowi korzenie – przestaje być zbyt normatywny i staje się prawdziwym frameworkiem. W efekcie przewodnik jest też łatwiej stosować w branżach innych niż tworzenie oprogramowania. Są pewne dalsze zmiany, które chcielibyśmy zobaczyć… ale kto wie, co przyniesie kolejna iteracja.

Zmiany od Scrum Guide 2017 do Scrum Guide 2020
Poniżej opisujemy zmiany między Scrum Guide 2020 a poprzednimi wersjami. Oceniamy wszystkie zmiany jako Scrum Academy – dostawca szkoleń agile.

Jeszcze mniej normatywny

Z biegiem lat Scrum Guide stawał się coraz bardziej normatywny. Wersja 2020 miała przywrócić Scrumowi charakter minimalnie wystarczającego frameworka poprzez usunięcie lub złagodzenie nakazowego języka – np. usunięto pytania Daily Scrum, złagodzono język dotyczący atrybutów PBI, złagodzono język dotyczący elementów retrospektywy w Sprint Backlogu, skrócono sekcję o anulowaniu Sprinta i wiele więcej.

Perspektywa Scrum Academy: Podoba nam się ta zmiana, ponieważ to powrót do bycia frameworkiem, a nie zbiorem wiedzy (BoK) podobnym do PMBOK® PMI. Piękno Scruma tkwi w jego prostocie i uniwersalności. Stosowaliśmy Scruma w oprogramowaniu, sprzęcie, farmacji i wszelkiego rodzaju usługach. Powrót do korzeni sprawia, że koncepcje stają się bardziej namacalne dla osób spoza świata wytwarzania oprogramowania.

Jeden zespół, skupiony na jednym produkcie

Celem było wyeliminowanie koncepcji oddzielnego zespołu w ramach zespołu, która prowadziła do zachowań „proxy" lub „my i oni" między Product Ownerem a zespołem deweloperskim. Teraz istnieje tylko jeden Scrum Team skupiony na tym samym celu, z trzema różnymi zestawami odpowiedzialności: Product Owner, Scrum Master i Deweloperzy.

Perspektywa Scrum Academy:
Uwielbiam tę zmianę. Koncepcja zespołu w ramach zespołu regularnie prowadziła do zamieszania – zarówno w trakcie szkolenia, jak i podczas późniejszego wdrożenia. Mentalność „my" kontra „oni" jest naprawdę niebezpieczna dla każdego zespołu, a dla zespołów agile w szczególności. Nadal jednak podkreśla się, że odpowiedzialności w zespołach są i muszą być jasno przypisane.

Podobnie podoba mi się podkreślenie, że w Scrum Teamie nie ma formalnych hierarchii – jedynie różne odpowiedzialności. Naprawdę mam nadzieję, że ta mała, ale ważna zmiana terminologiczna sprawi, że coraz więcej ludzi będzie interpretować role w Scrumie podobnie jak my.

Jedyną rzeczą, którą chciałbym zobaczyć w przyszłości, jest zmiana nazwy „Deweloperzy". Zbyt często widzimy ludzi, którzy zakładają, że chodzi wyłącznie o deweloperów oprogramowania – co nie jest prawdą.

Wprowadzenie celu produktu

Scrum Guide 2020 wprowadza koncepcję celu produktu, aby ukierunkować Scrum Team na większy, wartościowy cel. Każdy Sprint powinien przybliżać produkt do ogólnego celu produktu.

Perspektywa Scrum Academy:
Ogólnie podoba nam się wprowadzenie celu produktu i podkreślenie, że każdy Sprint powinien przybliżać produkt do ogólnego celu produktu. Ale żeby być szczerym, wolelibyśmy termin wizja produktu, bo to pojęcie, którego wiele osób używało już od dawna. Istnieją nawet narzędzia zbudowane wokół niego, jak np. Product Vision Board Romana Pichlera.

Jeden aspekt, który uważamy za pomocny do dodania, to systematyczne podejście do myślenia o celu produktu, tzn. co cel produktu powinien obejmować. Jednocześnie mogłoby to sprawić, że framework znowu stałby się zbyt normatywny… więc może lepiej pozostawić go w obecnej formie.

Aby pomóc zespołom systematycznie tworzyć dobry cel produktu, stworzyliśmy Product Goal Canvas. To proste narzędzie pomaga zespołom myśleć systemowo i tworzyć cel produktu.

Dom dla celu Sprinta, Definition of Done i celu produktu

Poprzednie wersje Scrum Guide opisywały cel Sprinta i Definition of Done bez nadawania im prawdziwej tożsamości. Nie były do końca artefaktami, lecz były jakoś doczepione do artefaktów. Dodanie celu produktu sprawia, że wersja 2020 daje więcej jasności w tej kwestii. Każdy z trzech artefaktów zawiera teraz „zobowiązania". Dla Product Backlogu jest to cel produktu, Sprint Backlog ma cel Sprinta, a Increment ma Definition of Done (teraz bez cudzysłowu). Istnieją po to, żeby zapewnić przejrzystość i skupienie na postępach każdego artefaktu.

Perspektywa Scrum Academy: To świetne uzupełnienie! Od wielu lat miałem trudności z wyjaśnieniem, dlaczego Definition of Done lub cel Sprinta nie są artefaktami. Powiązanie każdego z nich oraz celu produktu z konkretnymi artefaktami to świetny krok, który znacznie ułatwia zrozumienie ich znaczenia.

Cel produktu pomaga nam określić, co umieścić w Product Backlogu. Cel Sprinta pomaga nam wybrać priorytety, aby właściwe elementy trafiły do naszego Sprint Backlogu. I wreszcie Definition of Done to nasza checklista, która pozwala sprawdzić, czy Increment został stworzony czy nie.

Samozarządzanie ponad samoorganizację

Poprzednie wersje Scrum Guide opisywały zespoły deweloperskie jako samoorganizujące się, tzn. wybierające, kto i jak będzie pracować. Kładąc większy nacisk na Scrum Team, wersja 2020 podkreśla samozarządzający się Scrum Team, który wybiera, kto, jak i nad czym pracuje.

Perspektywa Scrum Academy:
Naprawdę podoba nam się ta zmiana, ponieważ znacznie lepiej wpisuje się w istniejącą terminologię. Termin „samoorganizacja" nie wyjaśniał, jakie jest uprawnienie zespołu. Natomiast „samozarządzanie" można wyjaśnić, odwołując się do Modelu Władzy Hackmana (patrz niżej).

Ten model jasno pokazuje, że samozarządzający się Scrum Team jest odpowiedzialny za wykonywanie zadań, monitorowanie i zarządzanie własną pracą. Ale nie jest odpowiedzialny za projektowanie zespołu ani za wyznaczanie kontekstu organizacyjnego i ogólnego kierunku działania.

Trzy tematy Sprint Planningu

Oprócz tematów Sprint Planningu „Co" i „Jak", Scrum Guide 2020 kładzie nacisk na trzeci temat, „Dlaczego", odnoszący się do celu Sprinta.

Perspektywa Scrum Academy:

Uwzględnienie krótkiej sesji „Dlaczego" w Sprint Planningu jest spójne z wprowadzeniem celu produktu – Product Owner jest przy tym odpowiedzialny za łączenie kropek.

Ogólne uproszczenie języka dla szerszego grona odbiorców

Scrum Guide 2020 kładzie nacisk na eliminowanie zbędnych i skomplikowanych sformułowań oraz usuwanie wszelkich odniesień do pracy IT (np. testowanie, system, projektowanie, wymagania itp.). Scrum Guide liczy teraz mniej niż 13 stron.

Perspektywa Scrum Academy:

Ogólnie uważamy, że obecna aktualizacja Scrum Guide to dobry i znaczący krok naprzód w pozycjonowaniu Scruma poza światem wytwarzania oprogramowania.