Scrum w kontekście zwinności: podstawy

Praca iteracyjna: po co Scrum i jak z nim zacząć

Scrum to jeden z frameworków opisanych w świecie Agile. Nie cała zwinność, ale często pierwszy kontakt z iteracyjną pracą nad produktem. W skrócie: aktualnie najpopularniejszy sposób organizacji pracy i wytwarzania produktów. Opiera się na dostarczaniu wartości w krótkich cyklach i jednoczesnym usprawnianiu procesu. W każdym cyklu (Sprint) zespół wytwórczy dostarcza kolejny przyrost produktu. Wyobraź sobie: co 2 tygodnie nowa działająca rzecz, na której możesz zarabiać?

W ciągu ostatnich kilku dekad Scrum mocno zmienił sposób organizacji pracy ludzi i zespołów. Zaczynał w branży IT. Z biegiem lat znalazł zastosowanie także w innych branżach.

Poniżej: czym jest Scrum, jak działa, dlaczego ma sens i po czym poznać słabego Scruma.

TL;DR

Scrum to metoda na szybkie uczenie się (czego chce klient i jak usprawniać proces pracy).

Najważniejsze w Scrumie to dostarczać Increment co Sprint, bo to umożliwia uczenie się.

Scrum to framework (nie metodyka, proces ani metodologia), do którego dodajesz praktyki i narzędzia zależnie od potrzeb.

Film o Scrumie znajdziesz TUTAJ

Co to jest Scrum w praktyce?

Scrum to metoda, która umożliwia uczenie się. Zaskoczony? Czytaj dalej. Kiedy wiemy, co robimy (znamy rezultat i drogę do celu), sprawa jest prosta: układamy plan i go realizujemy. Sytuacja się komplikuje, gdy droga jest niejasna. Do takich problemów służy Scrum: do wspólnego odkrywania ścieżki do celu przez zespół.

Zabrzmiało metafizycznie? Już się poprawiam. Jeśli wykonywałeś pracę na zamówienie, np. miałeś dostarczyć nowy produkt lub usługę, to prawdopodobnie bliskie są Ci takie wspomnienia: klient zmienia zdanie, klient nie wie, czego chce (albo nam się tak wydaje), wczoraj się podobało, a dziś ma uwagi, inaczej zrozumieliśmy to, na co się umówiliśmy.

Brzmi znajomo? Tu leży sedno: wiele zmian pojawia się dopiero wtedy, gdy klient dostaje produkt do ręki. Widzę produkt, korzystam z niego, pojawiają się przemyślenia i pomysły. Im szybciej klient dostanie kolejną funkcjonalność, którą zamówił (nawet jedną z wielu), tym szybciej udzieli feedbacku. W efekcie powstanie lepszy produkt, bardziej dopasowany do potrzeb.

„Magia” Scruma polega na tym, że skupia się na dostarczaniu wartości w krótkich iteracjach zwanych Sprintami. Na koniec każdego Sprintu zespół wytwórczy dostarcza coś, co pozwala zebrać od klienta feedback. Informacje zwrotne zasilają nową iterację. Za każdym razem, skupiając się na najważniejszych, najbardziej wartościowych częściach rozwiązania:

a) dostarczamy coś wartościowego, z czego klient może już korzystać

b) uczymy się, czy rzeczywiście to, co zrobiliśmy, jest wartościowe, i współtworzymy nowe pomysły na kolejne iteracje.

Zamiast szukać sposobu, jak idealnie „trafić” w oczekiwania klienta, metody zwinne (w tym Scrum) promują podejście: zaplanuj → zrób → zbierz feedback → wyciągnij wnioski. To po prostu sposób na uczenie się. Podejście oparte na wyciąganiu wniosków z faktów i planowaniu kolejnych działań na ich podstawie nazywamy empiryzmem.

BUDOWA SCRUMA

Zacznijmy od problemu: coś, co chcemy rozwiązać, dostarczyć albo usprawnić. Efektem pracy będzie produkt, który w naszym zamyśle ten problem rozwiązuje.

