Scrum to jeden z najpopularniejszych frameworków stosowanych w IT, a w internecie pełno jest informacji na temat tego, jak go wdrażać. Nie trudno też o informacje, jakie przynosi korzyści i dlaczego warto zaprzyjaźnić się z nim na dłużej. Dlaczego zatem Scrum nie działa?

źródło: memy.pl

Podręcznik teorii wspomnianego frameworku, czyli Scrum Guide, opisuje szczegółowo zdarzenia, role, artefakty i wartości Scruma. Możemy wyczytać, że mamy 3 role – Product Owner, Scrum Master, Development Team, które razem tworzą Zespół Scrum. Dalej jest 5 zdarzeń – Sprint, Daily Scrum, Sprint Planning, Sprint Retrospective, Sprint Review, a na koniec 3 artefakty, Product Backlog, Sprint Backlog i Product Increment. Każdy z wymienionych, jest niezbędnym elementem do tego, by całość frameworku w jakim się poruszamy mogła działać zgodnie z oczekiwaniami. Wydaje się to proste,  mało zasad, krótka instrukcja. Załóżmy, że wchodzimy z ogromnym entuzjazmem w erę agile w naszej organizacji…

źródło: Scrum.org

Rzeczywistość jest jednak brutalna. Pomimo tego, że sam Scrum jest prosty i nie zawiera tak dużej ilości elementów do opanowania jak pozostałe podejścia do wytwarzania produktów (to tylko około 16 stron), to nadal sprawia szereg problemów. Większość zespołów prędzej czy później, będzie musiała przez nie przejść. Weryfikacja tego, jak wygląda plan, a rzeczywistość przedstawia się zatem nierzadko tak, jak na załączonym obrazku – góry, wody, doliny…

źródło: internet

W kolejnych akapitach artykułu chciałabym pokazać 2 sprawy, przez które przechodziłam ze swoimi zespołami, a które uważam, są najczęstszymi przyczynami stwierdzenia „Scrum nie działa, to się u nas nie sprawdza”. Mimo wspomnianych dwóch problematycznych kwestii, punktów zapalnych jest więcej. Obecnie czytasz tekst gdzie rozprawię się ze spotkaniami i samoorganizacją, niebawem jednak pojawi się kolejna część, w której tematem przewodnim będą Product Owner i pytanie “Projekt czy produkt?”. Zapraszam do lektury!

Spotkania

Pierwsze, powiedziałabym wyzwanie, to spotkania. W Scrum wyróżniamy 5 zdarzeń, a 4 z nich – Daily, Review, Planning, Retrospektywa odczuwalne są w naszych kalendarzach. Warto także wspomnieć, że w trakcie sprintu odbywa się refinement, który jest definiowany przez Scrum Guide jako trwający proces. W efekcie, gdy w tym procesie potrzebny jest zespół, to staje się po prostu kolejnym spotkaniem.

„Za dużo tych spotkań, nie ma czasu na kodowanie!”
„W tygodniowym sprincie spotkań jest więcej!”
„Po co nam daily? Przecież wiemy co robimy…”

Jaki mamy z tym zatem problem? Powyżej umieściłam cytaty, które usłyszałam od różnych osób z moich zespołów deweloperskich w ostatnich latach. Dominuje w nich poczucie, że spotkań jest dużo, nie mają one większego sensu i odciągają programistów od tego, co “tak naprawdę powinni robić” – kodować.

Jako początkującego Scrum Mastera często irytowały mnie takie stwierdzenia. Sądziłam, że wszystko jest przecież w Scrum Guide, jak można tego nie wiedzieć? Warto jednak zastanowić się, jaka jest prawdziwa przyczyna tego stanu rzeczy.

źródło: internet

Przyczyny

Przyczyny są wg mnie w zasadzie dwie:

  • Wrażenie odbywania dużej ilości spotkań spowodowane ich regularnością.
  • Brak znajomości celu, prawidłowego przebiegu i wartości wynikającej z danego spotkania.

