Burzliwa historia o tym jak jako scrum master pomogłem rozbić zespół produktowy. Na potrzeby artykułu używam zasłyszanych cytatów nazw dwóch skłóconych zespołów: DEBEŚCIAKI oraz PATAŁACHY. Jest to też celowy zabieg literacki. Nie określa on mojego stosunku do obu zespołów. Każdy z nich miał swoją historię, która ukształtowała opisywane postawy. Nie mi je oceniać. Opisane wydarzenia były też sumą brania odpowiedzialności za zaistniałą sytuację przez różne osoby, w tym przeze mnie.

Sytuacja

Zostałem przydzielony jako scrum master do zespołu produktowego DEBEŚCIAKÓW, który choć pracował nad jednym z bardzo istotnych obszarów produktu, miał w organizacji renomę jednego z najtrudniejszych we współpracy. Zespół prezentował bardzo scementowaną i hermetyczną w skali firmy kulturę organizacyjną. Jego członkowie byli zdemotywowani i sfrustrowani. Byli też skłóceni z innymi zespołami oraz managementem. Język nienawiści był na porządku dziennym.

Co zrobiłem

Przez kilka miesięcy wykonałem serię eksperymentów, które miały ustalić stan faktyczny oraz pomóc DEBEŚCIAKOM dźwignąć się z dołka. Pracowałem nad “kulturą i atmosferą” codziennie. Zorganizowałem kilka retrospektyw. Zaproponowałem cykliczne spotkania z product ownerem oraz liderem zespołu. Zaproponowałem konsultacje ponad podziałami z “wrogimi zespołami”. Zostałem scrum masterem PATAŁACHÓW – najbardziej “wrogiego zespołu”, który był w procesie przejmowania od DEBEŚCIAKÓW prac nad produktem. Pomogłem obu zespołom zrobić samoocenę poziomu zwinności w oparciu o kryteria organizacji. Zwróciłem się też o pomoc do lidera, produkt ownera, a w końcu do Ich managerów.

Jakie były skutki moich (i nie tylko moich) działań

Moje różnorakie akcje nie pomogły dźwignąć się DEBEŚCIAKOM. Począwszy od najbardziej wybuchowego członka zespołu, poprzez formalnego lidera i product ownera, na większości członków kończąc, posypały się wypowiedzenia. Zespół przestał istnieć, a produkt przejęły w całości PATAŁACHY. Kilku managerów nazywało mnie “zabójcą zespołów”. W zespole DEBEŚCIAKÓW otrzymałem miano szpiega organizacji. Sobie sam zaś zafundowałem nieprzespane noce i spalenie całkiem dużych pokładów energii, których użyłem na ratowanie beznadziejnej sytuacji.

Full story

Zostałem przydzielony do DEBEŚCIAKÓW złożonych z PO, formalnego lidera technicznego i zespołu developerskiego. Właśnie rozpoczynał się 120-ty tygodniowy sprint. Zespół wraz z PATAŁACHAMI z innego miasta pracował nad tym samym produktem, który to produkt w bliżej nieokreślonej perspektywie zespół PATAŁACHÓW miał przejąć. To co zastałem w zespole było sumą doświadczeń z ostatnich ponad 2 lat pracy, której nie byłem świadkiem. Miałem więc kilku “wujków dobra rada”. Chcąc wyrobić sobie własne zdanie, wzbraniałem się przed Ich radami. Zespół prezentował bardzo scementowaną i hermetyczną w skali firmy kulturę organizacyjną, która miała swoje odzwierciedlenie w sposobie komunikacji, agresywnym języku, bardzo dużym przywiązaniu do grupy oraz czymś co współczesna psychologia nazywa kolektywnym narcyzmem. Członkowie zespołu twierdzili, że pracują jako jedyni dobrze i profesjonalnie, a niemal “cała organizacja” była przeciwko Nim. Obserwowałem olbrzymią frustrację i demota, które były manifestowane między innymi w codziennie używanym języku nienawiści ukierunkowanym na inne części organizacji.

Zacząłem pracę od kilku sprawdzonych wcześniej przeze mnie wzorców oraz kilku nowych rzeczy. Oprócz opisanych poniżej chronologicznych akcji, odbyłem wiele rozmów z członkami innych zespołów, scrum masterami, managerami różnego szczebla. Brałem udział w wielu spotkaniach zespołu. Zrobiłem kilka retrospektyw. Jeden z członków zespołu dostał załamania nerwowego i wylądował na L4. Inny opuścił statek matkę i przeniósł się do innego zespołu, co po czasie bardzo sobie cenił. Co zatem w zaistniałej sytuacji zrobiłem i jakie były tych działań skutki?

Akcja I

Poprosiłem zespół DEBEŚCIAKÓW o określenie oczekiwań wobec mojej osoby. Nie określili ich. Dowiedziałem się, że “przecież wiem jak wykonywać swoją robotę”. Przedstawiłem więc własne oczekiwania i zacząłem pracę bez oczekiwań w stosunku do mnie.

Akcja II

Podczas retrospektyw zachęcałem DEBEŚCIAKÓW do wypracowania 1 wdrażalnego w kolejnym sprincie usprawnienia, po czym zespół zapisywał je jako historię użytkownika z kryteriami akceptacji i wrzucał do sprint backlogu. Usprawnień nie udawało się jednak wdrażać.

Akcja III

Dogadałem się z produckt ownerem na codzienne spotkania aka “15-minutówki z PO” dotyczące produktu, backlogu i kultury zespołu. W kontekście naprawy sytuacji w DEBEŚCIAKACH z naszych rozmów nic nie wyszło.

Akcja IV

Kilkukrotnie próbowałem ustalić cykliczne spotkania z liderem DEBEŚCIAKÓW. Również bezskutecznie. W całej historii spotkaliśmy się dwa razy.

Akcja V

Przyglądałem się zatem pracy DEBEŚCIAKÓW i notowałem wszelkie informacje, które mogłyby się okazać przydatne w dalszej pracy. W trzecim tygodniu pracy przez dwa dni zanotowałem kilkadziesiąt cytatów zespołu w stylu „te patałachy”, „mamy to w dupie”, „po c..j oni nam zawracają dupę”, „debile k…a”, „niech spier….ją”, “niech ci pier….ni managerowie wezmą się do roboty”. Był to komunikacyjny codzienny, trwający od miesięcy standard, który zainspirował mnie do zorganizowania “grubszej” retrospektywy.

