Po czterech latach pracy w produkcji sprzętu jako projektant układów analogowych, zdecydowałem się na zmianę i objąłem stanowisko walidatora oprogramowania w systemach wbudowanych. Moja wiedza na temat zarządzania projektami w tamtym czasie ograniczała się głównie do tego, co wyniosłem ze studiów oraz doświadczeń zdobytych podczas pracy jako projektant. W ramach projektu ustalało się zakres i wymagania, menedżer przydzielał niezbędne zasoby, aby dotrzymać ustalonego terminu, a następnie rozdzielał zadania. Inżynierowie raportowali postępy na cotygodniowych spotkaniach, a w przypadku większych problemów, eskalowali je do menedżera. W tle funkcjonowały wykresy Gantta i ścieżka krytyczna – tak wyglądała magia zarządzania.
Moje pierwsze zetknięcie z tym, co można by nazwać Scrumem (chociaż z pewnym nadużyciem tego terminu), miało miejsce w pierwszym dniu mojej nowej pracy przy produkcji oprogramowania. Dowiedziałem się, że idziemy na „standup”, podczas którego będziemy mieli „call” z inżynierem z klienta. Nie zadając pytań, udałem się na krótkie spotkanie, gdzie każdy z nowych kolegów referował, nad czym pracował wczoraj, co planuje na dziś i czy napotkał jakieś trudności. W pewnym momencie nasz lider zespołu wypowiedział magiczne słowa: „…tym zajmiemy się w kolejnym sprincie”. Od razu pojawiło się w mojej głowie pytanie: Co to jest sprint? Założyłem, że dowiem się w odpowiednim czasie. Spotkanie przebiegło sprawnie i zaskoczyło mnie, jak dynamicznie wszystko się odbyło. Po nim wszyscy wrócili do „normalnej” pracy. Gdy zacząłem dopytywać o tajemniczy sprint, dowiedziałem się, że „my tu pracujemy w Scrumie”.
Dziś, po siedmiu latach, wiem, że moje pierwsze doświadczenia z pracą w Scrumie nie były do końca reprezentatywne. Oprócz spotkania co dwa tygodnie, na którym ustalano, kto ma się czym zajmować „w tym sprincie”, oraz codziennych krótkich „standupów”, nie działo się nic, czego wcześniej bym nie znał. Tak minęły dwa miesiące, aż pewnego poranka dowiedzieliśmy się, że projekt, nad którym pracowaliśmy, został zawieszony. Jak się później okazało, było to szczęśliwe zrządzenie losu, ponieważ kolejny projekt, do którego trafiłem, wyglądał zupełnie inaczej. Został stworzony nowy zespół, którym miał kierować mój kolega, świeżo po szkoleniu u Krystiana Kaczora i z certyfikatem PSM I. Był pełen entuzjazmu i zdeterminowany, aby wprowadzić Scrum w nowym zespole. Zaproponował, abym również wziął udział w szkoleniu, co z chęcią przyjąłem, ponieważ w kilku pierwszych rozmowach przy kawie udało mu się zarazić mnie swoim zapałem. Szkolenie wywarło na mnie ogromne wrażenie. Najbardziej ekscytujące było to, że to deweloperzy sami decydują o tym, jak wykonują powierzone im zadania. Fakt, że procesy wdrażane w codziennej pracy również będą naszą decyzją, a raz na sprint będziemy o tym rozmawiać na retrospektywie w celu ciągłego doskonalenia, był dla mnie rewelacyjny. Zdałem PSM I i zaczęliśmy implementację Scruma w naszym zespole. Team leader pełnił rolę Product Ownera, a ja, oprócz bycia deweloperem, objąłem rolę Scrum Mastera. W tej konfiguracji pracowaliśmy przez około trzydzieści sprintów. Udało nam się wprowadzić wiele interesujących praktyk i, co najważniejsze, dobrze zrozumieliśmy ideę Scruma. Wtedy doszedłem do wniosku, że praca Scrum Mastera to bułka z masłem! Każdy deweloper, gdy tylko wyjaśni się mu zasady pracy w Scrumie, będzie zachwycony. Z radością przyjmie fakt, że to on sam decyduje, jak zrealizuje swoje zadania, i że wraz z zespołem ma wpływ na organizację codziennej pracy. Odkryje, że od teraz traktuje się go jako partnera, a nie osobę, której zleca się zadania, co na pewno doceni i zaangażuje się w realizację Scruma.
Po pierwszej zmianie zespołu poddano weryfikacji wyciągnięte wnioski. Zmieniłem pracodawcę i dołączyłem do zespołu walidacyjnego, gdzie oprócz pracy inżyniera, powierzono mi zadanie implementacji Scruma i objęcia roli Scrum Mastera. Przedstawiając koncept deweloperom, spotkałem się z umiarkowanym entuzjazmem, a miejscami nawet oporem. W tamtym momencie założyłem, że być może źle tłumaczę i problem leży w moim przekazie. Uzbroiłem się w cierpliwość i przez kolejny rok pracowałem nad przekazywaną treścią oraz z zespołem, w którym działałem.
W kolejnej organizacji zostałem zatrudniony jako Scrum Master na pełen etat, co znacząco przyspieszyło mój rozwój. Pracowałem z pięcioma zespołami, więc moje doświadczenia były różnorodne. Już miałem przygotowaną narrację, którą zbudowałem w poprzedniej firmie, co dawało mi poczucie, że to, co mówię, ma sens. Jednak kolejne miesiące przynosiły nowe przykłady wątpliwości, niechęci, a nawet oporu. Tłumacząc deweloperom, na czym polega ich zadanie i czego wymaga od nich Scrum, słyszałem: „Po co to planowanie? Daj nam listę rzeczy do zrobienia, a my je zrealizujemy”, „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 wcześniejszy wniosek był błędny. Może nie w całości, ale w istotnym punkcie: nie każdy deweloper pragnie samodzielnie decydować o sposobie wykonywania swojej pracy i procesie, w jakim ta praca się odbywa. Jak w naturze, tak i tutaj występuje rozkład normalny. Jest wąska grupa entuzjastów, którzy czekają na wolność, jaką niesie ze sobą implementacja Scruma. Jest spora grupa osób umiarkowanych, które uważnie obserwują zmiany wokół siebie, oraz wąska grupa osób stawiających aktywny opór. Postrzegają oni Scruma jako zbyt radykalną zmianę, która rozszerza zakres ich odpowiedzialności. Dalsze zgłębianie 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 Józefa Ignacego Kraszewskiego: „Ludzie boją się zmian, nawet na lepsze” dobrze oddaje ducha tej mądrości. Sam będąc entuzjastą, mylnie oceniałem, że jest to powszechne podejście. Osoby o bardziej ostrożnym i konserwatywnym usposobieniu mogą postrzegać wprowadzanie Scruma zupełnie inaczej.
Zrozumiałem, że z praktycznego punktu widzenia ta wiedza jest kluczowa w pracy Scrum Mastera. Jeśli będziemy mieli szczęście, w zespole znajdzie się jeden, może dwóch entuzjastów. Prawdopodobnie będzie kilka osób o umiarkowanym nastawieniu, które przy odpowiednim podejściu i czasie na adaptację, przekonają się do wprowadzanych zmian. Możemy być niemal pewni, że trafi się jeden lub dwóch malkontentów. Świadomość tego faktu pozwala Scrum Masterowi dostosować swoją strategię działania. Zaangażowanie entuzjastów i ich działania mogą stać się 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śli wynik będzie pozytywny, może to stanowić dowód empiryczny, który pomoże przekonać nieprzekonanych. Postęp wprowadzania zmian może następować stopniowo. Agenci zmiany są doskonałym katalizatorem transformacji, a ich wsparcie jest niezwykle istotne.
Z drugiej strony, wspomniani malkontenci są cennym źródłem informacji na temat ryzyk i zagrożeń. Odpowiednie włączenie ich do dyskusji, aby mogli przedstawić swoje wątpliwości, pozwoli nam zająć się wieloma potencjalnymi problemami, które mogą wystąpić podczas wprowadzania zmian. Odpowiednia moderacja takich dyskusji w dłuższej perspektywie wesprze merytoryczną komunikację w zespole oraz budowanie wzajemnego zaufania. Świadomość różnic charakterologicznych członków zespołu umożliwia adekwatne zbudowanie i zaadresowanie przekazu oraz znalezienie cierpliwości w żmudnym procesie implementacji.
Po czterech latach pracy w produkcji sprzętu jako projektant układów analogowych, zdecydowałem się na zmianę i objąłem stanowisko walidatora oprogramowania w systemach wbudowanych. Moja wiedza na temat zarządzania projektami w tamtym czasie ograniczała się głównie do tego, co wyniosłem ze studiów oraz doświadczeń zdobytych podczas pracy jako projektant. W ramach projektu ustalało się zakres i wymagania, menedżer przydzielał niezbędne zasoby, aby dotrzymać ustalonego terminu, a następnie rozdzielał zadania. Inżynierowie raportowali postępy na cotygodniowych spotkaniach, a w przypadku większych problemów, eskalowali je do menedżera. W tle funkcjonowały wykresy Gantta i ścieżka krytyczna – tak wyglądała magia zarządzania.
Moje pierwsze zetknięcie z tym, co można by nazwać Scrumem (chociaż z pewnym nadużyciem tego terminu), miało miejsce w pierwszym dniu mojej nowej pracy przy produkcji oprogramowania. Dowiedziałem się, że idziemy na „standup”, podczas którego będziemy mieli „call” z inżynierem z klienta. Nie zadając pytań, udałem się na krótkie spotkanie, gdzie każdy z nowych kolegów referował, nad czym pracował wczoraj, co planuje na dziś i czy napotkał jakieś trudności. W pewnym momencie nasz lider zespołu wypowiedział magiczne słowa: „…tym zajmiemy się w kolejnym sprincie”. Od razu pojawiło się w mojej głowie pytanie: Co to jest sprint? Założyłem, że dowiem się w odpowiednim czasie. Spotkanie przebiegło sprawnie i zaskoczyło mnie, jak dynamicznie wszystko się odbyło. Po nim wszyscy wrócili do „normalnej” pracy. Gdy zacząłem dopytywać o tajemniczy sprint, dowiedziałem się, że „my tu pracujemy w Scrumie”.
Dziś, po siedmiu latach, wiem, że moje pierwsze doświadczenia z pracą w Scrumie nie były do końca reprezentatywne. Oprócz spotkania co dwa tygodnie, na którym ustalano, kto ma się czym zajmować „w tym sprincie”, oraz codziennych krótkich „standupów”, nie działo się nic, czego wcześniej bym nie znał. Tak minęły dwa miesiące, aż pewnego poranka dowiedzieliśmy się, że projekt, nad którym pracowaliśmy, został zawieszony. Jak się później okazało, było to szczęśliwe zrządzenie losu, ponieważ kolejny projekt, do którego trafiłem, wyglądał zupełnie inaczej. Został stworzony nowy zespół, którym miał kierować mój kolega, świeżo po szkoleniu u Krystiana Kaczora i z certyfikatem PSM I. Był pełen entuzjazmu i zdeterminowany, aby wprowadzić Scrum w nowym zespole. Zaproponował, abym również wziął udział w szkoleniu, co z chęcią przyjąłem, ponieważ w kilku pierwszych rozmowach przy kawie udało mu się zarazić mnie swoim zapałem. Szkolenie wywarło na mnie ogromne wrażenie. Najbardziej ekscytujące było to, że to deweloperzy sami decydują o tym, jak wykonują powierzone im zadania. Fakt, że procesy wdrażane w codziennej pracy również będą naszą decyzją, a raz na sprint będziemy o tym rozmawiać na retrospektywie w celu ciągłego doskonalenia, był dla mnie rewelacyjny. Zdałem PSM I i zaczęliśmy implementację Scruma w naszym zespole. Team leader pełnił rolę Product Ownera, a ja, oprócz bycia deweloperem, objąłem rolę Scrum Mastera. W tej konfiguracji pracowaliśmy przez około trzydzieści sprintów. Udało nam się wprowadzić wiele interesujących praktyk i, co najważniejsze, dobrze zrozumieliśmy ideę Scruma. Wtedy doszedłem do wniosku, że praca Scrum Mastera to bułka z masłem! Każdy deweloper, gdy tylko wyjaśni się mu zasady pracy w Scrumie, będzie zachwycony. Z radością przyjmie fakt, że to on sam decyduje, jak zrealizuje swoje zadania, i że wraz z zespołem ma wpływ na organizację codziennej pracy. Odkryje, że od teraz traktuje się go jako partnera, a nie osobę, której zleca się zadania, co na pewno doceni i zaangażuje się w realizację Scruma.
Po pierwszej zmianie zespołu poddano weryfikacji wyciągnięte wnioski. Zmieniłem pracodawcę i dołączyłem do zespołu walidacyjnego, gdzie oprócz pracy inżyniera, powierzono mi zadanie implementacji Scruma i objęcia roli Scrum Mastera. Przedstawiając koncept deweloperom, spotkałem się z umiarkowanym entuzjazmem, a miejscami nawet oporem. W tamtym momencie założyłem, że być może źle tłumaczę i problem leży w moim przekazie. Uzbroiłem się w cierpliwość i przez kolejny rok pracowałem nad przekazywaną treścią oraz z zespołem, w którym działałem.
W kolejnej organizacji zostałem zatrudniony jako Scrum Master na pełen etat, co znacząco przyspieszyło mój rozwój. Pracowałem z pięcioma zespołami, więc moje doświadczenia były różnorodne. Już miałem przygotowaną narrację, którą zbudowałem w poprzedniej firmie, co dawało mi poczucie, że to, co mówię, ma sens. Jednak kolejne miesiące przynosiły nowe przykłady wątpliwości, niechęci, a nawet oporu. Tłumacząc deweloperom, na czym polega ich zadanie i czego wymaga od nich Scrum, słyszałem: „Po co to planowanie? Daj nam listę rzeczy do zrobienia, a my je zrealizujemy”, „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 wcześniejszy wniosek był błędny. Może nie w całości, ale w istotnym punkcie: nie każdy deweloper pragnie samodzielnie decydować o sposobie wykonywania swojej pracy i procesie, w jakim ta praca się odbywa. Jak w naturze, tak i tutaj występuje rozkład normalny. Jest wąska grupa entuzjastów, którzy czekają na wolność, jaką niesie ze sobą implementacja Scruma. Jest spora grupa osób umiarkowanych, które uważnie obserwują zmiany wokół siebie, oraz wąska grupa osób stawiających aktywny opór. Postrzegają oni Scruma jako zbyt radykalną zmianę, która rozszerza zakres ich odpowiedzialności. Dalsze zgłębianie 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 Józefa Ignacego Kraszewskiego: „Ludzie boją się zmian, nawet na lepsze” dobrze oddaje ducha tej mądrości. Sam będąc entuzjastą, mylnie oceniałem, że jest to powszechne podejście. Osoby o bardziej ostrożnym i konserwatywnym usposobieniu mogą postrzegać wprowadzanie Scruma zupełnie inaczej.
Zrozumiałem, że z praktycznego punktu widzenia ta wiedza jest kluczowa w pracy Scrum Mastera. Jeśli będziemy mieli szczęście, w zespole znajdzie się jeden, może dwóch entuzjastów. Prawdopodobnie będzie kilka osób o umiarkowanym nastawieniu, które przy odpowiednim podejściu i czasie na adaptację, przekonają się do wprowadzanych zmian. Możemy być niemal pewni, że trafi się jeden lub dwóch malkontentów. Świadomość tego faktu pozwala Scrum Masterowi dostosować swoją strategię działania. Zaangażowanie entuzjastów i ich działania mogą stać się 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śli wynik będzie pozytywny, może to stanowić dowód empiryczny, który pomoże przekonać nieprzekonanych. Postęp wprowadzania zmian może następować stopniowo. Agenci zmiany są doskonałym katalizatorem transformacji, a ich wsparcie jest niezwykle istotne.
Z drugiej strony, wspomniani malkontenci są cennym źródłem informacji na temat ryzyk i zagrożeń. Odpowiednie włączenie ich do dyskusji, aby mogli przedstawić swoje wątpliwości, pozwoli nam zająć się wieloma potencjalnymi problemami, które mogą wystąpić podczas wprowadzania zmian. Odpowiednia moderacja takich dyskusji w dłuższej perspektywie wesprze merytoryczną komunikację w zespole oraz budowanie wzajemnego zaufania. Świadomość różnic charakterologicznych członków zespołu umożliwia adekwatne zbudowanie i zaadresowanie przekazu oraz znalezienie cierpliwości w żmudnym procesie implementacji.
Popular Categories
Popular Tags
Archiwa