Scrum jest obecnie najpopularniejszym sposobem prowadzenia projektów IT w sposób zwinny. Dzięki podejściu empirycznemu, doskonale sprawdza się podczas wytwarzania oprogramowania, często obarczonego dużą liczbą niewiadomych, jak np. problemy z określeniem wymagań. Prowadząc projekty w Scrumie dajemy klientowi możliwość szybkiej zmiany kierunku rozwoju produktu, np. po weryfikacji danej hipotezy biznesowej przez rynek. W sposób ciągły określamy, co stoi nam na drodze do efektywnej pracy (inspekcja) oraz na bieżąco dostosowujemy działania, usuwające napotkane przeszkody (adaptacja).

Naukę Scruma można porównać do gry w szachy - łatwo poznać zasady jednak, aby być w tym dobrym potrzeba dużo doświadczenia. 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 poważne błędy przy jego stosowaniu. Prawie zawsze prowadzi to do bolesnych konsekwencji.

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 taką rolę.

Konsekwencje:

W zasadzie zawsze obserwuję to samo. Poszczególne elementy Scruma są stosowane w błędny sposób. Nikt sobie z tego nawet nie zdaje sprawy. Proces 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. Prognozy zespołu stają się zobowiązaniem  

W Scrumie planując kolejny Sprint zespół PROGNOZUJE co jest w stanie zrobić podczas jego trwania. Niestety taka prognoza jest traktowana 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 końcowymi użytkownikami, ż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 spadnie.

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 oprogramowania 

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

Przykład:


Od 10 miesięcy nie było wydania 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ów 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.

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 programu w ramach Sprintu. Łamanie tej zasady jest nagminne i niestety prowadzi do poważnych problemów.

Przykład:


Zespół "Backend" tworzy API przez dwa miesiące. Po zakończeniu przekazuje swoją pracę "Frontendowi".

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ół "Backendowy" jest już zaangażowany do innych prac i nie ma możliwości na szybką pomoc kolegom z "Frontendu". 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 programu 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 Frontendem jest już często za późno na zmiany w aplikacji. API jest gotowe i wymagałoby drastycznych zmian.

Autor: Jakub Drzazga, Agile Coaching

Jakub posiada doświadczenie z najróżniejszych obszarów powiązanych z projektami IT. Zaczynał jako developer. Później już jako Scrum Master, wprowadzał Scruma w kolejnych projektach. Pracował też jako PM w projektach zwinnych, nieopierających się o metodykę Scrum. Obecnie robi to, co lubi najbardziej: jest konsultantem i szkoleniowcem. Od wielu lat pomaga organizacjom, od startupów po korporacje, w rozwiązywaniu problemów. Nie akceptuje kosmetycznych zmian i podążania za projektową modą. Gdy wymaga tego sytuacja, dołącza do projektu i pomaga wyprowadzić go z krytycznej sytuacji