Blog

Czasami ktoś pyta mnie, czym różni się dobry Scrum Master od osoby, która kiepsko sobie radzi pracując w tej roli. Zazwyczaj odpowiadam, że najbardziej obiektywnym i zarazem brutalnie bezwzględnym sposobem oceny jest przyjrzenie się efektom pracy.

Jeśli zespół co sprint wytwarza działający i w pełni ukończony produkt, który nadaje się do użycia i jest wartościowy (w szerokim rozumieniu tego, czym ta wartość jest) – to najprawdopodobniej Scrum Master wykonał dobrze swoją robotę. Być może wystarczyło, by nie przeszkadzał, ale doświadczenie podpowiada, że sytuacja jak opisałem „sama z siebie” zazwyczaj się nie pojawia i wysiłki Scrum Mastera są niezbędne, by do niej doprowadzić.

Czy ty zastanawiałeś lub zastanawiałaś się, jak sobie radzisz jako Scrum Master?

Przejrzystość

Scrum Master powinien zapewniać przejrzystość zamiast bronić zespół przed trudnymi pytaniami i zapewniać, że przede wszystkim będzie im się „przyjemnie” pracowało. Jeśli dla ujawnienia jak jest naprawdę trzeba powiedzieć „sprawdzam”, Scrum Master nie może się wahać. To wymaga odwagi, ale też i wyczucia, bo martwy Scrum Master (czyli taki, który wypchnięty został z zespołu) nie na wiele się przyda.

Jeśli więc, nawet w dobrej wierze, „chronisz” swój zespół przed ujawnieniem niekoniecznie pięknej prawdy o tym, jak przebiega praca nad produktem, prawdopodobnie wyświadczasz developerom i organizacji niedźwiedzią przysługę. Podejmowanie błędnych decyzji na bazie niekompletnej lub fałszywej informacji i zamiatanie pod dywan problemów nie służy usprawnieniom. W ostatecznym rozrachunku nigdy się to nie opłaca, bo w końcu rzeczywistość wystawi słony rachunek za to, że ją ignorowaliśmy.

Samoorganizacja

Scrum Master powinien uczyć zespoły samoorganizacji, nie zaś organizować pracę developerów. To nie inna nazwa na kierownika liniowego lub szefa projektu, tylko rola wspierającego przywódcy. Celem jest zbudowanie zespołu zdolnego do samodzielnego działania i świadomie korzystającego ze Scruma.

Jeśli więc mówisz developerom o co muszą zadbać, jeśli zamiast zadawać pytania podsuwasz rozwiązania lub wręcz wprost zalecasz im takie lub inne działania, okaleczasz zespół. Zdejmujesz z developerów odpowiedzialność, pozbawiasz ich realnego wpływu na to, jak wykonywana jest praca. Utrudniasz albo wręcz uniemożliwiasz nauczenie się czegokolwiek nowego. Team tak traktowany nie jest samoorganizujący, tylko co najwyżej dobrze wytresowany.

Scrum

Scrum Master powinien uczyć jak działać w poprawnym Scrumie a nie interpretować definicję metody w sposób, który pozwala na pracę „po staremu” bez dokonania istotnych zmian czy udoskonaleń. Ma uczyć empirycznego działania nie tylko developerów, ale również Product Ownera i wszystkich, którzy mają wpływ na funkcjonowanie i możliwości zespołu.

Jeśli „wdrożyłeś” Scruma omawiając na początku wszystkie elementy i uznałeś, że to wystarczy, zapewne funkcjonujesz teraz w mechanistycznym Scrumie. Są zdarzenia, ale nie służą założonym celom, a jedynie „odbywają się”, bo wymaga tego metoda. Są role, ale odpowiedzialności się przemieszały i rozmyły, zaś część decyzji wypłynęła poza zespół scrumowy do architektów, analityków, managementu. Są wreszcie artefakty, ale brak im przejrzystości, bo nikt o nią nie dba na bieżąco. Empiryzm wyparuje z takiego środowiska szybciej niż alkohol wylany na rozgrzaną blachę…

Poszukiwanie rozwiązań

Scrum Master powinien zwalczać szkodliwe status quo zamiast pomagać zespołowi i jego otoczeniu w dopasowaniu się do ograniczeń. Niezbędna do tego jest przejrzystość, umiejętność samoorganizacji i znajomość Scruma – a szerzej: zrozumienie na czym polega podejście zwinne. Agile kończy się tam, gdzie wszyscy uznają, że nic już nie da się zrobić lepiej. Scrum Master jest tym, który ma uświadomić wszystkim, że w każdej sytuacji da się realizować kolejne usprawnienia.

Jeśli swym autorytetem „przyklepujesz” sprzeczne z duchem Agile działania, jeśli o ograniczeniach mówisz, że „musimy z tym żyć” i nie dążysz do tego, by zespół nieustannie szukał sposobu zmiany niekorzystnej sytuacji, to degradujesz produkt, zespół i organizację dookoła. Jeśli nie nauczysz organizacji, że trzeba nieustannie poszukiwać sposobu jak zrobić coś dobrze (jeśli na razie robi to źle), albo jeszcze lepiej (jeśli już jest dobrze), zamiast pożądanego stanu „flow” uzyskasz co najwyżej „drift”…

Sprawdź

Czy wiesz, jakiej pomocy z twojej strony zespół potrzebuje teraz najbardziej? Jak zamierzasz mu pomóc w sposób, który zaowocuje wzrostem dojrzałości?

Czy twój zespół scrumowy działa faktycznie w sposób empiryczny? Skąd to wiesz? Czy przejrzystość jest na pozwalającym na to poziomie? Jak możesz to potwierdzić?

Czy wciąż jesteś moderatorem wszystkich retrospektyw? Jaki eksperyment, którego nie zaproponowałeś ty jako Scrum Master, zaplanował i przeprowadził zespół developerski, by uzyskać potencjalne usprawnienia?

Jesteś pewien, że w waszym Scrumie nie jesteś centralną postacią, bez której metoda przestanie funkcjonować? Masz odwagę, by sprawdzić, że tak nie jest…?