Poziom dojrzałości Zespołu Scrumowego

Gdy zaczynasz pracę jako Scrum Master w nowym środowisku – z zespołem, którego dobrze nie znasz, ważne jest poznanie jego poziomu dojrzałości.

Dlaczego?

• Zespoły o stosunkowo niskim poziomie dojrzałości potrzebują więcej wskazówek.
• Zespoły dojrzałe potrzebują więcej okazji do refleksji.

Aby nie być „słoniem w składzie porcelany” i nie zepsuć zbyt wcześnie relacji z zespołem, musisz zrozumieć, jak dojrzały jest Twój zespół, zanim rozpoczniesz działania.

Niedojrzały zespół może wymagać nie tylko aktywnej facylitacji Retrospektywy – może być nawet konieczne wcześniejsze ustalenie sensownego tematu Retrospektywy. Aby nie tracić czasu – być może trzeba zdecydowanie pokierować działaniami zespołu. Z drugiej strony dojrzały zespół może nawet nie potrzebować niczego od ciebie w retrospekcji, ponieważ ma głębsze zrozumienie tego, jak?, co? i dlaczego?, niż ty.

Oto kilka wskazówek, które pomogą Ci określić, jak dojrzały jest Twój nowy zespół.

Zwróć uwagę, że nie jest to skala binarna – to raczej gradient, który może być na różnych poziomach w zależności od konkretnego tematu.

Rozwiązywanie problemów, samozarządzanie

• Czy członkowie zespołu otwarcie omawiają problemy?
• Czy aktywnie je rozwiązują bez Scrum Mastera?
• Czy potrafią podejmować rozsądne decyzje?
• Czy potrafią przyjąć za nie odpowiedzialność?

Współpraca

• Czy członkowie zespołu organizują swoje działania i współpracę wokół dostarczania wartości dla klienta?
• Czy znają wartości scrumowe i stosują się do nich w codziennej praktyce?

Wytwarzanie Przyrostu

• Czy niedowieziona praca kumuluje się?
• Czy programiści pracują nad jak najmniejszą liczbą elementów jednocześnie i wykonują je tak sprawnie, jak to możliwe?
• Czy nowy element rejestru sprintu został rozpoczęty, zanim inne zostaną przeniesione do stanu „Gotowe”?

• Czy Przyrost spełnia „Definicję Ukończenia” i jest gotowy do wydania?

Zmiana procesu

• Czy programiści stale stosują kontrolowane eksperymenty, aby przerwać swój utarty sposób działania, w celu odkrycia nowych, lepszych sposobów tworzenia oprogramowania?

Zachowanie podczas spotkań

• Czy potrzebna jest obecność Scrum Mastera, aby zespół prowadził własne spotkania?
• Czy na spotkaniach programiści uzyskują to, co jest im niezbędne do dalszej efektywnej pracy?

Codzienny Scrum

• Czy członkowie zespołu synchronizują się i opracowują najbardziej rozsądny plan zespołu na najbliższe 24 godziny?

Doskonalenie Rejestru Produktu

• Czy istnieje wzajemna interakcja pomiędzy interesariuszami/klientami, Właścicielem Produktu i zespołem?
• Czy spotykają się tak często, jak to konieczne, aby zagwarantować wystarczającą liczbę elementów Rejestru Produktu spełniających Definicję Gotowości przed następnym Planowaniem Sprintu?
• Czy Zespół radzi sobie z podziałem zadań na mniejsze, bardziej granularne?
• Czy potrafi je właściwie wyestymować?

Planowanie

• Czy planowanie jest wykorzystywane jako okazja do zbadania intencji kryjących się za każdym elementem Rejestru Produktu?
• Czy podczas tego spotkania zadawane są trudne pytania, aby zakwestionować własne zrozumienie wymagań i sposobu jego realizacji?
• Czy pojawiają się dyskusje w sprawie rozwiązania, ponieważ nie ma „jednego najlepszego sposobu” na jego wykonanie?
• Czy praca zespołu jest przewidywalna?
• Czy zespół realizuje zaplanowaną w Sprincie pracę?

Przegląd Sprintu

• Czy Przegląd jest postrzegany jako doskonała okazja do wzajemnego uczenia się, pozwalająca uzyskać głębszy wgląd w umysły klientów?
• Czy Właściciel Produktu może dodać więcej wartości do elementów Rejestru Produktu?
• Czy gotowy do wydania Przyrost Produktu niesie wartość, której oczekiwał klient/użytkownik?

Retrospektywa Sprintu

• Jak głęboko deweloperzy zagłębią się w swój proces, aby odkryć ukryte problemy i sposoby ich rozwiązania?
• Czy odkrywają miejsca do poprawy w swoich sposobach pracy?

Interakcja

• Jak często widzisz programistów komunikujących się ze sobą i Właścicielem Produktu?
• Czy są pytania uważane za zbyt trywialne lub zbyt trudne do zadania?

Podsumowanie

Spójrz na powyższe wzorce: rozwiązywanie problemów, współpraca, realizacja zadań, zmiana procesu, zachowanie podczas spotkań i interakcja. Dzięki temu szybko i dokładnie zrozumiesz, jak dojrzały jest Twój zespół. Jako Scrum Master zdołasz wówczas dostosować swoje zachowanie do potrzeb zespołu.

Literatura:

Bręk Ł., „Zespół długodojrzewający”, Bialko.eu, 2019

Chrapko M., „Jak budować wydajne zespoły w Scrumie i nie tylko?”, MariuszChrapko.com, 2015

Pieńkowski R., „Czym się wyróżnia dojrzały Scrum?”, Sages.pl

Słowikowski P., „Badanie zdrowia zespołu”, PawelSlowikowski.pl, 2021