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-algorytmów wynika z pominięcia w nich kontekstu, a ten 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 teamie.

Widziałem wiele „potworków” spłodzonych w dobrej wierze po to, by „ułatwić” pracę Scrum Masterom, Product Ownerom i zespołom. 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 ról w Scrumie pewien meta-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 zarówno robiąc za dużo, jak i za mało.

Gdy interweniuje zbyt często i twardo moderuje postępowanie zespołu developerskiego 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 zespołu i Product Ownera. Pozostając zbyt głęboko w cieniu wtedy, gdy zapewnienie przejrzystości i działania empiryzmu wymaga zdecydowanych działań, Scrum Master przestaje de facto pełnić swą rolę.

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 pracujące w tej roli. 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 zespołu 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ł. Taki team z natury rzeczy będzie 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 zespołu, 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 (meta-krokiem) algorytmu musi być zawsze uzyskanie odpowiedzi na pytanie kto odpowiada za rozwiązanie problemu i której roli on dotyczy. Lub ujmując rzecz inaczej: w obszarze odpowiedzialności której z ról (Scrum Mastera, Product Ownera czy zespołu developerskiego) leży problem.

Krok pierwszy: czy problem w ogóle istnieje?

Jest możliwe, że problem dostrzega tylko Scrum Master. Istnieje też niezerowe prawdopodobieństwo, że jego / jej 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 nic-nie-robieniem): Scrum Master obserwuje pracę zespołu, jego otoczenie, 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 zespołu 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, 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 zespół również o tym wie.

Krok drugi: czy zespół wie o problemie?

Nierzadko już po kroku pierwszym zespół wie, że ma problem, z którym musi sobie poradzić. 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 zespołem swoimi obserwacjami i zapytać o wnioski i wpływ ujawnionych faktów na pracę w sprincie. Powstrzymanie się od jednoznacznego wskazania, że coś jest problemem, jest zachętą do zrobienia kolejnych kroków samodzielnie przez zespół. W szczególności to sygnał, że to zespół powinien zdecydować, czy problem istnieje, a jeśli tak, co z nim zrobić.

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) zespół. Natomiast nie powinien tych działań moderować w bezpośredni sposób, bo łatwo wpaść w pułapkę takiego ich poprowadzenia, że udowodnią z góry postawioną tezę o istnieniu problemu.

Krok trzeci: co zrobił w tej sprawie zespół?

Całkiem często na tym etapie zespół dochodzi do wniosku, że choć utrudnienie w sprincie się pojawia, nie wpłynie w istotny sposób na przebieg prac. Warto wtedy poszukać potwierdzenia, że tak będzie w istocie. Jeśli zespół sam o to nie zadba, Scrum Master może mu w tym pomóc, na przykład zadając pytania w rodzaju „jak możemy to potwierdzić?”.

Jeśli problem zagraża osiągnięciu celu sprintu, zespół (z pomocą, ale nie pod dyktando Scrum Mastera) dokona adaptacji backlogu sprintu tak, by uwzględnić w nim działania niezbędne do usunięcia utrudnienia. Warto zwrócić uwagę, że na tym etapie Scrum Master nie jest odpowiedzialny za zajęcie się problemem. Owszem, Scrum Guide jasno mówi, że obowiązkiem osoby pracującej jako Scrum Master jest usuwanie utrudnień, ale nie wszystkich, tylko:

• takich, które uniemożliwiają osiągnięcie celu sprintu,
• i jednocześnie takich, z którymi nie poradził sobie zespół developerski.

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 a to, czy sam będzie musiał coś zrobić, dopiero się ujawni.

Może być i tak, że zespół nie zrobi nic. Ot, będzie biernie czekał na rozwój sytuacji. Obowiązkiem Scrum Mastera również i wtedy nie jest działanie za zespół. Jako nauczyciel musi uświadomić developerom obowiązki związane z ich rolą w Scrumie. Jeśli zrobi to skutecznie, zespół powinienem sam (z pomocą Scrum Mastera, jeśli trzeba) zająć się ujawnionym utrudnieniem.

Krok czwarty: jakiej pomocy zespół potrzebuje?

Jeśli zespół zaplanował jakieś działania, Scrum Master wraca do aktywnego-nic-nierobienia, czyli obserwuje postępowanie zespołu. Jeśli to potrzebne, zadaje pytania. Gdy widzi, że to niezbędne, lub gdy poprosi 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ść.

Może się i tak zdarzyć, że zespół nie poradzi sobie z blokującym go utrudnieniem. Wtedy, i dopiero wtedy wiadomo, że – jak napisano w Scrum Guide – Scrum Master musi zająć się tym problemem.

A co, jeśli zespół zechce postąpić w sposób, który godzi w podstawy Scruma? Demontując framework nie można utrzymywać, że osiąga się zdefiniowany w jego ramach cel sprintu, bo sam koncept tego celu znika. Dlatego to również jest podstawa do interwencji Scrum Mastera, już nawet nie wynikającej 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 to jego odpowiedzialność. 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ń przez developerów.

Krok piąty: 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 wymaga działania w tym momencie od Scrum Mastera. Logika jest jednak nieubłagana: jakim cudem miałby on lub ona poradzić sobie z czymś, na czym poległ cały zespół wspierany przez Scrum Mastera? Pamiętać przy tym należy, że od osób pracujących w tej roli nie wymaga się wiedzy technicznej, a wiele problemów ma taki właśnie charakter…

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 teamie, czasem w innej organizacji. To odrywa zespół od pracy w sprincie. Niedostępność developerów skupionych na rozwiązywaniu problemu sama w sobie staje się utrudnieniem (bo znikają z zespołu również kompetencje, których nośnikami są ci ludzie). Usuwając jeden problem zespół pogrąża się w innym.

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 zespół developerski będzie potrafił to zrobić dobrze.

Scrum Master dysponuje czasem, którego zespołowi zacznie coraz bardziej brakować. Ponadto zazwyczaj Scrum Master lepiej orientuje się w organizacji niż developerzy. Osoby pracujące w tej roli dysponują zwykle wyższymi niż przeciętne umiejętnościami komunikacyjnymi, utrzymują też nierzadko relacje z osobami, do których developerom nawet nie przyjdzie na myśl się zwrócić.

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ąć. Ale 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, pomó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.