Jak unikać bezsensownych codziennych scrumów

Mechaniczne spotkania nie prowadzą do postępu

Jaki jest sens przeprowadzania codziennego Scruma z zespołem? Chociaż może ci się wydawać, że chodzi o udzielenie odpowiedzi na trzy pytania i wyjaśnienie, co się dzieje, takie rozumowanie jest błędne. Zostańcie ze mną jeszcze na chwilę. Wyobraźmy sobie następującą sytuację: codziennie o 09:15 każdy członek zespołu odpowiada na następujące pytania:

• Co zrobiłem wczoraj?
• Co zamierzam dzisiaj zrobić?
• Jakie mam blokery?

Co się stanie, gdy wszyscy odpowiedzą na te pytania? Każdy programista prawdopodobnie opuszcza rozmowę lub pokój i wraca do pracy. Nikt nie korzysta na tym codziennie. Nikt nie pomaga żadnemu członkowi zespołu, ponieważ nie działają jako zespół. Każdy ma swój Sprint. „Zrobiłem to, zrobię tamto i nie mam żadnych blokerów.” Następny, proszę.”

Myślałem, że zespół Scrumowy powinien mieć wspólny cel i współpracować, aby go osiągnąć, zamiast biegać każdy w innym kierunku.

Jeśli spojrzeć na Scrum Guide, 2020 można znaleźć następującą definicję codziennego Scruma:

Celem codziennego Scruma jest sprawdzenie postępu w kierunku celu Sprintu i dostosowanie Backlogu Sprintu w razie potrzeby, dostosowując najbliższe planowane prace.

Pytanie brzmi, dlaczego nikt nie mówi o celu Sprintu w codziennym Scrumie? Ponieważ większość zespołów ich nie ma lub dlatego, że nie trafiają w cel. W tym artykule podzielę się tym, co prowadzi do bezsensownej codzienności i jak od niej uciec.

Product Ownerzy mogą wszystko zepsuć

Czy Product Ownerzy powinni uczestniczyć w codziennym Scrumie? Myślę, że wielu programistów powiedziałoby: „Proszę, Nie!” Niestety, ale Product Ownerzy często zamiast być pomocni, przysparzają tylko problemów podczas codziennego Scruma.

Chociaż codzienny Scrum jest wydarzeniem dla programistów, to Product Ownerzy mogą w nim uczestniczyć i wnieść wartość dodaną do współpracy. Natknąłem się na kilka typowych problemów spowodowanych przez Product Ownerów podczas codziennego Scruma:

• Szef: spotkanie nie rozpocznie się, dopóki Product Owner nie będzie dostępny. Programiści nie mogą decydować, nad czym pracować, ponieważ Product Owner określa, kto powinien co robić.
• Raport o statusie: programiści raportują Product Ownerowi, co zrobili wczoraj i co robią dzisiaj. Mają nadzieję, że podejmą właściwe decyzje. W przeciwnym razie Product Owner zwróci im uwagę.
• Nowe zadania: Product Ownerzy zgłaszają nowe rzeczy podczas codziennego Scruma, nawet jeśli nie mają one związku z celem Sprintu.

Codzienny Scrum trwa piętnaście minut, ale szkody wyrządzone przez niektórych Product Ownerów mogą trwać miesiącami.

Product Ownerzy są częścią zespołu Scrumowego, a nie jego wartością nadrzędną. Scrum nie ma hierarchii; każdy przyczynia się do osiągnięcia tego samego celu Sprintu.

Jako Product Owner lubię być dostępny dla programistów. Sposobem na to jest codzienne pojawianie się na Scrumie. Chociaż codzienny Scrum jest wydarzeniem dla programistów, Product Ownerzy mogą w nim uczestniczyć i wnosić wartość dodaną.

Gdy Product Ownerzy zrozumieją, że są częścią zespołu Scrumowego, łatwiej będzie im uczestniczyć w codziennym Scrumie, i jakoś pomóc. Moim zdaniem podczas codziennego Scruma Product Ownerzy powinni:

• Słuchać uważnie programistów.
• Pomóc, jeśli ktoś potrzebuje pomocy.
• Unikać wpływania na codzienny plan pracy programistów.
• Ufać programistom.
• Unikać codziennego mikrozarządzania programistami.

Mechaniczny codzienny Scrum

Jest godzina 09:11. Björn właśnie się obudził i powiedział: „Cholera! Mam za 4 minuty ten nudny Scrum i umieram z głodu” Biegnie do kuchni, wypija szklankę wody, wkłada kapsułkę do ekspresu do kawy i czeka. Po kilku sekundach kawa jest gotowa; bierze ją i biegnie do swojego pokoju do pracy. W pośpiechu włącza komputer.

Niespodziewanie jego laptop rozpoczyna obowiązkową aktualizację. Björn spóźnia się i zaczyna się denerwować. Szybko podnosi swój telefon. Bum! Przez przypadek wpada na swój kubek i rozlewa kawę wszędzie!

Jest 09:17, Björn wskakuje szybko na codziennego calla ze swojego telefonu i natychmiast wyłącza kamerę.

Harold: „Dzień doooobry, Björn. Czekaliśmy na ciebie. Chyba trochę pospałeś”
Björn: „Przepraszam Was!” Miałem małe trudności, ale już jestem. Zaczynamy?