O ile pierwszą przyczynę stosunkowo łatwo i szybko można wyeliminować, wytłumaczyć, tak drugi punkt, to poważny problem. Mówiąc o nieznajomości celu łatwo wyobrazić sobie szereg niepotrzebnych działań z tego wynikających. Przykłady: rozwodzenie się nad tematami, które nie dotyczą danego spotkania, mnóstwo dygresji, ponowne spotykanie się, bo z poprzednich zdarzeń nic nie wyszło sensownego.

Spotkania, to jeden z głównych motorów Scruma i bez ich prawidłowego przebiegu proces ten przestaje mieć sens. W momencie, gdy spotkania są nieefektywne, łatwo stwierdzić, że jest ich więcej niż potrzeba i nie dają tego co istotne i niezbędne zespołowi do wypełniania codziennych obowiązków.

Rozwiązania

Przejdźmy do rozwiązań, które pomogą usprawnić temat spotkań w zespole. Na początek przyjrzyjmy się tematowi mnogości spotkań. Warto tutaj podkreślić, że dla danej długości sprintu, spotkania mają określone maksymalne czasy trwania. Review dla miesięcznego sprintu to 4h, dla tygodniowego to 1h, wyjątkiem jest daily, trwające zawsze maksymalnie 15 minut. Szukając rozwiązania, zastanówmy się, czy nasze spotkania są realizowane w przewidzianych przez SG timebox’ach, a także, czy zapewniamy ich odpowiednie rozłożenie w sprincie. Warto również zadać sobie pytania: czy pomiędzy spotkaniami nie marnujemy czasu? Czy po osiągnięciu celu spotkania przedłużamy je do granicy timeboxa?

W przypadku pracy nad celowością zachęcam zawsze wracanie do źródła, czyli Scrum Guide – każdy event scrumowy jest tam dogłębnie opisany. Autorzy znakomicie opisali też jaką wartość każde zdarzenie przynosi zespołowi. Jeśli Twój team ma problem z zapamiętaniem kolejności działań na spotkaniach – stwórz agendę dostępną dla wszystkich i zamieść w niej wszystkie informacje. Później wklejaj ją do zaproszeń w kalendarzu i przypominaj na początku spotkania. Spraw by agenda była dla wszystkich dostępna i powszechnie znana. Regularna praca i przypominanie zasad danego meetingu pozwoli lepiej zrozumieć jego cel i skupić się na konkretach.

Samoorganizacja

Zespół scrumowy jest samoorganizujący się i posiada pełną wiedzę do tego jak wykonać postawione przed nim zadania. Dzięki samoorganizującym się zespołom, cele są osiągane szybciej i z lepszym efektem, a przyrost dostarczany klientowi spełnia jego rzeczywiste wymagania. Samoorganizujący się zespół to zaangażowani, otwarci i skupieni na celu członkowie.

Z doświadczenia pracy z różnymi zespołami mogę powiedzieć, że nie wszyscy, będą dążyli do samoorganizacji. Znajdą się także osoby, które skupiają się tylko na swoim “tasku” bez refleksji, czy jest ono ważne dla celu sprintu.

Przykłady takich zachowań, to znów cytaty jakie kiedyś usłyszałam:

„Nie wiem dlaczego nie działa, ten drugi robił to zadanie.”
„Kiedy Scrum Master powie nam co mamy robić?”

Zdarzyło mi się kiedyś nawet usłyszeć, że zadanie nie jest wykonane bo nikt deweloperowi nie powiedział, że trzeba się nim zająć. No i rzecz jasna, Scrum tutaj nie działa ;).

Takie podejście w wielu sytuacjach może skończyć się marnowaniem czasu i pieniędzy Product Ownera, frustracją z niedokończonego lub niedziałającego przyrostu. Skupienie tylko na swoim obszarze sprzyja także powstawaniu silosów kompetencji, a w efekcie nawet sytuacji, w której gdy w zespole kogoś zabraknie, to razem z nim ucieka cała wiedza.

Z perspektywy pracy nad zakresem sprintu, ważna jest także wewnętrzna samoorganizacja Zespołu Deweloperskiego. Gdy w Scrumie pracują osoby bez doświadczenia z procesem, często z przyzwyczajenia trzymają się zasady, że to ktoś inny mówi im co mają robić.  Nierzadko tą osobą będzie dla nich Scrum Master. Z drugiej strony, to Scrum Master może być tym, kto samoorganizację hamuje.

