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.

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.

4 thoughts on “Scrum – 4 Najczęstsze Błędy

  1. scrummaster says:

    Punkt 2. zdecydowanie tyczy się naszego zespołu i od pewnego czasu zastanawiam się, co z tym zrobić. PO zaczyna dostrzegać spadające velocity ze Sprintu na Sprint, ale jeszcze nie rozumie, że 1 z powodów jest mocna asekuracja zespołu właśnie z powodu traktowania estymat jak deadline’y…

    • admin says:

      Masz naprawdę trudny orzech do zgryzienia:) Tego typu przekonania zazwyczaj są głęboko zakorzenione, do tego może też tak być, że osoby nad Product Ownerem (np. klient) są również mocno przyzwyczajone do traktowania forecastów jako deadline’ów. To co mogłoby pomóc to rozmowa z Product Ownerem i wyjaśnienie mu jaki damage powstaje z powodu takiego podejścia.

      Jeżeli wprowadza się zmianę w sposobie pracy to najlepiej zacząć od małego kroku. Może dobrym pomysłem byłoby pogadać z zespołem i Product Ownerem po planningu i zapytać ich co z ich forecastu na następny Sprint będzie zrobione na 95%, a co z mniejszym prawdopodobieństwem? Być może takie coś „oswoiło by” Product Ownera z ideą, że oni tylko prognozują i nie są w stanie podpisać się krwią pod forecastem.

  2. Przyszły SM says:

    Hm, dokładnie rozumiem problemy w punkcie 2., jak i w punkcie 3., ale czy patrząc na to całościowo nie jest tak, że one się wykluczają? Bo niby nie mamy za wszelką cenę osiągać prognoz, ale koniecznie musimy dostarczyć kolejną wersję softu. Jak to w końcu wygląda? 🙂

    • Jakub Drzazga says:

      hej,

      2 i 3 porusza odrobinę inne tematy.

      2 oznacza, że zespół musi dostarczyć wymagania „no matter what”. 3 oznacza, że pracujemy w taki sposób, że wytwarzamy kolejne rzeczy i nawet po 10 Sprintach jest to rozgrzebane – nie tworzymy tego w taki sposób, aby każdy Sprint kończył się z działającym softem – takim który można zreleasować 🙂

Skomentuj Jakub Drzazga Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany.