Scrum – 4 Najczęstsze Błędy

Często słyszę od moich klientów, że w ich firmach pracuje się w Scrumie. Niestety w większości przypadków, okazuje się, że popełniają oni bardzo poważne błędy przy jego stosowaniu. Prawie zawsze prowadzi to do bolesnych konsekwencji. Oczywiście błędy, jakie zauważam są bardzo różne, jednak cztery z nich spotykam zdecydowanie najczęściej.

1. Brak Scrum Mastera

W tej sytuacji rola Scrum Mastera jest marginalizowana albo wręcz uważana za nadmiarową.

Przykład 1:

Podjęto decyzję, że projekt będzie prowadzony w Scrumie, jednak nikt nie ma pełnej wiedzy jak to zrobić. Stwierdzono natomiast, że aby zaoszczędzić, rola Scrum Mastera zostanie pominięta.

Przykład 2:

Zostaje powołany „rotacyjny” Scrum Master. Co Sprint kolejna osoba z zespołu deweloperskiego wcieli się w tę rolę.

Konsekwencje:

W zasadzie zawsze obserwuję to samo. Poszczególne elementy procesu są stosowane w błędny sposób. Nikt sobie z tego nawet nie zdaje sprawy. Scrum bardziej szkodzi niż pomaga. W projekcie jest bałagan i brak kontroli nad tym co się w nim dzieje.

Problemy nie są na bieżąco rozwiązywane. Z czasem coraz bardziej się nawarstwiają i zaogniają. Zespół pracuje coraz mniej wydajnie. Pojawiają się też konflikty. Najczęściej prowadzi to krok po kroku do porażki projektu.

2. Progozy zespołu stają się zobowiązaniem

W Scrumie planując kolejny Sprint zespół PROGNOZUJE co jest w stanie zrobić podczas jego trwania. Niestety taki forecast jest traktowany często błędnie jako zobowiązanie, z którego zespół będzie później skrupulatnie rozliczany.

Przykład:

Zespół prognozuje, że wykona przez najbliższe 2 tygodnie X funkcjonalności. Product Owner zobowiązuje się wobec klienta, że wspomniany zakres będzie gotowy na czas. Klient na podstawie tej informacji rozpoczyna kampanie marketingową zobowiązując się przed end userami, że określone funkcjonalności będą gotowe do użycia.

Konsekwencje:

Gdy zespołowi nie uda się wykonać na czas tego co prognozował, klient będzie bardzo zawiedziony. Poniesie nieprzyjemne biznesowe konsekwencje, natomiast jego zaufanie do pracy zespołu dramatycznie spadnie. Product Owner, Scrum Master albo nawet ktoś z wyższego managementu najprawdopodobniej zacznie wywierać naciski na zespół albo będzie stosować micro management aby zespół zaczął „dowozić” więcej.

Zespół, czując brak bezpieczeństwa może, stać się bardzo asekuracyjny. W takim wypadku prognozy na kolejne Sprinty będą przesadnie ostrożne i będzie mniej „brane do Sprintu”. W związku z czym wydajność zespołu spadnie1.

Istnieje też ryzyko, że zespół będzie miał tendencje do dowożenia za wszelką cenę. Przykładowo gdy kilka dni przed końcem Sprintu będzie wiadomo, że jest on zagrożony, zostanie on uratowany dużą liczbą nadgodzin i pracą w weekend. Jest to zazwyczaj niepotrzebne bohaterstwo. Praca ponad siły zaowocuje przemęczeniem i wyraźnym spadkiem efektywności w kolejnych Sprintach.

W najczarniejszym scenariuszu, gdy Sprint będzie zagrożony niedokończone zadania zostaną uznane za DONE (np. przymkniemy oko na błędy albo jakąś niedoróbkę). To pierwszy krok do całkowitej klęski projektu.

3. Po Sprincie nie ma działającego softu

W Scrumie każdy Sprint MUSI zakończyć się kolejną wersją działającego softu. Oznacza to, że jest gruntownie przetestowana i w 100% gotowa. Zawiera też funkcjonalności gotowe do użycia przez end usera aplikacji. Jest też w takim stanie który umożliwia szybki release2. Niestety ta zasada jest nagminnie łamana i ma to bardzo poważne konsekwencje.

