Pracę dobrego Scrum Mastera poznać można po tym, że w pewnym momencie przestaje być potrzebny w codziennej pracy Zespołu Developerskiego. Jednak nie zawsze tak się dzieje. Błędy Scrum Mastera zawsze mogą się zdarzyć, jakie są ich przyczyny?

Najczęstsze błędy Scrum Mastera – omówione zagadnienia:

  1. Nadobecność Scrum Mastera
  2. Niewystarczająca obecność Scrum Mastera
  3. Podumowanie

Praca Scrum Mastera polega przede wszystkim na wspomaganiu pracy Zespołu Developerskiego. Dlatego najczęstsze popełniane błędy Scrum Mastera wypływają zwykle ze sposobu, w jaki uczestniczy on w codziennym funkcjonowaniu Developerów. Błędy Scrum Mastera podzieliliśmy na dwie grupy. Pierwsza obejmuje problemy wynikające ze zbyt dużego zaangażowania, zaś druga z niewystarczającej obecności Scrum Mastera w życiu Zespołu Developerskiego.

mistakes of Scrum Master - The Scrum Master's Absence

Nadobecność Scrum Mastera

Potrzeba utrzymywania zbyt dużej kontroli nad Zespołem często powoduje błędy Scrum Mastera. Błędy Scrum Mastera najczęściej stają się widoczne w następujących sytuacjach.

  1. Scrum Master szuka rozwiązania problemu zamiast wspomagać zespół w radzeniu sobie z trudnościami.Często źródłem problemu jest to, że Scrum Master jest zarazem specjalistą w dziedzinie tego, czym zajmuje się Zespół Developerski. Nieumiejętność wyjścia z roli eksperta sprawia, że nie jest on w stanie skutecznie wspomagać zespołu w samodzielnym znajdowaniu rozwiązań. Takie podejście może także prowadzić do jednoosobowego, autorytarnego podejmowania decyzji – a to chyba największy błąd, jaki może popełniać Scrum Master.
  2. Scrum Master nie pozwala zespołowi popełniać błędów. Ten problem wiąże się ściśle z poprzednim. Jeśli zespół będzie skutecznie chroniony przez Scrum Mastera przed popełnianiem błędów, nie nauczy się samodzielnie rozwiązywać problemów, ani brać odpowiedzialności za swoją pracę. Zawsze będzie polegał na radzie i ekspertyzie Scrum Mastera.
  3. Scrum Master próbuje zmieniać ludzi zamiast pracować nad atmosferą w zespole.Problem ten dotyczy zarówno zbytniego nacisku na zmianę zachowań członka lub członków zespołu, jak i zmian personalnych. Błędem jest zmienianie składu Zespołu Developerskiego podczas pracy nad Celem Produktu jeśli nie jest to absolutnie konieczne. Może to wprowadzić znaczące opóźnienia w jego realizacji, zaburzyć rytm pracy Zespołu Developerskiego. A także zaburzyć rytm kształtowania się Zespołu, o którym piszemy w osobnym artykule.
  4. Scrum Master pełni w organizacji funkcję przełożonego Zespołu Developerskiego. Jest to błąd, który nie wynika często z decyzji samego Scrum Mastera. Może jednak powodować nasilenie wszystkich błędów wynikających z potrzeby kontroli nad Zespołem.
  5. Scrum Master nadmiernie angażuje się w działanie ZespołuGdy Zespół składa się z ekspertów znających swoje umiejętności i zakresy obowiązków, oraz funkcjonuje w zgodzie z zasadami Scrum, Scrum Master nie powinien nieproszony ingerować w sposób jego działania. Jeśli to robi, po prostu przeszkadza w sprawnym działaniu swojego zespołu. Dobry Scrum Master dzięki ugruntowanej pozycji coacha i lidera będzie proszony o radę w sytuacjach nadzwyczajnych lub wymagających świeżego spojrzenia. Dlatego powinien być dostępny na wezwanie Developerów, ale nie narzucać swej obecności.
  6. Scrum Master zbyt sztywno trzyma się zasad Scrum.eśli któryś z aspektów Scrum w danym Zespole nie działa, Scrum Master powinien spróbować innego podejścia. Każdy Zespół jest inny, a Scrum jest tylko ogólnymi ramami działania.
