SCRUM – CO TO? ZASTOSOWANIA METODY? JAK ZACZĄĆ?

BUDOWA SCRUMA

Zacznijmy od problemu – coś co chcemy rozwiązać/ dostarczyć/ usprawnić. Efektem naszej pracy będzie więc pewien produkt, który w naszym zamyśle rozwiązuje wskazany problem.

Wśród zespołu jest osoba, która pełni szczególną odpowiedzialność – wskazuje kierunek prac – to Product Owner. To on(a) decyduje nad czym będzie pracował zespół Scrum Team. Robi to w oparciu o swoją wiedzę, informacje z zespołu, klientów i interesariuszy. 

Z reguły nasz problem i jego rozwiązanie to duży temat. Składa się z wielu funkcji, mniejszych problemów do rozwiązania, jest tam też mnóstwo znaków zapytania. Realizacja może zająć wiele tygodni czy miesięcy. Zamiast pamiętać o wszystkim co jest do zrobienia, zespół używa narzędzia – to uporządkowana lista wymagań nazywana Product Backlogiem. Product Owner, poprzez określenie kolejności elementów na tej liście, pokazuje wszystkim zainteresowanym nad czym będzie pracował zespół w dalszej kolejności. Product Backlog składa się z elementów. Realizacja każdego z nich ma dostarczyć nową wartość w produkcie.

Product Backlog to miejsce na pomysły i jedyne źródło pracy zespołu. Z pomysłami jest tak, że lubią się mnożyć 😎. To dobra rzeczy, gorzej gdy pomysły są ze sobą sprzeczne. Wtedy trudniej o współpracę. Aby zapewnić zrozumienie dokąd idzemy, Product Owner dba o ustanowienie Celu Produktu – azymut prac. Czasem to kierunek na kilka tygodni a czasem miesięcy. Wtedy każdy Sprint, niczym kolejny checkpoint, przybliża nas do osiągnięcia mety.

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

Każdy Sprint to okazja na dostarczenie czegoś naprawdę wartościowego. Aby utrzymać skupienie, gdy startuje nowy cykl, zespół wskazuje sobie kolejny cel do osiągnięcia – to Cel Sprintu. Aby osiągnąć cel, potrzebny jest jeszcze plan jego realizacji. Stworzenie planu wymaga trochę czasu. Członkowie zespołu spotykają się na Sprint Planningu. Product Owner wskazuje swoje pomysły na Sprint. A pozostali zastanawiają się jak je zrealizować. Zdarza się, że oryginalny pomysł musi ulec zmianie, np. trzeba go podzielić na mniejsze elementy. Członkowie zespołu opracowują pomysł na realizację. Plan można uznać za dobry gdy składa się z 3 rzeczy: a) zdefiniowaliśmy razem cel, b) wiem jak chcemy go zrealizować (które elementy z Product Backlogu będziemy realizować by osiągnąć cel) oraz c) mamy pomysł na wykonanie prac (np. kto, co i kiedy będzie robił).

Ten plan określany jest jako Sprint Backlog. Im bardziej widoczny, tym lepiej. Łatwiej reagować na problemy gdy możemy szybko zobaczyć, że nasz plan przestaje działać. Plan tworzony jest przez tych członków 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 czasowym Sprintu. Ci, którzy wytwarzają produkt nazywani są Deweloperami. Tylko Deweloperzy zarządzają Sprint Backlogiem. Nic w planie nie ulega zmianom bez ich decyzji. To bardzo ważne, ponieważ w ten sposób, Deweloperzy mogą wziąć odpowiedzialność za wyniki swojej pracy.

A z planami jak to z planami – potrafią się zmieniać i rozsypywać. Zespół o tym wie i dlatego każdego dnia członkowie zespołu weryfikują aktualność Sprint Backlogu oraz dokonują w nim niezbędnych korekt. Dzieje się to podczas krótkiego, 15- minutowego spotkania – Daily Scrum. To idealne miejsce by ocenić postęp, wskazać pozostałym zagrożenia w realizacji Celu Sprintu oraz stworzyć plan na następne 24h. 1 dzień to z jednej strony mało – jeśli okaże się, że pomyliliśmy się – straciliśmy tylko 1 dzień. I jest to jednocześnie dużo by ocenić czy idziemy w dobrą stronę.

Kiedy grupa osób pracuje nad czymś razem, łatwo zgubić wspólne rozumienie wykonania pracy: “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ół wykorzystuje standardy – Definicję Ukończenia (Done) – która niczym checklista pomaga zespołowi pamiętać o wykonaniu wszystkich niezbędnych kroków. Tak by każda funkcjonalnośc przechodziła te same kryteria jakościowe produktu.