Akcja VI

Na ścianie w pokoju zespołu zrobiłem wizualizację (jakieś 3 na 2 metry), na której wywiesiłem zdjęcia kilku zespołów oraz kilkudziesięciu ludzi, z którymi DEBEŚCIAKI współpracowały. Następnie podczas retrospektywy poprosiłem, aby wyobrazili sobie, że wszyscy Ci ludzie weszli teraz do pokoju i są z nami. Następnie przy nazwiskach po kolei przykleiłem kilkadziesiąt soczystych cytatów zespołu, które dotyczyły danych osób czy zespołów. Czytałem je na głos. Pojawiły się śmiechy i żarty. Po wszystkim zapytałem wszystkich zebranych “jaki według Nich rysuje się obraz zespołu?”. Jedyną odpowiedzią było “że wulgarny”. Później ciągnąłem temat komunikacji nie stawiając żadnych tez, ani nie nakłaniając do żadnych zmian. Poprosiłem tylko, aby zastanowili się nad tym co widzą, słyszą i jak się komunikują. Sukcesem był fakt, że udało mi się nie wejść w tryb oceniający, chociaż gotowało się we mnie. Ta oraz wszelkie inne retrospektywy nie zmieniły jednak języka komunikacji. Problem leżał znacznei głębiej. Tak głęboko, że nigdy nie udało mi się odryć prawdziwej jego natury. Pierwsza grubsza retrospektywa przyniosła za to efekt, o którym dowiedziałem się po jakimś czasie. Jeden z developerów odciął pępowinę hermetycznej kultury organizacyjnej i postanowił odejść do innego zespołu. Po czasie, był wskazywany przez pozostałych członków zespołu jako ten słaby, który wymiękł.

Akcja VII

Po odkryciu, że najwięcej tarć oraz inwektyw jest kierowanych pod kątem PATAŁACHÓW – współpracującego nad tym samym produktem zespołu developerskiego z innego miasta, zaproponowałem, że przyjadę do Nich i spotkam się w gronie: product ownerzy, liderzy i scrum masterzy obu zespołów oraz architekt celem przedyskutowania i mediacji w tej zaognionej “sytuacji”. Do spotkania nie doszło z powodu braku odzewu. Pierwsze wspólne spotkanie udało się zorganiozować po wielu tygodniach. Skończyło się niedomówieniami i wzajemnymi oskarżeniami.

Akcja VIII

Przez półtora tygodnia próbowałem się skontaktować ze scrum masterem PATAŁACHÓW codziennie dzwoniąc. Chciałem przegadać jak wspólnie można zająć się komunikacją na styku obu zespołów. Z naszych rozmów nic nie wyszło.

Akcja IX

Po kilku tygodniach udało mi się dogadać w ten sposób, że zostałem scrum masterem PATAŁACHÓW. Chciałem zapewnić moją bezstronność w konflikcie, jakby nie patrzeć, współpracujących nad tym samym produktem zespołów. Wsiadałem zatem w pociąg o 6 rano i jechałem raz, dwa razy w tygodniu przez Polskę, aby zobaczyć jak jest. Zespół PATAŁACHÓW prezentował odmienną, pozytywnie przeze mnie odbieraną kulturę zarówno wypowiedzi jak i organizacyjną. Nie byli tytanami otwartości na dialog, niemniej jednak pomimo mojej “agenturalnej przeszłości” i pracy dla wroga przyjęli mnie ciepło i zaczęliśmy owocną współpracę. Pomagałem Im podczas przeglądów sprintów, planowań sprintów oraz retrospektyw. Sygnały wskazywały, że problem w istocie leży w DEBEŚCIAKACH.

Akcja X

Zacząłem spotykać się regularnie z managerem zespołu PATAŁACHÓW. Były to owocne, pełne kultury i zrozumienia spotkania, choć z Jego strony jednostronnie oceniające, że problem leży po stronie DEBEŚCIAKÓW.

Akcja XI

Zaproponowałem, że pomogę PATAŁACHOM zrobić samoocenę zwinności, na podstawie której mogliby znaleźć przestrzenie do usprawnień choćby w komunikacji na styku DEBEŚCIAKI-PATAŁACHY. To samo ćwiczenie wykonałem z zespołem DEBEŚCIAKÓW. Była to kwartalna ankieta oceny zwinności zespołu, wspólna dla wszystkich zespołów w firmie, na podstawie której zespół samodzielnie bądź z pomocą scrum mastera określał sobie kierunki dalszego rozwoju w kontekście zwinnego wytwarzania produktów. Niestety wynik ankiety był również połączony z wysokością premii. Sama jednak ankieta była profesjonalnym merytorycznym narzędziem wypracowanym przez kilka tygodni w kilkuosobowym zespole scrum masterów. Na każdym etapie jej powstawania była konsultowana z doktor psychometrii, która wielokrotnie “czelendżowała” jej merytoryczne założenia. Jej wyniki dawały na prawdę dobry obraz zwinności danego tesamu. W wyniku przeprowadzenia ankiety oba zespoły miały przed sobą sporo różnych potencjalnych usprawnień. PATAŁACHY podeszły do wyników z umiarkowanym entuzjazmem, ale ze świadomością pracy do wykonania. DEBEŚCIAKI kontestowały wielokrotnie zasadność samej ankiety, a jej wspólnie wypracowane wyniki oraz ostateczną ocenę określiły jako dla Nich krzywdzące. Zaprosiłem wobec tego DEBEŚCIAKÓW do współtworzenia jej kryteriów. Na deklaracji, że dołączą się skończyło.

Akcja XII

Zaprosiłem managera PATAŁACHÓW, aby odwiedził DEBEŚCIAKÓW i wysłuchał Ich zażaleń na pracę drugiego zespołu. Spotkanie polegało na wylewaniu żali dlaczego PATAŁACHY są PATAŁACHAMI i niczym konstruktywnym się nie skończyło.

Akcja XIII

