Agile / Szkolenia

Scrum – nowe reguły gry 2020

27 stycznia, 2021 0
Podziel się:

18 listopada 2020 opublikowana została nowa wersja Przewodnika po Scrumie (ang. The Scrum Guide): Przewodnik po Scrumie: opis reguł (ang. The Definitive Guide to Scrum: The Rules of the Game). Zmiana ta jest tyleż istotna, że od 10 stycznia 2021 wszystkie egzaminy prowadzone przez scrum.org (w tym Professional Scrum Master – PSM) będą bazowały wyłącznie na nowej wersji Przewodnika. Każda osoba przystępująca do egzaminu powinna zapoznać się z tymi zmianami. Warto również, aby osoby działające w zespołach pracujących z wykorzystaniem Scrum, przeczytały nową wersję Przewodnika po Scrumie i zastanowiły się, jakie korzyści może odnosić ich zespół przy implementacji tych zmian.

Scrum – co to jest?

Scrum to ramy postępowania (ang. framework) pozwalające dostarczać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów, dla których nie ma prostych przepisów na znalezienie rozwiązania. Fundamentem Scruma jest empiryzm zakładający, że wiedza powstaje na podstawie doświadczeń (czasem nieudanych), a wszelkie decyzje powinny być podejmowane na podstawie dotychczasowych obserwacji. U podstaw Scrum leży też koncepcja lean koncentrująca się na optymalizacji pracy poprzez eliminacje marnotrawstw (ang. waste) oraz nakierowaniu działań i wysiłków na te obszary, które przyniosą największą wartość. Scrum wykorzystuje iteracyjne i przyrostowe podejście do wytarzania produktów oraz filary empiryzmu, którymi są przejrzystość (ang. transparency), inspekcja (ang. inspection) i adaptacja (ang. adaptation). Efektywne wykorzystanie Scrum zakłada, że zespół realizujący prace będzie działa w oparciu o pięć wartości: Zaangażowanie, Skupienie, Otwartość, Szacunek i Odwaga (ang. Commitment, Focus, Openness, Respect, and Courage). Ramy postępowania opisane w Scrum składają się z 3 elementów: Scrum Teamu, Artefaktów (ang. Artefacts) tworzonych przez Team i Wydarzeń (ang. Events) określających komunikację i zasady współpracy.

Scrum został zaprezentowany po raz pierwszy przez jego autorów (Ken Schwaber i Jeff Sutherland) w roku 1995, jako podejście do wytwarzanie oprogramowania. Tworzenie nowych produktów IT jest złożonym problemem, gdzie zarówno technologia jak i zmieniające się otoczenie oraz wymagania biznesowe powodują, że zastosowanie prostych, dobrze opisanych sposobów postępowania często prowadzi do porażki. Wytwarzanie oprogramowania w oparciu o integracyjny i przyrostowy proces opisany w Scrum okazuje się przynosić dużo większą wartość niż działanie w tradycyjnych modelach. Dlatego też Scrum stał się tak popularny w środowisku IT. Warto jednak zauważyć, że Scrum jest coraz częściej stosowanych także w innych obszarach niż IT. Wiele organizacji może w różnych sposób stosować Scrum w zależność od kontekstu w jakim działają. Pewne podstawowe reguły opisane w Scrum są niezmienne, ale niektóre obszaru Scrum ewoluowały, aby opis zawarty w Przewodniku był jak najbardziej zrozumiały i precyzyjny oraz zgodny z doświadczeniami jakie zostały zidentyfikowane przez ostatnie lata.

Zmiany w wersji 2020 dotyczą głównie kilku obszarów:

  • Ograniczenie Przewodnika do minimalnie wystarczających ram oraz jego uproszczenie
  • Koncentracja na samozarządzającym się Scrum Team i usunięcie pojęcia Development Team
  • Wprowadzenie pojęcia Cel Produktu (ang. Product Goal) oraz uporządkowanie i usystematyzowanie opisów pojęć Definicja Ukończenia (ang. Definition of Done) i Cel Sprintu (ang. Spring Goal)
  • Zmiany w polskim tłumaczeniu

Scrum KISS (Keep It Simple Stupid)

Pierwsza rzecz, którą możemy zauważyć czytając nową wersję Scruma to fakt, że jest ona o kilka stron krótsza od wersji z 2017 roku. Wynika to z pewnych korekt stylistycznych i uproszczeń językowych, ale przede wszystkim ze zmian merytorycznych. Autorzy doszli do wniosku, że należy usunąć niektóre elementy opisane w poprzednich wersjach, gdyż są one zbyt nakazowe. Możemy je stosować, ale nie są one konieczne dla każdego zespołu. Takie rozwiązania dalej pozostają w środowisku Scrum, ale w publikacjach uzupełniających, a nie w samym Przewodniku. Przykładem takich zmian może być usunięcie trzech pytań z Daily Scrum (Co zrobiłem? Co będę robił? Jakie widzę problemy?). W nowej wersji Przewodnika usunięte zostały wszelkie pojęcia i odniesienia do sektora IT, które stanowiły pewną pozostałość po tym z jakiego obszaru Scrum się wywodził. Dzięki tym zmianom opis Scrum stał się jeszcze prostszy i bardziej uniwersalny.

