Blog

Wzdragam się za każdym razem, gdy ktoś prosi mnie o listę kroków, które Scrum Master powinien podjąć w określonej sytuacji. Szkodliwość takich procedur i algorytmów wynika z pominięcia w nich kontekstu, a ten zawsze ma kluczowe znaczenie. Coś, co jest logiczne w jednej sytuacji, może być absurdalnym postępowaniem w innym przypadku. Coś, co godzi w podstawy Scruma w jednym Zespole, może być najlepszym możliwym rozwiązaniem w innym.

Widziałem wiele potworków spłodzonych w dobrej wierze po to, by „ułatwić” pracę Scrum Masterom, Product Ownerom i Developerom. Niektóre składały się z ogólnych haseł, które były niekoniecznie poprawnymi echami sformułowań zawartych w Scrum Guide. Inne stanowiły próbę odpowiedzenia na każde możliwe pytanie i przewidzenia wszystkich możliwych wariantów rozwoju sytuacji. I jedne i drugie stanowiły rzecz niemal bezużyteczną, a potencjalnie szkodliwą, jeśli wpadłaby w ręce osoby niedoświadczonej lub nieznającej Scruma. Początkujący Scrum Master może bowiem użyć (zapewne w dobrej wierze) takiego „przewodnika” i trzymać się go na ślepo, krzywdząc tym zarówno siebie, jak i Zespół.

O ile takie „procedury na każdą okazję” sensu nie mają, to da się spisać dla każdej z odpowiedzialności w Scrumie pewien generyczny algorytm podpowiadający, jak postępować, żeby zredukować ryzyko wyjścia poza obszar odpowiedzialności swojej roli. Postanowiłem podzielić się jednym z nich.

Wąska ścieżka Scrum Mastera

Będąc Scrum Masterem, nieustannie dokonuje się wyborów: działać, czy nie działać; a jeśli działać, to w jaki sposób. Scrum Master może bowiem zaszkodzić Zespołowi Scrum, zarówno robiąc za dużo, jak i za mało.

Gdy interweniuje zbyt często i twardo moderuje postępowanie Developerów oraz Product Ownera, w najlepszym razie spowalnia rozwój Zespołu Scrum. Ceną za niemal każdą bezpośrednią lub zawoalowaną ingerencję Scrum Mastera w proces decyzyjny jest cofnięcie Zespołu w jego zdolnościach do samoorganizacji.

Z drugiej strony Scrum Master obawiający się bezpośrednich działań może bardzo szybko zredukować się do roli asystenta dla Developerów i Product Ownera. Pozostając zbyt głęboko w cieniu wtedy, gdy zapewnienie przejrzystości i empirycznego działania wymaga zdecydowanych działań, Scrum Master przestaje de facto wywiązywać się ze swych obowiązków.

Proces decyzyjny przy rozwiązywaniu problemów

Jednym z obowiązków Scrum Mastera jest usuwanie utrudnień, które uniemożliwiają Zespołowi osiągnięcie Celu Sprintu. Poniżej prezentuję i opisuję kolejne kroki, jakie zazwyczaj podejmują osoby będące Scrum Masterami. Zazwyczaj, bo są sytuacje, w których nie sposób i nie warto trzymać się takiej kolejności, i kiedy prawie od razu nastąpić musi interwencja Scrum Mastera.

Dodatkowo warto mieć świadomość, że wiele zależy od dojrzałości Developerów i Product Ownera. Kroki przedstawione poniżej niekoniecznie będą pasować do problemu, z jakim mierzy się Zespół, który dopiero kilka dni temu powstał. Będzie on z natury rzeczy wymagał bardzo dużego wsparcia ze strony Scrum Mastera. I nie ma w tym niczego nagannego, byleby wsparcie to nie trwało zbyt długo, bo zamiast wspierać, uzależni on lub ona Zespół od siebie.

I jeszcze jedno zastrzeżenie: bywają problemy, które związane są wprost z obszarem odpowiedzialności Scrum Mastera. W takim przypadku nie może on czekać na działanie kogokolwiek innego w Zespole, tylko zabiera się do pracy od razu. Przykładem może być problem niezrozumienia Scruma przez otoczenie Zespołu, co bez wątpienia może stać się utrudnieniem w osiąganiu Celów Sprintu, a z czym sam Zespół niewiele zrobi (bo od tego, by edukować organizację, ma Scrum Mastera).