W zespole jest osoba, która wskazuje kierunek prac: Product Owner. Decyduje, nad czym będzie pracował zespół, w oparciu o swoją wiedzę oraz informacje z zespołu, klientów i interesariuszy.

Z reguły problem i jego rozwiązanie to duży temat. Składa się z wielu funkcji, mniejszych problemów i mnóstwa znaków zapytania. Realizacja może zająć wiele tygodni czy miesięcy. Zamiast pamiętać o wszystkim, zespół używa uporządkowanej listy wymagań: Product Backlogu. Product Owner, ustalając kolejność elementów, pokazuje wszystkim, nad czym zespół będzie pracował dalej. Realizacja każdego elementu ma dostarczyć nową wartość w produkcie.

Product Backlog to miejsce na pomysły i jedyne źródło pracy zespołu. Pomysły lubią się mnożyć. To dobra rzecz, gorzej gdy są ze sobą sprzeczne. Wtedy trudniej o współpracę. Żeby było jasne, dokąd idziemy, Product Owner dba o Cel Produktu: azymut prac. Czasem to kierunek na kilka tygodni, czasem na miesiące. Każdy Sprint, niczym kolejny checkpoint, przybliża do mety.

Nie da się zrobić wszystkiego naraz (można zacząć, ale to głupie). Zespół rozumie, że częsty kontakt z klientem to okazja do wyciągania wniosków. Dlatego pracuje w cyklach zwanych Sprintami. Sprint trwa maksymalnie 1 miesiąc (w praktyce tydzień lub dwa).

Każdy Sprint to okazja na dostarczenie czegoś naprawdę wartościowego. Żeby utrzymać skupienie, gdy startuje nowy cykl, zespół wskazuje sobie Cel Sprintu. Do osiągnięcia celu potrzebny jest plan. Członkowie zespołu spotykają się na Sprint Planningu. Product Owner wskazuje swoje pomysły na Sprint. Pozostali zastanawiają się, jak je zrealizować. Zdarza się, że oryginalny pomysł trzeba zmienić, np. podzielić na mniejsze elementy. Plan jest dobry, gdy składa się z trzech rzeczy: a) zdefiniowaliśmy razem cel, b) wiemy, jak chcemy go zrealizować (które elementy z Product Backlogu), c) mamy pomysł na wykonanie prac (np. kto, co i kiedy będzie robił).

Ten plan to Sprint Backlog. Im bardziej widoczny, tym lepiej: łatwiej reagować, gdy plan przestaje działać. Tworzą go członkowie zespołu, którzy będą wykonywać pracę w Sprincie. Profesjonaliści wiedzą najlepiej, co potrafią i co są w stanie wykonać w krótkim oknie Sprintu. Ci, którzy wytwarzają produkt, nazywani są Deweloperami. Tylko Deweloperzy zarządzają Sprint Backlogiem. Nic w planie nie zmienia się bez ich decyzji. Dzięki temu mogą wziąć odpowiedzialność za wyniki swojej pracy.

A z planami bywa różnie: potrafią się zmieniać i rozsypywać. Dlatego każdego dnia zespół weryfikuje aktualność Sprint Backlogu i wprowadza korekty. Dzieje się to podczas krótkiego, 15-minutowego spotkania: Daily Scrum. To miejsce, by ocenić postęp, wskazać zagrożenia w realizacji Celu Sprintu i stworzyć plan na następne 24h. Jeden dzień to z jednej strony mało (jeśli pomyliliśmy się, straciliśmy tylko dzień), a z drugiej wystarczająco dużo, by ocenić, czy idziemy w dobrą stronę.

Kiedy grupa osób pracuje razem, łatwo zgubić wspólne rozumienie wykonania: „Czy to już skończone?” „Tak!” „Na pewno?” „A nie czekaj, zapomniałem jeszcze o XYZ!”

Brzmi znajomo? Zespół wpadł już kilka razy w tarapaty przez to. Najgorzej, gdy problemy wychodzą przy korzystaniu z produktu przez klienta: wtedy jest po prostu wstyd. Dlatego zespół używa standardu: Definicji Ukończenia (Done). Niczym checklista pomaga pamiętać o wszystkich niezbędnych krokach, żeby każda funkcjonalność przechodziła te same kryteria jakościowe.