Gdy zespół pracuje, interesariusze nie śpią. Robią biznes: kupują, sprzedają, reklamują itp. Wiedzą, że zmieniło się otoczenie problemu nad którym pracuje zespół. Dlatego pod koniec Sprintu zespół wraz z interesariuszami spotykają się na Sprint Review. Zespół prezentuje wyniki swojej 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 – to nie ma wartości. Interesariusze poznają nowy produkt i oceniają jego wartość. Dzielą się swoimi pomysłami i informacjami z swojego świata. Dzięki temu zespół dowiaduje się co nowego w trawie piszczy (bo na co dzień może nie mieć czasu – skupiają się nad tworzeniem Incrementu). Product Owner prezentuje Product Backlog i swoje pomysły na następne Sprinty. Wszyscy zebrani wymieniają się pomysłami – co zespół powinien robić w dalszej kolejności? co dostarczy najwięcej wartości? Product Owner podejmuje ostateczną decyzję czy i jak nowe pomysły wpływają na dalszą kolejność prac. Efektem tej decyzji jest modyfikacja Product Backlogu.

Dostarczone w Sprincie Incrementy nie kończą pracy zespołu. Tak jak profesjonalny zespół po meczu piłki nożnej czy siatkówki, również Scrum Team ma dużo przemyśleń na temat swoich wyników i sposobu pracy. Sprint Retrospective to ostatni element Sprintu. To tu następuje ocena stosowanych przez zespół praktyk: co pomaga, co przeszkadza, co działa a co nie. Efektem jest plan na usprawnienia w kolejnych Sprintach. Po Sprint 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 zadbanie o to by zespół stosował Scruma zgodnie z jego przeznaczeniem.

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

Według nas- bardzo! Kilka przykładów:

Product Backlog – to uporządkowana lista tego co należy zrobić w produkcie. Lista jest uporządkowana według wartości. To co na górze, powstaje jako pierwsze. Jeśli dostarczysz Increment, a klienci mają WTF? to już wiesz, że coś jest nie tak z wybranym kierunkiem prac. Przyznasz, że lepiej dowiedzieć się wcześniej niż później, prawda? Dodatkowo, bardzo często okazuje się, że początkowe pomysły, zanim dojdziemy do ich realizacji, dezaktualizują się. Odkrycie, że czegoś już nie trzeba robić – to solidna wiedza! W międzyczasie rodzą się nowe pomysły. Dodane do Product Backlogu, zostaną zrealizowane zgodnie z ich wartością. Pracując w oparciu o Product Backlog, Scrum Team uczy się klienta, jego potrzeb.

Sprint Backlog – to plan na Sprint. Wczoraj wydawał się świetny, dziś, gdy wgryźliśmy się w temat, okazuję się, że trzeba plan zmienić. Coś miało zająć 3 dni a zajmuje 5. Jeśli takich zadań w backlogu jest więcej, to mamy solidne podstawy by przekalkulować nasze plany. Być może skończymy dużo później! Lepiej wiedzieć o tym wcześniej, prawda?

Increment – klient zobaczył wyniki naszych prac i nie rozumie jak produkt działa – to bolesna, lecz cenna lekcja. Pomyśl o Incremencie jak o prezencie, opakowanie może być super ładne, ale jak zajrzysz do środka to dopiero będziesz wiedział czy Ci się podoba. Scrum Team dostarcza co Sprint prezenty. Wiadomo, że chcielibyśmy żeby były najlepsze, najpiękniejsze i najbardziej wartościowe. Na koniec dnia, to klient decyduje co mu się podoba. Patrzymy na reakcję klienta (dane, metryki, feedback) i decydujemy co mu 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ą w czasie pracy zespołu, by takie wyjazdy jak Heńka 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 deweloperów. Jak decydować o sposobie realizacji pracy by była zgodna ze sztuką i podatna na ciągłe zmiany? Jeśli interesujesz się sportami zespołowymi, to wiesz, że posiadanie gwiazd zespołu nie czyni. To wymaga czasu, wiedzy, poznania swoich mocnych i słabych stron. Czyli wiedzy:) Scrum daje nam tę możliwość w każdym Sprincie, wymaga od nas też systematyczności – po każdym Sprincie, zatrzymajcie się i popatrzcie co możecie robić inaczej, lepiej, sprawniej, co działa a co nie.

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 metodyka Scrum zyskała ogromną popularność, stając się jednym z filarów filozofii Agile.

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

Zombie Scrum to zjawisko, które pojawia się, gdy zespół stosuje Scruma „na papierze”, ale w rzeczywistości nie realizuje jego zasad. Objawy Zombie Scruma?

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

Aby uniknąć Zombie Scruma, warto zacząć do podstaw:

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

JAK ZACZĄĆ UCZYĆ SIĘ SCRUMA?

Scrum jest niby prosty, ale mimo wszystko trudny do opanowania. Oto kilka kroków, które pomogą Ci zacząć:

1. Przeczytaj Scrum Guide – To podstawa!
2. Zapisz się na kurs online – Możesz znaleźć wiele kursów, zarówno darmowych, jak i płatnych.
3. Ćwicz w praktyce – Jeśli pracujesz w zespole, spróbuj wdrożyć zasady Scruma.
4. Zdobywaj certyfikaty – Na przykład Professional Scrum Master (PSM) lub Certified ScrumMaster (CSM). W ten sposób sprawdzisz swoje rozumienie Scruma.
5. Dołącz do społeczności – Fora internetowe, grupy na LinkedIn czy meetupy to świetne miejsca do wymiany doświadczeń. Nasz newsletter znajdziesz tutaj.