Gdy rozpoczynaliśmy transformację agile w IT GetResponse, pierwszą sprawą, o jakiej pomyśleliśmy, było wprowadzenie całej organizacji w temat tego, czym naprawdę jest agile i Scrum. Powody były oczywiste: usunięcie wątpliwości i obaw, ale także zaspokojenie ciekawości pracowników. Chcieliśmy również wyjaśnić, dlaczego planujemy zmienić nasz sposób pracy, kim właściwie są Scrum Masterzy i co takiego mają zamiar robić.
Wiedzieliśmy, że powinniśmy poszukać niestandardowego sposobu, który umożliwi nam obudzenie pozytywnej energii i zbudowanie podatnego gruntu dla naszej transformacji. Przypomnieliśmy sobie o warsztatach Lego4Scrum, które podobały nam się na tyle, że postanowiliśmy na ich bazie stworzyć własne, autorskie warsztaty.
100 osób, 32 godziny szkoleń i niesamowite efekty!
Obecnie jesteśmy już po ośmiu edycjach warsztatów Scrum Lego. Ich rezultaty uważamy za rewelacyjne. Udało nam się w przeszkolić ponad 100 osób. Każda z edycji trwała ok. 4 godzin a grupy liczyły od 12 do 14 osób. Po każdej z sesji zbieraliśmy uwagi i modyfikowaliśmy warsztaty tak, aby każde następne jak najlepiej odpowiadały potrzebom naszych uczestników.
Cel naszego projektu był konkretny: umieścić ludzi w zwinnym, dynamicznie zmieniającym się środowisku i umożliwić im doświadczenie działania Scruma w praktyce. Oczywiście, a może przede wszystkim, dobrze się przy tym bawiąc.
Rozpoczęliśmy od rozbudowanego, teoretycznego wprowadzenia do Scruma, Kanbana, oraz ról (Interesariusze, Product Owner, Scrum Master i Zespół Deweloperski). W tej części warsztatów korzystaliśmy z założeń myślenia wizualnego, czyli użyliśmy rysunków dla zobrazowania omawianych idei i zasad. Ten sposób okazał się niezwykle skuteczny – rysunki wypełniliśmy sporą dawką dobrego humoru, co ułatwiło wyjaśnienie uczestnikom wszystkich aspektów poruszanych przez nas tematów.
Marzenia o wyjątkowym mieście Lego, czyli praktyka czyni mistrza
Jednak nic nie działa tak dobrze jak praktyka, dlatego już na samym początku poprosiliśmy uczestników, aby samodzielnie podzielili się na zespoły, wspólnie wybrali dla nich nazwy i zagrali w prostą grę. Użyliśmy jej, aby zwizualizować to w jaki sposób niewielkie zmiany w procesie mogą spowodować olbrzymie różnice w efektach wykonywanej pracy, ale też pokazać w dużym uproszczeniu podstawowe zasady Kanbana. To był również wstęp do rozmowy o technikach szacowania (m.in. o jednostkach jak idealne godziny, rozmiary koszulek, Story Points, itp. ale też o sposobach np. Scrum Poker).
Po przekazaniu bazowej wiedzy mogliśmy pójść dalej. Zasady gry były proste: 2 zespoły, każdy dysponujący własnym budżetem (jeden zespół zarządzał budżetem publicznym, drugi budżetem prywatnym), posiadający własne środowisko produkcyjne (duże pudło klocków Lego classic 10698, kredki, papier, taśma klejąca, markery), dedykowany Backlog i jednego wspólnego Product Ownera decydującego o tym, jakie prace przybliżą go do realizacji marzenia o wyjątkowym mieście Lego.
Zespoły pracowały w trzech sesjach, każda z nich zawierała planowanie sprintu (6 minut), sam sprint (7 minut), przegląd sprintu (7 minut) i retrospektywę (3 minuty). Każdy zespół dysponował własnym stołem – środowisko testowe, ale efekty pracy każdego ze sprintów były prezentowane na oddzielnym, dużym i wspólnym dla obu zespołów stole – środowisko produkcyjne.
Jak to bywa w rzeczywistości, symulację procesu rozpoczęliśmy od przemówienia Product Ownera i zapoznania zespołów z wymaganiami, a następnie przeszliśmy do sesji szacowania backlogu (7 minut).
Chcieliśmy, aby w każdej z sesji zawierała się dawka dobrego humoru. Dlatego postanowiliśmy nadać humorystyczny wydźwięk historyjkom, wokół których toczył się cały warsztat.
Przyjrzyjmy się kilku przykładom.
Dla zespołu obszaru publicznego:
- Jako burmistrz chcę, aby powstał pomnik mojej osoby, tak aby następne generacje wiedziały, komu zawdzięczają to piękne miasto.
- Jako burmistrz chcę, aby powstał mój dom, abym miał gdzie mieszkać.
- Jako burmistrz chcę, aby powstał ratusz, abym miał miejsce do pracy i mógł oddzielić życie zawodowe od prywatnego.
Dla zespołu obszaru prywatnego:
- Jako kapitalista chcę, aby powstał bar, żeby miejscowi pracownicy mieli miejsce do odpoczynku po ciężkiej codziennej pracy i aby mieli gdzie wydawać zarobione pieniądze.
- Jako kapitalista chcę, aby powstał ekskluzywny apartamentowiec, aby zarabiać na sprzedaży mieszkań.
- Jako kapitalista chcę, aby powstał wieżowiec, aby moja firma była postrzegana jako prestiżowa i abym mógł zarabiać na wynajmowaniu powierzchni.
Zdecydowaliśmy się na zbudowanie historyjek w dość specyficzny sposób. Zawarliśmy w nich jedynie ogólne informacje, bez żadnych konkretów.
Co nam to dało?
Z jednej strony, pozwoliło to zespołom na samodzielne odkrycie tego, że aby osiągnąć sukces, konieczna jest współpraca. W momencie gdy jeden z zespołów miał za zadanie wybudować most przecinający rzekę, drugi miał zbudować stocznię. Uzyskanie zadowalających rezultatów wymagało komunikacji i porozumienia, w tym przypadku chociażby ustalenia przebiegu cieków wodnych w obrębie miasta.
Z drugiej strony, zobaczyliśmy, jak ważna jest komunikacja na linii zespół – Product Owner. W czasie przeglądania backlogu, szacowania poszczególnych wymagań i planowania Product Owner (grany przez Scrum Mastera) był dostępny dla zespołów i gotowy na to, aby odpowiedzieć na wszelkie pytania. Zespoły w każdej chwili mogły pytać Product Ownera o szczegóły dotyczące poszczególnych wymagań (jak duża powinna być budowla, w jakiej lokalizacji, jakiego koloru itp.), natomiast w pierwszej iteracji następowało to bardzo rzadko.
Kluczowym momentem, który sprawił, że zespoły zorientowały się, że coś jest nie tak, było przedstawienie Product Ownerowi wyników prac pierwszego sprintu w trakcie przeglądu sprintu. Zupełnie niespodziewanie uzyskano zaskakujące informacje zwrotne… zły kolor (nienawidzę różowego!), pomnik burmistrza nie jest wystarczająco majestatyczny (Jestem taki niski? Serio?), za duże koszty materiałów (jeśli hotel został zbudowany z żółtych klocków padało pytanie: Dlaczego zrobiony jest ze złota?) itp. Informacje i ton w jakim zostały przekazane pozwoliły w zabawny i lekko ironiczny sposób pokazać zespołom, jak bardzo ich praca zależy od dobrej komunikacji.
W czasie retrospektywy zespoły stwierdziły, że zbyt mało czasu poświęcały na dowiedzenie się, co Product Owner tak naprawdę chce uzyskać i jak bardzo ich prace zależą od drugiego zespołu.
Każdy przegląd i każda retrospektywa przynosiły nowe odkrycia dotyczące tego, co możemy zrobić, aby uzyskiwać coraz lepsze efekty w pracy Zespołu Scrumowego. O co dopytywać Product Ownera? Jak współpracować z drugim zespołem, aby wspólnie otrzymywać jak najlepsze wspólne efekty? Jak możemy lepiej planować swoją pracę?
Dodatkowo, aby gra była jeszcze bardziej realistyczna, wprowadziliśmy namiastkę zdarzeń losowych. Na początku każdego Sprintu uczestnicy rzucali kostkami i na podstawie wyników mogli zostać na pewien czas wykluczeni z działań zespołu. Wtedy zespół musiał sobie poradzić w uszczuplonym składzie.
W rezultacie zespoły na bieżąco w kontakcie z Product Ownerem mogły przearanżowywać swoje backlogi, zmienić priorytety, ale też dostosowywać pracę i podział obowiązków w zespole do sytuacji, a przez to sprostać wyzwaniom każdego kolejnego sprintu. Tak długo jak Product Owner dysponował odpowiednim budżetem, gra trwała…
Wnioski
Dzięki warsztatom pokazaliśmy w praktyce, jak istotne jest tworzenie wymagań dobrej jakości, otwartość na współpracę i jasna komunikacja pomiędzy Zespołami Deweloperskimi, Product Ownerem i interesariuszami. Uważamy, że to jedne z najbardziej kluczowych aspektów Scruma.
Jak wiadomo, najlepiej pokazywać nowe idee i zapoznawać ludzi z ich zasadami poprzez praktykę – jeszcze lepiej, jeśli model, który zaprezentujemy, będzie prosty, a sam warsztat pozwoli na uczenie poprzez zabawę. W naszych warsztatach przekazaliśmy niezbędną wiedzę w sposób zapadający w pamięć, dawkę teorii przełamaliśmy ćwiczeniem praktycznym, dodaliśmy klocki Lego i dużą dawkę dobrego humoru – ta mieszanka idealnie wpasowała się w potrzeby naszej organizacji.
Jesteśmy dumni nie tylko z tego, że tak wiele osób zdecydowało się na uczestnictwo w naszych warsztatach, ale przede wszystkim z tego, że otrzymaliśmy od nich bardzo pozytywną informację zwrotną. Warsztaty pozwoliły na zrozumienie zasad Scruma i kultury agile. W efekcie wszyscy uczestnicy nie tylko poczuli się bezpieczniej w obliczu zmiany, ale też zastosowali dobre nawyki nabyte na warsztatach w codziennym życiu.