Gdy zespół pracuje, interesariusze nie śpią. Robią biznes: kupują, sprzedają, reklamują. Wiedzą, że zmieniło się otoczenie problemu, nad którym pracuje zespół. Dlatego pod koniec Sprintu zespół i interesariusze spotykają się na Sprint Review. Zespół prezentuje wyniki pracy, czyli aktualny produkt.

Nowe funkcjonalności poszerzają wartość produktu: tydzień temu nie było X, a teraz już jest. Tę dodawaną wartość nazywamy Incrementem. To najważniejsza część Scruma: gdy nie ma Incrementów / zmian w produkcie, które dostarczają nowe cechy, nie ma wartości. Interesariusze poznają nowy produkt i oceniają jego wartość. Dzielą się pomysłami i informacjami ze swojego świata. Dzięki temu zespół dowiaduje się, co nowego w trawie piszczy (na co dzień może nie mieć czasu, bo skupia się na tworzeniu Incrementu). Product Owner prezentuje Product Backlog i pomysły na następne Sprinty. Wszyscy wymieniają się pomysłami: co zespół powinien robić dalej? Co dostarczy najwięcej wartości? Product Owner podejmuje ostateczną decyzję, czy i jak nowe pomysły wpływają na kolejność prac. Efektem jest modyfikacja Product Backlogu.

Dostarczone Incrementy nie kończą pracy zespołu. Jak profesjonalny zespół po meczu, również ten ma przemyślenia o wynikach i sposobie pracy. Sprint Retrospective to ostatni element Sprintu. Tu oceniacie stosowane praktyki: co pomaga, co przeszkadza, co działa, a co nie. Efektem jest plan usprawnień na kolejne Sprinty. Po Retrospective zespół jest gotowy zacząć kolejny Sprint.

Każdy Sprint to pełne zaangażowania działania. Łatwo stracić skupienie, wejść komuś na odcisk, zapomnieć o ważnym elemencie współpracy, np. komunikacji. W zespole Scrumowym jest dodatkowa odpowiedzialność: Scrum Master, którego zadaniem jest zadbać o to, by zespół stosował Scruma zgodnie z jego przeznaczeniem.

SCRUM W SKRÓCIE - CZYLI JAK TO JEST ZE SOBĄ POŁĄCZONE?

Scrum to: 3 x 5 x 3 x 3

obraz

Są 3 odpowiedzialności (nie stanowiska czy tytuły):

Product Owner - zarządza Product Backlogiem, decydując o wartości.
Developerzy - zarządzają Sprint Backlogiem i wytwarzają Incrementy.
Scrum Master - wspiera stosowanie Scruma.

Jest 5 zdarzeń:

Sprint Planning - otwiera Sprint; tu powstaje plan na Sprint → Sprint Backlog.
Daily Scrum - codzienna aktualizacja postępów i plan na następny dzień.
Sprint Review - feedback na temat Incrementów i pomysły na kolejne Sprinty.
Sprint Retrospective - usprawnienie procesu pracy zespołu.
Sprint - zawiera powyższe zdarzenia.

Są 3 artefakty (to one głównie podlegają ocenie i modyfikacjom):

Product Backlog - lista rzeczy, które zespół chce wykonać, by dostarczyć produkt.
Sprint Backlog - plan na Sprint: cel, droga do niego i sposób realizacji.
Increment - przyrost w produkcie: to, co zostało ukończone w Sprincie, wraz z poprzednimi Incrementami.

Żeby robota nie rozeszła się na boki, mamy jeszcze 3 zobowiązania:

Żeby Product Backlog nie był workiem pomysłów od Sasa do Lasa, istnieje Cel Produktu. Product Backlog powinien zawierać tylko to, co wspiera aktualny Cel Produktu.
Żeby zespół pracował razem, w jednym kierunku, istnieje Cel Sprintu.
Żeby wszyscy zainteresowani mieli to samo zrozumienie, co produkt ma, a czego nie ma, istnieje Definicja Ukończenia. Dzięki temu wiemy, kiedy powstaje Increment.