Przyczyny

Jaka jest zatem przyczyna wymienionych problemów? Według mnie dzieje się tak, bo Scrum jest wymagający – od każdej z ról wymaga czegoś więcej niż wąskiej specjalizacji.

Developer w Scrum nie tylko koduje, bo przecież wspiera Product Ownera swoją wiedzą w podejmowaniu decyzji, wspiera kolegów i koleżanki z zespołu w ich pracach jeśli zaistnieje taka potrzeba. To samo dotyczy SMa i PO, ich role są szersze niż to się wydaje.

scrum nie działa
źródło: dilbert.com

Przyczyną jest zatem brak świadomości czy zrozumienia wymagań, jakie stawia się przed konkretną rolą. Może być to także małe doświadczenie, nieznajomość procesu, albo zwyczajna obawa przed popełnieniem błędu. Jako jedną z inspiracji warto wspomnieć książkę „Software Craftsman”. Wprawdzie mowa jest w niej o rozwoju i postawie dewelopera, ale każdy znajdzie tu cząstkę dla siebie. Szczególnie, gdy celem jest posiadanie wiedzy jak strona techniczna w samoorganizującym się zespole wspiera biznes.

Rozwiązania

Pracując z zespołem w kierunku samoorganizacji warto zacząć od znajomości ról w Scrumie. Mam na myśli to, że poszczególne osoby w zespole, na początku swojej przygody ze Scrum, mogą nie wiedzieć co należy do ich obowiązków. Nie zawsze od razu wiadomo czego się od nas wymaga. Dobrą praktyką jest omówienie na początku współpracy z nowym składem ról w zespole. Dla każdego jest to wartościowa lekcja i przypomnienie sobie jakie zadania do nas należą.

Idąc dalej, chciałbym mocno podkreślić wartości Scruma, które wdrażane i respektowane otwierają zespół ku coraz większej samodzielności. Samoorganizacja zespołu opiera się na zaufaniu, seniora do juniora, dewelopera do SMa, PO do dewelopera itd. Każdy z członków teamu to ekspert w swojej dziedzinie i jest zdolny do podejmowania wyzwań. Każdy ma swoje miejsce w procesie, a jego zdanie jest ważne i istotne. W sytuacji gdy w członkach zespołu brakuje zaangażowania i zaufania, warto zastanowić się, czy mają oni przestrzeń do swobodnego wyrażania swoich opinii, czy bez żadnych problemów mogą wykonywać swoją pracę. Bez tego faktycznie, Scrum nie działa – i nie ma wręcz prawa zadziałać.

Przezwyciężając skupienie na zadaniu i budowanie silosów kompetencji – warto promować ideę wspólnego wykonywania zadań w pair programmingu. U mnie działała także praktyka dzielenia się wiedzą: np. codziennie po daily. Każdy może opowiedzieć o czymś nowym dotyczącym całego produktu, czy też konkretnej części systemu nad jakim pracujemy. I najważniejsze – odpowiedzialność. W Scrum, za to jak wygląda produkt odpowiada cały zespół, nie tylko PO. Wszyscy musimy pracować nad poczuciem odpowiedzialności za wytwarzany produkt choćby poprzez zadawanie pytań. Świetnie (i budująco!) działają prośby o opinie różnych członków teamu – każdy powinien czuć, że ma wpływ na to co robimy.

Scrum nie działa?

Podsumowując – Scrum wymaga od dewelopera więcej niż kodowania, od Scrum Mastera więcej niż pilnowania spotkań i zasad. A od Product Ownera więcej niż wymyślania nowych funkcjonalności i porządkowania backloga. Zapewne łatwiej stwierdzić, że Scrum nie działa, gdy zmienia się całe otoczenie w jakim pracujemy, stąd, wszystkie powyższe zmiany warto wprowadzać stopniowo.

„Scrum tworzy ramy dla wytwarzania i utrzymywania złożonych produktów.”

Scrum Guide

Sprawdź nasze ostatnie wpisy: