Po czterech latach pracy w produkcji hardware’u jako projektant układów analogowych, zmieniłem pracę i zostałem walidatorem software’u w systemach wbudowanych. W tamtych czasach moja wiedza na temat zarządzania projektami ograniczała się do tego, czego nauczyłem się na studiach oraz do tego, z czym zetknąłem się pracując jako projektant: dla projektu ustalało się zakres oraz wymagania. Manager ustalał potrzebne zasoby aby zmieścić się w założonym czasie, a następnie rozdzielał zadania. Każdy inżynier raportował status na cotygodniowych spotkaniach i w przypadku napotkania jakiegoś większego problemu, eskalował temat do managera. I to właściwie tyle. Gdzieś w tle wykresy Gantt’a i na nich ścieżka krytyczna. Tyle z magii zarządzania.
Moje pierwsze zetknięcie z czymś co można, dokonując poważnego nadużycia, nazwać Scrumem, miałem już pierwszego dnia w nowej pracy przy produkcji oprogramowania Dowiedziałem się, że idziemy na „standup”, na którym będziemy mieli „call’a” z inżynierem od klienta. Nie zadając pytań poszedłem na krótkie spotkanie, gdzie każdy z nowo poznanych kolegów po kolei referował czym zajmował się wczoraj, co będzie robił dziś i czy napotkał jakieś problemy. W pewnym momencie nasz Team Leader wypowiedział magiczne słowa: „…tym zajmiemy się w kolejnym sprincie”. Od razu nasunęło mi się pytanie co to jest sprint?! Założyłem, że dowiem się w odpowiednim czasie. Spotkanie było krótkie i sprawne. Zrobiło na mnie wrażenie jak dynamicznie „nam” to poszło. Po nim wszyscy rozeszli się do biurek do „normalnej” pracy. Gdy zacząłem dopytywać co to za tajemniczy sprint, dowiedziałem się że „my tu pracujemy w Scrumie”.

Dziś po siedmiu latach wiem, że z tym całym pracowaniem w scrumie to nie była tak do końca prawda. Poza tym, że raz na dwa tygodnie było spotkanie, na którym ustalano kto ma się czym zajmować „w tym sprincie” oraz poza krótkimi „standup’ami” rano każdego dnia, nie działo się nic czego wcześniej nie widziałem. Tak upłynęły około dwa miesiące, gdy pewnego dnia rano dowiedzieliśmy się, że projekt, nad którym pracowaliśmy został zawieszony… Jak się po czasie okazało, było to szczęśliwe zrządzenie losu, ponieważ kolejny projekt, do którego trafiłem, wyglądał zupełnie inaczej. Na jego potrzeby został utworzony nowy zespół, który miał być prowadzony przez mojego kolegę. Był on świeżo po szkoleniu u Krystiana Kaczora i zdanym certyfikacie PSM I. Był bardzo zajarany Scrum’em i zdeterminowany aby wprowadzić go w nowym zespole jak należy. Zaproponował, abym ja również wybrał się na to szkolenie, na co z chęcią przystałem, ponieważ już w kilku pierwszych (i nie ostatnich) rozmowach przy kawie, zdążył mnie tym zajaraniem zarazić. Szkolenie zrobiło na mnie piorunujące wrażenie. Najbardziej ekscytująca była myśl, że to deweloperzy sami decydują o tym jak wykonują postawione przed nimi zadania. Fakt, że procesy
jakie będą zaimplementowane w codziennej pracy również będą naszą decyzją oraz, że raz na sprit będziemy o tym rozmawiać na retrospektywie w celu ciągłego polepszania, nie mieścił mi się w głowie. Zdałem PSM I i rozpoczęliśmy układanie Scruma w naszym zespole. Team leader pełnił rolę Product Ownera, a ja, poza tym, że byłem deweloperem, objąłem rolę Scrum Mastera. W tej konfiguracji pracowaliśmy około trzydzieści sprintów. W tym czasie udało nam się zaimplementować sporo fajnych praktyk, a co najważniejsze dobrze poznaliśmy się z tym całym Scrumem. Doszedłem wtedy do pewnego wniosku. Praca Scrum Mastera to pikuś! Każdy deweloper, jak tylko wytłumaczy mu się, na czym praca w Scrum’ie polega, będzie zachwycony. Oszaleje z radości, jak dowie się, że od teraz sam będzie decydował jak zrealizuje swoje zadania i że wraz z całym zespołem będzie decydował o tym jak wygląda codzienna praca. Że od dziś będzie traktowało się go jak partnera a nie kogoś, komu zleca się zadania do robienia. Że to doceni i z całym zaangażowaniem zabierze się za jego wdrażanie.

Już po pierwszej zmianie zespołu, poddano pod weryfikację wyciągnięte wnioski. Zmieniłem pracodawcę i dołączyłem do zespołu walidacyjnego, gdzie poza pracą inżyniera, powierzono mi zadanie implementacji Scruma i objęcie roli Scrum Mastera. Przedstawiając koncept deweloperom, napotkałem na umiarkowany entuzjazm. a miejscami nawet opór. W tamtym momencie założyłem, że widocznie coś źle tłumaczę i problem polega na tym, że nie umiem skutecznie przekazać tego złożonego konceptu. Uzbroiłem się więc w cierpliwość i przez kolejny rok pracowałem nad przekazywaną treścią i zespołem, z którym pracowałem.
W kolejnej organizacji zostałem zatrudniony jako Scrum Master na sto procent, więc zbieranie doświadczenia znacząco przyspieszyło. Było to również związane z tym, że w tamtym czasie pracowałem z pięcioma zespołami, więc doświadczenia były „różne” 🙂 Już miałem przygotowaną gotową narrację, którą zbudowałem w poprzedniej firmie. Miałem więc poczucie, że to co mówię ma ręce i nogi.
Jedak kolejne miesiące przynosiły coraz to nowe przykłady wątpliwości, niechęci czy nawet oporu. Tłumacząc deweloperom, na czym polega ich zadanie i czego wymaga od nich Scrum, padało: „Po co to planowanie? Daj nam listę rzeczy do zrobienia to je zrobimy”, „Ja nie jestem analitykiem! Nie będę rozpisywał zadań!”, „Dlaczego my mamy ustalać proces wytwarzania? Ty jesteś Scrum Masterem, to jest twoje zadanie!” (…) Im więcej tego słuchałem, tym bardziej utwierdzałem się w przekonaniu, że wniosek wyciągnięty wcześniej jest błędny. Może nie w całości ale w bardzo istotnym punkcie. Nie KAŻDY deweloper tylko czeka aż będzie mógł samodzielnie decydować o sposobie wykonywania swojej pracy oraz procesie w jakim się ona odbywa. Jak to w całej naturze, również i tu zastosowanie ma rozkład normalny. Jest wąskie grono entuzjastów którzy tylko czekają na wolność,
którą niesie ze sobą implementacja Scruma. Jest spora grupa ludzi umiarkowanych, którzy uważnie słuchają i obserwują zmiany, które dzieją się naokoło nich, oraz jest wąska grupa osób które stawiają aktywny opór na wprowadzane zmiany. Postrzegają oni Scruma jako zbyt radykalną zmianę, która zbyt mocno rozszerza spektrum ich odpowiedzialności. Dalsze zgłębianie tego tematu uświadomiło mi jak złożonym, trudnym i wręcz bolesnym procesem dla ludzi jest zmiana przekonań, poglądów i przyzwyczajeń. Cytat dobrze oddający ducha tej mądrości: „Ludzie boją się zmian, nawet na lepsze” -Józef Ignacy Kraszewski. Samemu będąc entuzjastą, mylnie oceniałem że jest to powszechne podejście. Osoby o bardziej ostrożnym i konserwatywnym usposobieniu, mogą wprowadzanie Scruma postrzegać zupełnie inaczej.

Zrozumiałem, że z praktycznego punktu widzenia, wiedza ta jest bardzo istotna w pracy Scrum Mastera. Jak będziemy mieli szczęście to w zespole będzie jeden, może dwóch entuzjastów. Najprawdopodobniej kilka osób o umiarkowanym nastawieniu, które przy odpowiednim podejściu i upływie czasu na adaptację, przekona się do wprowadzanych zmian. Czego możemy być prawie pewni, trafi się jeden lub dwóch malkontentów.
Świadomość tego faktu pozwala Scrum Masterewi wprowadzić to do swojej strategii działania. Zaangażowanie entuzjastów i ich działania mogą być precedensem i dobrym przykładem dla reszty zespołu. Nie trzeba przekonywać całego zespołu do eksperymentu. Czasami wystarczy jeden ochotnik, który go przeprowadzi. Jeżeli wynik będzie pozytywny, to może stanowić dowód empiryczny pomocny w przekonywaniu nieprzekonanych. Postęp we wprowadzaniu zmian może następować stopniowo. Agenci zmiany są bardzo dobrym katalizatorem transformacji i ich wsparcie jest bardzo istotne.
Z drugiej strony wspomniani malkontenci są nieocenionym źródłem informacji na temat ryzyk i zagrożeń. Odpowiednie włączenie ich w dyskusję, aby mogli przedstawić swoje wątpliwości, pozwoli nam zaadresować wiele potencjalnych problemów, które mogą nas spotkać na drodze wprowadzanych zmian. Odpowiednia moderacja takich dyskusji w dłuższym okresie wesprze merytoryczną komunikację w zespole, jak również budowanie wzajemnego zaufania. Uświadomienie sobie różnic charakterologicznych członków zespołu, pozwala odpowiednio zbudować i zaadresować przekaz oraz znaleźć cierpliwość do żmudnego procesu implementacji.

MD