Czy wszyscy będziemy Scrum Masterami?
Ironicznie można powiedzieć, że dobry Scrum Master to taki, który sprawia, że nie jest potrzebny w zespole. To tak jakbyś grał/a w planszówkę, w której wygrasz, gdy przegrasz. Albo inaczej – w której wygrasz, gdy inni też wygrają.
Anna Bąkiewicz. IT Analityk oraz Scrum Master w Robert Bosch. Po ukończeniu studiów ekonomicznych swoją karierę związała z zarządzaniem projektami IT. Kompetencje biznesowe budowała między innymi poprzez wsparcie globalnych projektów od strony PMO oraz staż w austriackim oddziale firmy Bosch. W codziennej pracy spaja sferę biznesową ze światem IT, pracując aktualnie nad wewnętrzną aplikacją łączącą dane z wielu inżynieryjnych systemów. Poza pracą, miłośniczka teatru oraz społecznik od urodzenia.
W IT „scrum” przejawia się jako sygnał zwiastujący programistom codzienną piętnastominutową rozmowę z kawką w ręku. Dla managementu zaś scrum jest dziwnymi zaklęciami ukrytymi pod przykrywką refinementów i retrospektyw. Z której strony byśmy nie patrzyli, bycie scrum masterem to dość enigmatyczne zajęcie. Odczarujmy zatem tę rolę.
Zadania scrum mastera są tak naprawdę jasne – przekazuje on zespołowi wiedzę o założeniach scruma. Dzieli się teorią, pomaga wdrożyć ją w praktykę, by usprawnić proces wytwarzania produktu. Proste, prawda? W teorii zatem, jeśli wszystko działa jak należy, to można uznać, że scrum master nie ma, co robić. Tylko, czy kiedykolwiek wszystko działa jak powinno? Gdyby tak było, nie powstałoby tyle memów o pracy w IT.
Przez sam fakt, że scrum wpisuje się w koncepcję lean managementu, zawsze można znaleźć pole do poprawy na różnych poziomach. Hipotetycznie możemy założyć, że w zespole, w którym pracujemy, jest idealnie. Wyobraźmy sobie, że user story jest dokładnie tym, co chciałeś/aś od dawna zaprogramować, wszystko jest klarownie opisane w Jirze i zapieczętowane trzema story pointami. W ciągu krótkiego sprintu przygotowujesz przetestowaną paczkę do wypuszczenia na produkcję, w przerwach rozgrywając meczyk w piłkarzyki. I nawet jeśli po drodze nic się nie wywali, nie zastanie nas żaden pożar na produkcji, a product owner będzie skakał z radości na ten feature… to nawet wtedy praca scrum mastera się nie kończy.
Twórcy scruma dość odważnie zaznaczyli zakres działania scrum mastera, nie ograniczając go tylko do zespołu. Scrum master powinien działać szerzej – nie tylko z teamem deweloperskim, ale również ma być liderem zmian w organizacji, co zapewnia scrum masterom pracę na długie lata…
Czy scrum tak naprawdę jest potrzebny?
Nie raz słyszałam opinie programistów: “Po co nam ten scrum? Jak był waterfall to przynajmniej było wiadomo, co robić”. Jasne, zgadzam się. To chyba marzenie każdego project managera, aby klient wiedział, czego chce i dokładnie umiał to opisać. Waterfall działa dobrze, kiedy oczekiwania klientów są znane i niezmienne.
Natomiast dla wielu rozwiązań IT nie jesteśmy w stanie spisać z góry wymagań. W świecie VUCA [Volatility, Uncertainty, Complexity, Ambiguity], gdzie mało projektów ma z góry określony outcome, agile przychodzi jako remedium. Specjalnie nie mówię tu scrum. Niestety często scrum to w praktyce puste słowo wstawiane na ofertach rekrutacyjnych tuż obok “pracy w młodym i dynamiczny zespole” oraz “owocowych czwartków”.
Rozmawiam ze znajomym, pracującym w mniejszej firmie, pytam go, czy pracują w scrumie. “Tak”. Zatem podpytuję dalej: “Jestem ciekawa jak na retrospektywie u Was rozwiązujecie taki i taki problem…”. Chwila konsternacji. “Retro… co?” – pada odpowiedź.
I nie ma w tym nic złego, jeżeli rozmawia się z programistą, którego – bądźmy szczerzy – raczej mało obchodzi, czy te wszystkie “ceremonie” odbywają się według założeń scruma, scrumbana czy innego SAFe. Po to właśnie zatrudnia się scrum lub agile masterów, by porządkowali te procesy. Oni mają być liderami promującymi zmianę, tłumacząc jej zawiłości. Oni mają wspierać zespół, jak i całą organizację w dążeniu do perfekcji. Nawet jakby sam ideał był niedościgniony, to warto kierować się w jego stronę.
Mówi się, że w ciągu kilku lat ta kompetencja ma być jedną z najbardziej rozchwytywanych na rynku. I pozwolę sobie mówić szerzej, wyjdę poza samego scruma. Moim zdaniem nie ma znaczenia, czy będziesz Scrum Masterem, Agile Masterem, czy Agile Ninja. Twoim celem w każdej z tych pozycji będzie pomaganie zespołom w wytwarzaniu większej wartości w odpowiedzi na bardzo złożone problemy.
Dla przykładu, jako scrum master będziesz dążył/a do tego, aby inni coraz bardziej zanurzali się w scrumowe wartości. Tego wymaga od nas rynek technologiczny: zaangażowanie, odwaga, skupienie, otwartość i poszanowanie – to nie mogą być tylko puste słowa. Wyzwania, z jakimi się mierzymy, oczekują od nas nie tylko hard skillów, ale też kompetencji miękkich.
Scrum master przychodzi do zespołu z konkretną misją: podnieść efektywność zespołu. Jak ma to zrobić? Na to pytanie nie ma jednoznacznej odpowiedzi – metody, które dobierze będą zależały od dojrzałości teamu i panujących warunków. Warunków, które – nie zapominajmy – nie są niezmienne.
Zauważmy jak COVID wywrócił świat do góry nogami. Z tego pandemicznego chaosu wiele firm wyjdzie mądrzejszych. Wiele kultur organizacyjnych przemieni się w te, które zamiast tradycyjnego managementu promują idee nowego przywództwa. Przywództwa służebnego, gdzie gramy do jednej bramki.
Można marzyć, że za jakiś czas wszyscy będziemy scrum masterami. No dobra, może nie w pełni i nie na papierze, ale czy nie o to chodzi, aby każdy w zespole (product owner, tester, programista, analityk…) podejmował inicjatywy usprawniające, kultywował scrumowe wartości i umiał sobą zarządzać?
Aby zatem móc odpowiedzieć na potrzeby współczesnego świata, wzrastającej konkurencji i zmieniających się reguł, firmy muszą mieć w swoich organizacjach kogoś, kto pomoże im stworzyć najlepsze warunki pracy, a to wszystko oczywiście po to, aby dostarczać najwyższą jakość usług. Tego sobie i Wam życzę!
Zdjęcie główne artykułu pochodzi z unsplash.com.