Niejasności organizacyjne w świecie zwinnym

Znacie te historie, gdy coś nazywa się tak samo lub dwie osoby mówią o tym samym lub są przekonane, że myślą o tym samym, a później okazuje się, że mówiły o czymś zupełnie innym? I żadnej nie przyszło do głowy, że druga osoba może rozumieć coś inaczej.

Myślenie konwergencyjne zakłada istnienie tylko jednej słusznej perspektywy, tylko jednej poprawnej odpowiedzi. I jak wiadomo, każda strona uznaje swoją perspektywę za TĘ DOBRĄ, drugiej stronie przypisując TĘ ZŁĄ. Strony ze sobą przecież na ten temat nie rozmawiały, bo nie ma czasu na rozmowy o „oczywistościach”. A poza tym to trudne i kłopotliwe.

Tak samo bywa w IT.

Przychodzi Scrum Master do firmy…

Powinien teraz być żart o babie, ale… przychodzi nowy Scrum Master do firmy i nagle jakiś RTE (człowiek od wydań oprogramowania na produkcję w „zwinnym” otoczeniu, w którym kilka zespołów pracuje nad częściami tego samego rozwiązania) oczekuje wyjaśnień od Scrum Mastera na zebraniu przy zespole. Zespół przyszedł na spotkanie zaproszony przez samego Scrum Mastera. Scrum Master pracuje – jak rola sugeruje – scrumowo. Jak jest pytanie o zakres i terminy, to Scrum Master woła zespół wytwórczy, przecież sam nie jest ekspertem domenowym, nie będzie mydlić oczu, tłumaczyć czegoś za zespół, podawać terminów ani bawić się w głuchy telefon. Nie od tego jest.

RTE dociska i pyta, dlaczego coś nie jest gotowe. Najpierw krzyczy na Scrum Mastera, później próbuje wykazać niekompetencję developerów z jego zespołu, którzy ku zdziwieniu Scrum Mastera nieprzyzwyczajeni są do spotkań z RTE (osoba wyżej w strukturze), a w ogóle to z nikim poza sobą nawzajem. Siedzą zazwyczaj w piwnicy, a nagle Scrum Master wyciąga ich z kartonów i każe iść rozmawiać z osobą zarządzającą wydaniami (sam jednak tych wydań RTE nie robi). A później niespodziewanie: kara, wytykanie palcem, poniżenie. Wszystkim po równo. RTE triumfuje. Pokazał swoją wyższość w strukturze.

I mamy nieporozumienie

„Tak trochę dziwnie…”, myśli Scrum Master, bo przecież pracuje w Scrumie. Jak coś dotyczy zespołu, to zespół idzie i gada. Oni wiedzą lepiej. Scrum Master jest tylko „enablerem”, aktywatorem, eliminuje utrudnienia, jeśli sam zespół ma taką potrzebę i coś jest poza horyzontem jego możliwości dotarcia. Nagle Scrum Master dostaje łatkę od RTE: „Niby jesteś certyfikowanym Scrum Masterem, a nie znasz swoich zadań ani systemów, i dlatego takie jaja wychodzą. Odpowiadasz za koordynację i ogarnięcie zależności, żeby zespół dostarczył na czas swój rejestr zadań, zgodnie z budżetem i w ustalonym terminie”.

Podobno jakiś termin był ustalany wcześniej, zanim pojawił się nowy Scrum Master. Architekt przy RTE określił czasochłonność zadań, które zlecono zespołowi, ale w zespole brakowało specjalistów od procesu i wiedzy na temat rozwiązania, więc ciężko było faktycznie ocenić, ile co zajmie. Wyliczenia architekta były wyznacznikiem. Scrum Master po rozmowach z developerami prosił RTE o wsparcie osobowe, ale jakimś cudem został wyśmiany.

To samo inaczej

A później okazuje się, że ten Scrum Master w swoim przekonaniu pracował w Scrumie, tym oryginalnym, gdzie zespół bierze odpowiedzialność, bo jest uczony przez Scrum Mastera o ciągłym dostarczaniu wartości, przyrostach i o istocie wartości scrumowych oraz filarach Scruma. Tam, gdzie są warunki do pracy scrumowej. Gdzie produkt nie jest procesowy i nie opiera się przede wszystkim na zależnościach niemożliwych do ogarnięcia przez sam zespół. Okazało się z kolei, że zespół techniczny tego Scrum Mastera oraz RTE pracowali w adaptacji Scruma w SAFe, gdzie na Scrum Mastera nałożona była inna odpowiedzialność niż na Scrum Mastera z oryginalnego Scruma. Rola tak samo się nazywa, ale jest inna. Tak się złożyło. Nie ma tematu. A może właśnie jest?

Frameworks like SAFe (…) are inconsistent with the Scrum guide and codify dysfunction that can cripple teams for years.

Jeff Sutherland

Inne role, wartości i brak empiryzmu

I każdy ma niby rację. I każdy myśli o drugiej stronie „Co do cholery?”. Scrum Master patrzy na RTE spod byka, bo ten wg niego nie pracuje zgodnie z zasadami i wartościami Scruma, dobija zespół. RTE i zespół patrzą na Scrum Mastera spod byka, bo nie bierze odpowiedzialności jak PM za zakres i terminy, nie koordynuje prac i zależności, nie odciąża na tym polu zespołu, a są na niego z góry nałożone niewyartykułowane oczekiwania o wzięciu odpowiedzialności za efekty prac. Inna rola Scrum Mastera w SAFe, inna perspektywa zespołu na zakres i na znajomość zakresu wycenionego wcześniej przez architekta, inna rola Product Ownera w SAFe, który to w sumie jest skrybą z biznesu i SM niewiele z nim pracuje.

Scrum Master z SAFe skupia się na kontakcie z zespołem developerskim, a tak po prawdzie (zgodnie z wcześniejszymi zapisami w SAFe) to na koordynacji i zarządzaniu zależnościami między jego zespołem technicznym a innymi (terminy, testy integracji). Zespół spisuje kryteria akceptacji w narzędziu. Albo Scrum Master. Product Ownerowi nie przyjdzie to do głowy, bo „to są sprawy IT, piszcie jak chcecie, ja chcę mieć zakres, który wysłałem w excelu. Taki otrzymałem z góry”. Product Owner zarządza rejestrem zadań zespołu a nie Produktem (dlaczego więc nazywany jest Właścicielem Produktu?). Pracuje z zespołem i rejestrem zadań, a nie z produktem, klientem i organizacją. Zombie Scrum.

The fundamental philosophical schism between Scrum and SAFe is [that] Scrum controls risk through empiricism. SAFe tries to control risk through predictability. We have years and years of experience learning that predictability is not possible for complex problems like software development.

Ken Schwaber

Opłakane skutki kilku różnic

Na wstępie jednak w firmie zapomnieli powiedzieć Scrum Masterowi, że praca to Scrum w SAFe. Nie powiedzieli, bo zapewne NIE MIELI POJĘCIA, że to się czymkolwiek różni. Bo nikt im nie powiedział. Firma robiła dawno temu podejście do SAFe, ale myślą, że nie zadziałało, więc nie ma sensu o tym wspominać. Nawet jeśli część praktyk została zaadaptowana. Wiedząc o tym, Scrum Master może miałby świadomość, jakie nieporozumienia mogą z tego wyniknąć. Każdy kopie Scrum Mastera, Scrum Master kopie innych, bo się broni. Wartość biznesowa, samoorganizacja, branie odpowiedzialności za produkt (gdzie jest produkt i kto jest za niego odpowiedzialny?) i sens bycia zwinnym i proaktywnym przepadły między kopniakami.

Jeśli produkt wytwarzany przez zespół stoi na zależnościach, a zespoły nie planują pracy wspólnie (a zdarza się i to), to zespół nie będzie poświęcał większości czasu na zarządzenie tymi zależnościami. Potrzebny jest PM, jeśli wytwarzane przez zespoły produkty są od siebie mocno zależne i zespoły nie mają nawyku ścisłego kontaktu, bo ktoś inny koordynuje zależności. Praca w dwutygodniowych sprintach i branie udziału w spotkaniach scrumowych nie robi z żadnej grupy zespołu scrumowego.

Kiedy Scrum spotyka SAFe

A ten żart o babie to do wyboru. W gruncie rzeczy każdy pasuje. W każdym baba i lekarz mówią o czymś innym, myśląc, że mówią o tym samym.

Przychodzi baba do lekarza.
– No i co, pomogły pani te lekarstwa co przypisałem na hemoroidy?
– Tak, pół na pół.
– Jak to?
– Te długie śliskie tabletki to jakoś połknęłam. Ale tego kremu, co mi pan przepisał, to nawet z chlebem zjeść nie mogłam.


Przychodzi baba z dzieckiem do lekarza.
– Czy dziecko przechodziło odrę? – pyta lekarz.
– Ta gdzie tam, panie, my zza Buga.


Przychodzi baba do lekarza z żabą na głowie.
– Co się stało? – pyta lekarz.
– Coś mi się przykleiło do dupy – odpowiada żaba.

Sam Scrum, i bez wpływu SAFe, jest trudny do opanowania. Mam jednak wrażenie, że gdyby nie SAFe ze swoim alternatywnym, wybiórczym zombie Scrumem, sytuacji takich jak powyższa byłoby zdecydowanie mniej. Widzę, że zdarzają się one częściej, niż bym zakładała. Kiedy poprawnie przygotowany do roli Scrum Master spotyka organizację wdrażającą SAFe, rodzą się nieporozumienia i patologie. Powtarzane długo i z uporem – dla niektórych stają się zwykłą codziennością. A później zdziwienie że problemy.

Zdaję sobie sprawę, że wdrożenia takich frameworków jak SAFe są poniekąd tak dobre, jak ludzie, którzy w tych strukturach pracują. Zapewne gdzieś na świecie są firmy, które są z SAFe zadowolone. Znam miłośników SAFe, którzy za atut uznają jego preskryptywność (jasne zalecenia). Są też zapewne wdrożenia SAFe, w których w ogóle firma nie korzysta z adaptacji Scruma w SAFe. I pod pewnymi względami – jasne, dobry wybór.

Bywają jednak takie struktury organizacyjne, które sprzyjają generowaniu bardziej złożonych dysfunkcji. I do tych struktur moim zdaniem należy właśnie SAFe ze swoją protezą Scruma. Decydując się na framework, należy pamiętać, że za strukturą organizacji posłusznie podąża jej kultura.

5 1 vote
Ocena artykułu
Subskrybuj
Powiadom o
0 komentarzy
Inline Feedbacks
Zobacz wszystkie komentarze