Przewodnik po Scrumie | 39. Najczęstsze błędy podczas Retrospektywy Sprintu

Opublikowany: 2022-07-20

Retrospektywa Sprintu to wydarzenie kończące każdy Sprint. A jednocześnie jedno z najtrudniejszych spotkań Zespołu Scrumowego. Najczęstsze błędy podczas Retrospektywy Sprintu to unikanie rozmów na tematy drażliwe, a także brak konkretnych zobowiązań prowadzących do rozwiązania zdiagnozowanych już problemów.

Częste błędy podczas Retrospektywy Sprintu – spis treści:

  1. Wstęp
  2. Niewystarczająca przejrzystość
  3. Skup się na jednorazowych problemach lub sukcesach
  4. Nadreprezentacja Właściciela Produktu
  5. Problemy z samozarządzaniem
  6. Zbyt wiele zobowiązań
  7. Częste błędy podczas Retrospektywy Sprintu – Podsumowanie

Wstęp

Błędy podczas Retrospektywy Sprintu są niestety bardzo częste. Dzieje się tak dlatego, że jest to jedno z najtrudniejszych spotkań do pomyślnej realizacji, ponieważ wymaga od zespołu dużej dojrzałości. Dlatego warto przyjrzeć się problemom, które najczęściej występują w innych zespołach, abyś mógł łatwiej dostrzec ich symptomy podczas przeprowadzania Retrospektywy Sprintu w Twoim Zespole Scrumowym.

Common mistakes during a Sprint Retrospective

Niewystarczająca przejrzystość

Według Scrum Guide, każdy członek Zespołu Scrumowego jest zobowiązany do uczciwości i śmiałości w wyrażaniu obaw oraz wyrażania swojej opinii podczas Retrospektywy Sprintu. W praktyce jednak zobowiązanie do przejrzystości jest bardzo wymagające. Z tego powodu członkowie Zespołu Scrumowego często próbują go obejść.

Trudnym do zauważenia i rozwiązania problemem jest unikanie dyskusji o zaobserwowanych niedociągnięciach w pracy Zespołu Scrumowego. Na dłuższą metę może to prowadzić do znacznie poważniejszych problemów.

Zadaniem Scrum Mastera jest zatem baczne obserwowanie sytuacji w zespole i zachęcanie wszystkich członków zespołu do proaktywności od samego początku Retrospektywy Sprintu.

Skup się na jednorazowych problemach lub sukcesach

Kolejnym problemem, który może pojawić się podczas Retrospektywy Sprintu, jest zwracanie zbyt małej uwagi na cykliczne i powtarzalne zachowania zespołu oraz ich wpływ na efektywność zespołu.

Zawsze dobrze jest pogratulować członkom Zespołu Scrumowego, jeśli osiągnęli wyjątkowy sukces. Jednak Przegląd Sprintu nie powinien być poświęcony jego świętowaniu. To samo dotyczy niepowodzeń. Jeśli coś zawiodło z przyczyn losowych lub już zdiagnozowanego błędu, nie warto przeanalizować zdarzenia podczas Przeglądu Sprintu.

Czasami jednak zespół poświęca takim wydarzeniom dużą część Retrospektywy Sprintu. Pamiętaj jednak, że celem Sprint Retrospective jest poszukiwanie sposobów na usprawnienie codziennej pracy zespołu. Dlatego spotkanie nie powinno obracać się wokół jednorazowych sukcesów lub problemów, które z dużym prawdopodobieństwem się nie powtórzą.

Nadreprezentacja Właściciela Produktu

W wielu organizacjach stanowisko Product Ownera utożsamiane jest z stanowiskiem Product Managera. Product Owner jest wówczas często uważany za superwizora Zespołu Scrumowego. Z tego powodu zdarza się, że Zespół Deweloperski nie chce rozmawiać o problemach z pracą zespołową w jego obecności.

Dlatego tak ważne jest budowanie wzajemnego zaufania pomiędzy Zespołem Deweloperskim a Właścicielem Produktu. Niestety proces budowania zaufania jest trudny i długotrwały. Dlatego czasami dobrym pomysłem dla Product Ownera jest zrezygnowanie z udziału w całości lub części Retrospektywy Sprintu, aby zostawić miejsce na dyskusję dla reszty zespołu.

Problemy z samozarządzaniem

Samozarządzanie oznacza, że ​​członkowie Zespołu Scrumowego samodzielnie decydują, kto z nich będzie wykonywał określone zadania, kiedy i jak. Podczas Retrospektywy Sprintu zespół omawia ludzi, ich interakcje, a także praktyki zespołowe. Następnie decyduje, jakie problemy należy rozwiązać w nadchodzącym Sprincie, jak to zrobić wspólnie i kto będzie odpowiedzialny za podjęcie działań.

Jeśli w zespole samozarządzającym pojawią się poważniejsze problemy, w Zespole Scrumowym może pojawić się pokusa zrzeczenia się odpowiedzialności.

Czasami członkowie zespołu nie chcą brać udziału w dyskusji i próbują zrzucić odpowiedzialność za zarządzanie na kogoś innego. Aby temu zapobiec, niezwykle ważne jest regularne omawianie nawet drobnych problemów, aby zapobiec ich kumulacji.

Most common mistakes during a Sprint Retrospective

Zbyt wiele zobowiązań

Aktywny Zespół Scrumowy działający w oparciu o trzy filary empiryzmu : przejrzystość, inspekcję i adaptację, może napotkać problem podejmowania zbyt wielu zobowiązań na raz.

Jeśli zobowiązań podjętych przez Zespół Scrumowy podczas Retrospektywy Sprintu jest zbyt wiele, istnieje duże ryzyko, że:

  • żadne ze zobowiązań nie zostanie zrealizowane prawidłowo
  • niektóre zobowiązania w ogóle nie zostaną zrealizowane
  • wprowadzone zmiany nie będą trwałe

Dlatego dobrą praktyką jest podejmowanie nie więcej niż czterech ulepszeń w każdym Sprincie. Pozwala to na stopniową, ale skuteczną poprawę wyników zespołu.

Częste błędy podczas Retrospektywy Sprintu – Podsumowanie

Ponieważ Sprint Retrospective jest trudnym wydarzeniem, często pojawiają się problemy podczas jego prowadzenia. Aby łatwiej sobie z nimi poradzić, warto zwrócić uwagę na te, które pojawiają się najczęściej. Typowe błędy podczas Retrospektywy Sprintu to:

  • niewystarczająca przejrzystość – gdy członkowie Zespołu Scrumowego nie radzą sobie uczciwie w trudniejszych sytuacjach zespołowych
  • koncentracja na jednorazowych problemach lub sukcesach – gdy członkowie Zespołu Scrumowego skupiają się na omawianiu sukcesów i porażek, zamiast na długofalowej efektywności pracy zespołu
  • Nadreprezentacja Product Ownera – gdy członkowie Zespołu Scrumowego traktują Właściciela Produktu z ograniczonym zaufaniem tak, jakby był kimś spoza zespołu lub przełożonym
  • problemy z samozarządzaniem – gdy członkowie Zespołu Scrumowego próbują przerzucić odpowiedzialność za problemy i podejmowanie decyzji.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube, Pintereście.

Scrum Guide | 39. Most common mistakes during a Sprint Retrospective caroline becker avatar 1background

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Zobacz wszystkie posty

Przewodnik po Scrumie:

  1. Słowniczek podstawowych pojęć, ról i pojęć
  2. Co to jest Scrum?
  3. Wartości Scrum
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Zespół Scrumowy - co to jest i jak działa?
  6. Kim jest Product Owner?
  7. Najczęstsze błędy Product Ownera
  8. Kim jest Scrum Master?
  9. Charakterystyka dobrego Scrum Mastera
  10. Najczęstsze błędy Scrum Mastera
  11. Jakie statystyki i metryki powinien śledzić Scrum Master?
  12. Współpraca Product Ownera ze Scrum Masterem
  13. Zespół Deweloperski w Scrum
  14. Najczęstsze błędy programistów
  15. Artefakty Scrum
  16. Skalowanie Scrum
  17. Backlog Sprintu
  18. Czym jest Backlog Produktu?
  19. Czym są historie użytkowników?
  20. Tworzenie najlepszej historii użytkownika z INVEST
  21. Najczęstsze błędy User Story
  22. Kryteria akceptacji historii użytkownika
  23. Szacowanie i punkty fabularne w Scrumie
  24. Poker Planowania
  25. Drużynowa gra szacowania
  26. Definiowanie przyrostu
  27. Wydarzenia scrumowe
  28. Czym jest Sprint w Scrumie?
  29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
  30. Co to jest wykres spalania?
  31. Jak stworzyć i zinterpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
  35. Codzienny Scrum
  36. Planowanie sprintu
  37. Przegląd sprintu
  38. Czym jest retrospektywa sprintu?
  39. Typowe błędy podczas Retrospektywy Sprintu
  40. Pielęgnacja Backlogu Produktu