Scrum-Pasożyt, który szkodzi organizacjom

Jest ostatnio moda na teksty krążące w okół hasła agile is dead. Nie jestem ortodoksem i myślę, że do tematu trzeba podejść na spokojnie i bez niepotrzebnych inwektyw. Dlatego dla odmiany proponuję, aby zastanowić się, cóż począć z pasożytniczym podejściem do Scrum i agile w organizacjach.

Z jakiej planety przybył agile coach?

W ewangeliarzu Scruma stoi napisane, że:

• Coaching the team members in self-management and cross-functionality
• Leading, training, and coaching the organization in its Scrum adoption

Zerknijmy również do słownika, by poznać znaczenie słowa coaching. Otóż coaching to:

• the process of training somebody to play a sport, to do a job better or to improve a skill
  • a coaching session
  • I received hours of coaching for my audition
• the process of giving a student extra teaching in a particular subject
  • Extra coaching is available for students who might need a little more help

Zdziwko? Mam nadzieję. Z tajemniczych przyczyn przez lata słowo coaching Scrum Guide było tłumaczone jako kołczuje. W związku z czym całe tłumy nadwiślańskich Scrum Masterów wbiło sobie do głowy, że oto będą kołczować swoje zespoły i organizacje, czyli używać wobec nich metody coachingowej. I hajda ruszyli w rynek zadawać pytania wszystkim. Nawet tym, którzy nie mieli ochoty na nie odpowiadać.

Bazowym założeniem metody coachingowej jest to, że delikwent posiada wszelkie zasoby, aby wykonać zadanie. Większość z tych, z którymi ma pracować Scrum Master tych zasobów nie ma, gdyż brak im wiedzy. Bardzo proszę wbić sobie mocno do głowy, że w organizacjach ludzie najbardziej potrzebują odpowiedzi, a nie pytań. Potrzebują tej wiedzy, gdyż goni ich walec zwinnej transformacji i bardzo chcą się dowiedzieć wszystkiego, co jest im potrzebne. Więc nie wnerwiaj już zestresowanych ludzi zadawaniem pytań z czapy wziętych.

Właściwe tłumaczenie słowa coaching to instruuje. Scrum Master:

• Instruuje the team members in self-management and cross-functionality*
• Leading, training, and instruuje the organization in its Scrum adoption

Scrum Master okiem inżyniera

Jeśli choć trochę otarłeś/aś się o dewelopment, to pewnie kojarzysz akronim SOLID. Szczególnie interesuje nas literka S jak Single Responsibility Principle, która mówi o bałaganie w architekturze wynikającym z nadwyrężania odpowiedzialności bytów. Czyli pakowania w jedną rzecz zbyt wielu rzeczy do zrobienia.

Poniżej narysowałem poglądowo relacje pomiędzy rolami w Scrumie z perspektywy ich odpowiedzialności:

• Product Owner ma zdefiniowane 4 odpowiedzialności
• Developers również cztery
• Organizacja nie jest doprecyzowana, więc może chodzić o managera, jako przedstawiciela organizacji jak również o wszystko co poza zespołem; uczciwie przydzielam więc największą odpowiedzialność
• Scrum Master ma zdefiniowanych 12 odpowiedzialności

W związku z powyższym poglądowy rysunek wygląda tak:

Inżyniera dziwi tu, że Scrum Master ma aż tak dużą odpowiedzialność w porównaniu do reszty aktorów tej tragedii. Czytając wnikliwiej to, czego chce się od Scrum Mastera, trudno oprzeć się wrażeniu, że ma on zajmować się wszystkim tym, czym nie chcą zajmować się inni, czyli pozostałe role. To się nazywa Helper Class.

Helper Class jest pomocny w początkowych fazach refaktoringu (transformacji!), gdyż umożliwia innym klasom skupić się na swoich zadaniach. Gdy kod się stabilizuje, Helper Class staje się antywzorcem, ponieważ siłą rozpędu gromadzi w sobie nadmiarową odpowiedzialność - ogarnia to, co nie pasuje nigdzie indziej, czyli wszystko. Tak właśnie postrzegam sytuację Scrum Masterów - ugrzęźli gdzieś między wbijaniem spotkań, a prowadzeniem fajnych retro.

Ostatecznie w stabilnym kodzie Helper Class należy usunąć, a ichnie odpowiedzialności rozparcelować między inne klasy o wyraźnie wyznaczonym celu istnienia. Tak by to zrobił inżynier.

