Czym jest Scrum?

Czym jest Scrum?

Scrum to zbiór ram postępowania (ang. framework), który pomaga ludziom i organizacjom dostarczać wartość. Praca w Scrumie odbywa się w iteracjach stałej długości (Sprinty), podczas których Zespół rozwiązuje złożone problemy, sprawdza i dostosowuje swoją skuteczność za pomocą procesu empirycznego. Najważniejsze w Scrumie jest wytworzenie ukończonego przyrostu produktu na koniec Sprintu.

Oprócz stworzenia wyraźnych ram, framework oferuje bardzo jasne pokazanie efektywności twoich praktyk budowania produktu. Możesz o nim myśleć, jak o lustrze, w którym codziennie przeglądasz efekty działań. Co możesz zrobić, jeśli nie podoba ci się to, co widzisz? Możesz zmienić sposób postępowania i przejrzeć się ponownie. Na tym polega empiryzm.

Role i odpowiedzialności

• Product Owner jest właścicielem produktu. Odpowiada za podejmowanie decyzji co do rozwoju produktu i zarządzanie backlogiem produktu, dbając o maksymalizację wartości.
• Developerzy są właścicielami planu pracy w Sprincie. Odpowiadają za zaplanowanie, organizację i wykonanie pracy potrzebnej do dostarczenia przyrostu produktu.
• Scrum Master jest właścicelem procesu. Odpowiada za wprowadzenie Scruma w organizacji, wspiera zespół poprzez facylitację i usuwanie przeszkód, dbając o przestrzeganie zasad frameworku. Wspiera Product Ownera w zarządzaniu produktem. Zarządza zmianą w kierunku zwinności w organizacji.

W najnowszej wersji Przewodnika po Scrumie (Scrum Guide) termin “rola” został zamieniony na “odpowiedzialność”, żeby podkreślić, że nie chodzi o stanowisko, które się piastuje w firmie, a o wzięcie odpowiedzialności za konkretne aspekty pracy w Scrumie. W nowym Scrum Guide podkreślona została odpowiedzialność całego Zespołu Scrumowego za dostarczenie działającego Przyrostu produktu.

Spotkania

W Scrumie określone zostały obowiązkowe spotkania, które mają ustalonych uczestników i maksymalny czas trwania. Każde takie spotkanie jest ważne i czemuś służy — ma określony cel. Dlatego w Scrum spotkania nazywamy Wydarzeniami.

• Sprint — Iteracja nie dłuższa niż jeden miesiąc, obejmująca wszystkie pozostałe wydarzenia.
• Sprint Planning — Planowanie pracy na nadchodzący Sprint, wybór najbardziej wartościowych elementów do realizacji i przygotowanie zgrubnego planu.
• Daily Scrum — Codzienne spotkanie Developerów, aby sprawdzić stan pracy i ustalić dalsze działania.
• Sprint Review — Przegląd przyrostu produktu na koniec Sprintu, zbieranie feedbacku od interesariuszy i wspólne ustalenie, jak dalej rozwijać produkt.
• Sprint Retrospective — Analiza procesu pracy po zakończeniu Sprintu, identyfikacja usprawnień. Usprawnienia są wprowadzane w życie w kolejnym Sprincie.

Artefakty

Artefakty to elementy, które przechowują ważne informacje, które będziemy poddawać ocenie. Są to również wyniki pracy zespołu. Artefakty służą zwiększeniu przejrzystości pracy i efektywności procesu.

• Product Backlog — Lista rzeczy do zrobienia dla produktu, jedyne źródło pracy dla zespołu. Pokazuje, jakie są plany rozwoju produktu.
• Sprint Backlog — Lista rzeczy do zrobienia w danym Sprincie, aktualizowana na bieżąco. Pokazuje, jaki jest stan prac w Sprincie i jaka jest szansa na osiągnięcie Celu Sprintu.
• Product Increment — Ukończony, przetestowany i zintegrowany przyrost funkcjonalności produktu na koniec Sprintu. Pokazuje, w jakim stanie jest produkt i co zostało do tej pory zrobione.

Czy zespół w Scrum zobowiązuje się do czegoś?

Zespół Scrum zobowiązuje się dążyć do osiągniecia Celu Sprintu, który jest potrzebny do zrealizowania Celu Produktu poprzez dostarczanie ukończonych zgodnie z Definicją Ukończenia Przyrostów Produktu.

Te trzy elementy zostały podkreślone w Scrum Guide jako zobowiązania (ang. commitments).

