Już niedługo ukaże się nowa edycja Scrum Guide. Są tacy, co już ogłaszają, co się zmieni, choć na razie marnie idzie im zrozumienie wersji obowiązującej od trzech lat. Ci mniej narwani zaczęli spekulować, że być może w końcu Scrum Guide rozstrzygnie jednoznacznie toczące się od lat „ważkie” dyskusje.

Czemu piszę „ważkie” w cudzysłowie? Odrobina nieskrywanego sarkazmu nigdy nie zaszkodzi, ale pisząc bardziej serio: większość debat, jakim oddają się ludzie „zajmujący się Scrumem” jest żałośnie rozbieżna z całą ideą Agile, a więc i samym Scrumem. Bo czy to naprawdę tak ważne, czy maksymalna długość sprintu to miesiąc kalendarzowy, czy raczej 30 dni (żeby już nie wspominać lutego i lat przestępnych)? Czy Scrum Master może być kierownikiem zespołu? A w ogóle to dopuszczalne jest bycie jednocześnie Scrum Masterem i Product Ownerem?

„Ważkie” problemy, nieprawdaż?

A przecież Scrum to framework – narzędzie do rozwiązywania problemów i uzyskiwania z tego korzyści. Daje podstawowe zasady i nic więcej, dlatego wymaga włączenia samodzielnego myślenia u tych, którzy Scruma używają. Muszą sami wypełnić ramy tej metody swoimi zasadami, kontekstem organizacji, środowiskiem pracy, definicją celów itd. Póki nie będzie sprzeczności między frameworkiem a tym, co do niego dokładamy, ma szansę dać korzyści.

Scrum Guide to nie recepta, instrukcja ani poradnik jak używać Scruma, tylko jego definicja. Nie pierze się ubrań specyfikacją pralki, ale pralką – wlewając do niej wodę i detergenty. Opis pralki nie wyjaśnia, czy czarne spodnie trzeba prać na „lewej stronie” ani nie instruuje, by z kieszeni polaru wyjąć klucze i drobne monety. Twórcy pralki zakładają, że użytkownik przed włączeniem urządzenia uruchomi myślenie. Dokładnie na tej samej zasadzie Scrum Guide nie jest Scrumem; Scrumem jest to, co robią zespoły, uzupełniając framework swoimi praktykami.

A jak ktoś desperacko potrzebuje takiej meta-instrukcji stosowania Scruma, to proszę:

Krok 1: Stwórz zespół zaangażowanych i kompetentnych ludzi, którzy będą dostarczać więcej wartości, niż kosztuje ich utrzymanie i daj im sensowny cel działania (Zespół Scrum).

Krok 2: Określ, kto z nich będzie decydował o tym, co należy zrobić, aby ten cel osiągnąć (Product Owner)

Krok 3: Aby upewnić się, że wszyscy wiedzą, co jest do zrobienia i w jakim kierunku zmierzamy, Product Owner spisze to w listę i będzie ją aktualizował, jak tylko coś się zmieni (Backlog Produktu).

Krok 4: W zespole oczywiście musza być osoby, które niezbędne rozwiązania zbudują (Developerzy), a żeby było jasne, co to znaczy „zrobione” i co tak naprawdę robią, stworzą listę tych kryteriów i czynności (Definicja Ukończenia).

Krok 5: Umawiamy się na długość iteracji, w jakich developerzy będą budować rozwiązania (Sprint) tak, żeby przynajmniej 12 razy w roku sprawdzić, czy to, co wytwarzają, ma wartość.

Krok 6: Każda iteracja zaczyna się od ustalenia przez zespół co będzie robione (Planowanie Sprintu), jaką to przyniesie korzyść (Cel Sprintu) i jak Developerzy chcą go osiągnąć.

Krok 7: Żeby na bieżąco organizować sobie robotę, Developerzy posługują się jakąś formą wizualizacji planów i postępów prac (Backlog Sprintu).

Krok 8: Codziennie Developerzy sprawdzają, jak idzie im praca i czy ustalony cel nadal jest osiągalny (Daily Scrum), a jeśli trzeba, zmieniają poczynione wcześniej plany.

Krok 9: Za każdym razem, jak uda się wytworzyć działający produkt, który spełnia kryteria Definicji Ukończenia (Przyrost), Product Owner decyduje, czy zostanie użyty, czy powinien być dalej rozwijany.

Krok 10: Na koniec iteracji zespół sprawdza z interesariuszami, czy to, czy powstało w iteracji, faktycznie przyniosło korzyść interesariuszom i ustala, co robić dalej (Przegląd Sprintu).

Krok 11: A żeby w kolejnej iteracji działać efektywniej, zespół ustala na jej zakończenie, co zmienić lub usprawnić w kolejnym Sprincie (Retrospekcja Sprintu).

Krok 12: I chociaż to wszystko brzmi prosto, często okaże się bardzo trudne, więc jedna osoba w zespole skupi się nie na ustalaniu, co warto robić, i nie na budowaniu produktu, ale na podniesieniu efektywności zespołu – usuwając problemy, ucząc jak używać Scruma, ujawniając braki przejrzystości i tak dalej (Scrum Master).

I tak naprawdę to cały Scrum, oskubany do absolutnego minimum. Wszystkie „niuanse”, o których dyskutujemy, tkwią w ludzkich umysłach, które nie potrafią uwolnić się od poszukiwania recept i instrukcji, zamiast na bazie kilku prostych zasad zdefiniować własny sposób działania.

Jakie ma znaczenie dla tych 12 kroków, czy ktoś będzie albo nie będzie kierownikiem kogoś innego? Albo czy będzie odpowiadał za więcej niż jedną z rzeczy, które trzeba zrobić? To kwestie mało istotne, o które potkniemy się dopiero wtedy, jeśli zapomnimy, po co zaczęliśmy stosować Scrum.

Gdy ktoś rozsądny chce użyć Scruma jako narzędzia do rozwiązania złożonego problemu, zadaje zupełnie inne pytania po przeczytaniu Scrum Guide (albo tej mojej krótkiej meta-instrukcji). Przykłady takich sensownych pytań to:

  • W czym może mi pomóc empiryzm?
  • Dlaczego to w ogóle działa?
  • Czy empiryczna kontrola procesu ma jakieś ograniczenia?
  • Jak mam dobrać długość iteracji tak, żeby w moim środowisku wciąż działać empirycznie?
  • Jak określić, co jest wartością?
  • Jak zdefiniować produkt?

Niestety takie pytania padają rzadko, a dyskusje o Scrumie (i ogólniej o Agile) skupione są nie na użyciu zwinnych metod z sensem, ale na „wdrożeniu Scruma” lub innego frameworku jako procesu. Gdzieś umyka w tym kluczowe pytanie: po co to robić i co nam to w ogóle da?

Zachęcam do traktowania Scrum Guide zgodnie z intencją twórców: jako definicji metody. A definicja ta, jak każda inna, ma tę paskudną cechę, że samemu trzeba wymyślić, jak zastosować ją w swoim środowisku z pożytkiem dla kogokolwiek. Żaden trener ani konsultant, ani żadna książka, nie zrobi tego za nas.

Zdjęcie: Alexander Milo