Scrum Guide 2020 – co się zmieniło?

Scrum kończy 25 lat. Mimo swojego wieku bardzo często jest nazywany nowoczesnym podejściem do wytwarzania produktów. Podczas tych lat wyszło bardzo dużo nowych wersji, które zawierały poprawki oraz nowe pojęcia stosowane do dziś. W dniu 18 listopada 2020 roku Ken Schwaber wraz z Jeffem Sutherlandem opublikowali najnowszą wersję Scrum Guide. Zapewne zadajecie sobie pytanie jakie różnice pojawiły się między wersją z 2017, a 2020 roku?  

Odchudzony Scrum Guide

Mimo, że Scrum Guide zawsze był objętościowo dość cienką lekturą, to w najnowszej wersji został okrojony jeszcze bardziej. Nowy przewodnik po Scrum posiada tylko 13 stron. Na nich opiera się zwinne podejście do wytwarzania produktu. 

Definicja oraz Teoria Scrum

Otwierając nowego Scrum Guide od razu rzuca nam się w oczy różnica w definicji. W wersji z 2020 roku widzimy wyraźny nacisk na generowanie wartości oraz adaptacyjne rozwiązywanie złożonych problemów. 

Najnowsza wersja mocno podkreśla już na samym wstępie to, że Scrum Master jest rolą kluczową i odpowiedzialną za zbudowanie środowiska Scrum. Dodatkowo zaprezentowano informację, jak powinna wyglądać pętla iteracyjnego podejścia:

  1. Product Owner porządkuje pracę dla złożonego problemu w Product Backlog 
  2. Zespół Scrum zamienia wybrane elementy w wartościowy Przyrost podczas sprintu
  3. Zespół Scrum oraz interesariusze dokonują Inspekcji Przyrostu oraz dostosowują zakres następnego sprintu
  4. Powtórz

Na podstawie wyżej wymienionych punktów możemy dojść do wniosku, że to Zespół Scrum w całości jest odpowiedzialny za osiąganie celów i dostarczanie wartości. 

Teoria Scrum

Nowa wersja Scrum Guide jako podstawy frameworka wskazuje znany wcześniej Empiryzm, oraz nowo wspomniany Lean. Oznacza to, że ważnym elementem jest nie tylko podejmowanie decyzji na bazie doświadczeń i obserwacji co wynika wprost z podejścia empirycznego, ale również identyfikacja i usuwanie marnotrawstwa, co wpisuje się bezpośrednio w filozofię Lean. 

Dodatkowo widzimy podkreślenie bezpośredniej relacji między wydarzeniami Scrum a jego trzema filarami: Transparencją, Inspekcją i Adaptacją. Jest to bardzo ważne dla czerpania wymiernych korzyści z frameworka, aby w każdym wydarzeniu dochodziło do Inspekcji i Adaptacji, co przekłada się na maksymalizację wartości produktu.

Trzy filary Scrum

W obszarze filarów Scrum podkreślono również ścisłe powiązanie między Transparencją, a Inspekcją, jak również Inspekcja, a Adaptacją. To stwierdzenie zostało dodatkowo wzmocnione mimo, że już od pierwszej wersji Scrum Guide była o tym mowa. Jedno bez drugiego ma małe szanse powodzenia lub w innych słowach nie możemy dokonać Inspekcji, jeśli nie ma Transparencji, oraz Adaptacji bez wcześniejszej Inspekcji. Dodatkowo Adaptacja będzie utrudniona w momencie braku odpowiedniego umocowania i promowania samoorganizacji w Zespole Scrum.

Wartości Scrum

Wartości Scrum pozostają bez zmian:  OpennesS, Courage, Respect, FocUs, CoMmitment. Natomiast zauważalnym jest zwiększenie ilości wystąpienia wartości Commitment i bezpośrednie odniesienie się tej wartości do: 

  • Product Goal
  • Sprint Goal
  • Definition of Done

Zespół Scrum

