Już niedługo ukaże się nowa edycja Scrum Guide. Są tacy, którzy 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 cztery tygodnie, 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 czy 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 przez tych, którzy go 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ładają, mają szansę uzyskać wymierne 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 jeśli ktoś desperacko potrzebuje takiej metainstrukcji stosowania Scruma, to proszę, oto ona:
Krok 1: Stwórz Zespół zaangażowanych i kompetentnych ludzi (Zespół Scrum), którzy będą dostarczać więcej wartości, niż kosztuje ich utrzymanie.
Krok 2: Określ, kto będzie decydował o tym, co należy zrobić (Product Owner), aby powstał wartościowy produkt.
Krok 3: Aby zapewnić przejrzystość planów rozwoju produktu, Product Owner musi określić cel, do którego będzie zmierzał wraz z Zespołem (Cel Produktu) oraz listę rzeczy, które należy wytworzyć, by cel ten osiągnąć (Backlog Produktu).
Krok 4: W Zespole oczywiście muszą być osoby, które mają kompetencje niezbędne do zbudowania produktu (Developerzy), a żeby nie było wątpliwości, co już zostało zrobione, Zespół ustala listę warunków, których spełnienie o tym rozstrzyga (Definicja Ukończenia).
Krok 5: Ustalamy długość iteracji, w jakich Zespół budować będzie produkt (Sprint) tak, żeby przynajmniej 12 razy w roku sprawdzić, czy to, co powstaje, ma faktycznie wartość dla interesariuszy.
Krok 6: Każda iteracja zaczyna się (Planowanie Sprintu) od ustalenia przez Zespół prognozy tego, co zostanie zrobione, jaką to przyniesie korzyść interesariuszom (Cel Sprintu) i w jaki sposób Developerzy chcą to osiągnąć.
Krok 7: Żeby na bieżąco organizować swoją pracę, Developerzy posługują się jakąś formą wizualizacji planów i postępów prac nad osiąganiem Celu Sprintu (Backlog Sprintu).
Krok 8: Codziennie Developerzy sprawdzają postęp prac, upewniają się, że Cel Sprintu nie jest zagrożony, a jeśli to konieczne, zmieniają poczynione wcześniej plany działania (Daily Scrum).
Krok 9: Za każdym razem, gdy uda się wytworzyć działający produkt, który spełnia kryteria ujęte w Definicji Ukończenia (Przyrost), Zespół może – ale nie musi – zdecydować o udostępnieniu rozwiązania interesariuszom, by z niego korzystali.
Krok 10: Na koniec iteracji Zespół sprawdza z interesariuszami, czy to, co udało się wytworzyć, przyniosło korzyści, a następnie ustala, co w związku z tym należy 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 okazuje się bardzo trudne, więc jedna osoba w Zespole bierze na siebie odpowiedzialność za dbanie o skuteczność 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 „ważkie problemy”, o jakich dyskutujemy bezproduktywnie, tkwią w umysłach ludzi, którzy poszukują gotowych recept i instrukcji, zamiast na podstawie prostych zasad zdefiniować i ewolucyjnie udoskonalić własny sposób działania.
Jakie ma znaczenie dla tych 12 kroków powyżej, czy ktoś będzie albo nie będzie kierownikiem kogoś innego w Zespole? 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.
Ktoś rozsądny, chcący użyć Scruma jako narzędzia do rozwiązania złożonego problemu, skupi się na zupełnie innych pytaniach:
- W czym może mi pomóc empiryzm?
- Dlaczego to w ogóle działa i czy faktycznie może zadziałać u mnie?
- 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 w sposób mechanistyczny. 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, konsultant ani nawet żadna książka nie zrobi tego za nas.