Jeden zespół – wspólny cel

Podstawowym elementem Scrum jest Scrum Team. Tworzą go Scrum Master, Product Owner oraz Developerzy. Cały Scrum Team odpowiada za dostarczanie wartości poprzez rozwijanie produktu. Nowa wersja Przewodnika kładzie jeszcze większy nacisk na odpowiedzialność całego Zespołu Scrum. Dlatego też zdecydowano się usunąć nazwę Development Team, która sugerowała, że Developerzy działają jako odrębny podzespół niezależny od Scrum Mastera i Product Ownera. Nie jest to tylko zmiana teoretyczna. Jest to zaadresowanie problemu, który pojawia się w praktyce. Często zdarza się, że Product Owner, czy też Scrum Master nie jest postrzegany przez Developerów jako osoba z zespołu. Efektywne działanie wymaga synergii w pomiędzy całym Scrum Teamem. Tworzenie niepotrzebnych barier może powodować wyłącznie zmniejszenie jakości działania całego Scrum Teamu, a co za tym idzie dostarczanie gorszych, mniej wartościowych rozwiązań. W Scrum Teamie są różne role wynikające z kompetencji oraz zakresu odpowiedzialności, ale tylko wspólne działanie osób pełniących te role może sprawić, że wytwarzanie produktów będzie realizowane w sposób skuteczny i efektywny.

Z tego powodu w nowym Przewodniku położono nacisk na samozarządzanie Scrum Team w miejsce samoorganizacji Development Teamu. Samoorganizacja oznaczała, że Development Team sam określa kto i jak będzie wykonywał poszczególne zadania. Samozarządzanie jest szerszym pojęciem. Po pierwsze nie dotyczy one wyłącznie Development Teamu, ale całego Scrum Teamu. Po drugie do decyzji kto i jak wykona daną pracę dodany jest element określający kierunek działania Scrum Teamu, czyli zdefiniowanie nad czym będziemy jako zespół pracować.

Po co my to w ogóle robimy?

– Czemu tak biegacie z pustymi taczkami?

– Panie, tu tyle jest roboty, że nie ma czasu taczek załadować!

Ten stary i sucharowy dowcip oddaje coś z czym często boryka się wiele organizacji. Wszyscy tak mocno koncentrują się na efektywności wytwarzania produktu, że już nikt nie pamiętam w jakim celu go robimy i czy jest on w ogóle komuś potrzebny. W nowej wersji Przewodnika po Scrum ta kwestie została odpowiednio zaadresowana. Po pierwsze na Spring Planningu oprócz kwestii „co” i „jak” ma być robione w kolejnym Sprincie dodano trzeci temat odpowiadający na pytanie „po co”.

Wprowadzono również pojęcie Celu Produktu, który opisuje długoterminowe zamierzenie, dla którego realizowany jest produkt. Cel Produktu jest powiązany z Product Backlogiem i staje się kompasem przy podejmowaniu decyzji odnośnie wszelkich zmian (np. piorytetyzacji) oraz wybieraniu elementów z Backlogu do realizacji. Cel Produktu jest zobowiązaniem Scrum Teamu powiązanym z Product Backlogiem, co powoduje, że każda praca zespołu jest nakierowana na realizację celu jaki jest stawiany przed produktem.

Dla pozostałych Artefaktów (ang. Artifacts) opisanych Scrum również określono zobowiązania. Dla Sprint Backlogu jest to to Cel Sprintu (ang. Sprint Goal), a dla Incrementu Definicja Ukończenia (ang. Definition of Done). Elementy te były opisane w poprzedniej wersji Przewodnika, ale dopiero w nowej wersji zostało to uporządkowane, a opisy precyzyjnie powiązane z poszczególnymi Artefaktami.

Do you Scrum in Polish?

Przewodnik po Scrum podobnie jak w poprzednich wersjach został również wydany w polskiej wersji językowej. Również tym razem autorzy tłumaczenia stanęli przed dylematem na ile tłumaczenia ma być wierne językowo, a na ile pozostawić pewne pojęcia w wersji angielskiej z uwagi na to, że takie ich stosowanie przyjęło się w praktyce. Tym razem zdecydowano się w polskiej wersji pozostawić wszystkie nazwy własne elementów Scruma po angielsku. Decyzja ta była założeniem narzuconym tłumaczom przez autorów Scrum. W efekcie nie ma już np. Właściciela Produktu (jest Product Owner), czy Rejestru Sprintu (jest Spring Backlog), czy Codziennego Scruma (jest Daily Scrum). Niemniej pojęcia opisujące filary empiryzm (przejrzystość, inspekcja, adaptacja), czy też wartości Scruma (Zaangażowanie, Skupienie, Otwartość, Szacunek, Odwaga) oraz zobowiązania Artefaktów (Cel Produktu, Cel Sprintu, Definicja Ukończenia) zostały pozostawione po polsku.

