Przejdź do treści

Dlaczego Scrum nie działa?

Scrum FailPewien zespół programistów postanowił wdrożyć w swojej pracy framework Scrum. Jedna z osób w tym zespole przeczytała książeczkę pod tytułem Scrum Guide i opowiedziała innym jak ten cały Scrum wygląda – opowiedziała o tym, że są sprinty, że ostatnio cały świat tak robi, że będą bardziej efektywni oraz że w ogóle będzie miło i przyjemnie.

Zabrano się do pracy. Ustalono role – Franek został Właścicielem Produktu, zaś Marek został Scrum Masterem. Ustalono, gdzie będzie trzymany backlog oraz nauczono się, że gotowe zmiany w kodzie od teraz nazywają się inkrementem. Ustalono długość sprintu, w kalendarzach pojawiły się nowe spotkania pod tytułem planowanie sprintu, codzienny scrum, przegląd oraz retrospektywa. Wszystko zaczęło się toczyć, właściciel produktu priorytetyzował zadania w backlogu, backlog produktu zmieniał się w backlog sprintu, backlog sprintu zmieniał się w inkrement, a wykresy spalania poruszały się to w górę, to w dół.

Wszystko miało być pięknie. Jednakże po pewnym czasie członkowie zespołu doszli do wniosku, że w zasadzie nic się nie zmieniło. Zadania są takie same, jakość dostarczanego produktu w zasadzie cały czas pozostawia sporo do życzenia, a odbiorca cały czas jest tak samo niezadowolony. I w zasadzie to po co nam ten cały Scrum, więcej z niego kłopotu niż pożytku…

Historia jakich wiele? Kojarzysz podobny przypadek? To zastanawiające, jak często taka historia się powtarza…

Patrząc na kilka znanych mi wdrożeń Scruma, mam poczucie, że jest on trochę podobny do góry lodowej. Sam Scrum jest zestawem reguł, które łączą ze sobą role, artefakty oraz zdarzenia. I te zdarzenia, artefakty i role są właśnie tymi rzeczami, które widać nad powierzchnią wody. To są elementy łatwo identyfikowalne – bardzo prosto jest określić czy mamy Scrum Mastera, jak długi jest sprint oraz ile elementów mamy w backlogu. Sęk w tym, że jest to framework dla ludzi – a ludzie chociaż czasami kierują się regułami, to dużo, dużo częściej kierują się własnymi przekonaniami, wartościami lub przyzwyczajeniami.

scrum_iceberg

Tym, co kryje się pod powierzchnią wody, są właśnie wartości i przekonania naszego zespołu. Ich bezpośrednio nie widać – natomiast mają one zasadniczy wpływ na to, w jaki sposób zespół pracuje.

Scrum tak naprawdę dość dobrze definiuje zestaw wartości. Na samym wstępie Scrum Guide’a mamy wymienione trzy filary procesu: przejrzystość, inspekcję oraz adaptację. Jest tam również bardzo mocno podkreślona samoorganizacja i interdyscyplinarność zespołu deweloperskiego (self-organizing and cross-functional teams). Jak poszukamy dalej, to odnajdziemy pięć wartości, które są podkreślone przez Scruma: odwaga, otwartość, szacunek, skupienie oraz zaangażowanie. Odnajdziemy podkreślenie pracy w stałym tempie. Scrum należy do nurtu metodyk zwinnych, więc jak najbardziej ma do niego zastosowanie manifest Agile: ludzie i interakcje ponad procesy i narzędzia; działające oprogramowanie ponad obszerną dokumentację; współpraca z klientem ponad formalne ustalenia oraz reagowanie na zmiany ponad podążanie za planem.

Podczas wdrożenia Scruma w zespole może się zdarzyć jedna z trzech sytuacji.

Może zdarzyć się tak, że członkom zespołu wartości opisane wyżej są bardzo bliskie. Członkowie zespołu mogą nawet nie określać w żaden sposób tych wartości (nie wiedzą, że mówią prozą…), ale tak jakoś te wartości są im znajome, czują je, mają je we krwi. W takiej sytuacji wdrożenie Scruma przypomina „efekt wow!” i podczas retrospekcji często powtarza się radosne słowo „wreszcie!”. „Wreszcie zadania są jasne i klarowne”, „wreszcie pojawia się cel”, „wreszcie o czymś decydujemy”, czy „wreszcie zaczęliśmy pracować razem jako zespół”. Scrum Master nie ma zbyt wiele pracy, jest pięknie.

