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 każda mówiła o czymś 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ę poprawną, drugiej stronie przypisując tę błędną. Strony ze sobą przecież na ten temat nie rozmawiały, bo nie ma czasu na rozmowy o „oczywistościach”. Poza tym to trudne i kłopotliwe.

Przychodzi Scrum Master do firmy…

I nagle 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. Wszystkie zapytania kieruje do Scrum Mastera, a jeśli zwraca się do deweloperów, to nie wiedzą, jak się zachować, bo RTE jest wyżej w strukturze i nie mieli z nim wcześniej do czynienia. 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 pretensje, oczekiwanie wyjaśnień i raportu prac. 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”. Chwila, co?

Dodatkowo, 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.

Oczywiście wszystko powyżej to dysfunkcja. Widziałam ją jednak na własne oczy. Często kultura podążą za strukturą. Zachęca do określonych działań czy postaw. Jeśli praca nie jest oparta na wartościach, jest szansa, że ludzie będą wykorzystywać swoje stanowisko do umacniania własnego ego i pokazywania wyższości w pewnych obszarach.

To samo inaczej

Po jakimś czasie okazuje się, że Scrum Master był przekonany, że ma pracować w Scrumie, tym oryginalnym, gdzie zespół bierze odpowiedzialność, bo jest uczony przez Scrum Mastera o ciągłym dostarczaniu wartości, crossfunkcjonalności, przyrostach, 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

Skutki kilku różnic

Na wstępie 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 mógłby być czujny na nieporozumienia, jakie mogą z tego wyniknąć.

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 Project Manager, 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

Żart o babie jak najbardziej na miejscu.

Przychodzi baba do lekarza.
– No i co, pomogły pani te lekarstwa co przepisał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.

Baba i lekarz mówią o czymś innym, myśląc, że mówią o tym samym.

Sam Scrum, i bez wpływu SAFe, jest trudny do opanowania. Mam jednak wrażenie, że gdyby nie SAFe ze swoim mechanicznym zombie Scrumem, sytuacji takich jak powyższa byłoby mniej. 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 są na świecie firmy, które są z SAFe zadowolone. Znam miłośników SAFe, którzy za atut uznają jego preskryptywność. 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. Dla niektórych korporacji SAFe to może jedyna droga, aby zbliżyć biznes do technologii i zachęcić strony do dyskusji. Powinien to być jednak co najwyżej etap transformacji organizacyjnej niż cel sam w sobie. SAFe nie opiera się na wartości, nie wiadomo, kto jest właścicielem produktu i gdzie w tym wszystkim jest klient.

Bywają takie struktury, 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.