Dlaczego Scrum nie działa?

Pewien 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.

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…