mistakes of Scrum Master

Zbyt małe zaangażowanie Scrum Mastera

Nie tylko zbyt duże, lecz również niewystarczające zaangażowanie Scrum Mastera może przynieść błędy Scrum Mastera. Opisaliśmy poniżej najczęstsze z nich.

  1. Scrum Master niewystarczająco dobrze zna zasady Scrum. Błąd ten z dużym prawdopodobieństwem doprowadzi do ich niewłaściwego wdrażania. Zaś praca Zespołu tylko z pozoru będzie pracą w Scrum.
  2. Scrum Master nie egzekwuje zasad Scrum.Niewystarczająca obecność Scrum Mastera na co dzień sprawia, że nie chroni zespołu tak, jak powinien. Może to prowadzić do braku ochrony przed napływem zadań z zewnątrz. Albo do niewywiązywania się Zespołu Developerskiego z realizacji Celu Sprintu.
  3. Scrum Master nie pilnuje przestrzegania stałego rytmu Scrum. Niedbałość w kwestii organizacji Wydarzeń Scrum może prowadzić do marnowania czasu. Rezultatem będą za długie lub źle prowadzone Wydarzenia – Sprint Planning, Sprint Retrospective czy Sprint Review (o których piszemy w osobnych wpisach). Błędem jest także przekładanie wydarzeń lub zmiana czasu ich trwania.
  4. Scrum Master nie reaguje na konflikty w Zespole.Oczekiwanie, że konflikty w Zespole z czasem się rozwiążą, jest błędem Scrum Mastera. Konflikt nie zawsze jest zły, ale Scrum Master powinien być nie tylko świadom jego istnienia i aktualnego stanu, ale również zaangażować się w niego jako negocjator. A także potrafić wykorzystać konflikt do zmiany i usprawnienia działania Zespołu.
  5. Niewystarczająca obecność Scrum Mastera. Problem pojawia się, gdy Scrum Master za mało czasu poświęca pracy z Zespołem i angażuje się na przykład w zadania specjalistyczne. Sprawia to, że za mało słucha i zadaje za mało pytań. To zaś, jak pisaliśmy w poprzednim artykule, jest kluczową umiejętnością Scrum Mastera. W rezultacie Scrum Master nie wie wystarczająco dobrze, jaka jest aktualna sytuacja i atmosfera panująca w Zespole. Oraz zadowala się status quo.
  6. Scrum Master nie kwestionuje status quo.Żeby Zespół Developerski, a także cały Scrum Team mógł się rozwijać, konieczne jest ciągłe kwestionowanie status quo. Jest to często działanie ryzykowne i potencjalnie konfliktogenne. Scrum Master powinien się go podejmować ze świadomością trudności, jakie może napotkać. Jednak nie ma czegoś takiego, jak „dojrzały Zespół Developerski, który już się nie rozwija”. Pozostawienie go samemu sobie szybko doprowadzi do znaczącego pogorszenia jego działania.
  7. Scrum Master nie dzieli się z Zespołem swoimi obserwacjami dotyczącymi jego funkcjonowania. Zatrzymywanie tej wiedzy dla siebie utrudnia, a nawet zupełnie zahamowuje rozwój Zespołu. Jest on co prawda zupełnie skupiony na swoich codziennych obowiązkach, jednak nie pracuje nad sposobem, w jaki współpracują ze sobą jego członkowie. Prowadzi to często do nawarstwianie się problemów i konfliktów.

Podsumowanie

Błędy Scrum Mastera wynikające z niewystarczającego lub nadmiernego zaangażowania Scrum Mastera w pracę Zespołu Developerskiego mogą zniszczyć rytm pracy. A nawet przyczynić się do zaprzestania działania według zasad Scrum. Dlatego warto, by Scrum Master był świadom potencjalnych błędów i płynących z nich zagrożeń. A także na bieżąco obserwował swoją relację z Zespołem.

Zapoznaj się z kolejnym wpisem z tej serii: Jakie statystyki i metryki powinien śledzić Scrum Master?

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 10. Najczęstsze błędy popełnianie przez Scrum Mastera caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?