5 grzechow glownych scrum mastera

Czy Twoja firma zdecydowała się przejść na Scrum, a Ty zostałeś świeżo upieczonym Scrum Masterem lub Product Ownerem? A może już dłuższy czas pracujesz w scrumowym zespole i zastanawiasz się, co można by zmienić?

Zobacz, jakie pułapki czyhają na każdego Scrum Mastera i jakich grzechów nie powinien popełniać.

1. Dyrygowanie zespołem

Przyjrzyj się, w jaki sposób rozdzielana jest praca w zespole. Czy przydzielasz zadania konkretnym osobom? Czy ulegasz pokusie pośredniczenia we wszelkiej komunikacji pomiędzy członkami zespołu a otoczeniem (zwłaszcza z Product Ownerem)?

A może, z racji swojego dłuższego stażu w projekcie, bierzesz na siebie przekładanie wymagań klienta na konkretne zadania techniczne? Może się okazać, że występujesz bardziej w roli Project Managera, a nie Scrum Mastera.

Jedno z moich ulubionych określeń Scrum Mastera to “servant leader”. Dla mnie oznacza to służenie zespołowi w zakresie usuwania przeszkód na drodze do celu oraz tworzenie przyjaznego środowiska, w którym zespół może skupić się na wykonywaniu swojej pracy, którą sam sobie organizuje. Samoorganizacja i komunikacja z Product Ownerem są tu kluczem do sukcesu.

Wiem z doświadczenia, że klient bardzo szybko dostrzega korzyści płynące ze Scruma, gdy pozwoli mu się dyskutować swoje wymagania i problemy z zespołem. Co dwie głowy, to nie jedna, a co dopiero cały zespół.

Różnica między kierownikiem zespołu a Scrum Masterem jest mniej więcej taka, jak między trenerem a coachem. Ideą coachingu jest wzmacnianie poczucia odpowiedzialności za własną karierę i życiowe cele; rozwijanie samodzielności w dokonywaniu zamierzonej zmiany. Podobna idea przyświeca Scrumowi.

Oddanie “mocy” zespołowi nie tylko wpływa pozytywnie na poziom motywacji, ale także na jakość wytwarzanego produktu i zadowolenie klienta.

Oczywiście, może zdarzyć się tak, że Scrum Master przejmuje stery nad zespołem z obawy, że jego członkowie nie poradzą sobie w obliczu złożonego problemu lub, że obiorą nieoptymalny sposób na jego rozwiązanie. Pomocne może tu być stosowanie tzw. “safe-fail experiments”.

Jeśli zespół chce spróbować w kodzie nowej biblioteki, nowej organizacji pracy lub rozbicia zespołu na dwa mniejsze, można to zrobić w pewnych bezpiecznych ramach, upewniając się, że na wypadek niepowodzenia, można wrócić do poprzedniego układu.

2. Zakurzone „Definition of Done”

Co znaczą dla Ciebie pojęcia „done” lub „production ready”? Czy rezultat każdego sprintu może być wdrożony produkcyjnie? Czy czujesz jakikolwiek dreszczyk niepewności, gdy rezultat Waszej pracy ma ujrzeć światło dzienne?

Jeśli tak jest, to prawdopodobnie warto przedyskutować z zespołem Wasze “Definition of Done” – czy jest respektowane i jaki ma kształt oraz proces testowania produktu przed jego wdrożeniem. Zróbcie “burzę mózgów” i spróbujcie namierzyć wszystkie luki i ryzyka w tym procesie.

Następnie postarajcie się im zapobiec przez  wprowadzenie odpowiednich testów (jednostkowych, automatycznych “klikaczy”, obciążeniowych) oraz praktyk zarządzania ryzykiem z zakresu Continuous Delivery.

Gdy pojawił się Scrum, klienci byli w szoku, że nowe funkcjonalności można było wdrażać nie raz na rok, ale nawet co pół miesiąca. Continuous Delivery idzie o krok dalej i umożliwia wypuszczanie zmian na produkcję nawet po każdej zmianie w repozytorium kodu.

Jest to możliwe dzięki bardzo szczelnej warstwie testującej, która jest w stanie wyłapać prawie wszystkie poważniejsze błędy. Dzięki temu, że wypuszczamy zmiany często, są one relatywnie mniejsze, przez co również skala potencjalnej porażki jest ograniczona.

Polecam również zapoznanie się z ideą Canary Release, która proponuje wypuszczać nową funkcjonalność w pierwszej kolejności do ograniczonej liczby użytkowników, a dopiero gdy wszystko pójdzie dobrze – do wszystkich. Dzięki temu, nawet jeśli nowa wersja naszego produktu będzie wyjątkowo pechowa, ucierpi na tym tylko pewien procent użytkowników.