Może się również zdarzyć tak, że członkowie zespołu nie cenią pracy zespołowej, autonomii, samoorganizacji – ale są otwarci i są w stanie się tego nauczyć. Powoli odkrywają urok autonomiczneo decydowania o sposobie wykonywania swojej pracy, odkrywają inspekcję i adaptację, uczą się wzajemnego zaufania i pracy zespołowej. Zadaniem Scrum Mastera jest katalizacja tego procesu, zwracanie uwagi na rzeczy które działają słabo i pomaganie zespołowi w odkrywaniu tych wartości.

Ale może się zdarzyć również tak, że członkowie zespołu cenią sobie inne wartości niż te zdefiniowanie przez framework. Co – uwaga, uwaga! – wcale nie oznacza, iż ten zespół jest zły czy też musi być nieefektywny. W pewnych warunkach ten zespół może działać całkiem sprawnie i dostarczać dobre projekty. Ale nie odnajdzie się dobrze w środowisku Scrum’owym.

Jakie wartości zespołu mogą stać w sprzeczności z wartościami Scruma? Na przykład zespół może nie chcieć się adaptować. „My mamy swoją metodę pracy, sprawdzała się we wszystkich projektach, nie ma potrzeby jej zmieniać”. A jeżeli prowadzone projekty są podobne do siebie, to faktycznie może całkiem sprawnie działać. Zespół może nie chcieć pracować wspólnie nad zadaniami – może się zdarzyć, że ludzie dobrze czują się dzieląc swoje zadania według z góry znanego klucza: „zapytania SQL zawsze pisze Piotrek, HTML-a nie rusza nikt oprócz Jacka, z testami tylko do Basi”. Zespół może nie lubić pracować w stałym tempie: „spokojnie skupmy się na teraz na doborze kolorów interfejsu, a jak pojawią się jakieś problemy, to przysiądziemy mocniej nad projektem przed terminem”. Zespół też może nie chcieć się samoorganizować, bo jest przyzwyczajony do tego, że jest ktoś – kierownik zespołu bądź lokalny guru – kto zawsze podejmuje decyzje o tym, jak pracujemy.

Co się dzieje, gdy wartości Scruma stoją w sprzeczności z wartościami zespołu? Z pozoru wszystko jest OK: są sprinty, backlogi, przeglądy i retrospekcje. Ale widać zwątpienie na twarzach („po co nam to wszystko, wcześniej też było dobrze”), czasami słychać narzekanie na zmiany („ten adżajl to sam chaos, ja nie wiem co mam robić, kiedyś było lepiej”) i widać, że w postępowaniu zespołu nie zachodzą zmiany. Albo jeżeli jakieś zachodzą, to staje się to bardzo, bardzo powoli.

Co może wówczas zrobić Scrum Master? Chyba najlepszą rzeczą, jaką może zrobić, jest pokazanie zespołowi tego konfliktu wartości. Pokazanie tego, co kryje się pod powierzchnią wody. Pokazanie, jakie wartości zespołu decydują o tym, że nie stosujemy adaptacji, pracy zespołowej czy samoorganizacji. I postawienie zespołowi otwartym tekstem pytania, czy chcemy, żeby tak było.

Być może zespół wtedy podejmie autonomiczną decyzję o zmianie swojego sposobu pracy. A być może  dojdzie do wniosku, że bez sprintów i bez rewolucji żyje się jednak spokojniej…

Pytanie tylko, czy na ten spokój nas stać.

* * *

Problem konfliktu wartości to oczywiście nie jest jedynym problemem, który może przytrafić się podczas wdrożenia Scruma. Jeżeli po przeczytaniu tego artykułu odczuwasz niedosyt przyczyn, dla których Scrum może działać kiepsko  – polecam serdecznie tekst 10 reasons why your Scrum project is failing”. A do samego tematu Scruma i wdrażania go powrócimy na Trzeciej Kawie już wkrótce…

