Scrum-Utopia

S

Wspominki

W naszej branży ciągle się mówi o zbawiennym wpływie stosowania metodyk zwinnych na projekt, na team, na atmosferę pracy i oczywiście na sam produkt. Najbardziej popularnym frameworkiem jest Scrum. To o nim się mówi najczęściej, tenże właśnie stosuje się najczęściej, do tego stopnia, że często jest kojarzony jako jedyny.

Kilka lat temu, miałem przyjemność i szczęście pracować w firmie stosującej Scrum. Po okresie wdrożenia wszystkie aspekty pracy były już mniej dziwne i nieznane, a nawet sensowne. Spotkania daily, backlog grooming, retro, planning itd. Wspólne estymacje zadań, za pomocą kart oczywiście. Dema podczas których rozpierała nas duma ze względu na wysoki stopień dowożenia zadań. No i najważniejsze, poczucie jedności z zespołem, poczucie tego, że jak trzeba to pomogę, a jeśli ja potrzebuję, to pomogą. Zespół cross-funkcjonalny. Wszyscy robiliśmy wszystko i każdy z nas, w razie potrzeby (choroba, sytuacje losowe), mógł być zastąpiony przez innego członka zespołu z powodzeniem.

Oczywiście, nie twierdzę że cała ta sielanka była zasługą Scrum, „docieranie się” wymagało czasu. Nie byliśmy zgraną ekipą od pierwszego dnia. Musieliśmy się nauczyć nie tylko samego Scruma, ale także samych siebie, bo zespół był „częściowo-nowy”. Sprzeczki i utarczki były normalnością, ale z czasem stawały się hmmm… rodzinnym rytuałem? Sposób pracy, jaki mieliśmy wdrożony, musieliśmy najpierw wypracować. Musieliśmy eksperymentować. Co ciekawe, nasz scrum master też się uczył. Powiecie – „No to kicha. Amatorzy biegnący za amatorem.” W sumie nie zdziwiłbym się, ale z drugiej strony osiągnęliśmy wartość. Wartość jaką była jakość produktu, zadowolony klient (co przełożyło się na dobre relacje z nim i jego większą wyrozumiałość w razie czego…), zadowoleni pracownicy, radość z pracy i podejmowanych wyzwań. Trudno mi to opisać, a dla niektórych może to brzmieć jak bajeczki, utopia.

 

Przepis na utopię

Takie jest moje doświadczenie pracy w Scrumie, dlatego szokiem było dla mnie kiedy, w trakcie meetupu ŚGMS #12, dowiedziałem się, że w The Scrum Guide nie ma ani słowa o stand-up’ach, o estmacji kartami czy koszulkami, o tablicach z karteczkami, o narzędziach do trackowania tasków i zarządzania projektami. Wybaczcie mi małe faux pas, jestem prostym programistą.

Dowiedziałem się że to co robiliśmy ze scrumem było osobniczą cechą naszego zespołu, że inny zespół prawdopodobnie wdroży scrum inaczej. I bardzo dobrze! Skoro scrum wyznacza tylko ramy, określa reguły gry, to przecież grajmy tak żeby wygrać, prawda? Teoretycznie, niestety ludzie mają tendencje do nadużyć. Już mówię o co chodzi.

Daily Scrum…

  • Jest to rodzaj spotkania które odbywa się w gronie developerów w celu oceny postępów prac, zaadresowania problemów, jakie oddalają zespół od osiągnięcia celu. Dzięki krótkiemu porannemu spotkaniu jesteśmy w stanie trzymać rękę na pulsie. Co może być problemem?
  • Czas. Jeśli te codzienne spotkania będą wydłużane w nieskończoność, to ludzie zaczynają się na nich nudzić. Nie słuchają współpracowników, bujają w obłokach i myślą o liście zakupów na obiad. Co jeszcze?
  • Tematyka. Jeśli omawiamy na takim spotkaniu sprawy mocno techniczne, lub rozwijamy jakiś temat zbytnio, kompletnie wypaczamy cel tego spotkania. Jeszcze raz. Określenie postępu prac i wczesne zaadresowanie problemów, co daje możliwość wczesnego reagowania i wiedzę odnośnie aktualnego stanu sprintów.

Sprint Retrospective…

  • Czas, jaki poświęcimy na inspekcję poprzedniego sprintu i w razie potrzeby, na ustalenie planu na usprawnienie naszych działań w następnym sprincie. Analizujemy poprzedni sprint mając na uwadze głównie ludzi, nasze relacje w zespole, procesy jakie zadziałały (lub nie), narzędzia. Rzecz jasna zostawiamy to co się sprawdziło, jednocześnie usprawniając to co się nie sprawdziło. Gdzież w tym wypadku może tkwić problem?
  • A no w nas, w nas samych. Mamy w swojej naturze tendencje do „wycieczek personalnych” podczas oceny czyjejś pracy. I nie tylko! Potrafimy różnie oceniać siebie samych, wybielać lub całkowicie się oczerniać, dołować. Zależy to od człowieka, od charakteru. Jesteśmy tylko ludźmi. W takich sytuacjach dużą rolę grają emocje. Nie każdy nad nimi panuje odpowiednio, znowu – jesteśmy tylko ludźmi. Ostatnio, modne stały się różne gry i zabawy, mające na celu realizację retrospektywy w bardziej kontrolowany i stonowany sposób. Należy tylko nie tracić z oczu celu tego spotkania i trzymać się zdrowego rozsądku, a będzie dobrze.