Tragedia Scrum Mastera

Wspomniane przeświadczenie jakoby istotą pracy Scrum Mastera było kołczowanie zespołu i organizacji, prowadzi do przeświadczenia, że można pełnić tę rolę bez jakiegokolwiek doświadczenia inżynierskiego. Moim zdaniem nie można i szczegółowo to omówiłem w wystąpieniu na temat wszystkich patologii pseudozwinności.

Tragedia takich Scrum Masterów polega na tym, że z powodu braku podstaw rzemiosła lewitują w stronę wszystkiego co "miękkie". Włączywszy w to przytulanie drzew. Gdy zaś zespół odtrąca ten styl, próbują kołczować zarządy firm. Zarządy na to nie idą, bo rozmyty Scrum Master nie jest partnerem do dyskusji dla osób, które głowami odpowiadają za osiąganie celów organizacji.

Natomiast wszystkich tych, którzy twierdzą, że Scrum Master jest psychologiem lub terapeutą zespołu, odsyłam z powrotem na planetę, z której przybyli. Chcesz się wygadać Scrum Masterowi? - luz, żaden problem. Pamiętaj jednak, że grzebanie ludziom w głowach, to poważna sprawa. Przeczytanie książki z analizy transakcyjnej nie oznacza, że nabywasz umiejętności odnajdywania skrzywdzonego dziecka w każdym rozmówcy. Wiesz, jeśli jedynym Twoim narzędziem jest młotek, wszystko zaczyna przypominać gwóźdź...

Psychologizowanie rekomenduję zostawić psychologom, a prowadzenie terapii terapeutom.

Czy Scrum Master jest agentem zmiany?

Spotkałem się gdzieś z proponowaną ścieżką kariery w obrębie tzw. zwinności. Otóż najpierw jesteś team member, potem scrum master, następnie agile coach i w końcu change agent. Kardynalnym błędem zwinnych transformacji jest oparcie zmiany na scrum masterach. Nie, scrum master nie jest agentem zmiany w organizacji. Skutecznym agentem zmiany może stać się ktoś, kto ma możliwość inicjowania i wprowadzania zmian.

Szukając agentów zmian, trzeba zastanowić się, w jaki sposób działają ścieżki dowodzenia w organizacjach. W korporacjach często dowodzenie opiera się na managerach, w softwarehouses wdrażających coś u klientów na kierownikach projektów, w software houses usługowych również na managerach, w niektórych software houses na analitykach, w firmach produktowych na menadżerach produktu, a w maluśkich firmach na właścicielach. To są kandydaci i kandydatki na skutecznych agentów zmian. Kłopot polega na tym, że osoby na tych stanowiskach, to ludzie-orkiestry, ale to oddzielny temat.

Mityczny waterfall, którym obecnie straszy się dzieci, z założenia da się wprowadzić dyrektywą prezesa. Zwinności się nie da, ponieważ zwinność w dużej mierze stawia na postawy i wartości. Procesy i narzędzia są istotne, ale postawy i wartości nieco istotniejsze. Opieranie zmiany na nowozatrudnionych lub nowowykształconych scrum masterach jest działaniem przeciwko istniejącemu systemowi dowodzenia w organizacji. Jest zmianą wykluczającą i generującą konflikt, a nie zmianą włączającą.

Jest taki wymemłany mocno przez szkoleniowców różnorakich frazes, że "ludzie boją się zmian" albo, że "ludzie chcą zmiany, ale nie chcą się zmieniać". Jeśli rzeczywiście tak jest, to przyklejanie plakietki agenta zmiany do nowej roli jaką w organizacji będzie scrum master sprawi, że ludzie będą bać się jeszcze bardziej i jeszcze bardziej nie będą chcieli się zmieniać.

Skutecznymi agentami zmiany mogą być tylko te osoby, które tworzą strukturę dowodzenia w organizacji, ponieważ to oni mają możliwość skutecznego wprowadzania zmian. Zadaniem scrum mastera jest nauczyć ludzi pracy w nowym stylu, wyjaśnić zasady, zorganizować proces, pokazać narzędzia, zrobić inspirującą prezkę i tak dalej. Jednak agentem zmiany, jak wcześniej wspomniałem, jest: manager, kierownik projektów, menadżer produktu, analityk, właściciel - w zależności od organizacji. Scrum master pracuje dla nich. Zatem scrum masterze, scrum masterko - znaj swoje miejsce.

