W ramach pracy nad kompetencjami mBanku przygotowałem autorski program szkolenia z podstaw Scruma i w ramach tego artykułu chcę się podzielić filozofią, jaka mi przyświecała przy jego tworzeniu. Gdy niedawno przygotowywaliśmy się razem do współprowadzenia “Podstaw Scruma” jedna ze Scrum Masterek zadała mi pytanie: “na podstawie czego ten program powstał”. Dla mnie to pytanie dotyka dość ważnej kwestii, czyli tego jaka jest konstrukcja szkieletu warsztatu, a może z jakiego innego szkolenia to szkolenie jest kopią ;).
Program jakiego używam w mBanku jest mocno autorski w tym sensie, że założyłem zasadę pustej kartki, więc to nie są slajdy przetłumaczone, skopiowane, przeniesione, czy nawet inspirowane przez jakieś konkretne szkolenie. A byłem na wielu, na samych szkoleniach z podstaw Scruma byłem na szkoleniu Certified Scrum Master w 2009 roku u Angeli Druckman, pół roku później u Dana Rawsthorne’a. W 2011 roku w czasie transformacji zwinnej w Allegro wziąłem udział w Professional Scrum Product Owner u Tomka Włodarka, a w kolejnym roku uczestniczyłem w szkoleniu Professional Scrum Foundations Tomka jako pomocnik w moderowaniu ćwiczeń i gość, który mógł z boku trochę pokomentować, gdy pojawiały się jakieś pytania o transformację Allegro. Scrumowo najmocniejszym przeżyciem było szkolenie Certified Scrum Master u Jeffa Sutherlanda, który sam Jeff nazywał raczej zaawansowanym Scrumem, niż podstawami Scruma. Nie wymieniam tego, żeby się chwalić, ale żeby pokazać, że szkoleń o Scrumie widziałem parę jako uczestnik i każde dało mi okazję z jednej strony zobaczyć warsztat trenerski, a z drugiej każde kolejne było okazją do przemyślenia, odświeżenia, wypolerowania sobie wiedzy o Scrumie jako takim.
Ale moje szkolenie nie jest kopią, ani jakimś miksem żadnego z tych kursów. Filozofia tego warsztatu wraca do pewnego krótkiego szkolenia w Allegro, gdzie zaeksperymentowałem z koncepcją opowiedzenia Scruma przez pryzmat problemów, jakie Scrum rozwiązuje – w metodzie zaszyte są pewne praktyki, które rozwiązują typowe problemy podejścia tradycyjnego. Na warsztacie miałem nietypowy zespół, który chciał się dowiedzieć czym jest Scrum i zamiast im tłumaczyć jak zwykle, zacząłem od wypytania z jakimi problemami stykają się przy realizacji projektów. Tak się jakoś dziwnie samo złożyło, że wszystkie problemy przez nich wymienione stały się szkieletem zdefiniowania Scruma. Dosłownie to się działo na whiteboardzie, na którym dopisywałem kolejne elementy frameworka jako odpowiedź na ich problemy z codziennego życia projektowego. Oni wymieniali m.in. problemy komunikacyjne, problemy z priorytetami, problemy ze sformułowaniem wymagań, a ja im pokazałem po kolei Product Backlog i Przyrost, Planowanie Sprintu, a z drugiej strony ewentualne odkrycie na Review, że się nie dogadaliśmy itd. No i koncepcja bardzo zażarła, w tym sensie, że zarówno ja jak i uczestnicy byliśmy zadowoleni z jasnego wytłumaczenia i łatwości z jaką przebiegł ten warsztat.
Gdy dołączyłem do mBanku postanowiłem zaeksperymentować z tą formułą jako kompletnym sposobem na szkielet warsztatu. Całkowicie zrezygnowałem z podejścia “klasycznego”, że tak to nazwę Scrum “po kolei”: zacznijmy od ról, no to role: pierwsza, druga, trzecia rola; no to teraz zdarzenia: pierwsze, drugie, trzecie, czwarte zdarzenie; no to teraz artefakty: pierwszy, drugi, trzeci artefakt; teraz jakiś temat zaawansowany, dyplom, ankieta, koniec! W takim podejściu moim zdaniem strasznie ciężko jest zdefiniować poszczególne elementy Scruma bez definiowania “nieznane przez nieznane”. Scrum Master to jest ten, kto pracuje z Product Ownerem, a kto to jest Product Owner? Coś, co ja zastosowałem, to takie rozsupłanie Scruma nie rola po roli, zdarzenie po zdarzeniu, tylko problem po problemie, jaki mamy w projektach. Stąd zaczynam od sformułowania tematów zarządzania produktem, potem wprowadzam temat pracy zespołowej, potem jest temat ciągłego usprawniania, potem jest temat realizacji projektów no i na końcu jest miejsce na tematy zaawansowane np. skalowanie, ale to już często bardzo wynika z konkretnej potrzeby szkolonego zespołu.
Szkoleń po dołączeniu do mBanku robiłem bardzo dużo, pewnie doliczył bym się kilkudziesięciu szkoleń poprowadzonych, co pozwoliło w krótkim czasie pokombinować z różnymi ćwiczeniami, z różnymi formułami instrukcji i dopracowywać slajdy, zwrócić uwagę na rozłożenie akcentów, rozłożenie kolejności przekazywanej wiedzy. Pozwoliło to też reagować na to co wyglądało, że zostało przekazane niejasno albo pojawiało się w feedbackach jako słabszy fragment. Najmocniejszym feedbackiem było zjawisko zbierania swoich własnych owoców poszkoleniowych. Gdy najpierw szkoliłem, a potem osobiście coachowałem (po prostu byłem jedynym coachem w całej organizacji), bardzo łatwo mogłem dostrzec to, jak niedoskonałości moich pierwszych szkoleń później było widać w zespole. Na przykład temat retrospektywy, żeby ukonkretnić opowieść. Dla mnie samego retrospektywa była dosyć oczywista, stąd jak przyszedł czas na ten temat na szkoleniu, no to w zasadzie w skrócie opowiedziałem, że trzeba to robić i dzięki temu się ciągle usprawniamy. Porównywalnie o wiele więcej czasu i uwagi skupiałem na tematy backlogów, Ownera, roli Scrum Mastera, prognozowanie realizacji projektu. Potem docieram do pierwszego zespołu, który przeszkoliłem, który dzięki mojemu szkoleniu spróbował wykorzystać Scruma i spotykam ścianę. Nie wiedzą jak zrobić retrospektywę, więc najprostsza reakcja, jak nie wiemy, jak coś zrobić to tego nie robimy. Gdy szkoliłem kolejny zespół, już wzmocniłem w swoim programie temat propozycji konkretnych technik retrospektyw, podpowiedź starfish diagram i timeline, tak żeby umieli zastosować to na początku swojej pracy, na początku swojej drogi ze Scrumem. Kolejna kwestia, która najwyraźniej nie wybrzmiewała na moich szkoleniach to retrospektywa jako element obowiązkowy w każdym sprincie. Pierwsze zespoły miały ochotę robić retrospektywę wtedy gdy trzeba, a nie co sprint. Zwłaszcza startującemu zespołowi naprawdę nie uwierzę, że nie potrzebuje robić retrospektywy co sprint, ale w kolejnych warsztatach zwracałem uwagę na jakieś wzmocnienie tematu jak bardzo retrospektywa jest potrzebna co sprint.
Oczywiście nadużyciem byłoby stwierdzenie, że dzięki wypolerowanym warsztatom ludzie przeze mnie przeszkoleni idealnie od pierwszego sprintu będą realizować Scruma, ale wiem, że warsztat ma dobry szkielet, który uzupełniam ciągłymi usprawnieniami, dzięki temu, że mogę też zbierać feedback z prawdziwego zastosowania w praktyce tego, co uczę.
PS. Jeśli temat uczenia się Scruma jest w twoim obszarze zainteresowań, sprawdź mój webinar o Retrospektywie Sprintu – zbiera wyżej wspomniane doświadczenia w skondensowaną pigułkę, w postaci wideo, ebooka i dodatkowej instrukcji do technik na retro.