Dlatego krokiem zerowym algorytmu musi być zawsze uzyskanie odpowiedzi na pytanie, kto odpowiada za rozwiązanie problemu i obszaru czyjej odpowiedzialności on dotyczy: Product Ownera, Developerów czy Scrum Mastera.

Krok 1: czy problem w ogóle istnieje?

Jest możliwe, że problem dostrzega tylko Scrum Master. Istnieje też niezerowe prawdopodobieństwo, że jego ocena sytuacji jest niewłaściwa lub uległa wypaczeniu przez niedostatek informacji. Dlatego, zanim Scrum Master cokolwiek zrobi, powinien potwierdzić, że domniemany problem istnieje.

Jak to robi? Dysponuje dwoma prostymi narzędziami. Jedno to aktywna obserwacja (zwana też aktywnym nicnierobieniem): Scrum Master obserwuje pracę Developerów i Product Ownera, otoczenie Zespołu, przysłuchuje się rozmowom, wyszukuje wzorców i symptomów wskazujących na istnienie problemu.

Drugie narzędzie to zadawanie pytań. Oczywiście wskazanie paluchem i spytanie „nie wydaje wam się, że tu jest problem?” nie jest najlepszym pomysłem na wspieranie ludzi w działaniu. Aby uniknąć projekcji swoich przekonań i obserwacji na inne osoby, najlepiej posługiwać się pytaniami otwartymi – takimi, które skłaniają do zastanowienia i odkrycia nowej informacji.

Przykład dobrego pytania otwartego: „jak wpłynie na nas wyłączenie serwerów testowych planowane na jutro?”. Niczego nie sugeruje, a jednocześnie zmusza do zastanowienia. Co więcej, jeśli ktoś nie wiedział o planowanym wyłączeniu, takie pytanie od razu ujawni ten fakt i zainspiruje do działania.

Czasami próba potwierdzenia, że domniemany problem istnieje, nie powiedzie się ze względu na zbyt niski poziom przejrzystości procesu, stanu artefaktów, otoczenia Zespołu Scrum, kanałów komunikacji itd. A to również problem, którym trzeba się zająć.

Gdy już Scrum Master potwierdzi istnienie problemu lub ujawni kwestię braku przejrzystości, pora na zapewnienie, że reszta Zespołu również o tym wie.

Krok 2: czy Zespół wie o problemie?

Nierzadko już po kroku pierwszym wszyscy dostrzegają problem, z którym trzeba coś zrobić. Im dojrzalszy Zespół i większe jego zaangażowanie w to, co robi, tym częściej tak się zdarza.

W innym przypadku Scrum Master powinien podzielić się z Developerami i Product Ownerem swoimi obserwacjami i dać szansę, by samodzielnie wyciągnęli wnioski. Powstrzymanie się od jednoznacznego wskazania, że coś jest problemem, stanowi zachętę do zrobienia kolejnych kroków bez oczekiwania na reakcję Scrum Mastera.

Jeśli konieczne są jakieś działania, by uzyskać więcej informacji – warsztat, dyskusja, być może z osobami spoza Zespołu – Scrum Master facylituje (wspiera) je na tyle, jak dalece jest to konieczne. Natomiast niekoniecznie musi te działania moderować w bezpośredni sposób, bo łatwo w ten sposób wpaść w pułapkę takiego ich poprowadzenia, że udowodnią z góry postawioną tezę o istnieniu problemu.

Krok 3: co zrobił w tej sprawie Zespół?

Jeśli Zespół dochodzi do wniosku, że choć utrudnienie istnieje, nie wpływa w istotny sposób na możliwości rozwoju produktu, wtedy empiryzm wymaga potwierdzenia, że tak jest w istocie. Jeśli Developerzy lub Product Owner o to nie zadbają, Scrum Master może w tym pomóc, na przykład zadając pytania w rodzaju „jak możemy to sprawdzić?”.