Wielokrotnie słyszałem od różnych Scrum Masterów zdania typu: “po tym sprincie potrzebujemy jeszcze przeprowadzić fazę integracji” lub “po zamknięciu sprintu odbędą się dwa tygodnie testów”. Jeśli tak się dzieje, to trudno nazwać taki projekt scrumowym. W każdym sprincie powinien powstawać produkt gotowy do wdrożenia na produkcję i tylko od Product Ownera zależy, czy takie wdrożenie nastąpi. A gotowość do wdrożenia powinna być jednoznacznie zdefiniowana właśnie w “Definition of Done”.

3. Brak asertywności

Czy przydarza Wam się to, co spotyka chyba każdy zespół scrumowy, tzn. zmiana wymagań w trakcie sprintu, która stawia pod znakiem zapytania jego cel? Co robicie w takich sytuacjach? Czy zgadzacie się wziąć do sprintu więcej, niż zespół jest w stanie przerobić?
Czy jesteś w stanie obronić swój zespół przed “atakami” z zewnątrz, gdy w projekcie robi się “gorąco”? Nie chodzi mi tutaj o zaprzeczanie, ani o branie odpowiedzialności za cały projekt na siebie, lecz o branie odpowiedzialności przez cały zespół, bez wskazywania winnych.

Asertywność powinna również przejawiać się w odpowiednim sformułowaniu wspomnianego wcześniej Definition of Done. Jego punkty powinny być sprawdzalne w sposób “zero-jedynkowy” i obiektywny. Tzn. każdy, kto przyjdzie z zewnątrz i porówna wynik sprintu z wymaganiami, będzie w stanie stwierdzić, na podstawie DoD, czy nadaje się on do wdrożenia na produkcję.

DoD nie powinno zawierać niejednoznacznych punktów, takich jak: “Funkcjonalność podoba się Product Ownerowi” lub “Aplikacja posiada ładny interfejs”. W tym pierwszym przypadku, gromadzenie wymagań od klienta powinno się odbywać na sesjach refiningu oraz na planowaniu, a jeśli zespół poprawnie je zaimplementował, można je uznać za wykonane (Done).

Oczywiście Product Owner może stwierdzić, że to, co widzi, nie jest do końca tym, co sobie wyobrażał. Powinien on jednak uznać wynik pracy, jeśli zespół wykonał zadanie zgodnie z założeniami. W przeciwnym razie może to wpłynąć negatywnie na motywację developerów. Korektę do przedstawionego rozwiązania Product Owner może zgłosić na następnym planningu.
Jeśli widzisz, że zespół zgadza się na wzięcie zbyt wielu zadań (często niedoprecyzowanych) do sprintu, mimo że nie wierzy w ich skończenie, powinna Ci się zapalić czerwona lampka.

Podobnie jest z pomijaniem pisania testów, czy refaktoryzacji kodu i ciągłe odkładanie tego na później. Na jednej ze swych prezentacji jeden z twórców Scruma, Ken Schwaber, powiedział, że naczelnym zadaniem Scrum Mastera jest upewnianie się, że jakość nie będzie zagrożona. Nie da się tego dokonać bez asertywnej postawy Scrum Mastera, który będzie w stanie przeciwstawić się naciskom na zwiększenie prędkości wytwarzania, kosztem jakości.

W dalszej perspektywie zaniżanie jakości przeważnie skutkuje drastycznym zmniejszeniem prędkości zespołu.
Inną sprawą, nad jaką warto się zastanowić, to Twoja reakcja na wynik Retrospektywy Sprintu. Czy jest to tylko spotkanie, na którym wszyscy możemy sobie ponarzekać?

Myślę, że Retrospektywa ma wartość tylko wtedy, gdy jesteśmy w stanie szczerze przyznać, na co mamy wpływ, a na co nie mamy i to, co możemy zmienić, przetworzyć na konkretne zadania do następnego sprintu. Jeśli nie wprowadzamy zmian do naszego procesu, to mamy tylko jeden składnik Scruma: “Inspect” bez “Adapt”.
Polecam w tym miejscu przeczytać post z naszego bloga w podobnym temacie: 5 Scrum values.

4. Tracenie z oczu klienta i wartości biznesowej

Czy masz pewność, że klient na pewno “wie, czego chce”? Czy nie zabrnął za daleko w formułowaniu wymagań do części systemu, której prawie nikt nie będzie używał?

