Według pochodzących z ”15th Annual State of Agile Report” danych wynika, że 66% spośród badanych firm organizowało swoją pracę w zgodzie z zasadami gry w Scruma. A kolejnych 15% stosowało jakąś formę scrumowej hybrydy.
Można więc uznać, że Scrum to niewątpliwie najpopularniejszy model pracy z rodziny tych zwinnych. Można również powiedzieć, że moda na Scrum trwa w najlepsze.
Nic więc dziwnego, że większość kandydatów do zespołów deweloperskich ma w swoim cv wpisane, że pracowali w Scrumie.
Here’s a little story that must be told…
Prowadząc rozmowy rekrutacyjne, zawsze interesuje mnie to jaką styczność ze zwinnymi procesami mieli do tej pory kandydaci. Czy rozumieją iteracyjność? Czy praktykowali inspekcję i adaptację? Ale przede wszystkim – jak bardzo zostali skrzywdzeni w poprzednich firmach.
Bo w trakcie, gdy o tym Scrumie zaczynamy rozmawiać okazuje się, że… Och, jakże on jest różnie implementowany w organizacjach. I nie chodzi o to, że autorzy frameworka zostawiają wiele pola do własnej interpretacji. Tylko jest on po prostu wdrażany i stosowany niezgodnie z zasadami gry.
– Mamy daily i planning. Oraz dwutygodniowe sprinty – usłyszałem ostatnio od jednego z kandydatów. I zanim zdążyłem zapytać o pozostałe scrumowe elementy, rozmówca zaczął opowiadać o przebiegu daily.
– Spotykamy się codziennie, całym zespołem. Spotkanie ma charakter takiego statusu, w ramach którego każdy opowiada nad czym pracował wczoraj i co będzie robił dzisiaj.
– Całym zespołem? – zapytałem unosząc lekko brew do góry, mając w pamięci wypowiedź sprzed kilku minut, w której padło, że zespół liczy około… dwadzieścia osób. – To ile Wam to spotkanie zajmuje?
– Owszem, całym. Zajmuje nam to 40-45 minut.
Na kolejną serię moich pytań – czy tak codziennie, czy uważa to za efektywnie spędzony czas i czy w zespole jest jakiś Scrum Master, kandydat kolejno odpowiedział:
– Tak, codziennie spędzamy te trzy kwadranse. Czy jest to efektywne? Nie wydaje mi się. Bo każdy po prostu czeka na swoją kolejkę. W moim przypadku wypowiedź zazwyczaj zajmuje 1-2 minuty. A Scrum Master – owszem, jest. Uczestniczy w spotkaniu i jest odpowiedzialny za przydzielanie kolejno głosu.
Wait… what?
Pozwólcie, że zaproszę na chwilę tutaj mojego dobrego znajomego – Vanilla Ice’a, który witając się powie:
Na przykładzie tej jednej, krótkiej wypowiedzi wskazać mogę sześć anty-wzorców, z jakimi można się spotkać w kontekście najkrótszego (wg. Scrum Guide’a) scrumowego spotkania. Te anty-wzorce to:
- 20+ osób na daily
- Daily, które trwa 40-45 minut (codziennie!)
- Daily, które ma charakter statusu
- Bierne zaangażowanie uczestników
- Scrum Master udziela głosu na Daily
- Scrum Master w ogóle zabiera głos na Daily
[tak, ten punkt już trochę na siłę i ”czepiam się”, ale… zostańcie ze mną!]
Zmierzmy się w takim razie z nimi. Po kolei.
Dwie pizze
Bezos zwykł mawiać, że zespoły i grupy robocze powinny być takiej wielkości, by dało się je nakarmić dwiema pizzami. To oznacza zespoły nie większe niż 4-8 osób. Chyba, że w zespole jest Aks to „reguła dwóch pizz” dotyczyć będzie zespołu maksymalnie 4 osobowego (hej, po prostu… lubię pizzę!).
Wielkość zespołu scrumowego bardzo jasno definiuje Scrum Guide. W najbardziej aktualnej jego wersji (pochodzącej z 2020) znaleźć można taką informację:
Scrum Team jest wystarczająco niewielki, aby pozostawać zwinnym, a jednocześnie wystarczająco liczny, aby móc ukończyć znaczącą część pracy w Sprincie, zwykle składa się z 10 osób lub mniej.
Jak wynika z naszego doświadczenia, mniejsze zespoły na ogół lepiej się komunikują i są bardziej produktywne.
Poprzednia wersja Scrum Guide’a (z 2017) zawierała podrozdział „Wielkość Zespołu Deweloperskiego”, w którym znaleźć można było takie informacje:
Mniej niż troje członków oznacza mniejszy stopień interakcji i niższy wzrost produktywności.
Mniejsze Zespoły Deweloperskie mogą napotykać w trakcie Sprintu braki kompetencji uniemożliwiające im dostarczanie Przyrostu gotowego do potencjalnego wydania.
Więcej niż dziewięcioro członków wymaga zbyt dużych nakładów na koordynację. W dużych Zespołach Deweloperskich poziom złożoności jest tak wysoki, że stosowanie procesu empirycznego przestaje być użyteczne.
Co ważne – wersja z 2017 dotyczy tylko ilości deweloperów w zespole, więc przedział 3 do 9 osób nie uwzględnia ról PO i SM. Wersja z 2020 dotyczy całego Scrum Teamu. Czyli 10 osób = 8 deweloperów + Scrum Master + Product Owner.
Czyli – im więcej osób w zespole, tym większa złożoność w komunikacji. Ponad 20 osób na spotkaniu, które ma służyć do synchronizacji informacji na temat postępów prac brzmi… co najmniej nieefektywnie 😉
Czas, czas, czas
Tematowi daily poświęciłem kiedyś swoje wystąpienie na 4Developers. Do zajęcia się tym tematem zainspirowała mnie kolejna fala popularności pewnego pomysłu z 2016 roku. Jego autor doradzał, że jeśli Wasze daily scrumy trwają zbyt długo to warto je połączyć z… sesją planka.
Wprowadzanie takich pomysłów jest dla mnie jak tapetowanie ściany, która pokryta jest grzybem. Chwilowo ukryjemy to co przykre, ale czy faktycznie pozbędziemy się problemu?
Do innych przyczyn przedłużania się daily wrócę tu jeszcze kiedyś, ale dziś zatrzymam się na przytoczonym powyżej przykładzie. Duży zespół to duża złożoność. I „stosowanie procesu empirycznego przestaje być użyteczne”.
Duży zespół to długie spotkanie. Które jest po prostu sporą stratą – czasu oraz… pieniędzy. Warto czasem przemnożyć ilość osób uczestniczących w spotkaniu przez „jakąś” stawkę godzinową i zadać sobie pytanie, czy ta inwestycja dowozi jakąś faktyczną wartość…
Chcesz mieć krótsze i bardziej efektywne daily? Zacznij od zastanowienia się, czy ilość osób uczestniczących w tym spotkaniu faktycznie pozwala na efektywną wymianę informacji.
„Więcej tasków nie pamiętam”
Według Scrum Guide’a:
Celem Daily Scrum jest sprawdzenie postępów w dążeniu do osiągnięcia Celu Sprintu oraz w razie konieczności adaptacja Sprint Backlogu, czyli dostosowanie zaplanowanej pracy.
Czyli: deweloperzy spotykają się, by dokonać synchronizacji informacji na temat tego jak realizowana aktualnie praca (wczoraj, dzisiaj, w najbliższym czasie) przybliża zespół do zrealizowania założonego celu.
Jeśli w trakcie ostatnich 24 godzin (czyli od ostatniego spotkania) zidentyfikowaliśmy pracę, którą należy wykonać by ten cel zrealizować, to dostosowujemy Sprint Backlog tak, by tę pracę odzwierciedlał.
Jeśli w trakcie synchronizacji zorientujemy się, że ktoś w zespole wykonuje pracę, która nas do tego celu nie przybliża, to robimy inspekcję (dlaczego tak się dzieje, z czego to wynika, czy zagraża to celowi), a następnie podejmujemy decyzję co w zaistniałej sytuacji robimy. Czyli robimy adaptację.
To nie spowiedź. To nie rundka. To nie przegląd tasków. To wspólne sprawdzenie postępów w dążeniu do osiągnięcia Celu Sprintu.
Za czym kolejka ta stoi?
Daily to nie spotkanie, w ramach, którego uczestnicy biernie czekają na swoją kolejkę. Synchronizacja wiedzy wymaga uważności.
Jeśli wspólnie weryfikujemy czy realizowana przez członków zespołu praca przybliża nas do realizacji Celu Sprintu to wymaga to co najmniej dwóch procesów.
Pierwsze to świadomość… czym jest cel danej iteracji ? A drugie to aktywne uczestnictwo poprzez aktywne słuchanie tego, co w trakcie spotkania się dzieje. By móc zidentyfikować problemy, by móc zidentyfikować zagrożenia, by móc zasygnalizować chęć wsparcia.
Bierne czekanie, aż przyjdzie moja kolej / aż zostanę wyznaczony do odpowiedzi nie stwarza dobrego podłoża do skutecznej wymiany informacji.
Ale też… trudno oczekiwać od dwudziestu kilku osób ciągłego skupienia przez trzy kwadranse. Czyli – małe zespoły oznaczają mniejszą złożoność i płynniejszy obieg informacji. Pozwalają zachować uważność na to co dzieje się dookoła. A i przy okazji… sprawiają, że codzienne spotkania synchronizacyjne trwają krócej.
Klasowy przewodniczący
Zacznijmy od tego, że teoria (SG2020) mówi: daily to spotkanie dla deweloperów.
Jeśli Product Owner lub Scrum Master wykonują pracę związaną z elementami Sprint Backlogu, uczestniczą w spotkaniu jako Developerzy.
Czyli w skrócie – jeśli w trakcie danej iteracji praca, którą wykonujesz przybliża zespół do zrealizowania celu, to uczestniczysz w daily na równych zasadach z pozostałymi uczestnikami. Jeśli nie przyczyniasz się do wytworzenia przyrostu, to… nie ma Cię na daily.
Tak mówi teoria. W praktyce osobiście zachęcam, by w daily uczestniczył cały zespół scrumowy. Przy jasnym określeniu i zrozumieniu ról i odpowiedzialności.
Spotkanie to jest oczywiście przede wszystkim dla devów – prowadzone przez devów i służące wymianie informacji pomiędzy nimi. Obecność PO może usprawnić wspólne podejmowanie decyzji na temat wyników bieżącej inspekcji lub szybko identyfikować problemy do rozwiązania na poziomie zrozumienia wymagań biznesowych. Obecność SM może pomóc w trzymaniu kontenera, proponowaniu technik, gdy „nie idzie” i upewnianiu się, że spotkanie spełnia swój cel i nic nie zaburza jego przebiegu.
Więc, gdyby trzymać się bardzo mocno podstaw teoretycznych, w przytoczonej na wstępie opowieści mógłbym do anty-wzorców zakwalifikować sam fakt obecności Scrum Mastera na daily. Nie będę jednak aż takim purystą.
Większym problemem jest fakt, że SM z tej historii nie rozumiał swojej roli. I zamiast grać rolę pierwszoplanową, doradziłbym w pierwszej kolejności zmianę formy tego spotkania. Na taką, w ramach której wymiana informacji odbywać się będzie w bardziej efektywny sposób. A następnie – usunąć się w cień, by obserwować dynamikę i w razie potrzeby proponować kolejne usprawnienia.
Ciężko nawet w takim przypadku powiedzieć o facylitacji. Scrum Master, który prowadzi spotkania, udziela głosu i organizuje „odpytkę” odbiera przestrzeń do samoorganizacji i samozarządzania. Stając się mikromenadżerem.
Scrum Master jako „przewodniczący daily” opisany został w doskonałym dokumencie Barry’ego Overeema wśród postaw błędnie interpretowanych w kontekście Scrum Mastera. I zdecydowanie odsyłam Was do tego świetnego whitepapera. A także – do jego tegorocznego update’u. Bo w ramach tej aktualizacji osiem postaw stało się… sześcioma.
Jedną z wykreślonych jest postawa menadżera. Pierwotnie autorowi chodziło o zarządzanie scrumowym procesem. Jednak postawa ta wprowadzała sporo zamieszania i bywała błędnie interpretowana jako „menadżer zespołu”. Tak jak w opisanym powyżej przykładzie. Dlatego ostatecznie wypadła z opisywanego modelu.
On and on and on and on…
Tekst ten zdecydowanie nie wyczerpuje tematu mitów, anty-wzorców i dysfunkcyjnych zachowań związanych z daily. A przypominam – mówimy o spotkaniu z założenia trwającym… kwadrans.
Jeśli jesteście zainteresowani usprawnianiem Waszych codziennych spotkań – odsyłam do dodatkowych materiałów, w których znajdziecie kolejne podpowiedzi na temat tego, jak identyfikować symptomy nieefektywnych daily oraz jak sobie z nimi radzić:
- Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team, czyli poświęcony Daily rozdział z budowanego przyrostowo ebooka „Scrum Anti-Patterns Guide”; polecam również zajrzeć do całości dotychczas stworzonego materiału, bo to kopalnia wiedzy,
- „Labirynty Scruma” Jacka Wieczorka, czyli książka, w której autor opisał najczęstsze pułapki i propozycje ich usprawnień; rozdział poświęcony Codziennym Scrumom zawiera „9 najczęstszych pułapek oraz 14 sprawdzonych porad„,
- „Codzienny Scrum” opisany przez Agile Institute, czyli całkiem zgrabnie uporządkowane informacje czym Daily jest i jak powinno przebiegać,
- Garść świetnych i obszernych treści dostarczonych przez zaprzyjaźnioną ekipę z Parabola:
- Daily Scrum: Complete Beginner’s Guide – wszystkie najważniejsze informacje i podpowiedzi zgromadzone w jednym miejscu, jasno i klarownie
- 14 Daily Standup Formats to Try With Your Team, czyli propozycje różnych strategii podpowiadających jak eksperymentować z formuła, by nie popaść w rutynę
- 57 Daily Standup Questions for More Engaging Updates, czyli podpowiedzi dotyczące tego, jakie pytania sobie wzajemnie zadawać, by daily było angażujące i efektywne.
Parabol ma nową funkcję
A skoro przy Parabolu jesteśmy, to chciałbym wspomnieć o ich nowej funkcji. Ale zanim o tym, napiszę wprost: TO NIE JEST POST SPONSOROWANY ? Jestem po prostu zadowolonym użytkownikiem ?♂️ Nie czerpię żadnych profitów z racji tego, o czym dalej tu wspominam.
Parabol poznałem w 2020, gdy całe nasze „pracowe” życie trzeba było przenieść on-line. Sięgnąłem po to narzędzie, by wraz z zespołami z którymi pracowałem móc sprawnie realizować zdalne retrospektywy.
Przez kolejne miesiące obserwowałem, jak twórcy dodają nowe usprawnienia w obrębie modułu retrospektyw. A nawet dzieliłem się obszernym feedbackiem na temat korzystania z tego narzędzia.
Z czasem w ekosystemie Parabola zaczęły pojawiać się nowe produkty. Najpierw było to narzędzie do Sprint Pokera. A najświeższym rozwiązaniem, które trafiło „na produkcję” w ostatnich tygodniach jest moduł wspierający Daily Scrumy.
I tu również miałem okazję być królikiem doświadczalnym i uczestniczyć w fazie testów. A część mojego feedbacku nawet została uwzględniona ?
W każdym razie – jeśli szukacie narzędzia, które wesprze Was w zdalnych lub hybrydowych retrospektywach, sesjach planowania lub daily – Parabol wart jest Waszej uwagi.
W tekście zawarłem kilka odniesień popkulturowych, więc podrzucam garść wyjaśnień: