Podstawy Scrum – Michał Moroz

Praktyczny podręcznik dla początkujących

Spis treści

Czym jest Scrum
Kiedy Scrum ma sens, a kiedy nie
Filary Scruma: przejrzystość, inspekcja i adaptacja
Wartości Scruma
Scrum Team
Product Owner
Scrum Master
Developers
Product Backlog
Sprint Backlog
Increment
Product Goal, Sprint Goal i Definition of Done
Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Przykład pracy zespołu Scrum krok po kroku
Najczęstsze błędy we wdrażaniu Scruma
Prosty plan wdrożenia Scruma w firmie

1. Czym jest Scrum

Scrum to sposób organizowania pracy zespołu, który tworzy produkt w warunkach niepewności. Nie jest szczegółową metodyką zarządzania projektem, nie jest listą procedur i nie jest systemem raportowania ludzi. Scrum jest ramą pracy, czyli szkieletem, który pomaga zespołowi regularnie planować, wykonywać, sprawdzać i poprawiać sposób działania.

Najprościej można powiedzieć:

Scrum pomaga zespołowi często dostarczać małe, wartościowe fragmenty produktu i uczyć się na podstawie informacji zwrotnej.

W tradycyjnym podejściu często próbuje się zaplanować cały projekt od początku do końca. Zakłada się, że wymagania są dobrze znane, zakres jest stabilny, a zespół może dokładnie przewidzieć, ile czasu zajmie całość. W praktyce, szczególnie w projektach IT, produkcyjnych, automatyzacyjnych i wdrożeniowych, bardzo często tak nie jest.

Klient zmienia zdanie.
Rynek się zmienia.
Użytkownicy dopiero po zobaczeniu pierwszej wersji wiedzą, czego naprawdę potrzebują.
Technologia okazuje się trudniejsza niż zakładano.
Część wymagań była źle zrozumiana.
Priorytety biznesowe zmieniają się w trakcie projektu.

Scrum nie udaje, że ta zmienność nie istnieje. Przeciwnie — przyjmuje ją jako normalną część pracy nad złożonym produktem.

2. Kiedy Scrum ma sens

Scrum najlepiej sprawdza się tam, gdzie:

cel jest znany, ale droga dojścia nie jest w pełni oczywista,
wymagania mogą się zmieniać,
potrzebna jest częsta informacja zwrotna,
produkt można rozwijać przyrostowo,
zespół potrzebuje regularnego rytmu pracy,
ważniejsze jest dostarczanie wartości niż samo wykonywanie planu.

Przykłady zastosowania Scruma:

tworzenie aplikacji internetowej,
rozwój systemu ERP, MES, WMS lub CRM,
wdrażanie nowego modułu oprogramowania,
rozwój produktu cyfrowego,
automatyzacja procesów biznesowych,
budowa platformy e-commerce,
rozwój usługi SaaS,
praca nad nową funkcjonalnością dla klientów.

Scrum może być stosowany także poza IT, ale trzeba uważać, aby nie robić tego mechanicznie. Jeżeli praca jest bardzo powtarzalna, prosta i przewidywalna, Scrum może być zbyt ciężki lub niepotrzebny. Jeżeli natomiast praca wymaga uczenia się, eksperymentowania i częstego podejmowania decyzji, Scrum może być bardzo pomocny.

3. Kiedy Scrum nie jest najlepszym wyborem

Scrum nie zawsze będzie dobrym rozwiązaniem.

Może nie mieć sensu, gdy:

praca jest w pełni powtarzalna i proceduralna,
nie ma zespołu, tylko pojedyncze osoby wykonujące niezależne zadania,
organizacja nie akceptuje zmiany priorytetów,
klient oczekuje sztywnego zakresu, terminu i budżetu bez miejsca na adaptację,
zespół nie ma wpływu na sposób wykonania pracy,
Scrum ma służyć tylko do kontroli pracowników.

Scrum nie naprawia automatycznie problemów organizacji. On je raczej ujawnia. Jeżeli firma ma chaos decyzyjny, brak właściciela produktu, sprzeczne priorytety i kulturę obwiniania, Scrum szybko pokaże te problemy. To może być bolesne, ale jest też bardzo wartościowe.

4. Empiryzm: fundament Scruma

Scrum opiera się na empiryzmie. Oznacza to, że decyzje podejmujemy na podstawie doświadczenia, obserwacji i faktów, a nie tylko na podstawie założeń.

W Scrumie nie zakładamy, że na początku wiemy wszystko. Zamiast tego pracujemy krótkimi cyklami, regularnie sprawdzamy efekty i dostosowujemy dalsze działania.

Trzy filary empiryzmu w Scrumie to:

Przejrzystość

Wszyscy powinni widzieć rzeczywisty stan pracy. Nie chodzi o tworzenie ładnych raportów, tylko o prawdziwy obraz sytuacji.

Przejrzystość oznacza, że wiadomo:

nad czym pracuje zespół,
jaki jest cel Sprintu,
co jest gotowe,
co nie jest gotowe,
jakie są przeszkody,
jakie decyzje trzeba podjąć.

Bez przejrzystości nie da się dobrze sprawdzać postępów.

Inspekcja

Inspekcja oznacza regularne sprawdzanie tego, co się dzieje.

Zespół sprawdza:

produkt,
postęp prac,
jakość,
sposób współpracy,
sens aktualnych priorytetów.

Inspekcja nie jest kontrolą ludzi. Jest sprawdzaniem rzeczywistości.

Adaptacja

Adaptacja oznacza zmianę działania na podstawie tego, czego się nauczyliśmy.

Jeżeli coś nie działa, trzeba to poprawić.
Jeżeli priorytety się zmieniły, trzeba dostosować plan.
Jeżeli użytkownicy inaczej korzystają z produktu, trzeba wyciągnąć wnioski.

Bez adaptacji Scrum staje się pustym rytuałem.

5. Wartości Scruma

Scrum Guide wymienia pięć wartości Scruma: zaangażowanie, skupienie, otwartość, szacunek i odwagę. Wartości te mają kierować zachowaniem Scrum Teamu i wspierać przejrzystość, inspekcję oraz adaptację. (Scrum Guides)

Zaangażowanie

Zespół zobowiązuje się do osiągania celów i wspierania siebie nawzajem. Nie chodzi o ślepe obiecywanie nierealnych terminów. Chodzi o odpowiedzialne podejście do wspólnego celu.

Skupienie

W Scrumie zespół powinien skupiać się na celu Sprintu. To bardzo ważne, ponieważ w wielu organizacjach zespoły są rozpraszane przez dziesiątki pobocznych tematów.

Skupienie oznacza:
„W tym Sprincie najważniejsze jest to. Na tym koncentrujemy energię.”

Otwartość

Zespół powinien otwarcie mówić o postępach, problemach, ryzykach i ograniczeniach. Bez otwartości Scrum zamienia się w teatr, w którym wszyscy udają, że wszystko idzie dobrze.

Szacunek

Członkowie zespołu traktują się jak kompetentni profesjonaliści. Szacunek nie oznacza braku trudnych rozmów. Oznacza prowadzenie ich bez poniżania, agresji i obwiniania.

Odwaga

Odwaga jest potrzebna, aby mówić prawdę, kwestionować złe decyzje, przyznawać się do problemów i proponować zmiany.

W Scrumie odwaga jest szczególnie ważna, ponieważ przejrzystość często pokazuje rzeczy niewygodne.

6. Scrum Team

Podstawową jednostką Scruma jest Scrum Team. Składa się on z jednej osoby pełniącej odpowiedzialność Product Ownera, jednej osoby pełniącej odpowiedzialność Scrum Mastera oraz Developers. W Scrum Teamie nie ma podzespołów ani hierarchii wewnętrznej; jest to spójna grupa profesjonalistów skupiona na jednym celu produktu. (Scrum Guides)

Scrum Team powinien być:

mały,
interdyscyplinarny,
samozarządzający,
odpowiedzialny za dostarczanie wartości,
zdolny do tworzenia użytecznego przyrostu produktu.

W praktyce oznacza to, że zespół powinien mieć wszystkie kompetencje potrzebne do wykonania pracy. Jeżeli zespół stale czeka na decyzje, analizy, testy, wdrożenia lub akceptacje z zewnątrz, jego zdolność do pracy w Scrumie jest ograniczona.

7. Product Owner

Product Owner odpowiada za maksymalizację wartości produktu wynikającej z pracy Scrum Teamu. To osoba, która dba o kierunek rozwoju produktu i zarządza Product Backlogiem.

Product Owner odpowiada za:

wizję produktu,
Product Goal,
kolejność elementów w Product Backlogu,
jasność wymagań,
kontakt z interesariuszami,
podejmowanie decyzji produktowych,
maksymalizację wartości.

Product Owner nie powinien być tylko „sekretarzem wymagań” ani osobą przepisującą życzenia klientów do listy zadań. Jego zadaniem jest podejmowanie decyzji: co jest najważniejsze, co daje największą wartość, co można odłożyć, a czego nie warto robić.

Dobry Product Owner umie powiedzieć „nie”.
Dobry Product Owner rozumie biznes.
Dobry Product Owner potrafi rozmawiać z klientami i zespołem technicznym.
Dobry Product Owner nie zmienia priorytetów codziennie bez powodu.

8. Scrum Master

Scrum Master odpowiada za skuteczność Scruma. Pomaga zespołowi, Product Ownerowi i organizacji rozumieć oraz stosować Scrum.

Scrum Master nie jest kierownikiem zespołu. Nie rozdziela zadań, nie pilnuje ludzi jak nadzorca i nie jest osobą od „prowadzenia spotkań” w sensie administracyjnym.

Scrum Master pomaga:

usuwać przeszkody,
usprawniać współpracę,
chronić zespół przed chaosem,
uczyć organizację Scruma,
wspierać Product Ownera,
dbać o sens wydarzeń Scrumowych,
rozwijać samozarządzanie zespołu.

Dobry Scrum Master nie pyta tylko:
„Czy Daily się odbyło?”

Pyta raczej:
„Czy Daily pomaga zespołowi osiągnąć Cel Sprintu?”
„Czy Sprint Review daje realną informację zwrotną?”
„Czy Retrospektywa prowadzi do konkretnych usprawnień?”
„Czy Product Backlog jest przejrzysty?”
„Czy zespół ma warunki do pracy?”

9. Developers

Developers to osoby w Scrum Teamie, które tworzą przyrost produktu. W IT będą to zwykle programiści, testerzy, analitycy, UX designerzy, DevOps, konsultanci techniczni lub inne osoby wykonujące pracę potrzebną do dostarczenia produktu.

Nazwa „Developers” nie oznacza wyłącznie programistów. Chodzi o ludzi, którzy rozwijają produkt.

Developers odpowiadają za:

planowanie pracy w Sprincie,
tworzenie Sprint Backlogu,
dostarczanie jakościowego Incrementu,
przestrzeganie Definition of Done,
codzienną adaptację planu,
techniczny sposób wykonania pracy.

W dobrze działającym Scrumie Developers nie czekają, aż ktoś rozdzieli im zadania. Sami organizują pracę tak, aby osiągnąć Cel Sprintu.

10. Artefakty Scruma

Scrum ma trzy główne artefakty:

Product Backlog
Sprint Backlog
Increment

Każdy artefakt zwiększa przejrzystość pracy. Każdy ma też powiązane zobowiązanie: Product Backlog ma Product Goal, Sprint Backlog ma Sprint Goal, a Increment ma Definition of Done. Koncepcja Product Goal została dodana w Scrum Guide 2020, aby Scrum Team skupiał się na większym, wartościowym zamierzeniu produktu. (AgileAdept.pl)

11. Product Backlog

Product Backlog to uporządkowana lista tego, co może być potrzebne w produkcie.

Może zawierać:

funkcje,
poprawki,
usprawnienia,
wymagania techniczne,
błędy,
eksperymenty,
prace badawcze,
zmiany wynikające z informacji zwrotnej.

Product Backlog nigdy nie jest „ostatecznie zamknięty”. Zmienia się wraz z rozwojem produktu, wiedzą zespołu, potrzebami klientów i sytuacją biznesową.

Najważniejsze elementy powinny być najlepiej opisane, ponieważ prawdopodobnie będą realizowane najwcześniej. Elementy dalsze mogą być mniej szczegółowe.

12. Sprint Backlog

Sprint Backlog to plan pracy na Sprint.

Zawiera:

Sprint Goal,
wybrane elementy Product Backlogu,
plan ich realizacji.

Sprint Backlog należy do Developers. To oni codziennie aktualizują plan, aby zwiększyć szanse osiągnięcia Celu Sprintu.

Ważne: Sprint Backlog nie jest zamrożoną listą zadań. Może się zmieniać w trakcie Sprintu, o ile zmiany pomagają osiągnąć Cel Sprintu.

13. Increment

Increment to gotowy, użyteczny fragment produktu powstały w trakcie Sprintu.

Increment powinien spełniać Definition of Done. To znaczy, że nie jest „prawie gotowy”, „do testów”, „do akceptacji kiedyś później”. Jest wykonany zgodnie z ustalonym standardem jakości.

W idealnej sytuacji Increment może być wydany użytkownikom. Nie zawsze musi być natychmiast wydany, ale powinien być w stanie nadającym się do użycia.

14. Product Goal, Sprint Goal i Definition of Done

Product Goal

Product Goal opisuje większy cel produktu. To kierunek, do którego zmierza Scrum Team.

Przykład:

„Uruchomić platformę B2B, która pozwoli klientom samodzielnie składać zamówienia i sprawdzać status realizacji.”

Albo:

„Stworzyć moduł planowania produkcji, który pozwoli firmie układać harmonogram zleceń na podstawie dostępności maszyn i pracowników.”

Sprint Goal

Sprint Goal to cel konkretnego Sprintu.

Dobry Sprint Goal nie brzmi:

„Zrobić zadania 1, 2, 3, 4 i 5.”

Lepszy Sprint Goal:

„Umożliwić klientowi złożenie podstawowego zamówienia przez panel B2B.”

Sprint Goal daje zespołowi sens i kierunek. Pomaga podejmować decyzje, gdy pojawiają się problemy.

Definition of Done

Definition of Done to wspólne rozumienie tego, kiedy praca jest naprawdę ukończona.

Przykład Definition of Done dla zespołu IT:

kod został napisany,
kod przeszedł review,
testy automatyczne przechodzą,
funkcja została przetestowana,
dokumentacja została uzupełniona,
nie ma znanych błędów krytycznych,
funkcja jest zintegrowana z główną wersją produktu.

Bez Definition of Done zespół może myśleć, że coś jest gotowe, podczas gdy w rzeczywistości wymaga jeszcze wielu dni pracy.

15. Sprint

Sprint to podstawowy cykl pracy w Scrumie. Trwa maksymalnie miesiąc. W praktyce często stosuje się Sprinty jedno- lub dwutygodniowe.

W trakcie Sprintu zespół pracuje nad osiągnięciem Sprint Goal i dostarczeniem Incrementu.

Sprint zawiera wszystkie wydarzenia Scrumowe:

Sprint Planning,
Daily Scrum,
Sprint Review,
Sprint Retrospective.

Sprint daje zespołowi rytm. Dzięki temu praca nie jest chaotycznym ciągiem zadań, ale uporządkowanym cyklem planowania, wykonania, sprawdzania i poprawy.

16. Sprint Planning

Sprint Planning rozpoczyna Sprint.

Podczas Sprint Planningu zespół odpowiada na trzy pytania:

Dlaczego ten Sprint jest wartościowy?
Co można zrobić w tym Sprincie?
Jak wybrana praca zostanie wykonana?

W Scrum Guide 2020 mocniej podkreślono pytanie „po co”, czyli związek Sprint Planningu z Celem Sprintu. (AgileAdept.pl)

Efektem Sprint Planningu jest Sprint Backlog.

Typowy przebieg Sprint Planningu:

Product Owner przedstawia najważniejsze elementy Product Backlogu.
Zespół rozmawia o celu Sprintu.
Developers oceniają, ile pracy są w stanie podjąć.
Zespół wybiera elementy do Sprintu.
Developers tworzą wstępny plan realizacji.
Scrum Team uzgadnia Sprint Goal.

17. Daily Scrum

Daily Scrum to krótkie, codzienne wydarzenie dla Developers. Trwa maksymalnie 15 minut.

Celem Daily Scrum nie jest raportowanie Scrum Masterowi. Celem jest sprawdzenie postępu wobec Sprint Goal i dostosowanie planu na najbliższy dzień.

Dobre Daily koncentruje się na pytaniu:

Co musimy dziś ustalić, żeby zwiększyć szanse osiągnięcia Celu Sprintu?

Złe Daily wygląda tak:

każdy raportuje status,
nikt nikogo nie słucha,
Scrum Master odpytuje ludzi,
problemy nie są rozwiązywane,
spotkanie trwa za długo,
zespół nie aktualizuje planu.

Daily powinno pomagać zespołowi, a nie być codzienną kontrolą obecności.

18. Sprint Review

Sprint Review odbywa się pod koniec Sprintu. Jego celem jest sprawdzenie wyniku pracy i zebranie informacji zwrotnej.

To nie jest tylko „demo”. To rozmowa o produkcie.

Podczas Sprint Review:

zespół pokazuje, co powstało,
interesariusze przekazują informację zwrotną,
omawiane są zmiany w otoczeniu biznesowym,
Product Backlog może zostać dostosowany,
zespół i interesariusze rozmawiają o kolejnych krokach.

Dobre Sprint Review pomaga odpowiedzieć na pytanie:

Czy idziemy w dobrym kierunku?

19. Sprint Retrospective

Sprint Retrospective kończy Sprint. To wydarzenie, podczas którego Scrum Team analizuje sposób swojej pracy i planuje usprawnienia.

Retrospektywa dotyczy między innymi:

współpracy,
komunikacji,
jakości,
narzędzi,
procesów,
przeszkód,
relacji z interesariuszami,
Definition of Done.

Dobra retrospektywa kończy się konkretnymi działaniami usprawniającymi.

Przykłady:

„Od następnego Sprintu robimy code review najpóźniej dzień po zgłoszeniu.”
„Product Owner przygotuje elementy Backlogu minimum dwa dni przed Planningiem.”
„Dodajemy do Definition of Done test migracji danych.”
„Ograniczamy liczbę równoległych zadań w toku.”

Retrospektywa bez działań jest tylko rozmową. Scrum wymaga adaptacji.

20. Przykład Scruma w praktyce

Załóżmy, że firma tworzy system do obsługi produkcji.

Product Goal:

„Stworzyć moduł, który pozwoli planować i monitorować zlecenia produkcyjne od przyjęcia zamówienia do zakończenia produkcji.”

Product Backlog zawiera między innymi:

rejestr zleceń produkcyjnych,
kartę zlecenia,
listę operacji technologicznych,
przypisywanie operacji do stanowisk,
statusy realizacji,
rejestrację rozpoczęcia i zakończenia operacji,
raport braków,
widok obciążenia stanowisk,
integrację z Subiektem,
podstawowy panel kierownika produkcji.

Sprint 1 może mieć Sprint Goal:

„Umożliwić utworzenie i przeglądanie podstawowego zlecenia produkcyjnego.”

Zespół wybiera do Sprintu:

formularz dodawania zlecenia,
listę zleceń,
szczegóły zlecenia,
podstawowe statusy,
zapis do bazy danych.

Na Sprint Review zespół pokazuje działający fragment systemu. Kierownik produkcji zauważa, że potrzebne jest dodatkowe pole „priorytet zlecenia”. Product Owner aktualizuje Product Backlog.

Na Retrospektywie zespół zauważa, że wymagania były zbyt ogólne. Ustala, że przed kolejnym Sprint Planningiem Product Owner przygotuje przykładowe scenariusze użycia.

Sprint 2 może mieć Sprint Goal:

„Umożliwić opisanie zlecenia przez operacje technologiczne.”

W ten sposób produkt rośnie krok po kroku, a zespół regularnie uczy się na podstawie realnych efektów.

21. Najczęstsze błędy we wdrażaniu Scruma

Błąd 1: Scrum jako mikrozarządzanie

Scrum nie służy do codziennego odpytywania ludzi z pracy. Daily Scrum nie jest raportem dla kierownika.

Błąd 2: Brak prawdziwego Product Ownera

Jeżeli nikt nie podejmuje decyzji produktowych, Product Backlog staje się listą życzeń wszystkich interesariuszy.

Błąd 3: Brak Definition of Done

Bez Definition of Done zespół dostarcza prace „prawie gotowe”, które później generują dług techniczny i chaos.

Błąd 4: Zbyt duże Sprinty

Jeżeli Sprint trwa zbyt długo, zespół rzadziej otrzymuje informację zwrotną. Krótszy Sprint zwykle szybciej ujawnia problemy.

Błąd 5: Brak Sprint Goal

Bez Sprint Goal Sprint staje się przypadkowym zbiorem zadań.

Błąd 6: Retrospektywy bez efektów

Jeżeli po retrospektywie nic się nie zmienia, zespół szybko przestaje traktować ją poważnie.

Błąd 7: Mylenie Scruma z Agile

Agile to szersza filozofia pracy zwinnej. Scrum jest konkretną ramą pracy. Można być Agile bez Scruma, ale Scrum powinien realizować zasady zwinności.

22. Prosty plan wdrożenia Scruma w firmie

Krok 1: Wybierz produkt

Nie zaczynaj od całej organizacji. Wybierz jeden produkt, moduł lub obszar pracy.

Krok 2: Zbuduj Scrum Team

Określ:

kto jest Product Ownerem,
kto jest Scrum Masterem,
kto należy do Developers,
czy zespół ma kompetencje do dostarczania produktu.

Krok 3: Ustal Product Goal

Zespół powinien wiedzieć, do czego zmierza.

Krok 4: Utwórz pierwszy Product Backlog

Nie musi być idealny. Ważne, aby zawierał najważniejsze potrzeby produktu.

Krok 5: Ustal Definition of Done

Bez tego trudno mówić o jakości i gotowym przyroście.

Krok 6: Uruchom pierwszy Sprint

Zrób Sprint Planning, pracuj codziennie nad celem, pokaż efekt na Sprint Review i przeprowadź Retrospektywę.

Krok 7: Poprawiaj proces co Sprint

Scrum nie polega na tym, że od razu wszystko działa idealnie. Scrum polega na regularnym uczeniu się i poprawianiu.

23. Minimalna ściąga Scrum

Scrum Team

Product Owner — odpowiada za wartość i Product Backlog.
Scrum Master — odpowiada za skuteczność Scruma.
Developers — tworzą gotowy Increment.

Artefakty

Product Backlog — lista tego, co może być potrzebne w produkcie.
Sprint Backlog — plan pracy na Sprint.
Increment — gotowy przyrost produktu.

Zobowiązania

Product Goal — cel produktu.
Sprint Goal — cel Sprintu.
Definition of Done — kryterium ukończenia.

Wydarzenia

Sprint — cykl pracy.
Sprint Planning — planowanie Sprintu.
Daily Scrum — codzienna inspekcja postępu.
Sprint Review — przegląd produktu i informacja zwrotna.
Sprint Retrospective — usprawnianie sposobu pracy.

24. Podsumowanie

Scrum jest prosty do opisania, ale trudny do dobrego stosowania. Jego siła nie polega na spotkaniach, tablicach ani nazwach ról. Siła Scruma polega na regularnym dostarczaniu wartości, przejrzystości pracy, częstej informacji zwrotnej i gotowości do adaptacji.

Dobrze wdrożony Scrum pomaga zespołowi:

lepiej rozumieć cel,
szybciej dostarczać wartość,
wcześniej wykrywać problemy,
poprawiać jakość,
ograniczać chaos,
lepiej współpracować z biznesem,
uczyć się z każdego Sprintu.

Źle wdrożony Scrum staje się tylko zestawem spotkań i nazw. Dlatego najważniejsze pytanie nie brzmi:
„Czy robimy Daily, Planning i Review?”

Najważniejsze pytanie brzmi:

Czy dzięki Scrumowi częściej dostarczamy wartość, szybciej się uczymy i lepiej adaptujemy do rzeczywistości?