5 komentarzy do “Dlaczego Scrum nie działa?”

  1. Wg wikipedii: „Jako że zespół z założenia jest samoorganizującym się ciałem, nie ma mowy o odgórnym przypisywaniu zadań do poszczególnych członków zespołu, lecz samodzielnie dokonują oni wyboru realizowanych zadań, według wspólnych ustaleń, umiejętności czy innych preferencji.”

    – Wiec chyba nie ma nic zlego w tym ze Piotrek czy Basia beda mieli takie same zadania jak zwykle. Moze do nich przywykli i lubia je.

    Ale ja nie o tym chcialam. Chcialam o tym, ze – we wszystkich znanych mi przypadkach porazki Scruma – o porazce zdecydowal sposob wprowadzenia metodologii. Przyszedl bardzo wazny czlowiek i powiedzial „przeczytalem ksiazke o scrumie [albo „bylem na fajnym szkoleniu ze skruma”] wiec od jutra pracujecie w tej metodologii. Na szkolenie na razie nie mamy czasu [/budzetu/trenera….]. Najwazniejesze ze ja i scrum master (ktorym oczywiscie zostal kierownik projektu) wiemy o co chodzi”.

    A wtedy zespol powiedzial (po cichutku, co by nie daj boze kierownik nie uslyszal) „to wy sobie ze skram masterem wprowadzajcie co tam chcecie a my wracamy do pracy”.

    Efekt – na standardowe codzienne spotkania zespolu od miesiaca przychodza 2 osoby: scrum master i product owner. .. :-)

    1. Jeżeli mamy akurat w sprincie takie zadania, jakie Piotrek i Basia lubią – to niech je dzielą między siebie jak chcą i robią!

      Cały problem polega na tym, że w praktyce zwykle w sprincie trafiają się zadania, które nie są w 100% dopasowane do preferencji zespołu. I wtedy zespół robi jedną z dwóch rzeczy: albo Piotrek pomaga Basi i odkrywa w tym wartość, albo też Basia robi swoje, a Piotrek znajduje sobie zajęcie zastępcze i dyskretnie czeka aż Basia skończy. Oczywiście narzekając przy tym, jakie to wszystko bez sensu…

      A co do tego, że Scrum przywożony w prezencie przez Jaśnie Oświeconego Menedżera („Scrum to samoorganizacja, więc się weźmiecie i zorganizujecie, przecież to nic trudnego”) nie działa – pełna zgoda.

  2. Świetny wpis. Niestety często wdrażanie Scruma sprowadza się właśnie tylko do zmiany procesu i to połowicznie. Wprowadza się reguły (rules), role, artefakty, spotkania, ale bez wsparcia odpowiednimi praktykami, bez zrozumienia zasad (principles) i bez zmian w systemie wartości, jakimi organizacja się kieruje.

  3. U mnie w pracy niestety wprowadzono scruma jako magiczny lek na brak testow, metody ciagnace sie ekranami i potezny dlug technologiczny, bledy splywajace tysiacami i zupelny brak dokumentacji. Do zespolow scrumowych wrzucono nowozatrudnionych programistow i robia sprinty. Mialem nieprzyjemnosc pracowac w ten sposob przez pol roku kiedy jako doswiadczonego z produktem wyrwano mnie z mojego dosc hermetycznego zespolu zeby scrumowy zespol byl interdyscyplinarny. Ludziom w scrumowych zespolach nic zarzucic nie moge, bo sie staraja, ale testow nadal nie robia bo nie ma przyzwolonia na „tracenie czasu”, dlug technologiczny nadal rosnie, bo refactoring robi sie dopiero w razie awarii, a ja na szczescie sie stamtad wyrwalem. Teraz chca na sile wprowadzac scruma w zespole gdzie ja pracuje. Mamy tutaj testy, kazdy wie co ma robic i za co odpowiada. Wszystko dziala… No ale gora rozkazala i bedzie trzeba prowadzic cala te niepotrzebna nam scrumowa biurokracje, przychodzic do pracy nie pozniej niz o… bo daily itp.

  4. Pingback: 10 blogów o Agile, które lubię i mogę Ci polecić - K85.pl - Agile i takie tam sprawy

Skomentuj Stanisław Matczak Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.