• Cel Produktu — Kontekst dla całego backlogu produktu, odpowiada na pytanie “dlaczego” tworzymy produkt.
• Cel Sprintu — Zobowiązanie dla Sprint Backlogu, zapewnia spójność i skupienie zespołu.
• Definition of Done — Zobowiązanie dla przyrostu produktu, jasno określa, kiedy element Backlogu Produktu jest ukończony i tym samym określa poziom jakości przyrostu.

Cały framework Scrum i szczegóły możesz przejrzeć w wizualizacji Scrum Guide 2016 jako mapa myśli.

Od 2009 roku autorzy opisują kolejne wersje w Przewodniku po Scrumie (ang. Scrum Guide). Ten dokument zawiera pełny opis, zatem rzeczy tam opisane stanowią nierozerwane elementy i niezbędne minimum. Wszystko ponadto jest dodatkiem, lepszą lub gorszą praktyką. W czasie pisania tego artykułu najnowszą wersją Scrum Guide jest ta z listopada 2020 roku.

Czym jest Scrum w 15 minut

Czy Scrum jest trudny?

Scrum jest lekki i prosty do zrozumienia, ale trudny do opanowania. Wymaga konsekwencji i zaangażowania zespołu w realizację zadań zgodnie z jego zasadami. Pomimo prostoty jego struktury, efektywne stosowanie Scrum wymaga praktyki i ciągłego doskonalenia.

Framework Scrum został zbudowany z 3 ról, 5 wydarzeń i 3 artefaktów. Zależności między tymi elementami określają proste zasady. Scrum nie mówi, jak postępować w każdej sytuacji. Nie ma tutaj zbioru najlepszych praktyk (ang. best practice). Problemy trzeba rozwiązywać samodzielnie. Dlatego korzystanie ze Scrum jest trudniejsze niż na przykład z gotowej metodyki zarządzania projektami.

Scrum nie gwarantuje, że zbudujemy wartościowy produkt i odniesiemy sukces. Scrum dobitnie pokazuje, jaka jest nasza efektywność, a rynek zweryfikuje, czy produkt jest wartościowy. Zderzenie z rzeczywistością może być trudne.

Żeby Scrum przyniósł oczekiwane efekty, musi zostać wdrożony bez modyfikacji, bez twierdzenia “jesteśmy specyficzną firmą”. Scrum wymaga środowiska, gdzie zmotywowane zespoły biorą na siebie odpowiedzialność za osiągnięcie celu, a kadra zarządzająca wspiera zespoły w ich pracy, zapewniając zasoby i dbając o środowisko. To zupełnie inne podejście niż command & control w hierarchicznej firmie i mikrozarządzanie.

Czy Scrum to Agile?

Scrum jako pojęcie jest często używany zamiennie ze słowem Agile i nie do końca jest to błąd. Dlaczego? Dobrze stosowany Scrum może być drogą do osiągnięcia założeń podejścia zwinnego do wytwarzania oprogramowania, czyli Agile. Oznacza to, że jeżeli prawidłowo go stosujesz, to spełniasz cztery podstawowe założenia Agile Manifesto i 12 zasad Agile.

Są inne sposoby na realizację Agile Manifesto, takie jak Extreme Programming (XP), Kanban, DSDM, Crystal czy Lean Startup. Zatem można powiedzieć, że została opracowana cała rodzina metod zwinnych, Agile. Jednak raporty takie jak State of Agile z Version One czy listy osób, które uzyskały certyfikaty, pokazują jednoznacznie, że to właśnie Scrum zdominował świat Agile.

Wizja w oczach Jeffa nie pozostawiała żadnych złudzeń co do jego intencji:

Celem Scrum jest osiągnąć “efekt Toyoty”, dostarczając czterokrotnie więcej oprogramowania, dwunastokrotnie lepszej jakości, w szeregu krótkich ram czasowych nazwanych “Sprintami”, które trwają 30 dni lub krócej.

Jeff Sutherland przekonał swojego szefa i zaczął eksperymentować. Nowy sposób pracy udoskonalany w ciągłej pętli zwrotnej okazał się strzałem w dziesiątkę. Zupełnym przypadkiem (podobno w życiu nie ma przypadków) Ken Schwaber zaprezentował Scrum szerszej publiczności w 1995 roku na konferencji OOPSLA. I tak rozpoczęła się rewolucja w świecie opanowanym do tej pory przez waterfall. Kolejne zakładane przez Kena Schwabera organizacje, Agile Alliance, Scrum Alliance i wreszcie scrum.org, zaczęły oferować szkolenia i certyfikaty takie jak Certified Scrum Master i Professional Scrum Master. Do tej pory sam Scrum.org od 2009 roku certyfikował prawie pół miliona osób.