A może żąda zmiany, którą ryzykuje “pożar” na produkcji w parę minut po wdrożeniu? Czy pomagasz swojemu Product Ownerowi w priorytetyzowaniu backlogu? Czy uświadamiasz go, jak estymaty historyjek powinny wpływać na ich pozycję w backlogu?

Nie zawsze jest możliwe zbudowanie z Product Ownerem takiej zażyłej relacji, żeby móc pójść z nim na piwo i pogadać o sprawach prywatnych. Nic jednak nie stoi na przeszkodzie, żeby dążyć do relacji pełnej wzajemnego szacunku i zaufania.

Najważniejsza jest jednak nie relacja PO ze Scrum Masterem, ale z zespołem jako całością. Dopiero, gdy klient ma odpowiednie poczucie bezpieczeństwa w kontakcie z zespołem, może szczerze porozmawiać o swoich problemach i swoich celach.

Tylko w takich warunkach może dojść do konstruktywnej krytyki i w miarę obiektywnej oceny wartości biznesowej poszczególnych historyjek. Może się okazać, że przy niewielkiej zmianie wymagań o połowę zmniejszy się ich estymata.

A może z dyskusji wyłoni się pomysł na nową funkcjonalność o dużej wartości dla użytkowników? Sesje refiningu i planowania są dobrym pretekstem do przeniesienia wymagań ze środowiska komputerowego do międzyludzkiego i poddania ich dogłębnej analizie, nie tylko pod kątem technicznym, ale przede wszystkim pod kątem funkcjonalnym. Dzięki takim spotkaniom zespół poznaje klienta i jego potrzeby, natomiast PO poznaje developerów, testerów i ich problemy, czy preferencje.

Wypracowanie dobrych relacji z PO polega głównie na budowaniu zaufania, które może się przydać w trudnych sytuacjach. Na przykład, gdy zespół potrzebuje kilku story-pointów na poprawę jakości kodu albo gdy PO zależy na tym, by wyjątkowo zamienić priorytety wewnątrz sprintu. Zaufanie przydaje się też w momencie, gdy zespół przyznaje, że z pewnymi historyjkami nie wyrobi się w sprincie.

5. Unoszenie się na powierzchni Scruma

Popularna opinia o Scrumie jest taka, że jest on łatwy do zrozumienia, ale trudny do opanowania. Każdy Scrum Master powinien w “małym palcu” mieć treść Scrum Guide’a.

W końcu to tylko kilkanaście stron. Ale czy to wystarczy? Pozostawanie jedynie na poziomie teorii Scruma może prowadzić do pewnej “sztuczności”, do braku przekonania co do sensu prowadzonych spotkań scrumowych, do nieumiejętności przekonania Product Ownera, że pewne rzeczy warto robić, a innych powinno się unikać, itp.
Jeśli, jako Scrum Masterzy, ograniczamy swoje pole widzenia do “własnego podwórka”, możemy nie dostrzec powierzonej nam odpowiedzialności za zmianę w całej organizacji.

Wypełnianie tego zadania może się powieść, jeśli poszerzymy swoją wiedzę i będziemy patrzeć na problemy z szerszej perspektywy. Dobrze w tym celu zapoznać się z różnymi metodologiami i podejściami do prowadzenia projektów, poczytać wpisy na blogach o “zwinnej” tematyce, albo poszukać na youtube prezentacji Kena Schwabera oraz Jeffa Sutherlanda – twórców Scruma.

Warto zaznajomić się z takimi pojęciami jak Kanban, Lean, czy Cynefin Framework. Mogą się też przydać krótkie warsztaty z mediacji lub technik łagodzenia konfliktów. Nie chodzi tu o to, żeby być ekspertem w każdej dziedzinie, ale by zdawać sobie sprawę z istnienia różnych koncepcji, które mogą uzupełniać naszą wiedzę w zakresie Scruma o ważne aspekty.

Wdrożenie Scruma w danej organizacji nie dzieje się od razu. To jest proces, który wymaga czasu i uważnej obserwacji. Jak zauważył Geert Hofstede, zmiana przechodzi przez kolejne poziomy. Zaczyna się od warstwy symboli (stworzenie backlogu, tablicy kanbanowej), poprzez warstwę bohaterów (doświadczeni Scrum Masterzy, agile-coache), warstwę rytuałów (wprowadzenie spotkań scrumowych, sesji refiningów), aż do najgłębszej warstwy, jaką stanowią wartości (przejęcie agile’owego sposobu myślenia, “czucie” Scruma).

Sukces jednego projektu może zainspirować inne projekty do wypróbowania Scruma.