Przy czym odpowiedzialnością Scrum Mastera jest zapewnienie skuteczności działania Zespołu. Pozostawianie nieusuniętych utrudnień, nawet takich i niskiej dotkliwości, zawsze będzie w jakimś stopniu ograniczać możliwości Developerów i Product Ownera. Dlatego Scrum Master powinien dążyć do zajęcia się problemem i jego wyeliminowania. Dobrą strategią będzie tutaj np. wskazywanie utraconych możliwości, po które Zespół mógłby sięgnąć.

Jeśli problem zagraża osiągnięciu aktualnego Celu Sprintu, Developerzy (z pomocą, ale nie pod dyktando Scrum Mastera) dokonają adaptacji Backlogu Sprintu tak, by uwzględnić w nim działania niezbędne do usunięcia utrudnienia. Być może będzie to wymagało również jakichś decyzji ze strony Product Ownera.

Dlaczego nie powinien zajmować się tym przede wszystkim Scrum Master? Dlatego, że niemożność osiągnięcia Celu Sprintu wynika z problemów technicznych (to obszar odpowiedzialności Developerów) lub decyzji produktowych (te podejmuje Product Owner), a nie z zasad Scruma. W szczególności Scrum Master może nie być w stanie rozwiązać problemu, jeśli wymagałoby to zadziałania jako Developer, lub zmian decyzji Product Ownera.

Może być i tak, że Zespół nie zrobi nic. Ot, będzie biernie czekał na rozwój sytuacji. Obowiązkiem Scrum Mastera w takiej sytuacji nie jest rzucenie się do działania. Wbrew przekonaniom wielu osób, Scrum Guide nie wymaga, by to Scrum Master usuwał utrudnienia, ale by powodował ich usunięcie. To oznacza, że jest zobowiązany do bezpośredniego działania tylko wtedy, gdy:

• ujawniony problem uniemożliwia osiągnięcie Celu Sprintu,
• i jednocześnie, kiedy wiadomo już, że Zespół z usunięciem problemu sobie nie poradził.

Sytuacja, w której z góry wiadomo, że coś przerasta możliwości Zespołu, zdarza się dość rzadko. Dlatego na tym etapie Scrum Master musi dać przestrzeń do działania Developerom i Product Ownerowi. Czy sam będzie musiał coś zrobić? To dopiero się okaże.

Czasami konieczne może okazać się przypomnienie Zespołowi (lub nauczenie go), w jaki sposób w Scrumie zdefiniowane są odpowiedzialności. Nie chodzi oczywiście o uchylenie się od działania, ale o spowodowanie, by jasne było, dlaczego Scrum Master nie może interweniować w każdym przypadku. Bardzo łatwo stałby się jednocześnie Developerem i Product Ownerem, a ciężko to potraktować jako pomoc w podnoszeniu skuteczności w działaniu czy wsparcie rozwoju Zespołu.

Krok 4: jakiej pomocy Zespół potrzebuje?

Jeśli Zespół podjął jakieś działania, Scrum Master wraca do aktywnego nicnierobienia, czyli obserwuje rozwój sytuacji. Jeśli to potrzebne, zadaje pytania. Gdy widzi, że to niezbędne, lub gdy poprosi go o to Zespół, uczestniczy w pracy jako facylitator lub moderator.

Obowiązkiem Scrum Mastera jest również zapewnienie, że problem nie zostanie ukryty (celowo lub przez przypadek), a więc że zachowana zostanie niezbędna przejrzystość.

Jeśli Zespół nie poradzi sobie z blokującym go utrudnieniem mimo podejmowanych działań i pomocy ze strony Scrum Mastera, wtedy dopiero można uznać, że obowiązkiem Scrum Mastera jest bezpośrednie działanie.

A co, jeśli Zespół zechce postąpić w sposób, który godzi w podstawy Scruma? To również podstawa do interwencji Scrum Mastera, przy czym w takim przypadku nie wynika to z potrzeby usuwania utrudnienia, co z konieczności zapewnienia, że metoda jest rozumiana i stosowana w praktyce.

Skrajnym przypadkiem może być sytuacja, w której Zespół nie podejmie żadnych działań mimo świadomości, że problemem powinni zająć się Developerzy lub Product Owner. Ostentacyjne zignorowanie swoich obowiązków jest sprzeczne z wartościami Scrum, więc wtedy również interwencja Scrum Mastera jest niezbędna. Przy czym niekoniecznie nakierowana będzie ona na rozwiązanie problemu po to, by jakoś „dokończyć Sprint”, a bardziej na rozwiązanie problemu zaniechania działań.

Krok 5: co muszę zrobić bezpośrednio jako Scrum Master?

Na tym etapie (jeśli do niego w ogóle dojdziemy) już wiadomo, że Sprint jest zagrożony, a Zespół nie potrafi sam usunąć przeszkody. Scrum Master, który odpowiada za to, by utrudnienie nie pozostało nieusunięte, musi sam przystąpić do działania. Jakim jednak cudem miałby poradzić sobie z czymś, na czym poległ cały Zespół?

Zastanówmy się nad tym, co właściwie znaczy stwierdzenie: „Zespołowi nie udało się usunąć problemu”.

Jeden z możliwych scenariuszy jest taki: aby przeszkodę usunąć, konieczne jest wychodzenie sobie wsparcia w organizacji, załatwienie czegoś w innym Zespole, czasem w innej organizacji. To wymaga czasu. Jeśli zajmą się tym Developerzy, ich niedostępność i brak skupienia same w sobie stają się kolejnymi utrudnieniami i zagrożeniami Celu Sprintu. Jeśli będzie to robił Product Owner, może braknąć mu czasu na ustalenie z interesariuszami, co powinno znaleźć się w Backlogu Produktu, nie mówiąc już o tym, że zwykle brakuje mu wiedzy technicznej, by w ogóle zrozumieć niektóre z pojawiających się problemów.

Drugi scenariusz jest związany wprost z kompetencjami, a dokładniej ich brakiem: czasami usunięcie problemu wymaga umiejętności dyplomatycznych, wiedzy jak porozmawiać z decydentem, jak dotrzeć do właściwych ludzi i kim ci właściwi ludzie są. Niekoniecznie Developerzy potrafią to zrobić dobrze. Product Owner zapewne poradzi sobie z tym lepiej, jeśli już ma doświadczenie i dobrą wiedzę o organizacji oraz układach, jakie w niej panują. Przyjmując, że będzie miał czas, bo być może pełni mnóstwo innych funkcji i jest w ciągłym biegu (niestety to dość typowe w dużych firmach).

Scrum Masterowi nie zrobi zatem niczego, czego nie mogliby potencjalnie zrobić Developerzy lub Product Owner. Ma od nich zwykle większą swobodę dysponowania czasem i dość dobrze orientuje się w organizacji niż Developerzy. To pozwala mu przejąć działania od Developerów lub Product Ownera i kontynuować je bez wywołania dodatkowych problemów.

Inaczej mówiąc, do pewnego momentu Scrum Master pomaga Zespołowi w usuwaniu utrudnień, a potem następuje przesunięcie odpowiedzialności – działa Scrum Master, a Product Owner lub Developerzy pomagają mu, jeśli istnieje taka potrzeba. W ten sposób, nie będąc wszechmocnym i wszechwiedzącym, poradzi sobie w końcu z utrudnieniem.

I dlatego, choć Scrum Master jest jeden, może skutecznie przejąć od Zespołu rozwiązywanie problemu, gdy stanie się jasne, że bez takiego bezpośredniego wsparcia Celu Sprintu nie uda się osiągnąć. Choć i tu ukryta jest pułapka zrobienia za dużo w dobrej wierze: gdy Scrum Master rzuci się w wir pracy, nie może zapomnieć o Zespole i całkiem z niego zniknąć.

Podejmując bezpośrednią interwencję, Scrum Master powinien ograniczyć jej zakres do niezbędnego minimum, czyli zrobić tylko tyle, by dalej Zespół poradził sobie już samodzielnie. Przy okazji powinien pokazać, jak dawać sobie radę z określonymi sprawami, np. pomagając Developerom zbudować relacje i nawiązać kontakty z ludźmi tak, by w przyszłości dzięki nim Zespół mniej zależał od wsparcia Scrum Mastera.

Algorytm usuwania utrudnień

Poniżej udostępniam w formie graficznej schemat omawianych pięciu kroków wraz ze wskazaniem narzędzi, z jakich zazwyczaj na poszczególnych etapach korzysta Scrum Master.