Blog

Dużo się mówi na temat zachowania i postaw Scrum Mastera, które pozytywnie wpływają na zespół, Product Ownera i organizację dokoła. Zaczynając pracę w tym zawodzie, 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ę roli 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 samoorganizacji i morale zespołu, 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 samoorganizacji, której tu niezbyt wiele…).

Tkwi też w większości z nas chęć wykazania się, udowodnienia, że radzimy sobie z problemami. Wytrenowani do reagowania i szybkiego 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, 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 na retrospektywę. Wciąż prowadzi wiele zdarzeń, ale nie dlatego, że uczy w ten sposób zespół czegokolwiek; robi to najczęściej po to, by „odciążyć” zajętych developerów – 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óż, nic przeciwnego. Zespół nie dostaje wsparcia merytorycznego wtedy, kiedy go potrzebuje: nikt nie zadaje kłopotliwych pytań w przypadku braku przejrzystości, nikt nie wskazuje potrzeby lub braku 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 biznes napiera, 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 jest dowodem na kompletne niezrozumienie tej metody i w ogóle podejścia zwinnego, tym niemniej często się zdarza. Skoro uczymy Scrum Masterów, że mają pomagać, ale nie mogą być kierownikami, skoro mówimy im, że nie powinni redukować się do roli asystenta zespołu, część osób osadza się na 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, jak jest naprawdę. Kanały komunikacji zamierają, bo Scrum Master staje się łącznikiem zespołu ze światem zewnętrznym, i wraz z developerami sprint po sprincie udowadnia otoczeniu, że „lepiej się nie dało, robimy co możliwe”. Przestrzeń dla empirycznego działania i współpracy 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…

Super-bohater

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 wszystko, czego potrzebują, zbawmy świat… Chwalebne, czyż nie? I jakie szkodliwe zarazem.

Bycie super-bohaterem 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 dokonując wyboru Scrum Master zamyka jakieś ścieżki, otwierając inne, w ostatecznym rozrachunku mniej korzystne?

Ciąg dalszy nastąpi

O czterech innych problematycznych postawach Scrum Mastera napiszę w kolejnej części artykułu już wkrótce. Będzie też mowa o sposobach, które pozwalają ustrzec się pułapek tych złych postaw.

Przeczytaj część drugą