Fundamentem Zespołu Scrum są ludzie. Skład osobowy powinien posiadać jednego Scrum Mastera, jednego Product Ownera oraz Developerów, u których nazwa roli uległa zmianie.  W poprzedniej wersji o zespole mówiło się, że jest samoorganizujący się, natomiast nowa wersja wprowadza pojęcie zespołu samozarządzającego się. Oznacza to, że Scrum Master, Product Owner oraz Developerzy samodzielnie podejmują decyzje o tym co, kto, kiedy i w jaki sposób wykona. 

Nowa wersja Scrum Guide wprowadza nową informację na temat wielkości Zespołu Scrum. Przypominamy, że wcześniej sugerowana liczba osób dotyczyła Zespołu Developerskiego. W najnowszej wersji liczba członków Zespołu Scrum wynosi maksymalnie 10 osób wliczając w to Product Ownera oraz Scrum Mastera. Dodatkowo podkreśla się, że jeśli Zespół Scrum jest zbyt duży, może dojść do problemów komunikacyjnych, dlatego w takiej sytuacji należy przemyśleć utworzenie kilku zespołów współpracujących nad jednym Backlogiem Produktu. Nie da się również pominąć jasnego i wzmocnionego przekazu o odpowiedzialności Zespołu Scrum za tworzenie wartościowego i użytecznego Przyrostu Produktu w każdym Sprincie. 

Scrum Master 

Nowy Scrum Guide bardzo wyraźnie podkreśla znaczenie i ODPOWIEDZIALNOŚĆ roli Scrum Mastera, który jest:

  • Odpowiedzialny za wdrożenie środowiska Scrum w organizacji
  • Odpowiedzialny za efektywność Zespołu Scrum
  • Odpowiedzialny za poprawne wykorzystanie Scrum w organizacji 

W naszym odczuciu w dalszym ciągu Scrum Master może być również osobą nietechniczną. Scrum Guide mówi, że Scrum ma zastosowanie w wielu dziedzinach, również tych, które nie są ściśle związane z wytwarzaniem oprogramowania. Mierzenie efektywności zespołu oraz dbanie o nią przez Scrum Mastera może być wykonane na wiele sposobów. Jednym z nich jest sprawdzanie i kalibracja Velocity zespołu. 

Wydarzenia Scrum 

Czytając o wydarzeniach Scrum nie widzimy znaczących zmian. Mimo wszystko warto zwrócić uwagę na Sprint Planning. Twórcy Scrum zaznaczają, że Product Owner jest odpowiedzialny za przedstawienie powodów, dla których kolejny Sprint zwiększy wartość produktu. Zespół Scrum jest odpowiedzialny za utworzenie Celu Sprintu, który wskazuje wartość wytwarzanego Przyrostu.

Artefakty Scrum

W dalszym ciągu Scrum Guide mówi o trzech Artefaktach Scrum: Product Backlog, Sprint Backlog oraz Przyrost.

Twórcy Scrum określają je jako przejrzyste zobowiązanie Zespołu, budujące odpowiedni poziom skupienia z możliwością mierzenia:

  • Product Backlog poprzez Product Goal
  • Sprint Backlog poprzez Sprint Goal
  • Increment poprzez Definition of Done

Product Goal opisuje przyszłą wartość budowanego produktu, która może być postrzegana jako długoterminowy cel dla Zespołu Scrum.

Sprint Goal jest zobowiązaniem Developerów w sprincie. Zachęca również do współpracy zespołowej tak, aby wszyscy Developerzy z zespołu dążyli do jego osiągnięcia. Cel Sprintu nie może być zmieniany podczas trwania Sprintu. 

Definition of Done jest formalnym opisem stanu Przyrostu, który musi zostać spełniony, aby wykonana praca mogła zostać zaakceptowana i przynosiła wartość. Moment, w którym Product Backlog Items (PBI) spełnia Definition of Done możemy nazwać narodzeniem Przyrostu. Jeżeli Definition of Done jest ustalone przez organizację, to jest to absolutne minimum, do którego Zespół Developerski musi się stosować. 

Podsumowanie

Scrum Guide 2020 przynosi nam wiele nowości. W naszej ocenie staje się on bardziej przystępny dla wszystkich produktów, nie tylko tych związanych z IT. Mimo nowej wersji Scrum Guide sam Scrum pozostaje w tej samej formie. Zmianie ulega wyłącznie jego opis.