Pierwszy dzień w pracy Scrum Mastera bądź Agile Coacha. Zapoznanie z zespołami i horror. Nic nie jest tak, jak być powinno. Zupełnie nic. Od czego zacząć? Za co się zabrać w pierwszej kolejności? A może… uciekać?
Problemy z Twoim Scrumem
Bądźmy szczerzy, prawie nigdzie nie ma idealnego, podręcznikowego Scruma. Co prawda mieliśmy szczęście widzieć i tworzyć miejsca, gdzie jest „książkowo”, ale nie ma ich wiele. Zwykle mamy do czynienia z jakimiś modyfikacjami. Czasami mają one sens i wynikają z lokalnych uwarunkowań, np. ze skalowania Scrum. Innym razem są to typowe ScrumButy, z którymi chcemy walczyć.
W tekście o oczekiwaniach do roli Scrum Mastera pisałem, że jeśli obiecano nam podręcznikowy Scrum, a okazuje się, że trzydziestoosobowe zespoły pracują w dwumiesięcznych „Sprintach„, a „Inspekcja i Adaptacja” kojarzy się wszystkim tylko z jakimś środkiem do czyszczenia podłóg, to faktycznie może lepiej się wycofać. Ale zdarzają się też Scrum Masterzy i Agile Coache, którzy lubią wyzwania.
Najczęstszą przyczyną scrumowej katastrofy jest po prostu niezrozumienie metodyki. Szczególnie po ostatnich zmianach w Scrum Guide 2020 podejrzewamy, że wiele osób przeczyta te kilkanaście stron i zacznie je stosować po swojemu. I przeważnie zacznie je dostosowywać do tego, jak dana organizacja pracowała wcześniej. A więc projektowo, hierarchicznie, z silnymi elementami kontroli. Takie podejście nie pasuje do Scruma, więc niepasujące elementy jak np. refinement, retro, Scrum Master) zostaną odrzucone.
Czasami z kolei wyjdzie nam Zombie Scrum, gdzie na pierwszy rzut oka wszystko dzieje się tak, jak powinno, ale jednak coś jest nie tak. To „coś”, to w tym przypadku mechaniczne wykonywanie zaleceń Scrum Guide’a, bez refleksji. Inspekcja bez adaptacji, Backlog Produktu bez priorytetyzacji, Product Owner bez umocowania i tak dalej. Niby wszystko jest, ale jak się przyjrzymy bliżej, to są tylko fasada.
Czy warto zacząć od wydarzeń?
„Na każdy tytuł/nagłówek, który kończy się znakiem zapytania można odpowiedzieć 'nie’.” – Prawo nagłówków Betteridge’a
Nie, nie warto zaczynać „naprawiania Scruma” od wydarzeń. Z bardzo prostego powodu, który nazywa się Ceremonie Scrum. Jeżeli nie wiemy po co coś robimy, będziemy robić to mechanicznie i wcale nie będzie nam zależało na osiągnięciu odpowiedniego celu. Będziemy coś robić „bo trzeba”. Bez zrozumienia, jakie mają być efekty.
Tak właśnie rodzą się „sesje narzekania” zamiast Sprint Retrospective, zdawanie statusu na Daily Scrum, demo zamiast Sprint Review i refinement wykonywany na Planowaniu. A to dopiero początek. Idąc z tym dalej możemy napotkać na o wiele większe przewinienia, np. projekt o stałym zakresie, budżecie i terminie realizowany w „Scrumie”.
Żeby cokolwiek naprawić w źle funkcjonującym procesie Scrum, musimy cofnąć się do samego początku i zadać kilka ważnych pytań. Po co w ogóle pracujemy? Co chcemy wytworzyć i czym jest nasz produkt? I najważniejsze – jak ma w tym pomóc Scrum?
Po co nam Scrum?
Pisaliśmy o tym dziesiątki razy, ale warto napisać kolejny. Scrum służy do iteracyjnego wytwarzania złożonych produktów. To znaczy, że robimy coś skomplikowanego, co nie do końca wiemy jak będzie wyglądało na końcu. Wiemy, jakie potrzeby ma spełniać, ale zarówno konkretne wymagania jak i sam sposób wytwarzania będzie tworzony i zmieniany w trakcie pracy.
Zacznijmy więc od tego, co chcemy osiągnąć. Zróbmy szybkie ćwiczenie i stwórzmy wizję produktu z naszym Product Ownerem (lub osobą, której najbliżej do bycia PO). Na podstawie tej wizji wyznaczmy Cel Produktu, a potem pod ten cel uporządkujmy Backlog Produktu. Może to nam zająć bardzo dużo czasu, ale musimy wiedzieć, co mamy zrobić i co chcemy osiągnąć, żeby Scrum nam w tym pomógł.
Jeżeli na tym etapie wyjdzie nam, że nie mamy Product Ownera, backlogu, zespołów, itd. to musimy cofnąć się jeszcze dalej. Kto jest w naszym zespole i za co odpowiada oraz skąd przychodzą do nas wymagania i kto jest w ich temacie decyzyjny? Bez odpowiedzi na te pytania daleko nie zajdziemy.
Jak już wiemy, co chcemy robić, to zastanówmy się kim i w jaki sposób. Upewnijmy się, że nasze Zespoły Scrumowe są kross-funkcjonalne i mają przestrzeń do bycia samozarządzającymi. To kolejny bardzo duży temat, zasługujący na osobne teksty i filmy.
Oczywiście, to tylko wysokopoziomowe wskazówki. Diabeł tkwi w szczegółach oraz w tym, jak przeprowadzić te zmiany nie stopując jednocześnie prac na kilka tygodni bądź miesięcy. O tym będziecie mogli poczytać w innych tekstach na naszym blogu lub… przekonać się na własnej skórze, jeżeli zdecydujecie się na zatrudnienie nas do wsparcia swojego Scruma. Polecamy się.