Zobowiązałem się, że usunę pewne blokady zewnętrzne, żeby pokazać DEBEŚCIAKOM, że się da. Tym samym świadomie wszedłem do systemu jako międzymordzie pomiędzy teamem, a resztą świata. W trakcie okazało się jednak, że blokady od początku były w zespole. Poczułem się jak idiota. Podzieliłem się tym z chłopakami. Przeprosili.

Akcja XIV

Kolejny raz zaproponowałem cykliczne spotkania w składzie PO, lider, ja. Podczas pierwszego i jedynego spotkania poprosiłem lidera i product ownera o pomoc w ratowaniu sytuacji i zespołu, który stacza się na dno. W odpowiedzi otrzymałem „środkowy palec” i dowiedziałem się od lidera zespołu, że nie będzie mi pomagał, ponieważ to moją odpowiedzialnością jest robienie retrospektyw i naprawienie sytuacji. W tym samym czasie najbardziej doświadczony domenowo DEBEŚCIAK, trochę koń pociągowy zespołu, złożył wypowiedzenie. Był jednocześnie najbardziej trolującym i agresywnym. Po złożeniu wypowiedzenia wzniósł się na wyżyny trolowania i narzekania na wszystko, wpływając jeszcze bardziej na resztę zespołu.

Akcja XV

W międzyczasie dowiedziałem się przypadkiem, też że lider złożył wypowiedzenie. Próbowałem się czegoś dowiedzieć. Lider poprosił mnie jedynie, abym nie przekazywał informacji zespołowi. Uszanowałem prośbę. Nie zdradzając szczegółów, poprosiłem jedynie zespół PATAŁACHÓW o większą niż zwykle wyrozumiałość, ze względu na trudną sytuację w DEBEŚCIAKACH. W ślad za liderem poszedł product owner, choć zrezygnował już w sposób jawny.

Ostatnia akcja XVI

Po wyczerpaniu moich pomysłów i kolejnych nieprzespanych nocach, zgłosiłem się w końcu o pomoc do managera zespołu. Przedstawiłem mu wszystkie kroki i akcje, które podjąłem. Rozłożyłem szczerze ręce bezradności, powiedziałem, że dalej nie ujadę i poprosiłem o pomoc. W efekcie manager siedział z zespołem przez tydzień bądź dwa. Po kilku kolejnych wraz z przełożonym product ownera ustalili twardy deadline na przekazanie PATAŁACHOM całości prac nad produktem. DEBEŚCIAKI otrzymały zaś propozycję wspólnego dołączenia do prac nad niemal dowolnym wybranym przez siebie innym produktem w firmie. Nie wybrali. W konsekwencji każdy indywidualnie otrzymał od managerów pytanie gdzie by chciał pracować oraz indywidualną ofertę. Dwie osoby skorzystały. Reszta, jak już wspomniałem na początku artykułu, po kolei złożyła wypowiedzenia. Wraz z nastaniem deadline’u, PATAŁACHY przejęły produkt, a burzliwa historia zespołu DEBEŚCIAKÓW zakończyła się.

Wnioski

Od wyżej przytoczonych wydarzeń minęło wiele czasu. Starałem się opisać przypadek możliwie pełnie korzystając z moich notatek z ówczesnego czasu. Zdaje sobie jednak sprawę, że nie byłem w stanie wyłuskać wszelkich niuansów sytucyjnych. Wnioski zaś mogę podać jedynie ze stanu umysłu na dzisiaj. Część z nich jest jednak ze mną od dawna w tym ten najważniejszy.

Praca scrum mastera w organizacji to często sprzątanie po niedoświadczonych managerach. Gdyby ktoś Ich dobrze nauczył jak dbać o ludzi, to nasza scrum masterska praca byłaby niepotrzebna.

Nasuwają mi się jeszcze następujące:

• Stawiam hipotezę, że zespół DEBEŚCIAKÓW padł ofiarą braku zainteresowania managementu Ich poczynaniami. Nikt nie interesował się co tam się dzieje w środku, a zespół zamykał się na świat zewnętrzny. Przez lata zajmowali się produktem wymagającym dużej odpowiedzialności. To był Ich skarb. Po drodze pojawiały się niezaopiekowanie przeszkody czy oczekiwania, nieskatalizowane napięcia oraz kolejne dołączające do produktu zespoły o mniejszym doświadczeniu domenowym. Tymczasem zespół wciąż czuł się w 100% właścicielem produktu, który rozwijał. Podświadomie nie dopuszczał innych do Ich skarbu. It came to me, my own, my love, my precious. – Gollum
• Warstwa managementu, która wspiera zespół i poszczególnych ludzi, ale też ma uprawnienia do twardego interweniowania w zasadnych przypadkach jest niezbędna. Sytuacja, w której komunikacja w zespole wchodzi na poziomy typu “niech ci pier….ni managerowie wezmą się do roboty” jest oczywiście nieakceptowalna. To wulgarne i agresywne wołanie jest jednocześniem rozpaczliwym wołaniem o pomoc wypowiedzianym nie wprost, być może w wyniku nieuświadomionych potrzeb i emocji.
• Decyzje managementu w tym przypadku były w mojej opinii sprzątaniem po poprzednikach i trochę odcięciem się od problemu.
• Lider zespołu utożsamiał się z postawą zespołu, a powinien wznieść się ponad podziały i stanowić jeśli nie przeciwwagę, to przynajmniej głos rozsądku. Lider powinien piłować zapędy w hejtowaniu PATAŁACHÓW, a tymczasem sam je wręcz podsycał, rysując memy z PATAŁACHAMI (w zawoalowanej formie, tak żeby tylko DEBEŚCIAKI wiedziały o co chodzi) i wieszając je na ścianach w pokoju.
• Brać odpowiedzialność za swoje decyzje i jednocześnie nie przejmować się rzeczami, na które nie ma się wpływu. Bezsenne noce, które sobie zafundowałem wynikały z mojego przesadnie dużego poczucia odpowiedzialności za uzdrowienie sytuacji i wyprowadzenia zespołu na prostą oraz poczucia rzekomego wpływu na przygniatającą większość podejmowanych wówczas decyzji, które moimi nie były.
• Nie współpracować z zespołem, managementem czy organizacją która tego nie chce. Gdybym dzisiaj spotkałbym się z podobnym przypadkiem, prawdopodobnie stawiałbym podobne pierwsze kroki. Odmówiłbym jednak współpracy z tej klasy i kultury zespołem już po kilku moich akcjach. Szkoda marnować życia i energii na pracę w zespole, w którym na dzień dobry jesteś szpiegiem imperium zła i nikt Ci nie pomaga.
• Zgadzam się z tymi, którzy twierdzą, że scrum master jest katalizatorem zmian. Rzadko natomiast spotykam się z katalizowaniem zmian jak opisane powyżej, tak zwanych negatywnych. Czy scrum master ma prawo przyspieszyć rozpad zespołu? Czemu nie? A czy scrum master może wręcz rozbić zespół, który i tak jest w fazie agonalnej? Czemu nie, zwłaszcza jak ma formalne ku temu uprawnienia? I oby zrobił to jak najwcześniej. Czy product owner może zatrzymać rozwój produktu? Czemu nie, zwłaszcza jak feedback z rynku jest jednoznacznie zły? I oby zrobił to jak najwcześniej. Widzicie podobieństwa?
• Hermetyczna kultura organizacyjna zespołu nie jest ani dobra ani zła. Tak zwany “culture bubble” może po prostu albo wspierać albo nie wspierać działań organizacji, firmy, czy też większej całości. Wszystko zależy od kontekstu. Na moim blogu podaję krótką historię – kontrprzykład zespołu o wyjątkowej kulturze, który wspierał organizację i klientów swoimi działaniami. Czytaj więcej w A Short Story Of An Antifragile Team.

Pośród wielu cnót, Scrum Master ma mieć odwagę. Skoro od pewnego czasu, w akapicie o wartościach głosi tak sam Scrum Guide i skoro Gunther Verheyen – jedna z najznamienitszych postaci kojarzonych ze Scrumem – głosi o tym już od kilku lat na swoim blogu, to tak musi być i basta!

Co to jest odwaga Scrum Mastera?

No właśnie. Jak to jest z tą odwagą? W jakich zachowaniach Scrum Mastera ona się przejawia? Czy da się jej nauczyć? A może gdzieś ktoś certyfikuje z tej wartości Scrumowej? Może dzięki temu certyfikatowi można zwiększyć swoje szanse na rynku pracy i opisywać swoje stanowisko mianem COSMO – Certyfikowany Odważny Scrum Master, O! Nie znam uniwersalnych odpowiedzi na powyższe pytania. Poniższe przykłady są przykładami Scrum Mastera PiMy, moimi przykładami. Dla mnie są ważne i doniosłe. Dla Ciebie bedą inne.

Odwaga = Strach

Odwadze niezmiennie towarzyszy strach. Mi również często towarzyszy. To co mi jednak dodaje odwagi kiedy się boję to fakt, że decyzje, które podejmuję, podejmuję w zgodzie z wewnętrznym kompasem, w zgodzie z moimi wartościami. Poniższe przykłady ułożyłem mniej więcej w kolejności od największego do najmniejszego strachu jaki czułem robiąc daną rzecz, bądź jaki wydaje mi się, że czułem. Uznałem, że wulgaryzmy zacytuję w niezmienionej postaci, aby pokazać z jak silnie manifestowanymi emocjami Scrum Master może mieć kontakt w swojej codziennej pracy. W wyniku podejmowania trudnych i wymagających ode mnie odwagi decyzji nic złego się nie stało. Ani mi ani mojemu otoczeniu. Jeśli po przeczytaniu poczujesz się lepiej niż przed, bądź jeśli któryś z przykładów zainspiruje Cię do działania, osiągnę swój ukryty cel :p

Ujebię Ci łeb!

Po nieudanym sprincie Chief PO przyszedł na przegląd prac. W obecności całego zespołu (Produkt Ołnera i Deweloperów) na początku review w ciszy pokazał film, w którym zbir strzela w lesie w tył głowy gościowi, który właśnie wykopał sobie grób. Po odtworzeniu filmu z uśmiechem na twarzy zadeklarował, że “to ja tutaj trzymam pistolet”. W pierwszej chwili przeżyłem szok. Po chwili jednak ze ściśniętym gardłem zapytałem, czy to jakaś forma zastraszenia zespołu. Otrzymałem odpowiedź, że “nikt tu nie stosuje mobbingu” oraz, że „nade mną też ktoś trzyma pistolet”. Wyszedł. Kolejnego dnia w firmie odbywała sie tak zwana wigilia pracownicza. Stałem w grupie kilku PO. Chief PO podszedł do nas i bez żadnego słowa wstępu, przy świadkach, zafundował mi wyjątkowej urody serię wulgarnych inwektyw. O tym, że „nie jestem ponad zespołem”, że „kiedy On prowadził biznes, to ja z koleżkami piłem winka w bramie”, że „należę do Niego, a nie do rodziny”, że „znajdzie sposób i ujebie mi łeb”. Nazajutrz poinformowałem przełożonego o zajściu. Poprosił mnie o milczenie w sprawie. Nie starczyło mi wtedy odwagi, aby iść wyżej. Dopiero po blisko 2 latach udało się gościa dyscyplinarnie wywalić z firmy po serii wywiadów z pracownikami. Opisałem swoją wersję zdarzeń jednemu z dyrektorów IT. Na szczęście nie musiałem zeznawać w sądzie, ale pisząc to dzisiaj czuję emocje prawie jak wtedy. Mogłem przecież się wtedy nie odezwać, mogłem nie iść do przełożonego, mogłem również w rozmowie z dyrektorem powiedzieć, że nie pamiętam. Tyle, że chciałem. Działałem w zgodzie ze swoimi wartościami. Odwaga?

W kanbanie nie ma pierdolonych Scrum Masterów