Backlog Refinement (lub Grooming, ale tego określenia się ostatnio nie używa, ze względu na złe konotacje)

  • Nazwijmy to spotkanie wstępem do planowania sprintu. Służy do doprecyzowania zadań w backlogu, nadania priorytetów, szacowania „czasochłonności” tfu…kosztu zadań. Problemy?
  • Traktowanie refinementu jako planningu. Nie powinno tak oczywiście być. Spotkanie to służy do przygotowania backlogu i zadbania o niego. Planowanie sprintu będzie później!
  • Praca nad zadaniami do następnego sprintu. Moim zdaniem błąd. Jeszcze może się dużo pozmieniać, w końcu pracujemy w agile. Najlepiej zająć się zadaniami jeszcze o jeden sprint do przodu, względem następnego.

Sprint Planning…

  • Oj, tu sprawa jest bardziej skomplikowana, zarówno pod względem tego, co chcemy podczas tego spotkania osiągnąć, jak i tego co nie powinno mieć miejsca w jego trakcie. Tradycyjnie zacznę od tego czym jest ten event. Jak sama nazwa wskazuje, planujemy sprint, jednakże nie jest to czas kiedy określamy zadania i to co trzeba w ich ramach zrobić. Nie, nie. To jest czas kiedy te zadania, już dobrze wyklarowane (jest takie słowo?) po prostu wrzucamy do backlogu, w oparciu o cel sprintu i możliwości przerobowe zespołu. Gdzie są problemy?
  • Największym błędem, moim skromnym zdaniem, jest sytuacja kiedy zespół nie wie jaką ma moc przerobową, ile story pointów (czegokolwiek) jest w stanie w trakcie sprintu „wystrzelać”. Planowanie bez tej wiedzy nie jest przecież nawet planowaniem.
  • Cel sprintu. No właśnie, przecież powinniśmy wiedzieć co chcemy osiągnąć na koniec sprintu, ale czy tylko? Celem sprintu powinna być jakaś wartość dodana, mało tego, mierzalna, testowalna. Tak, ja wiem, że nie w każdym przypadku jest to super łatwe, ale wierzcie mi, jest zawsze wykonalne. Ostatnia sprawa która w tym kontekście mnie „boli”. Planowanie sprintu to nie czas na pielęgnację backlogu. Od tego jest refinement!

Sprint Review

  • Spotkanie, event do którego, można by rzec, dąży sprint. Zapraszani są wszyscy interesariusze (business owner, stakeholders). Podczas tego spotkania scrum team prezentuje wyniki pracy minionego sprintu. Product Owner komunikuje które zadanie jest skończone, a które nie i robi to na podstawie stopnia realizacji zadań i feedbacku, który otrzymuje od wszystkich zainteresowanych. Co może pójść nie tak? Cóż, w tej kwestii mam akurat złe doświadczenie. Ograniczaliśmy się do traktowania sprint review, jako zwykłego „demo”, pokazania wyników pracy i zakomunikowania, co skończyliśmy, a co nie. Ogromny błąd. Najważniejszy podczas tego spotkania jest feedback. Po to się spotykamy, żeby sprawdzić jak inni odbierają nasze „dzieło”, żeby się dowiedzieć co sądzą, jak to oceniają. Tak właśnie oceniamy, czy osiągnęliśmy sprint goal, i dzięki temu jesteśmy w stanie wyznaczyć następne kroki, kierunek.

 

Reasumując

Można by tak pisać i pisać o problemach i niedoskonałościach ludzkiej natury i procesów. Nie o to chodzi, prawda? Zwracam jedynie uwagę, na te aspekty pracy w zespole które mi doskwierały, dziwiły mnie, bądź irytowały. Z tego wszystkiego można wywnioskować jedno – najważniejszy jest zdrowy rozsądek, znalezienie złotego środka. Zwłaszcza, jeśli chodzi o komunikację międzyludzką. Dbajcie o siebie w swoich zespołach, zdrowo rywalizujcie ze sobą i bądźcie otwarci, a każdy task, sprint pójdzie jak z płatka. Zyskają na tym klienci, my, produkt.

 

 

Napiszcie w komentarzach co sądzicie.

Dla chętnych i łakomych nowości, polecam opcję z subskrypcją mojego newslettera!

Czołem!

 



 

About the author

Add comment

By Patryk

Autor serwisu

Patryk

Społecznościowe

Instagram

Newsletter



Historycznie

Tagi