One size doesn't fit all

Mamy w Łodzi słowo szymelek, co znaczy wzór lub szablon. Trudno mi oprzeć się wrażeniu, że jeden szymelek zwinności przykładany jest do każdej organizacji. Omówiłem to bliżej we wspomnianym wcześniej wystąpieniu w części traktującej o fanatycznych ultrasach zwninności, których egzystencjalne pytanie brzmi Czy to jest adżajlowe?.

Autorzy podręcznika napisali while implementing only parts of Scrum is possible, the result is not Scrum i od tego czasu skrammastery rąbią organizacje faktem, że te nie mają Scruma, bo daily za długie, bo PO za słaby, bo backlog nie taki, bo to, bo tamto. Od siebie dodam, że jak na retro męczysz dziesiątą z rzędu technikę udzielania feedbacku na przemian z testem Lencioniego, to też nie jest Scrum, bo się guzik usprawniacie.

Organizacje mają swoje cechy, które nie pasują do ograniczonej liczby zwinnych szymelków.

Szymelek Product Ownera

Product Owner to konkretna osoba i jeśli chcesz zmian w produkcie, musisz przekonać PO. No, różnie z tym bywa. Bywa, że pijesz kawę w kuchni, a obok rozmawiają o właścicielstwie produktu i buuum! Znalazłeś się w odpowiednim miejscu, czasie i właśnie zostałeś nowym PO. Nikt nie zdjął Ci starych obowiązków, doszły tylko nowe. Nie chcesz tego robić, nie masz na to czasu, no ale musisz. Bywa też tak, że rola PO jest wstępem do dalszej kariery w biznesie, do tego aby dostać się do struktur dowodzenia w organizacji. Bywa, że PO ostateczne decyzje konsultuje ze swoim dyrektorem, albo jest więcej niż jeden PO, którzy rozkminiają tematy.

Co słyszy człowiek w opisanych wyżej sytuacjach? Słyszy:

• Nie jesteś prawdziwym PO. Prawdziwym PO jest twój szef.,
• Jesteś Proxy Product Ownerem,
• Tu nie ma Product Ownera,
• Nie jesteś wystarczająco decyzyjny,
• Nie masz odpowiedniego umocowania w organizacji

Szymelek Produktu

Uproduktowianie organizacji to modny kierunek. Jednak jest cała masa przypadków, w których trudno znaleźć jeden produkt wokół którego możnaby zbudować zespół. Jeśli przed transformacyjnym walcem trzydziestoosobowy zespół utrzymywał siedemnaście aplikacji (nie mylić z produktami), to jeśli podzielimy go na parę zespołów scrumowych, te aplikacje również gdzieś trzeba poupychać.

Do tego należy dodać sytuacje, w których zespół nie ma żadnych systemów, tylko np. utrzymuje zbiór raportów potrzebnych komuś tam, albo odpowiada za sieć, albo jeszcze za coś innego.

A już najdziwaczniejszym dla mnie pomysłem jest traktowanie organizacji albo samej transformacji jako produktu i przykładanie do niej tych wszystkich scrumowych szymelków. Przypomina to pchanie szablonu user stories gdzie popadnie. W konsekwencji powstają dziwadła w stylu Jako Spec od bezpieczeństwa chcę, aby system przestrzegał standardu ISO/IEC 27001, po to aby było bezpiecznie.

Szymelek Biznesu

Wyobraź sobie, że pracujesz w wielkim korpo zajmującym się importem śrubek. Ta firma miała kłopot z zarządzaniem stanami magazynowymi śrubek różnego rodzaju. Kierując się racjonalną zasadą buy, don't write zaprosiła jednego z dostawców do wdrożenia oprogramowania zapewniającego kompleksowe zarządzanie miliardami śrubek.

Po jakimś czasie okazało się, że wdrożone oprogramowanie trzeba w niektórych miejscach dostosować do specyfiki firmy. Okazało się również, że upgradowanie oprogramowania zgodnie z cyklem releasowym dostawcy jest kłopotliwe.

Firma znowu podjęła dwie racjonalne decyzje, aby rozsądnym kosztem zapewnić sobie stabilność działania procesów magazynowych:

• stworzyła zespół rozwoju oprogramowania, który był odpowiedzialny za drobne dostosowywanie oprogramowania dostawcy do specyfiki firmy,
• stworzyła zespół utrzymania oprogramowania, który był odpowiedzialny za pierwszą i drugą linię wsparcia oraz wdrażanie nowych wersji systemu, gdy tylko dostawca je wyda; dodatkowo w tym zespole wynajęli jednego dewelopera od dostawcy na zasadzie body leasing, aby zapewnić sobie transfer wiedzy.

No i teraz Twoja kolej. Wpadasz to naszej firmy z szymelkami Scruma wydziaranymi na piersiach i co robisz? Pewnie szukasz produktu. To jest akurat proste, bo system jest jeden. Szukasz zatem Product Ownera i żeby było prawilnie, szukasz go po stronie biznesu. No i zonk, bo nikt nie jest tym zainteresowany.

Po stronie umownego biznesu masz: magazynierów, kierowników magazynu, kupców, sprzedawców, speców od jakości, itd. Ci ludzie chcą używać tego systemu, a nie go rozwijać. Idziesz więc do zarządu i mówisz, że potrzebny 1 etat na PO. Ludzie z zarządu nie są w ciemię bici, więc słusznie kombinują, że przeznaczenie tego etatu na kolejnego kupca albo sprzedawcę, będzie miało większy sens dla firmy. Idziesz więc do pana Cześka kierownika magazynu, który z palca wyznacza Ilonę magazynierkę z działu ocynku jako PO. No! I to był ostatni raz, kiedy widziałeś swoją PO na żywo, bo Ilona ma roboty od cholery i tak jak wszyscy pozostali chce używać systemu magazynowego, a nie go rozwijać. Chętnie powie, jakich nowych ficzerów potrzebuje, ale nie weźmie na klatę pracy nad nimi.

Pewnego razu w naszym śrubkowym kopro pojawiają się dwie ważne inicjatywy:

• firma dokonała wrogiego przejęcia konkurenta produkującego nakrętki i trzeba zintegrować systemy oraz zespoły,
• jeden z prezesów wpadł na pomysł nowego modułu w systemie magazynowym, który wykorzysta AI do kategoryzacji śrubek i nakrętek; prezes ma możliwości, więc wyczarował również 3 etaty na ten cel i zamówił pakiet szkoleń.

Zacierasz ręce, że oto pojawiły się nowe możliwości, na dowiedzenie wszechpotęgi scrumowych szymelków. A tu znowu niespodzianka. Wspomniane inicjatywy to pomysły zarządu, zależą od nich premie, a być może i głowy prezesów. Powołano więc dwa komitety sterujące oraz kierowników projektów do każdej z inicjatyw, raportujących bezpośrednio do członków zarządu. I co teraz?

Ech...firmy nie są ani scrumowe, ani niescrumowe. Nie są też ani adżajlowe, ani nieadżajlowe. Firmy są jakie są. Nie zawracaj więc im głowy swoimi szymelkami, tylko pomóż im rozwiązać ich problemy.

Szymelek agile maturity

Istnieją trzy popularne sposoby na ogrywanie sytuacji, w której aktualna sytuacja organizacja nie pasuje do scrumowych szymelków. Pierwsza brzmi "do was bardziej pasuje Kanban". Przy czym poprzez "Kaban" najczęściej rozumie się to, żeby nie robić tych wszystkich spotkań, przestać męczyć się z celami sprintów, zrobić tablicę z trzema kolumnami i wio!

Drugi sposób jest bardziej wyrafinowany i nazywa się "model dojrzałości". Weźmy dla przykładu artykuł o pięciu poziomach dojrzałości product ownera.

Najniższym jest "scribe" czyli uboga wersja analityka, która chodzi za ludźmi i spisuje, co by tam chcieli. Niżej niż "scribe" nie da się już być, bo wtedy wypadamy poza ramy Scruma. Ja myślę, że to trochę naciągane, bo ów "scribe" to minimalny poziom ładu organizacyjnego, niżej jest już tylko chaos.

Piszę o tym z ważkiego powodu. Oto, dzięki modelowi dojrzałości możemy z pełnym przekonaniem stwierdzić, że niemal wszystko jest Scrumem, ale...na różnych poziomach dojrzałości. Voila!

Model dojrzałości rozmywa granice i znacząco poszerza definicje ról i praktyk. Daje również nieskończoną liczbę okazji do poklepywania się po plecach.