CHWILA, CHWILA! JAK TO SIĘ MA DO NAUKI?

Według nas: bardzo. Kilka przykładów:

Product Backlog - uporządkowana lista tego, co należy zrobić w produkcie, według wartości. To, co na górze, powstaje jako pierwsze. Jeśli dostarczysz Increment, a klienci mają WTF?, już wiesz, że coś jest nie tak z kierunkiem prac. Lepiej dowiedzieć się wcześniej niż później. Często początkowe pomysły dezaktualizują się, zanim do nich dojdziecie. Odkrycie, że czegoś już nie trzeba robić, to solidna wiedza. Tymczasem rodzą się nowe pomysły. Dodane do Product Backlogu, zostaną zrealizowane zgodnie z ich wartością. Pracując w oparciu o Product Backlog, zespół uczy się klienta i jego potrzeb.

Sprint Backlog - plan na Sprint. Wczoraj wydawał się świetny, dziś, gdy wgryźliśmy się w temat, okazuje się, że trzeba go zmienić. Coś miało zająć 3 dni, a zajmuje 5. Jeśli takich zadań jest więcej, macie podstawy, by przekalkulować plany. Być może skończycie dużo później. Lepiej wiedzieć o tym wcześniej.

Increment - klient zobaczył wyniki prac i nie rozumie, jak produkt działa. Bolesna, lecz cenna lekcja. Pomyśl o Incremencie jak o prezencie: opakowanie może być super ładne, ale dopiero po zajrzeniu do środka wiesz, czy Ci się podoba. Zespół dostarcza co Sprint prezenty. Chcielibyśmy, żeby były najlepsze i najbardziej wartościowe. Ostatecznie to klient decyduje, co mu się podoba. Patrzymy na reakcję (dane, metryki, feedback) i decydujemy, co przygotować na kolejne Sprint Review. Wiedza w najpiękniejszej postaci.

Deweloperzy wykonują prace w Sprintach. Jednym z nich jest Heniek (ekspert domeny ABC). Nagle Heniek decyduje, że chce spędzić więcej czasu ze swoim stadem owiec na Podhalu. Jak dzielić się zadaniami i wiedzą, by takie wyjazdy nie zabiły zespołu? Wytwarzanie produktów to ciągłe wyzwania związane z zarządzaniem nowinkami technologicznymi, by produkt był atrakcyjny nie tylko dla klientów, ale i dla deweloperów. Jak decydować o sposobie realizacji, by była zgodna ze sztuką i podatna na ciągłe zmiany? Jeśli interesujesz się sportami zespołowymi, wiesz, że posiadanie gwiazd nie wystarczy. To wymaga czasu, wiedzy, poznania mocnych i słabych stron. Scrum daje tę możliwość w każdym Sprincie i wymaga systematyczności: po każdym Sprincie zatrzymajcie się i popatrzcie, co możecie robić inaczej, lepiej, sprawniej, co działa, a co nie.

SCRUM - METODOLOGIA, METODYKA, METODA CZY FRAMEWORK?

Scrum często bywa określany jako metoda, metodyka czy metodologia, co czasem prowadzi do nieporozumień. Najtrafniejsze określenie to framework: ramy działania. Żeby to zrozumieć, warto najpierw rozróżnić metodykę i metodologię.

Metodyka to zestaw jasno określonych zasad, kroków i technik prowadzących do określonego celu. Jest praktyczna i operacyjna: skupia się na „jak działać”. Przykładem jest PRINCE2 w zarządzaniu projektami.

Metodologia to termin szerszy: naukowe podejście do tworzenia metod i ich badania. Bardziej teoretyczne: pomaga zrozumieć, dlaczego stosujemy określone metody, jakie są ich założenia i jakie wyniki można dzięki nim osiągnąć.

Scrum nie jest ani pełną metodyką (brak szczegółowych instrukcji wykonawczych), ani metodologią (brak naukowego wywodu). To framework: zbiór zasad, odpowiedzialności, zdarzeń i artefaktów, który daje zespołom elastyczność w dopasowywaniu się do zmieniających się warunków. Dzięki temu Scrum da się stosować w wielu kontekstach i dostosowywać do potrzeb, zamiast narzucać sztywny sposób działania.

