Blog

Czasami ktoś pyta mnie, czym różni się dobry Scrum Master od osoby, która kiepsko radzi sobie z tą odpowiedzialnością. 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 stan, jaki opisałem, sam z siebie zazwyczaj się nie pojawia i wysiłki Scrum Mastera są niezbędne, by do niego doprowadzić.

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

Przejrzystość

Scrum Master powinien zabiegać o przejrzystość stanu spraw, zamiast bronić Zespół przed trudnymi pytaniami i zapewniać, że przede wszystkim będzie 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, Product Ownerowi 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.

Samozarządzanie

Scrum Master powinien uczyć Zespoły zarządzania swą pracą (czyli samozarządzania, nazywanego też przez wiele lat samoorganizacją), nie zaś organizować tę pracę za Developerów lub Product Ownera. 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 nieustannie mówisz ludziom w swoim Zespole, 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. Przejmujesz od Product Ownera odpowiedzialność za produkt. Utrudniasz albo wręcz uniemożliwiasz ludziom nauczenie się czegokolwiek nowego. Zespół tak traktowany nie jest samozarządzający, tylko co najwyżej dobrze wytresowany.

Scrum

Scrum Master powinien uczyć, jak sensownie użyć Scruma, 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 jego elementy i uznałeś, że to wystarczy, zapewne funkcjonujesz teraz w mechanistycznym Scrumie. Zdarzenia nie służą założonym celom, a jedynie „odbywają się”, bo wymaga tego metoda. Odpowiedzialności zostały formalnie rozdzielone między ludzi, ale w praktyce przemieszały i rozmyły, a wiele decyzji podejmują poza Zespołem Scrum architekci, analitycy, wszelkiej maści eksperci i konsultanci oraz kierownicy. 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ń. Do ich usuwania niezbędna jest przejrzystość, zaangażowanie, znajomość praktyk, technik i narzędzi, a także szereg innych umiejętności, zależnych od sytuacji Zespołu. Ciężko sensownie używać Scruma bez zrozumienia, czym jest empiryczna kontrola procesu, a także tego, że Agile kończy się w momencie, gdy 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 na usunięcie tego, co go ogranicza, to degradujesz produkt, Zespół i organizację dookoła. Jeśli nie nauczysz organizacji, że trzeba nieustannie poszukiwać możliwości lepszego działania, zamiast pożądanego przepływu wartości (ang. flow of value) uzyskasz co najwyżej dryfowanie z prądem…

Sprawdź

Czy wiesz, jakiej pomocy z twojej strony Zespół potrzebuje teraz najbardziej? Jak zamierzasz mu pomóc podnieść możliwości i skuteczność działania? Jak dzięki twojej pomocy może stać się bardziej dojrzały?

Czy Zespół Scrum potrafi wykorzystać empiryczne podejście? Jeśli tak, co o tym świadczy? Wiesz to na pewno, czy jedynie zakładasz, że tak jest? Czy przejrzystość jest na pozwalającym na to poziomie? Jak możesz to potwierdzić?

Czy wciąż jesteś moderatorem wszystkich zdarzeń, w szczególności Retrospekcji Sprintu? Jaki eksperyment, którego nie zaproponowałeś ty, jako Scrum Master, zaplanował i przeprowadził Zespół, 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…?