W tym momencie Björn wyciszył swój telefon, pobiegł do toalety i wziął papier toaletowy, aby posprzątać bałagan, który zrobił. Nie robi nic poza słuchaniem członków zespołu.

Harold: „Dobrze, to zacznijmy. Wczoraj naprawiłem problem z API cenowym, a dziś zamierzam wdrożyć zmiany i wybrać coś innego. Ragnar?”
Ragnar: „Dzień dobry wszystkim. Wczoraj nie zrobiłem zbyt wiele. Dzisiaj zamierzam kontynuować pracę nad silnikiem rekomendacji i potencjalnie wysłać go na code review. Björn?”

Björn nadal sprząta swój stół, ponieważ na jego klawiaturze i notatkach jest kawa.

Ragnar: „Björn, jeśli mówisz, nie słyszymy cię. Włącz mikrofon.”
Björn: „Przepraszam!” Musiałem coś posprzątać. Wczoraj robiłem mniej więcej to samo. Zrobiłem kilka code review i poczyniłem postępy w moich zadaniach. Dzisiaj zamierzam wszystko zakończyć i iść dalej”
Floki (Scrum Master): „Dziękuję wszystkim za podzielenie się. Nikt nie ma żadnych blokerów, poczyniliście postępy w swoich działaniach, więc zakładam, że wszystko jest w porządku. Jeśli nie mamy nic do dodania, to myślę, że możemy skończyć.”

Rozmowa zakończyła się o 09:27 i nikt nie wiedział, co z niej wynikło. Björn nie słyszał, co kto mówi. W międzyczasie Harold i Ragnar pracowali nad niezwiązanymi ze sobą zadaniami i nie przejmowali się wzajemnymi update’ami. Chociaż mieli cel Sprintu, nikt o nim nie pamiętał, nawet Scrum Master.

Zespół Jorvik zaczyna swój dzień pracy od marnowania czasu. Mimo to akceptują bezsensowną codzienność i nikt się tym nie przejmuje.

Czy ten scenariusz coś ci przypomina? Czy kiedykolwiek doświadczyłeś czegoś podobnego? Niestety, byłem w takiej sytuacji częściej niż bym chciał. Wiele zespołów nadal nie funkcjonuje jako zespół, ale jako grupa ludzi biegnących w różnych kierunkach. W takiej sytuacji Scrum nie jest zbyt pomocny. Powszechne anty-wzorce, które zauważam, są następujące:

• Nikt nie mówi o celu Sprintu: każdy członek zespołu realizuje swój plan. Wszyscy koncentrują się na ukończeniu Sprintu. Zespół Scrumowy może posiadać cel Sprintu, ale albo nie posiada wytycznych, albo nikt się tym nie przejmuje.
• Odpowiadanie na pytania: mechaniczny codzienny Scrum ma miejsce, gdy programiści skupiają się na odpowiadaniu na standardowe pytania. Jest to rodzaj raportu o stanie zespołu, ale problem polega na tym, że nikt go nie słucha. A po codziennym spotkaniu każdy podąża w innym kierunku.
• Brak informacji zwrotnej: nikt nie jest na tyle odważny, by zwrócić uwagę innym. Zespół żyje w fałszywej harmonii. Na przykład, podczas pierwszego dnia Sprintu programista mówi: „Skończę to zadanie dzisiaj i wyślę je do review do końca dnia”, a następnie drugiego i trzeciego dnia programista mówi to samo, zadanie jest niedokończone i nikt mu nic nie mówi ani nie oferuje pomocy.

Nie powinno tak być. Sensowny codzienny Scrum powinien zawierać przegląd problemów, a członkowie zespołu powinni reagować, aby się nimi zająć i zwiększyć szanse na osiągnięcie celu Sprintu.

„Scrum jest jak twoja teściowa, wskazuje WSZYSTKIE twoje wady” — Ken Schwaber

Skuteczny codzienny Scrum

Codzienne Scrumy będą do bani, jeśli będą mechaniczne. Nikt nie chce uczestniczyć w spotkaniu, na którym nie rozumie korzyści z niego płynących. Mimo to uważam, że codzienny Scrum ma kluczowe znaczenie dla sukcesu zespołów, ale musi być żywy, a nie być spotkaniem, którego wszyscy chcą uniknąć.

Sensowny codzienny Scrum pomoże zespołowi zbliżyć się do celu Sprintu. Zamiast wymieniać, co zrobił każdy członek zespołu, zachęcam zespoły do skupienia się na celu Sprintu. Wymiana ma być dynamiczna, a nie mechaniczna. Każdy członek zespołu powinien podzielić się tym, co robi, aby zbliżyć się do celu Sprintu i czy być może potrzebuje w tym pomocy.

Pod koniec codziennego Scruma zespół powinien mieć jasność co do współpracy, aby zbliżyć się do celu Sprintu. Często członkowie zespołu muszą zmieniać swoje plany, aby wspierać się nawzajem i upewnić się, że ich wysiłki przyczyniają się do realizacji celu Sprintu, a nie celów indywidualnych.

Rezultatem sensownego codziennego Scruma jest pewność osiągnięcia celu Sprintu zamiast jasności co do tego, co wszyscy robią. Zespoły Scrumowe powinny być samozarządzające, a nie mikrozarządzające.

Oryginał tekstu w języku angielskim przeczytasz tutaj.