Ostatnim i moim najulubieńszym trikiem jest "to wszystko jest dobre i sensowne, tylko źle to wdrożyliście". To jest tak dobre, że gdyby Schopenhauer pisał "Erystykę" dziś, to omówił by ten tekst w osobnym rozdziale.

Jest świat poza Scrum-szymelkami

Gdzieś pod spodem, pod tymi wszystkimi frameworkami, pod wojnami o story pointy i o certyfikaty leżą bazowe zasady biorące się z Deminga, Goldratta i zdrowego rozsądku. Są to na przykład:

• szybka pętla zwrotna uczenia się,
• ciągłe usprawnianie,
• feedback od końcowych użytkowników,
• jasna ścieżka zgłaszania zapotrzebowania,
• przejrzyste polityki podejmowania decyzji,
• sprawna komunikacja,
• podporządkowanie się konkretnemu celowi,
• nastawienie na fachowość i doskonalenie rzemiosła,
• skupienie na jakości,
• shift left,
• współpraca w pełnokompetentym zespole,
• itp.

Te zasady są możliwe do zastosowania niezależnie od tego, czy mamy produkt czy usługi, jeden system czy kilka, utrzymanie czy dewelopment, projekty czy inicjatywy, komercja czy sektor publiczny.

Organizacje się przekształcają

Nie chcę już wspominać, o szymelku skalowania. Omawiałem to już w artykule Unspotify.me, gdzie się okazało, że firma Spotify nie używa już tzw. "Modelu Spotify" :) Otóż organizacje są żywymi społecznościami, które się przekształcają i ewoluują.

Cała tajemnica zwinnej transformacji polega na tym, że nie ma ona za swojego ostatecznego celu. Tak zwana zwinna transformacja, to jeden ze sposobów, aby organizacja usprawniała swój model operacyjny. Chodzi przede wszystkim o to, aby dzisiaj było nieco lepiej niż wczoraj i o nic więcej.

Rynek się zmienia, a wraz z nim zmieniają się organizacje, wpływają one na zmiany na rynku, a rynek oddziaływuje na organizacje i tak w kółko. W związku z tym nie ma sensu mówić o czymś takim jak dojrzałość w zwinności. Model dojrzałości może być jakąś lokalną diagnozą "na teraz", żeby się dowiedzieć czego nam brakuje. Jednak, gdy już braki zostaną uzupełnione, okazuje się, że brakuje nam czegoś jeszcze. Być może nie dlatego, że coś zrobiliśmy źle, lecz dlatego że organizacja jest już nieco inna i otoczenie jest inne. News sprzed lat jest obecnie dobrem powszechnym i niczym nadzwyczajnym.

Jeśli model dojrzałości nie jest czymś, za czym warto gonić, to nie są tym również przeróżne frameworki @scale. Bo cóż z tego, że wymęczyłeś w końcu te trajby i gildie, skoro dziś nie jest lepiej niż wczoraj? Jedynie opisane wyżej zasady leżące pod frejmłorkami mają sens jako narzędzia dla ewoluującej organizacji. Tylko kto ma się tych zasad trzymać?

Agile Business Partner

Jak już wspominałem żaden ze scrum mastera albo agile coach'a agent zmiany. Skutecznymi agentami zmiany są osoby, które są w ścieżce dowodzenia w organizacji np. managerowie. Ponieważ oni mają możliwość prowadzania zmian, oni również z powodzenia tej zmiany powinni być rozliczani (accountability). Potrzebują jednak pomocy merytorycznej od kogoś, kogo nie nazwałbym scrum master - bo moim zdaniem nie są oni trwale zespołowi potrzebni, nie nazwałbym agile coach - bo tu zbyt wiele kołczować nie potrzeba. Nazwałbym raczej agile business partner, przez analogię do HRBP.

Agile business partner to nie ktoś, kto biega od zespołu do zespołu, lecz raczej ktoś przywiązany na dłużej do konkretnego obszaru w organizacji, kto przede wszystkim pracuje z agentami zmiany np. z managerami. Dla managera zwinność nie jest celem sama w sobie. Dla managera zwinność, to posiadanie takiej organizacji pracy, która będzie przygotowana na zmiany w biznesie. Dla niego zwinności to przewidywanie i przygotowywanie się na przyszłość. Za to wszystko manager, czyli agent zmiany musi wziąć accoutablity, a agile business partner ma mu w tym pomóc.

Poniżej kluczowe różnice, jaki widzę pomiędzy agile coach a agile business partner.