Dziś stawiam pytanie retoryczne: po co udawać pracę w Scrumie? Mam nadzieję, że skłonię Was do ciężkich i trudnych przemyśleń. Uwaga! Zanim do tego przejdziemy, będzie trochę narzekania.
O tempora, o mores, o Scrum
Większość osób, która miała okazję pracować w Scrumie, zawsze dodaje „ale nie był to podręcznikowy, czysty Scrum„. Pal sześć, jeśli były to po prostu warianty skalowane bądź rozszerzone o jakieś dedykowane elementy. Ale zwykle autorzy takich stwierdzeń mają na myśli po prostu Scrum-But. Fatalnie!
Jeszcze gorzej, że najczęściej mówiący o „udawaniu Scruma” mają na myśli to, że nie robią Sprint Review, a retro odbywa się co Sprint. Czyli mają na myśli tylko i wyłącznie techniczne aspekty metodyki. Zgodzę się, że jeśli już na etapie Wydarzeń, Ról i Artefaktów nie mamy kompletu elementów wymaganych przez Scrum Guide to jest źle, a nawet tragicznie. Ale to i tak jeszcze pół biedy.
Prawdziwe „udawanie Scruma” to stan umysłu. „User Stories analityczne” w Backlogu Produktu, który nawet nie jest ułożony w kolejności. Zamiast tego mamy po prostu priorytety. Oczywiście wszystko ma priorytet najwyższy, bo mamy harmonogram wynikający z umowy i wszystkie Sprinty zaplanowane z góry aż do końca projektu. Nic więc dziwnego, że mamy tam wymagania podzielone na „część 1” w jednym Sprincie i „część 2” w kolejnym. Oczywiście bez zdefiniowania jakiejkolwiek wartości biznesowej, która wynika z części pierwszej.
Tę tyradę można by kontynuować bez końca. Premiowanie zespołów za dowiezienie 100% zaplanowanych wymagań. Elementy Backlogu Produktu „techniczne” i „testowe”. Niepowiązane ze sobą wymagania, które nie wiedzieć czemu trafiają do realizacji. Brak Product Ownera bądź hydra productownerska mająca kilka, a czasami nawet kilkanaście głów. Absolutny brak możliwości negocjowania zakresu, bo „wszystko musi dojechać do terminu”, a co za tym idzie brak eksperymentowania i management pilnujący na planowaniu „czy wszyscy zaplanowali się na 100%”. I tak dalej, i tak dalej…
Taki FrankenScrum wcale nie jest zjawiskiem rzadkim. To ja bym jednak wolał, żeby już czasami zamiast retro odbyło się wyjście na piwo, niż żeby totalnie wywracać to, do czego Scrum został stworzony.
Po co Scrum?
Chcemy stworzyć bądź rozwijać jakiś produkt. Nie wiemy, które jego aspekty są najważniejsze, ale mamy pewne podejrzenia. Od nich zaczynamy pracę – każdy realizowany kawałek czemuś służy i dostarcza jakiejś wartości biznesowej. W miarę postępów prac optymalizujemy dwie rzeczy – sposób naszej pracy oraz wizję naszego produktu. Wymagania cały czas się zmieniają. Odkrywamy nowe, niektóre zyskują na priorytecie, a przy innych stwierdzamy, że „tyle nam wystarczy”. To jest właśnie Scrum.
W Scrumie nie ma miejsca na sztywną listę wymagań i długi harmonogram. Powtórzę to jeszcze raz: siłą Scruma jest to, że w trakcie pracy nad produktem dostrzegamy lepsze sposoby jego budowy oraz nowe wymagania, które przyniosą więcej korzyści niż te zidentyfikowane wcześniej. Backlog cały czas żyje, a Product Owner cały czas układa go w kolejności tak, aby zmaksymalizować dostarczaną wartość.
Broken Window Theory mówi, że rezygnując z pewnych zasad rozpoczniemy reakcję łańcuchową i przyspieszymy degradację całej metodyki. W kontekście omawianego dziś problemu jest jednak jeszcze gorzej.
Możemy działać zgodnie z wszystkimi zasadami opisanymi w Scrum Guide, a i tak mieć FrankenScruma, w którym mamy dokładnie zero korzyści ze zwinnej pracy, a mnóstwo upierdliwych rzeczy. Jakieś Sprinty, planowania, Review, Retro, a do tego jeszcze Daily i Refinementy. Po co to wszystko, skoro i tak dzień po planowaniu przyjdzie ktoś i każe nam rzucić wszystko i zacząć robić coś mega pilnego? Jakim cudem mamy realizować najbardziej wartościowe wymagania, jeżeli dostajemy po prostu zadania do wykonania bez żadnego uzasadnienia?
Udawanie Scruma
Na wstępie napisałem, że mam nadzieję skłonić Was do ciężkich i trudnych przemyśleń. Jeżeli macie myśli typu „Po co nam ten cały Scrum! Przecież to w ogóle do nas nie pasuje!” to opcje są tak naprawdę dwie. Można zaakceptować ten stan rzeczy i wybrać inną, bardziej dopasowaną metodykę. Druga droga jest o wiele trudniejsza – można zacząć bolesną transformację i postarać się jednak zacząć pracować scrumowo.
W większości przypadków będzie się to wiązało z koniecznością zaczęcia od początku, czyli od definicji produktu. Następy w kolejności będzie Cel Produktu, totalne przeorganizowanie backlogu, przejście z zadań na wymagania (które niosą wartość biznesową) i takie układanie pracy, żeby faktycznie co Sprint dowozić jakąś wartość.
Wydarzenia i artefakty ogarnie nam dobry Scrum Master. Techniczne aspekty Scruma to pestka. Gorzej z podstawami podstaw, czyli agile mindset i faktyczne wykorzystywanie Scruma, aby w danym momencie robić to, co przyniesie najwięcej korzyści. Tylko koniecznie trzeba pamiętać, że to się zmienia co moment i co dostarczony Przyrost.
O wiele łatwiej jest zacząć pracować porządnie od samego niż „uzwinniać Scrum”. Przynajmniej nie musimy walczyć ze złymi nawykami. Niestety, liczba projektów ze sztywnym harmonogramem i zakresem, które tylko udają Scrum jest ogromna. Mam nadzieję, że nie doświadczacie tego w chwili obecnej, ale jeśli tak jest – spróbujcie to zmienić. Jeśli nie Wy, to kto?