Nazwa pochodzi od elementu gry w rugby, kiedy zespół zbiera się razem, żeby zrestartować rozgrywkę. W ten sposób Jeff oddał hołd Takeuchiemu i Nonace.

Czym Scrum nie jest?

Wbrew krążącym opiniom Scrum nie jest metodą zarządzania projektami. Przez projekt można tutaj rozumieć jedynie pojedynczy Sprint. Sprint nie może się nie udać, bo jego rezultatem jest pokazanie, co udało się zrobić i z jaką efektywnością.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

– Scrum Guide 2020

Scrum nie jest także nowym narzędziem do utylizacji zasobów, żeby ludzie pracowali szybciej i dostarczali więcej w tym samym czasie. Wprawdzie Jeff Sutherland obiecuje wzrost produktywności, ale to wymaga zmian w procesach i usunięcia przeszkód. Samo wprowadzenie frameworka nie przyniesie takiego efektu.

Framework nie jest sposobem na dowożenie wymagań na czas, ani techniką nieomylnego oszacowania pracy. Skupiamy się na dostarczaniu wartości biznesowej i działającego, użytecznego produktu. Nie oznacza to zaimplementowania wszystkich wymagań w niezmienionej formie.

Scrum nie jest przepisem na sukces, ani srebrną kulą likwidującą wszystkie problemy. Framework sprawi, że wszystkie problemy będą bardziej widoczne. Ale to organizacja musi je rozwiązać.

Framework Scrum nie jest kolejnym cyklem życia oprogramowania dotyczącym tylko działu IT i inżynierii oprogramowania. Ludzie z IT i z biznesu muszą pracować codziennie razem, żeby odnieść sukces. Wprowadzenie i korzystanie z tego frameworku często wymaga zmian w HR, budżetowaniu, zarządzaniu projektami, współpracy z klientem itd. Ludzie wykorzystują ten framework z powodzeniem poza IT, na przykład w wojsku, szkołach, a nawet w rolnictwie.

Zasadniczo zgodnie z wolą twórców Scrum, nie powinniśmy określać go jako metoda. Lepszym określeniem będzie struktura lub szkielet (ang. framework), w ramach którego możemy wytwarzać wartościowe produkty poprzez zarządzanie procesami. Scrum nie narzuca konkretnych praktyk lub technik rozwoju oprogramowania, tak jak robi to na przykład bliźniaczo podobne podejście, Extreme Programming (XP).  W kolejnych wersjach framework został odchudzony tak, żeby narzucać jak najmniej i pasować do różnych kontekstów użycia. Nie znajdziesz tutaj opisu konkretnego sposobu postępowania, żeby zbudować dobry produkt. Dlatego nie można powiedzieć, że jest to metoda, a tym bardziej metodyka czy metodologia. Więcej na temat metodyki Scrum napisałem w osobnym poście.

Po co Scrum? Jakie korzyści daje?

Wprowadzenie Scrum nie może być celem organizacji. Również wprowadzenie zwinnego myślenia i sposobu pracy (ang. Agile Mindset) nie może być celem. Transformacja do Agile czy transformacja cyfrowa to ciągły proces.

Każda organizacja powinna dążyć do osiągnięcia swoich celów strategicznych. Scrum może w tym pomóc. Scrum pokazuje efektywność praktyk w organizacji i wartość jej produktów. To powinny być istotne informacje dla kadry zarządzającej.

Możemy spodziewać się większego zaangażowania zespołów, lepszego zarządzania ryzykiem, lepszej efektywności wykorzystania budżetu, większego zadowolenia klientów, większej kreatywności itd.

Ogólnym celem wprowadzenia Scrum najczęściej jest osiągnięcie zwinności biznesowej. Warto mierzyć, czy szybkość reakcji na otoczenie faktycznie wzrasta i czy organizacja osiąga swoje cele.

Jak powinien wyglądać idealnie zaimplementowany Scrum dowiesz się z artykułu Idealny Świat Scrum.

Jeśli chcesz wiedzieć więcej, przeczytaj Scrum Guide i sięgnij po książkę Scrum i nie tylko. Teoria i praktyka metod Agile.
Lista  literatury zalecanej dla Scrum Mastera
Lista  literatury zalecanej dla Product Ownera.
Lista  literatury zalecanej dla Developera