HISTORIA SCRUMA

Czy wiesz, że Scrum został zainspirowany rugby? W 1986 roku Hirotaka Takeuchi i Ikujiro Nonaka opublikowali artykuł w Harvard Business Review, w którym porównali efektywne zespoły projektowe do drużyn rugby grających w zwartej formacji. Więcej o tym tutaj.

Na początku lat 90. Jeff Sutherland i Ken Schwaber stworzyli podstawy Scruma, jakie znamy dzisiaj. W 1995 roku oficjalnie zaprezentowali Scrum jako framework na konferencji OOPSLA (Object-Oriented Programming, Systems, Languages & Applications). Od tego czasu Scrum zyskał ogromną popularność i stał się jednym z filarów filozofii Agile.

SCRUM TERAZ

Aktualną definicję Scruma zawsze znajdziesz na tej stronie.

Dziś Scrum to nie tylko narzędzie pracy zespołów IT. Wykorzystuje się go w marketingu, edukacji, a nawet w organizacjach non-profit. Promuje otwartość, adaptację i transparentność, co czyni go uniwersalnym narzędziem.

Z wzrostem popularności Scruma idzie też cena. Większy popyt to większa podaż, więcej okazji do wypaczenia i błędnego użycia. To z negatywów.

Z plusów: Scrum z pewnością zmienił sposób wytwarzania produktów. Stał się niejako standardem organizacji zespołów.

UWAGA NA ZOMBIE SCRUM! CZY TWÓJ ZESPÓŁ JEST ZAGROŻONY?

Pozorny Scrum (tzw. zombie Scrum) pojawia się, gdy zespół stosuje Scruma „na papierze”, ale w rzeczywistości nie realizuje jego zasad. Objawy?

Brak zaangażowania zespołu.
Produkty, które nie dostarczają wartości.
Ignorowanie retrospektyw i opinii klientów.

Żeby tego uniknąć, warto zacząć od podstaw:

Zdobyć wiedzę o tym, czym Scrum jest, a czym nie jest.
Skupić się na Incrementach. To oczywiste, ale łatwo o tym zapomnieć. Celem stosowania Scruma nie jest stosowanie Scruma.
Identyfikować i usuwać przeszkody na drodze do skuteczności pracy zespołu.

GDZIE SZUKAĆ RZETELNYCH INFORMACJI O SCRUMIE?

Chcesz nauczyć się Scruma od solidnych źródeł? Oto kilka sprawdzonych:

Aktualną definicję Scruma zawsze znajdziesz na tej stronie.
Scrum.org - oficjalna strona: szkolenia, doradztwo, dużo darmowych materiałów o wytwarzaniu produktów.
Kursy online, np. Udemy, Coursera czy LinkedIn Learning.
Zapraszamy też na nasze szkolenia. Kalendarz znajdziesz tutaj.

JAK ZACZĄĆ UCZYĆ SIĘ SCRUMA?

Scrum jest niby prosty, ale mimo wszystko trudny do opanowania. Kilka kroków na start:

Przeczytaj Scrum Guide - to podstawa!
Zapisz się na kurs online - jest wiele kursów, zarówno darmowych, jak i płatnych.
Ćwicz w praktyce - w swoim zespole albo na warsztacie z doświadczonym trenerem (kalendarz szkoleń).
Dołącz do społeczności - materiały znajdziesz tutaj.

PODSUMOWANIE

Scrum to ramy pracy. Sens mają dopiero wtedy, gdy służą dowozowi wartości, a nie odwrotnie. Niezależnie od tego, czy pracujesz w IT, marketingu czy innej branży, zasady Scruma mogą pomóc działać efektywniej i dostarczać więcej wartości.

Jeśli szukasz uporządkowanego startu, zajrzyj do Scrum Guide albo na nasze szkolenia ze zwinności.

PS: Masz pytania o zwinność lub pracę iteracyjną? Daj znać. Chętnie pomożemy.

Praca iteracyjna: co daje framework Scrum w zwinnej organizacji