Real-life Agility Metrics And Visualizations at Scrum Days 2017

Several weeks ago, during the Scrum Days 2017 conference,  I was honoured to give a talk about real-life agility metrics and visualisations I have been trying for years.

The presentation is available here. Please watch in the presentation mode as there are over 100 interactive steps/animations available.

By inviting you to my world of metrics and visualisations, I tried to provoke you to:

  • check your intuitions against the data,
  • analyse trends as agility has no end-state,
  • measure with the Agile Manifesto in mind,
  • experiment with metrics,
  • and finally don’t be afraid of FAIL, as FAIL means „First Attempt In Learning”

You could see the process of building the ultimate agility metric, the evolution of process metrics from vanity ones to evidence-based, and lots of success and fail stories.

I hope my talk didn’t leave you indifferent.

O tym jak jako scrum master pomogłem rozbić zespół produktowy DEBEŚCIAKÓW

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.

Odważny Scrum Master

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 🙂

I visualized my Uber rides

Today I decided to visualize my Uber rides. After around 100 rides in my city Poznań in Poland, I came to the following results.

The most frequent car mark among 17 unique was Skoda (34.9%).

The most frequent car model among 38 unique was Skoda Fabia (25.3%).

 

 

My Most Frequent Uber Rides (by Car Mark)
My Most Frequent Uber Rides (by Car Mark)

 

My Most Frequent Uber Rides (by Car Mark & Model)
My Most Frequent Uber Rides (by Car Mark & Model)