Miałem kiedyś managera, którego dzisiaj cenię za wiedzę, wszechstronność i doświadczenie, choć wtedy nie zgadzałem się z Jego metodami pracy z ludźmi. Jako początkującemu Scrum Masterowi świat wydawał mi się wówczas zero-jedynkowy, toteż podczas cyklicznych spotkań ochoczo i gorączkowo wchodziłem z moim przełożonym w filozoficzne dyspóty o sposobach pracy z ludźmi. Dzisiaj rozegrałbym sytuację zdecydowanie bardziej dyplomatycznie, ale wówczas szedłem po bandzie. Po jednej z licznych przepychanek słownych, manager nie wytrzymał i wraz z innym Scrum Masterem dostaliśmy na twarz: „W kanbanie nie ma pierdolonych Scrum Masterów. Wypierdalać!”. Kilka dni później dostaliśmy ultimatum. Albo wracamy do pracy jako deweloperzy albo idziemy sobie gdzie indziej zbawiać świat scrumem. Kolega wrócił. Ja poszedłem dalej za głosem serca. Kilka lat później na konferencji dziękowałem owemu managerowi, za to, że wywalił mnie wtedy z pracy. Dzięki Niemu zrozumiałem, że chcę być Scrum Masterem. Odwaga?

Martwy SM to bezużyteczny SM, czyżby?

Któregoś dnia szef IT ściągnął ludzi z urlopów, zebrał zespół Scrum Masterów, w którym pracowałem i obwieścił nam, że następuje redukcja etatów. Siedzieliśmy tak sobie w salce i po kolei byliśmy wzywani na rozmowę. Część osób wracała spokojna, część ze łzami w oczach. Reakcje były tak różne jak różni ludzie. Trafiłem do nielicznej grupy uprzywilejowanych, którzy zachowali pracę. Pozostali z uprzywilejowanych podpisali przedstawione Im dokumenty i zachowali prawo odbijania codziennie karty. Moment jednak, w którym przedstawiono mi dokumenty do podpisania, był jednym z trudniejszych w mojej karierze. Rozumiałem decyzję oraz zmianę kierunku rozwoju w firmie jednak fundamentalnie nie zgadzałem się ze faktem zwalniania koleżanek i kolegów. Jednocześnie myślałem o synach, żonie i co dalej z zapewnianiem tzw. bytu. Musiałem wybrać: dalsza bezpieczna pensja czy moje wartości? Wybrałem wartości i nie podpisałem dokumentów. W zamian zyskałem kilka miesięcy fantastycznego slack time, który poświęciłem między innymi na opiekę nad synami. Dzięki temu wydarzeniu wkrótce wybrałem jeszcze ciekawszą pracę i byłem bardziej użytecznym SMem. Odwaga?

Pewna kasa czy niepewna nauka?

Przykład może trochę bardziej ogólny niż praca Scrum Mastera, ale dzięki niemu pewnie zostałem SMem. Wiele lat temu szukałem pracy we Wrocławiu, do którego przeniosła się moja przyszła żona. Wynajmowaliśmy wtedy zimny pokój na peryferiach Wrocławia z zagrzybioną łazienką i wątpliwym towarzystwem. Pamiętam, że otrzymałem wówczas jednocześnie dwie oferty pracy. Jedna z nich była bardzo lukratywna i oferowała pracę w firmie o tak zwanej ugruntowanej pozycji na rynku. Druga oferta, znacznie mniej płatna, niepewna, jednak potencjalnie oferująca niesamowite możliwości nauki, spłynęła do mnie z portalu społecznościowego, w którym wówczas pracowało 5 czy 6 osób. Wybrałem naukę zamiast bezpieczeństwa jakie dawała wysoka pensja i tym samym na blisko 4 lata trafiłem do Naszej Klasy, w której przeżyłem jedną z większych przygód życia. Od niemal początków istnienia portalu zajmowałem się tym, czym akurat trzeba było się zająć: webdewelopmentem, administrowaniem baz, architekturą portalu, product ołnerowaniem, itp. Wreszcie trafiłem na pierwsze szkolenie ze scruma i połknąłem bakcyla. Poznałem też niesamowitych ludzi, a w międzyczasie moja pensja mocno przebiła ofertę drugiej firmy. Czy istniało ryzyko, że się nie uda? Sure. Czy było warto? Bardzo. Odwaga?

Value for money, a może jednak money for value?

Inna historia. Pracowałem jako Scrum Master w zespole, który oferował swoje usługi klientowi zza granicy w modelu rozliczeń opartym o Time&Material. Klient podobnie jak inni płacił za poślado-godziny wypracowane na Jego rzecz. Jako, że zarówno klient jak i członkowie zespołu bardzo dużo uwagi przywiązywali do ciągłego rozwoju i wyciągania wniosków, zaczęliśmy dostarczać usługi o coraz wyższym poziomie zaawansowania. Od ogarniania kodu, architektury, wdrożeń, testowania, poprzez wsparcie UX, budowę prototypów, analizy konkurencyjnych serwisów, warsztaty strategiczne z klientem, zajmowanie się analityką, heatmapami, wdrażanie oparte na feedbacku z rynku, aż do przejmowania odpowiedzialności za produkt i pełnego skupienia na celach biznesowych klienta. Ciągły rozwój teamu (w tym mój) był swego rodzaju biletem w jedną stronę. Albo klient dostarczał teamowi nowych trudniejszych wyzwań, które były realizowane w tym samym czasie albo poprzez zwiększoną skuteczność, zespół był w stanie realizować te same zadania w krótszym czasie. Z racji tempa nauki zespołu i mojego, usługi SMa zaczęły również z czasem zajmować mi coraz mniej czasu. Zdałem sobie sprawę, że spokojnie byłem w stanie pracować na pół etatu. Jednocześnie model firmy nie dawał możliwości pracy w niepełnym wymiarze godzin za niższą pensję, a inni klienci nie byli gotowi, aby płacić za rolę SMa. Dodatkowo mój bezpośredni wpływ na zespół biznesowy klienta był ograniczony ze względu na fakt, iż nie miałem możliwości pracy za granicą. Chciałem, aby klient płacił za moją realną pracę „money for value”, a nie dupogodziny przesiedziane w biurze. Innymi słowy, miałem do wyboru. Siedzieć połowę czasu, nic nie robić, kasować klienta za to i pobierać pensję albo zadziałać w zgodzie z wewnętrznym kompasem i w przyjacielskiej atmosferze rozstać się z firmą, a co za tym idzie z klientem. Wybrałem to drugie. W ten sposób zyskałem więcej czasu dla rodziny i dla siebie. W ten sposób powstał również mój blog i właśnie powstaje ten artykuł. Odwaga?

Szlifowanie inicjatyw

Nowy szef IT podjął decyzję o połączeniu działów IT i BIZ w jeden. Zlikwidował stanowiska managerskie i ogłosił, że odtąd każdy w firmie może zgłosić swoją inicjatywę projektową. Jeśli inicjatywa zostanie pozytywnie zaopiniowana przez zarząd firmy, stajesz się właścicielem inicjatywy, dobierasz zespół, którego stajesz się szefem i jedziesz z koksem z projektem. Od tego momentu, potencjalnie każdy mógł być mini CEO, szefem, jeśli tylko miał potencjalnie dobry pomysł i ludzi, którzy za Nią, za Nim pójdą. Decyzja spowodowała wielkie poruszenie w firmie, wiele ekscytacji, ale też wiele naturalnytch obaw. Wobec pytań co dalej ze mną, co jeśli nie znajdę miejsca w nowej „strukturze”, co z moim obecnym produktem, usługą, itp. poczucie bezpieczeństwa wielu ludzi, co zrozumiałe, spadło drastycznie. Moje jako SMa również. W zaistniałej sytuacji jako SM zrobiłem kilka rzeczy:

• Po pierwsze pokazałem, że się da i jako pierwsza osoba w firmie zgłosiłem publicznie projekt VISUELLA, który choć nie został przychylnie przyjęty przez zarząd wart był dla mnie każdych pieniędzy, choćby przez strach przed i stres jakich doświadczyłem podczas prezentacji go przed najważniejszymi ludźmi w firmie,
• Po drugie zorganizowałem ogólnofirmowe cykliczne warsztaty „szlifowania inicjatyw”, które polegały na prezentowaniu przez pomysłodawców i zbieraniu feedabcku na temat swoich inicjatyw zanim zobaczy je zarząd,
• Po trzecie zająłem się zbieraniem wszystkich informacji o toczących się inicjatywach w jednym miejscu i informowaniem ludzi z firmy o procesie transformacji,
• Po czwarte wreszcie podjąłem się nieudanej próby zwizualizowania całego procesu zgłaszania inicjatyw, która nie wyszła z poniższej fazy prototypu oraz kilku stron na wiki. Nieudanej, ponieważ nie znalazłem zainteresowanych nią odbiorców. Odwaga?

Odwaga, zuchwałość czy brawura?

Nie wiem, gdzie leżą granice pomiędzy odwagą, zuchwałością, brawurą, a nawet głupotą. Być może kiedyś skończę jak gość ze zdjęcia z tego artykułu. Zamęczą mnie na śmierć za herezje albo inne takie. Wielokrotnie jednak w swojej pracy robiłem rzeczy dla mnie niewygodne bądź wizualizowałem niewygodne rzeczy dla innych. Choćby makatkę przy zarządzie czy dziesiątki innych wizualizacji, które opisałem w artukule Real-life Agility Metrics And Visualizations That Will Lead You Towards Evidence-Based Decision-Making.

Robiłem też rzeczy zuchwałe. Po tym jak management ogłaszał transformacje, wsyłałem zaczepne maile do kilkuset osób w firmie z treściami typu „Co zrobisz już dzisiaj skoro nikt za Ciebie nie odpowie na pytania takie jak: Kto za miesiąc będzie Twoim szefem? W jakim zespole będziesz za miesiąc pracował(a)? Nad jakim produktem będziesz za miesiąc pracował(a)?”. Próbowałem wdrażać w korpo sposoby pracy oparte o hipotezy. Jako Scrum Master walnie się kiedyś przyczyniłem do rozbicia zespołu, w którym pracowałem. Po owym rozbiciu większość jego członków złożyło wypowiedzenia, a ja dzwigałem brzemię zabójcy zespołu :p. Być może niektóre z tych rzeczy były brawurowe czy wręcz głupie. Choćby dzisiaj. Zamiast na tak zwanym bezrobociu aktywnie szukać pracy, po 5 godzinach i 40 minutach od rozpoczęcia, kończę pisać ten artykuł.

Choć wszystkie wyżej wymienione sytuacje strachem były podszyte i wymagały ode mnie odwagi, z perspektywy czasu okazywało się jednak, że strach miał wielkie oczy, a wymienione rzeczy warto było zrobić. Po ich zrobieniu często moje życie zmieniało zupełnie bieg. Na lepszy, bardziej wartościowy. Ufam, że ten artykuł też je tak zmieni 🙂

Dzisiaj rano z synami w drodze do przedszkola. Powietrze było mroźne, a autobus nie przyjeżdżał dłuższą chwilę. Policzki i noski chłopaków poczerwieniały z zimna. Po kilku przystankach wysiedliśmy, a synowie pełni radości pobiegli do przedszkola nie bacząc na śliski chodnik i mróz. W końcu w przedszkolu czekały na nich koleżanki i koledzy, których bardzo lubią i z którymi się świetnie bawią, troskliwe i szanujące panie oraz przygotowania do przedstawienia jasełkowego.

Idę do pracy

Sytuacja z rana skłoniła mnie do refleksji nad moją codzienną drogą do pracy. Przez chwilę chciałem napisać, że mam szczęście pracować w miejscach, które mi odpowiadają. Zdałem sobie jednak sprawę, że skłamałbym pisząc, że mam szczęście. To nie szczęście. To się nie przydarza samo. Pierwszą pracę podjąłem wiele lat temu trochę z przypadku,. Niemniej jednak każdej kolejnej zmiany środowiska dokonywałem coraz bardziej świadomie. Każda wymagała ode mnie większego „poświęcenia” i przeżycia większej „żałoby” po utracie. Dobrze mi wszakże się pracowało. Każda kolejna zmiana wyrzucała mnie z mitycznej „strefy komfortu”, każda przybliżała mnie też do mojego wymarzonego, idealnego miejsca pracy. Przez idealne rozumiem, takie miejsce, do którego jak te dzieciaki codziennie rano szedłbym z uśmiechem, pełen zapału. W końcu w tym miejscu czekałyby na mnie koleżanki i koledzy, których lubię i z którymi mi się dobrze pracuje, troszczący się i szanujący management oraz przygotowania do kolejnych ciekawych wyzwań. Jako, że mam to „szczęście” i kilka swoich lekcji już odrobiłem, zachęcam Cię do zadania sobie kilku pytań, dzięki którym być może odrobisz swoje.

Do pracownika

Czy zanim wyjdziesz do pracy, zadajesz sobie pytanie o to, co Cię tam czeka?

Czy jak już jesteś w drodze do pracy, to czy masz wypieki na twarzy na myśl o tym, jakie fajne rzeczy tam zrobisz?

Jeśli nie masz wypieków, to czy zastanawiasz się, nie czekając na management, szefa, kolegę z zespołu, co Ty możesz zrobić, aby zmienić sytuację? Co robisz, aby Ci się lepiej pracowało? Co zmieniasz? Co robisz, aby Twoim koleżankom i kolegom z zespołu pracowało się lepiej?

Do szefa

Czy zanim wyjdziesz do pracy, zadajesz sobie pytanie o to, co tam czeka Twoich podwładnych?

Czy jak już jesteś w drodze do pracy, to czy masz wypieki na twarzy na myśl o tym, jakie fajne rzeczy zrobią tam Twoi podwładni?

Jeśli nie masz wypieków, to czy zastanawiasz się, nie czekając na feedback od podwładnych, co Ty możesz zrobić, aby pomóc zmienić Ich sytuację? Co robisz, aby lepiej Im się pracowało? Co zmieniasz? O co pytasz? Jak się o Nich troszczysz? Ile razy w zeszłym tygodniu rozmawiałaś ze swoimi podwładnymi o Ich pracy, życiu, obawach i marzeniach?

Do pracodawcy

Czy zanim stworzysz miejsce do pracy, zadajesz sobie pytanie o to, co tam czeka Twoich pracowników?

Czy jak już jesteś w procesie tworzenia miejsca pracy, to czy masz wypieki na twarzy na myśl o tym, jakie fajne rzeczy zrobią tam Twoi pracownicy?

Jeśli nie masz wypieków, to czy zastanawiasz się, nie czekając na feedback z rynku, co Ty możesz zrobić, aby zmienić sytuację? Co robisz, aby chcieli przyjść i zostać w Twojej firmie? Co zmieniasz? O co pytasz innych ludzi, którzy tworzą miejsca pracy? Jak troszczysz się o swoich pracowników? Ile razy w zeszłym tygodniu rozmawiałaś ze swoimi pracownikami o ich pracy, życiu, obawach i marzeniach, planach, celach?

Idź do pracy

Jako osobie, która wielokrotnie w życiu szła do pracy, daję sobie prawo do zachęcania Cię, po pierwsze do zadawania sobie powyższych pytań, a po drugie do zmieniania pracy i szukania nowych lepszych dla Ciebie dróg. Nigdy się nie dowiesz czy decyzja była dobra, dopóki jej nie podejmiesz i czegoś nie zmienisz. Jeśli zaś z pełną otwartością przyjmiesz rzeczy, które w nowym miejscu Cię spotkają, przekonasz się, że każda decyzja była w jakimś sensie dla Ciebie dobra :).

Ja swoją już podjąłem. Pomimo, iż pracuję w najlepszym z dotychczasowych miejsc, w najlepszym z dotychczasowych zespołów, od początku lutego znowu coś zmieniam. Idę do pracy.

A Short Story Of An Antifragile Team

Wikipedia says that antifragility is a property of systems that increase in capability, resilience, or robustness as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures. Jennifer Havens, in her article titled Building an Antifragile Team, uses the term in a reference for teams working on products.

Evolution Of A Team

Before I share a very general story about the team I am working in, I would like to explain how I sense the evolution of a team. First, we work in some kind of chaos. No processes, no tools, no interactions. Then we try to embrace uncertainty with some kind of process, the waterfall-ish one or, if we’re lucky, the scrum-ish one. We have some interactions, several processes, and lots of tools. Then we „do agile”. We inspect and adapt, we value interactions, we sometimes deliver value for customers. Going further we become a truly agile and a resilient team – the one that stays in a good shape after unexpected events, changes in priorities, etc. We deliver more and more value in shorter and shorter time spans. At the end of a journey, the end I am able to imagine today, I see an antifragile team. The team that becomes stronger after each stress, shock, volatility, noise, mistake, fault, attack, or failure. This team not only delivers often more mythical value to the customer. It invents new ways of working. It uses pivots regularly and changes priorities as needed. It experiments. It becomes stronger after each team composition change. It has built-in mechanisms of exchanging knowledge and competencies like hiring people with different point of view, different backgrounds or competencies, etc.

Are We Antifragile Yet?

It would be arrogant to say so. In fact, I don’t know. I don’t know if such teams exist at all. However, I observe some good indicators we may become one in the future. I share „my individual” point of view. It can naturally be different from the points of view of other team members.

We are humans therefore events, emotions, and behaviours treated commonly as „negative” ones, are an integral part of our daily work, either work of individuals, teams, managers or the whole companies. Although I consider both „bad internals” and „good internals” as equally important, this time I want to share only the positive ones. Why? Firstly because I believe focusing on what’s postive brings bettre results. Secondly, because it wouldn’t be professional to reveal bad things about the team, managers or company without their explicit permission to do so. And finally, I intentionally write about The People as, at the end, they are the most important ones. The two remaining pillars of product development, The Product and The Process for later writing in my backlog I remain.

We integrate

One may immediately think about code integration stuff. As we have microservice oriented architecture based on AWS and other stack, yes, we are able to integrate code several times a day. I rather speak about something wider, about people integration. We integrate a lot during a day by speaking about every possible subject or sharing on our skype plenty of professional stuff intermingled with LOL content. We integrate several times a week with our client on hangouts. We integrate business items and ideas with our end-users doing weekly deployments. We go together to buy sandwiches. We have peer pressure and beer pressure :p. We integrate regularly outside the office. I believe none of the so-called professional subjects haves been touched on our yesterday’s integration.

We empathise

As I wrote above, I believe we speak about everything. We share our feelings and speak openly about some hard and uneasy experiences each of us faces from time to time. We empathise with each other. We understand that people have good and bad time at work, at home, at a gym, etc.

We care

Once someone is late, we call and ask if everything is ok. If someone is sick or feels like a shit, we do not eagerly ask what’s wrong? We let people go home if they need so. We care how other team members feel, sometimes in our specific and weird ways. The ways are rather non-publishable :p.

We share

I’ve heard once a feedback from the former team member that he treats speaking about personal stuff as an unprofessional behaviour. How the hell people who spend together most of their time, can become a professionally communicating team, if they don’t speak about various areas of life including personal observations, beliefs, stories?

We learn

We care also in terms of our development. Healthy peer pressure is constantly present. Our QA expert called „The Eye” reports bugs „in your face” and doesn’t omit even the smallest issues. Some developers push mates to code review or merge earlier. All try to constantly learn new things and exchange frontend and backend tasks regularly. We exchange who presents the product during the product review. Our scrum master or product owner exchanges duties, sometimes for many weeks. Our PO asks if we can deliver more and developers push him back for better acceptance criteria. Our scrum master was once a tester for 3 weeks and we survived :p

We remain small

We don’t let our team members count to grow beyond measure. We remain a small team and push ourselves to do more valuable work for a client not by scaling our team and our current services but by learning new things and scaling level of services we offer. Most of the team members are currently being considered to be promoted.

We have fun

LOL content is ubiquitous in all our communication channels. We laugh in the team and with our client on our product reviews or daily catch-ups. Sometimes we permit ourselves to be terrible trolls and use language that is far from being politically correct. We prepare sometimes easter eggs for the client. We collect retro turbo gum stickers which cover all our product’s user personas on our wall. We occasionally send some turbo gums to our client as well. We play some games regularly like HaxBall. We tried once to play the Remove the Carcass game.

Are we resilient yet?

I am sure, we are. For the last 8 months, the team has faced so many circumstances commonly considered as the bad, the hard, the uneasy, or event the disturbing ones, that I assume if we haven’t been resilient, we would never be able to survive.

So, perhaps we are antifragile?

I don’t know. This journey never ends. As long as:

• the business priorities and market demand changes,
• the team consists of people not thinking the same way,
• the team is relatively small,
• the team consists of people with a various skill set and various years of experience,
• the team composition changes from time to time,
• the team offers more advanced services for a client and end-users,
• the people exchange knowledge,
• and finally, as long as the people laugh and share their stories, one day they will become one for sure 🙂

I strongly believe I am currently working in the most advanced, open and matured agile team in my career. It’s pity I will soon be no longer a part of this fantastic bunch of people. But live’s going on. I will take my learnings and stories to another team or organisation.

THANK YOU !!!

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

The first of the 12 principles behind Agile Manifesto states: “Our highest priority is to satisfy the customer through an early and continuous delivery of valuable software”. In my opinion, the sentence is so powerful, dense and hard to implement, that once you try to remove any of its parts from your approach, you simply loose the spirit, the heart of agile software delivery. In general, I prefer to write about specific real-life examples of what I tried, done or seen. This time I would like to leave you with some questions instead.

Our highest priority

I am constantly faced with multiple issues, stories, targets, focuses, etc. that are all equally important. It’s extremely hard to have one priority. You need to be focused not only on an individual, personal level but also on a team’s level, sometimes even on a company level. Constant focus drives constant learning of new things, skills and approaches. This drives constant change. Constant change drives constant going out of individual’s and team’s comfort zones. How many times have you met an individual team member, a product owner, a product manager having one priority? How many times have you met a team which has one? Have you ever worked in a company having one?

Satisfying the Customer

I intentionally wrote Customer using a capital letter. The Customer is one and only one reason for which any product team exists at all. How many times have you met a team for which satisfying the Customer was really the highest priority? Rarity level of such teams is comparable to Yeti. During my almost 20 years career, I met around 5 such teams. Not because people weren’t skillful, engaged, open and eager to achieve something special for their Customers, but rather because an environment to which they have been „thrown”, wasn’t helpful and supportive.

Through early and continuous delivery

How early you know your code failed? How early you see red alert yelling your build shall not past? How early a teammate reviews and tests your code or accepts your feature before deployment? How early your delivery takes place? How early you gather valuable feedback from your end-users so you can learn faster?

Valuable software

And finally, Her Majesty, The Value. There are countless articles out there describing what value is and how an agile team brings this value. Simultaneously, how many times have you met or worked with a team of which every single member was ready to openly and sincerely state she or he delivers really valuable software that has a positive impact on users and business metrics? How many times have you worked in a team which each iteration have been treated as the last one: either we deliver value or we die?

From Velocity to Time To Feedback

I don’t know answers to all these questions. However, if you put the title of this article into a Google search, you will get over 7,000 strict results. It’s a lot. I believe there are many people out there who know the answers to some of the questions stated.

My first simple recommendation towards answering is to look at your data and simply measure it. Of course, you can measure velocity and other agile stuff. But what if you measured these ones instead?

• How many seconds before you know your commit failed?
• How many minutes till the red alert yelling your build shall not past?
• How many hours before a teammate reviews and tests your code or accepts your feature before deployment?
• How many days before delivery takes place?
• How many iterations, sprints or cadence meetings before you gather valuable feedback from your end-users so you can learn faster?
• Do you measure cycle time and shorten it?
• Have you tried to measure the systemic time to market and optimize it?
• Have you ever tried to measure time to feedback and tried to constantly shorten this time on a unit test, code review, acceptance tests, product owner’s or end user’s approval levels?

Scrum masters and audio engineers use similar signal-driven decision-making process:

AE: goes to the new band or place (e.g. stadium, arena, studio)
SM: goes to the new team or environment (e.g. company, division, room)

AE: has some audio console presets which define an initial quality of a sound
SM: has some predefined metrics/indicators which define an initial agility level of a team

AE: by listening carefully she modifies signals to produce the high-quality output signals
SM: by observing carefully she modifies feedback to produce the high-performing team.

"Zagraj w grę "USUŃ TO ŚCIERWO"" https://t.co/tdkRUVyJOJ by @AgilePiMa on @LinkedIn

— Piotr Maksimczyk (@AgilePiMa) September 6, 2016