Przykład:

Od 10 miesięcy nie było release’a ani nawet wersji która się do tego nadaje. Projekt od dłuższego czasu jest w 95% DONE.

Konsekwencje:

Nawet jeżeli jakieś wskaźniki mówią nam o poziomie zaawansowania projektu nie można na nich polegać. Nie mamy wiedzy, jaki jest prawdziwy postęp prac i „gdzie jesteśmy”.

Gdy mamy poczucie, że już prawie jesteśmy przy końcu projektu, zawsze pojawi się praca, której wcześniej nie przewidzieliśmy. Pojawi się też regresja. Gdybyśmy o nią dbali na bieżąco, koszt jej usunięcia byłby o wiele niższy. Niestety często byłem świadkiem, że regresja osiągnęła taki rozmiar, że jedyne co można było zrobić to zacząć projekt od nowa.

Kolejnym problemem jest to, że brakuje potwierdzenia czy produkt jest rozwijany we właściwym kierunku. Nie mamy kompletnej wersji którą możemy poddać inspekcji Stakeholderów3 i dokonać zmiany kierunku rozwoju aplikacji. Musimy bazować na wymaganiach zebranych dawno temu. Prawie na pewno stworzymy coś, co nie spełnia w pełni potrzeb użytkowników i celów biznesowych Stakeholder’ów.

Jeżeli chcesz się dowiedzieć więcej o różnych poziomach DONE zapraszam do artykułu: „6 poziomów działającego oprogramowania”.

4. Brak interdyscyplinarnych zespołów

W Scrumie zespół developerów musi być interdyscyplinarny. Oznacza to, że w zespole są WSZYSTKIE kompetencje potrzebne, aby stworzyć kolejną wersję działającego softu w ramach Sprintu. Łamanie tej zasady jest nagminne i niestety prowadzi do poważnych problemów.

Przykład:

Zespół „Back-end” tworzy API przez dwa miesiące. Po zakończeniu przekazuje swoją pracę „Front-endowi”.

Konsekwencje:

Najprawdopodobniej dojdzie do marnotrawstwa. Zespół tworzący API nie będzie w stanie przewidzieć potrzeb „Frontendu” za kilka miesięcy. Część rzeczy w API będzie niepotrzebna.

Co gorsza, część napisanego kodu API będzie wymagała zmian. W takim momencie najczęściej zespół „Back-endowy” jest już zaangażowany do innych prac i nie ma możliwości na szybką pomoc kolegom z „Front-endu”. Ci z kolei nie mogąc zamykać swoich zadań przestają „dowozić” Sprinty nie ze swojej winy. Wprowadza to silną demotywację i nierzadko generuje konflikty pomiędzy zespołami.

Najgorsza w tym wszystkim jest jednak utrata elastyczności – czyli istoty Scruma. W poprawnie zaimplementowanym Scrumie po każdym Sprincie dostajemy feedback od Stakeholderów na temat działającego softu i szybko możemy dostosować się do wizji biznesowej wprowadzając zmiany w kolejnych Sprintach. W tym przypadku podczas pracy nad API przez długi czas nie mamy żadnej informacji zwrotnej. Natomiast gdy zaczyna się praca nad front-endem jest już często za późno na zmiany w aplikacji. API jest gotowe i wymagałoby drastycznych zmian.

***

Więcej moich artykułów może znaleźć tutaj: https://agileinstitute.pl/index.php/author/jakub-drzazga/

Terminologia i dodatkowe uwagi:

1. Prawo Parkinsona mówi: „Praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie”, skoro mamy więcej czasu na zadania występuje duże ryzyko marnotrawstwa

2. W Scrumie używa się dokładnie pojęcia „Potentially Releasable Increment”

3. Steakholder – inaczej interesariusz. Osoba bezpośrednio zainteresowana wynikami projektu. To on ma być na końcu zadowolony z produktu.