Blog

Dużo się mówi na temat zachowania i postaw Scrum Mastera, które pozytywnie wpływają na Developerów, Product Ownera i organizację dokoła. Biorąc po raz pierwszy na siebie tę odpowiedzialność, czy to na kursach i szkoleniach, czy od bardziej doświadczonych kolegów, uczymy się o byciu coachem, nauczycielem, doradcą czy mentorem dla współpracowników.

Po czym wcielamy te rady i zalecenia w życie, często sparaliżowani obawami, by przypadkiem nie zrobić czegoś źle. To, co miało nas inspirować, staje się ograniczeniem – zamiast dobrze zrozumieć istotę odpowiedzialności Scrum Mastera i poszukać najlepszego sposobu, w jaki możemy działać skutecznie, próbujemy dążyć do niezdefiniowanego nigdzie i dalibóg nieistniejącego ideału.

I w dobrej wierze, z braku kompetencji, zrozumienia lub odwagi, zamiast owych zalecanych i chwalebnych postaw, pracujemy na przykład jako…

Kierownik Zespołu

Tysiące słów wypowiedziano i napisano na temat Scrum Mastera zarządzającego ludźmi niczym kierownik liniowy. Wszyscy wiedzą, że to szkodliwe dla morale Zespołu i jego zdolności samozarządzania, a mimo to dysfunkcja ta pojawia się najczęściej.

Źródłem jest, jak to zwykle bywa, chęć czynienia dobra: pomocy Zespołowi, nauczenia go szybko, by był efektywny w działaniu, by „dobrze robił Scruma” (cokolwiek to znaczy w takiej sytuacji, wszak dobrze robiony Scrum opiera się na samozarządzaniu, którego tu niezbyt wiele…).

Tkwi też w większości z nas chęć wykazania się, udowodnienia, że radzimy sobie z problemami. Wytrenowani do szybkiego reagowania i skutecznego działania, nie potrafimy się powstrzymać i w końcu, zamiast Zespół wspierać, zaczynamy mu przewodzić, a w końcu nim zarządzać. Bywa i tak, że szefostwo Scrum Mastera wprost ustawia dla niego lub dla niej taki cel, którego realizacji trudno odmówić.

Jeśli Scrum Master ustrzeże się przed chwyceniem Zespołu za twarz, wtedy obawa, by nie posunąć się za daleko, może spowodować, że zacznie pracować jako…

Sekretarz Zespołu

W tej postawie, często nazywanej też „asystentem Zespołu do spraw administracyjnych”, Scrum Master wycofuje się tak daleko z jakiejkolwiek dyrektywności, że ogranicza swe działanie do czynności takich jak rezerwowanie sali na spotkanie czy zamówienie mazaków i karteczek potrzebnych na Retrospekcji Sprintu. Wciąż prowadzi jako moderator wiele spotkań (w tym zdarzeń scrumowych), ale nie dlatego, że uczy w ten sposób Zespół czegokolwiek; robi to najczęściej po to, by „odciążyć” zajętych Developerów lub Product Ownera – jako sekretarz właśnie – nierzadko na ich wyraźne żądanie.

Pozornie taki Scrum Master-sekretarz, choć niezbyt pomocny, nie ma możliwości zaszkodzić. Cóż, szkodzi i to jak! Zespół nie dostaje wsparcia merytorycznego wtedy, kiedy go potrzebuje: nikt nie zadaje kłopotliwych pytań w przypadku braku przejrzystości, nikt nie wskazuje usprawnień. Zespół takiego Scrum Mastera prawdopodobnie nie będzie się niemal wcale rozwijał (bo i skąd miałby wiedzieć, że powinien?), a jest szansa, że stanie się nieporadny w kwestii najprostszych czynności typu zarezerwowanie spotkania w kalendarzu, jeśli zawsze robi to usłużny sekretarz.

Na antypodach tej postawy jest…

Obrońca uciśnionych

Wszak interesariusze napierają, Product Owner domaga się więcej i więcej w każdym Sprincie. Pojawiają się jacyś smutni panowie i panie, którzy nazywają się Agile coachami i zadają trudne pytania, na które ciężko odpowiedzieć bez przyznania, że dużo rzeczy można zrobić lepiej. Gdzieś w cieniu czai się kierownictwo, monitorujące postępy prac i wydajność poszczególnych Developerów. A nierzadko przygląda się temu z boku klient, który bezwzględnie musi być zadowolony z zainwestowanych pieniędzy albo sobie pójdzie gdzie indziej.

Postrzeganie pracy w Scrumie jako pola walki z otoczeniem jest dowodem na kompletne niezrozumienie tej metody i w ogóle podejścia zwinnego, niemniej jednak często się zdarza. Skoro uczymy Scrum Masterów, że mają pomagać, ale nie mogą być kierownikami, i skoro mówimy im, że nie powinni redukować się do roli asystenta Zespołu, część osób osadza się z tarczą w ręku na skraju owej wyimaginowanej linii frontu.

Skutkiem jest najczęściej spadek przejrzystości w miejscach, gdzie już wcześniej jej było za mało. Szuka się „dobrych odpowiedzi” na trudne pytania o to, jaki jest stan spraw naprawdę. Kanały komunikacji zamierają, bo Scrum Master staje się łącznikiem Zespołu ze światem zewnętrznym, po czym wraz z Developerami Sprint po Sprincie udowadnia otoczeniu, że „lepiej się nie dało, choć robimy wszystko, co możliwe”. Przestrzeń dla empirycznego działania i współpracy z otoczeniem szybko się zaczyna kurczyć.

O ile „obrońców” nie jest wśród Scrum Masterów tak wielu, to niejeden przywdział czerwoną pelerynę i walecznie wspiera Zespół jako…

Superbohater

Czyż Scrum Guide nie mówi, że Scrum Master ma usuwać utrudnienia z drogi Zespołu? A więc do dzieła! Rozwiążmy wszystkie problemy, dajmy Developerom i Product Ownerowi wszystko, czego potrzebują, zbawmy świat… Chwalebne, czyż nie? No, nie. I jakie szkodliwe zarazem.

Bycie superbohaterem przez Scrum Mastera uniemożliwia Zespołowi zetknięcie się z trudnościami, więc nie uczy się on, jak sobie z nimi radzić. Nie jest gotowy na nieprzewidywane. Często nawet nie ma świadomości, że problem istniał, tak skutecznie Scrum Master wyeliminował go, zanim jeszcze pojawił się na horyzoncie.

Jest też kolejna negatywna konsekwencja: takim działaniem Scrum Master podejmuje za Zespół wiele decyzji, nawet im o tym nie mówiąc. Rozwiązując problemy, trzeba dokonywać wyborów, a robiąc to bez komunikacji z Zespołem, Scrum Master kieruje się wyłącznie własnym osądem sytuacji. Być może eliminuje problemy, które wcale nie byłyby problemami, tylko okazjami do zrobienia czegoś lepiej niż do tej pory? Być może dokonanymi wyborami Scrum Master zamknął jakieś ścieżki, otwierając inne, w ostatecznym rozrachunku mniej korzystne?

Ciąg dalszy nastąpi

O czterech innych problematycznych postawach Scrum Mastera piszę w kolejnej części cyklu. Jest w nim też mowa o sposobach, które pozwalają ustrzec się pułapek tych złych postaw.

Przeczytaj część drugą