7 znaków zwiastujących problemy w Zespole Scrumowym

26 września 2022 • 7 min to read

Czy zauważyłaś jakieś problemy po wdrożeniu Scruma? Zastanawiasz się co możesz zmienić, aby pomóc Twojemu zespołowi się doskonalić? Przeczytaj ten artykuł i sprawdź, czy czasem nie wpadliście w którąś z 7 pułapek wymienionych przeze mnie.

Spis treści

Wstęp

Scrum lub inne praktyki Agilowe stały się bardzo popularne przez ostatnie 10-20 lat. Coraz więcej organizacji decyduje sie na ”Transformację Agile”. Co to znaczy w rzeczywistości? W wielu przypadkach jest to tylko zmiana języka w organizacji, ale podejście do pracy i ludzi pozostaje takie samo.

Na szczęście są firmy, które naprawdę chcą działać i zmieniają swój sposób myślenia, pracy i dostarczania produktów. Oczywiście zmiana to proces i nie da się wdrożyć Scruma lub jakichkolwiek innych praktyk zwinnych bez popełniania błędów.

Dzisiaj chciałabym pokazać 7 znaków zwiastujących problemy w Zespole Scrumowym. Bądź ostrożna jeśli zauważysz je w swoim zespole. Prawdopodobnie oznacza to, że jakieś elementy Scruma zgubiły się podczas implementacji. Ale nie przejmuj się! Zawsze możesz zastosować empiryczne podejście i sprawdzić co nie działa oraz zaaplikować potrzebne zmiany.

1. Właściciel Produktu lub Scrum Master przypisujący pracę

Jedną z większych różnic pomiędzy tradycyjnym dostarczaniem produktów (Waterfall) a Scrumem jest samozarządzanie oraz samoorganizacja samoorganizacja Zespołu Scrumowego.

Jeśli kiedykolwiek dostrzeżesz, że Właściciel Produktu lub Scrum Master przypisuje elementy Product Backlogu do ludzi, jest to zawsze zły znak. Oznacza to, że zespół nie ma autonomii, aby decydować jak będzie pracować i nie jest samozarządzający.

Właściciel Produktu powinien dać znać zespołowi tylko Co potrzebuje być zrobione, ale Jak to dokładnie będzie zrobione i Kto będzie pracować nad konkretnym zadaniem, to już jest decyzja Deweloperów w Zespole Scrumowym. Scrum Master także nie powinien kontrolować zespołu i przypisywać komukolwiek zadań. To powinna być osoba,która wspiera zespół i uczy jak mają być samozarządzający. Wiem, że łatwo się to mówi lecz wielu Scrum Masterów , którzy byli kiedyś Project Menedżerami ma problem z odpuszczeniem kontroli. Ale nie ma innego wyjścia jeśli naprawdę chcesz pomóc zespołowi.

2. Brak transparentności

Co mam na myśli pisząc “brak transparentności”? O rany! Jest tyle rzeczy, które ludzie potrafią ukrywać.

Jednym ze złych znaków w Zespole Scrumowym jest rozmawianie o problemach za plecami danej osoby, zamiast rozmawiać o tym z całym zespołem na Retrospektywie Sprintu. Może to oznaczać, że zespół nie ma wystarczająco zaufania do siebie, aby móc rozmawiać o problemach.

Problemy z transparentnością mogą być także związane z komunikacją z klientami np. Zespół Scrumowy ukrywający problemy związane z tworzeniem produktu, przez co interesariusze myślą, że wszystko jest w porządku.

W obu przypadkach, problemy wyjdą na jaw w pewnym momencie, a ukrywanie rzeczy nie przyniesie korzyści. W takich sytuacjach zdecydowanie polecam bycie szczerym i rozmawianie o tym z czym zespół się zmaga. Nawet jeśli nie będzie to komfortowe dla ludzi!

3. Brak Celu Sprintu - wszystko jest priorytetem

Jeśli zapytasz swojego Właściciela Produktu lub Zespół Scrumowy - ”Co jest dla nas najwyższym priorytetem?” a oni odpowiedzą ”Wszystko!”, jest to zawsze zły znak. Ale to nie koniec. Nawet jeśli odpowiedzą w ten sposób, ale mają Cel Sprintu i na końcu są w stanie wybrać najważniejsze elementy Product Backlogu, to powinno być w porządku.

Problem zaczyna się wtedy, gdy Zespół Scrumowy nie ma Celu Sprintu w trakcie Sprintu i myślą oni, że wszystko w Sprint Backlogu jest najważniejsze.

Jaki jest rezultat takiego myślenia? Multitasking i brak skupienia podczas Sprintu. **Cel Sprintu jest świetnym artefaktem, ponieważ pomaga Deweloperom w skupieniu i kieruje ich podczas każdej decyzji, którą podejmują w trakcie Sprintu.

4. Zbyt wiele osób w Zespole Scrumowym

Bazując na ostatniej wersji Przewodnika po Scrumie, Zespół Scrumowy powinien liczyć max. 10 osób. Dlaczego?

Jak wynika z naszego doświadczenia, mniejsze zespoły na ogół lepiej się komunikują i są bardziej produktywne.

Jeśli Zespół Scrumowy liczy więcej niż 10 osób, jest to zły znak. Najczęściej oznacza to, że komunikacja między członkami zespołu dzie działa. Czasami może się wydawać, że wszystko jest w porządku, ale w rzeczywistości zbyt duży zespół sprawia, że można pominąć potrzeby członków zespołu, ponieważ nie ma wystarczająco czasu i przestrzeni, aby każdy dzielił się z innymi swoimi myślami.

5. Product Backlog nigdy nie jest gotowy na Planowanie Sprintu

Ten problem występuje często i zdecydowanie jest to oznaka problemów. Jeśli Product Backlog nie jest gotowy na Planowanie Sprintu i zespół nie wie na czym powinien się skupić, Sprint prawdopodobnie będzie bardzo chaotyczny.

Kiedy mówię, że Product Backlog jest gotowy, nie oznacza to, że jest w pełni zdefiniowany. Oznacza to tylko, że elementy backlogu, które są na szczycie, są zdefiniowane wystarczająco, aby zespół mógł zacząć pracę nad nimi.

Oznacza to również, że Product Owner ma klarowną wizję produktu i będzie ona prowadzić zespół w dalszych działaniach. Powinniśmy unikać tak bardzo jak to możliwe **chaotycznego Product Backlogu, który nie służy Zespołu Scrumowemu.

6. Story points tłumaczone na godziny

Pozwólcie, że wyjaśnię - story points nie są częścią Scruma. Ale mogą być używane przez Zespół Scrumowy do szacowania i planowania ich pracy. Zatem jeśli Zespół Scrumowy zdecyduje się używać story points (szacowania w punktach), NIGDY nie powinni tłumaczyć ich na godziny. Dlaczego? Powód jest bardzo prosty. Godziny to szacowanie absolutne, a story points są relatywnym sposobem szacowania.

Co to oznacza?

Estymowanie absolutne jest wykonane w absolutnych wartościach np. godzinach. Jako ludzie, jesteśmy bardzo słabi w szacowaniu złożonych zadań w godzinach.

Jeśli chodzi o relatywną estymację, to szacowanie nie jest związane tylko z wysiłkiem włożonym w realizację zadania i w związku z tym nie powinniśmy tłumaczyć punktów na godziny. Musimy wziąć też pod uwagę ryzyko, niepewności, technologię oraz wolumen.

Wyobraź sobie, że zdecydowałaś, że 1 story point oznacza jakąś liczbę godzin. W tej sytuacji w rzeczywistości nie stosujesz relatywnej estymacji. To jest wciąż niezmienne szacowanie w godzinach.

Kiedy używamy story points do szacowania, te estymaty będą różne w zależności od zespołu, ich wiedzy, umiejętności i rzeczy, które wiedzą na temat zadania czy historyjki.

Szacują oni biorąc pod uwagę wszystkich członków zespołu. Zatem jedna osoba może pracować nad historyjką przez 8 godzin, bo jest nowa i musi się nauczyć danej technologii. Tymczasem inny członek zespołu mógłby zrobić to 3 godziny, ponieważ jest doświadczony i ta technologia jest dla niego prosta.

To jest jeden z przykładów jak działa estymacja. Jest to także świetna możliwość dla Deweloperów do dyskusji na temat poszczególnych elementów backlogu oraz do wyklarowania niewiadomych.

Tłumaczenie story points na godziny nie daje żadnej wartości, a dodaje ryzyka mikro menedżmentu i późniejszej weryfikacji przez kogoś, czy dane zadanie było ukończone w planowanym czasie.

7. Retrospektywa Sprintu bez akcji

To kolejny znany problem i chciałabym go tutaj podkreślić, ponieważ zatrzymuje to Zespół Scrumowy przed rozwojem. Najczęściej spotykanym scenariuszem jest Retrospektywa na której mówi się o tym co poszło dobrze, źle oraz co powinno być usprawnione. Problem pojawia się wtedy, gdy mówimy o problemach, pomysłach na usprawnienie, ale nie kończymy spotkania z jasnymi akcjami do wykonania.

Bazując na Przewodniku po Scrumie:

Scrum Team określa zmiany najbardziej pożądane pod kątem poprawy swojej efektywności. Najbardziej znaczące usprawnienia wprowadza się jak najszybciej. Można je wręcz włączyć do Sprint Backlogu na kolejny Sprint.

Powinniśmy określić zmiany, które powinny być wdrożone i jak najszybciej je wdrożyć. Bez tego, cała dyskusja jest tylko zmarnowaniem czasu i wówczas Retrospektywa nie daje wartości, którą powinna dostarczać.

Oczywiście, jeśli nie ustalamy akcji, to jest też to oznaka czegoś. Co się za tym kryje? Czy mamy wystarczająco przestrzeni w Sprincie, żeby pracować nad usprawnieniami? Czy firma wspiera nas w dokonywaniu zmian? Czy czujemy się częścią zespołu i mamy motywację, aby wprowadzać zmiany na lepsze?

To są pytania, które warto sobie zadać, jeśli rozpoznamy taki problem w swoim zespole.

Podsumowanie

Ten post miał na celu podsumowanie znaków problemów w Zespole Scrumowym, aby pomóc Ci je rozpoznać i zacząć je adresować.

To koniec artykułu, ale zdecydowanie nie jest to koniec znaków problemów w zespołach. Czy kiedykolwiek doświadczyłaś problemów, które wypisałam? Jak sobie z nimi poradziłaś? Czy są jakieś inne, które znasz i możesz wymienić?