Scrum 2020 – plusy ujemne, czy dodatnie?

Na koniec chciałbym się pokusić o moją subiektywną ocenę nowej wersji Przewodnika po Scrum. Bardzo podoba mi się idea dodania Celu Produktu. Uważam, że bardzo porządkuje to sposób myślenia o produkcie i celu jego rozwoju. Jest to coś czego ewidentnie brakowało w poprzedniej wersji. Wyeliminowanie roli Development Teamu oraz położenie większego nacisku na samozarządzanie i pełną odpowiedzialność całego Scrum Team również jest dobrym pomysłem. Warto też docenić zmiany porządkujące. Poczynając na stylistyce, a kończąc na elementach merytorycznych (np. jasne umiejscowienia Celu Sprintu i Definicji Ukończenia).

W kwestii uproszczenia i ograniczenia Przewodnika mam trochę mieszane uczucia. Z jednej strony widzę dostrzegam korzyści wynikające z większej prostoty i czytelności. Z drugiej jednak strony brakuje mi paru elementów (np. 3 pytań zadawanych na codziennych spotkaniach), które w mojej ocenie można było spokojnie pozostawić, bo są one mocno zakorzenione w kulturze zespołów Scurm.

Nie do końca przekonuje mnie polskie tłumaczenie. W mojej ocenie niektóre pojęcia np. Właściciel Produktu, Rejestr Sprintu, czy Retrospektywa nie brzmią źle i często są używane w praktyce. Najbardziej razi mnie stosowanie nazwy Scrum Team zamiast Zespół Scrum, a już w szczególności w odmianie (np. Scrum Teamu, czy Scrum Teamowi). Dodatkowo pozostawienie polskich tłumaczeń pojęć, które nie są elementami Scruma np. Definicja Ukończenia, Cel Produktu, czy też samej nazwy Przewodnik po Scrumie, powoduje u mnie pewien dysonans, jeśli te pojęcia występują tuż obok nieprzetłumaczonych elementów (np. „Cel Produktu jest odzwierciedlony w Product Backlogu”). Nie jest to jednak krytyczna uwaga do tłumaczy, a raczej do założeń jakie zostały im z góry narzucone.

Reasumując bardzo pozytywnie oceniam kierunek i charakter zmian merytorycznych przedstawione w nowej wersji Przewodnika po Scrumie. Do kilku mniej istotnych zmian pozostaje jednak krytyczny (w szczególności do polskiego tłumaczenia). W mojej ocenie Przewodnik po Scrumie w wersji 2020 pozwoli każdemu jeszcze lepiej zrozumieć i stosować Scrum, co przełoży się na większą efektywność działania zespołów przy tworzeniu produktów dostarczających coraz większą wartość biznesową.

Źródła:

https://www.scrumguides.org/index.html

https://www.scrumguides.org/scrum-guide.html

https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf


Sprawdź nasze szkolenia z obszaru Scrum i przygotuj się do egzaminu Professional Scrum Master I:

 

Kategorie: Agile, Szkolenia
Rafał Kwatek
Autor: Rafał Kwatek
Trener, konsultant i kierownik projektów. Posiada ponad 10-letnie doświadczenie praktyczne. Realizował projekty tradycyjne (waterfall), jak i zwinne (agile), w wielu różnych firmach, gdzie zajmował się budową usługowych organizacji IT, wdrażał metodyczne podejście do zarządzania projektami i architekturą korporacyjną, a także definiował, wdrażał, oceniał i optymalizował procesy biznesowe i IT. Ponadto dokonywał przeglądów i audytów organizacji, opracowywał struktury organizacyjne, budował katalogi usług, definiował umowy SLA/OLA. Uczestniczył także w projektach, obejmujących wytwarzanie oprogramowania oraz wdrożenia systemów i narzędzi IT. Posiada certyfikaty ITIL Expert, PRINCE2 Practitioner, PRINCE2 Agile Practitioner, Lean IT Foundation oraz Six Sigma Yellow Belt. Jest akredytowanym trenerem uprawnionym do prowadzenia szkoleń ITIL, PRINCE2 i PRINCE2 Agile. Posiada wieloletnie doświadczenie trenerskie – w prowadzonych przez niego szkoleniach i warsztatach wzięło udział kilka tysięcy osób.

    Imię i nazwisko (wymagane)

    Adres email (wymagane)

    Temat

    Treść wiadomości

    Zostaw komentarz