Pokaż mi swój Daily Scrum, a powiem Ci jaki jest Twój zespół

Daily Scrum

Codzienny Scrum (ang. Daily Scrum) jest spotkaniem zespołu developerskiego, dzięki któremu uczestnicy systematyzują wiedzę na temat postępu prac, napotkanych przeszkód oraz rysują wizję prac na najbliższe 24 godziny. Najczęstszym błędem tych spotkań jest pozwolenie, aby stały się spotkaniami statusowymi. Każdy mówi co robił i nad czym zamierza pracować, kompletnie nie słuchając co inni mają do powiedzenia. Jeżeli ten opis jest Ci bliski, to czytaj dalej. Twój problem może być poważniejszy niż początkowo się wydaje. 

To, jak wygląda Daily Scrum, jest zwierciadłem pracy zespołu. Obserwacja tego krótkiego spotkania może zdradzić więcej niż sądzisz, niekiedy wręcz wpływa na to, jak zespół będzie ze sobą współpracował przez resztę dnia. Przetestowałem wiele sposobów, które diametralnie zmieniają zarówno nastawienie zespołu, jak i wpływają na dalszą współpracę i tym doświadczeniem chcę się z Wami podzielić.

“Czy możemy zrezygnować z Daily Scrum?” – usłyszałem od pewnej osoby, gdy przejąłem rolę Scrum Mastera. To był jasny sygnał, że zespół nie widzi w tym spotkaniu żadnej korzyści. Tak zwykle dzieje się, gdy jest ono zorganizowane jak spotkanie statusowe. W większości takich wypadków uczestnicy raportują swoją pracę do jednej osoby, którą traktują jako lidera, sami jednak nie słuchają się nawzajem i nie wynoszą z tego spotkania wymiernej korzyści. Będąc w takiej sytuacji, najlepiej wrócić do korzeni i zastanowić się czemu ono powinno służyć. 

Jeff Sutherland w swojej książce pod tytułem “Scrum. Czyli jak robić dwa razy więcej dwa razy szybciej” opisuje kulisy powstania Scruma, między innymi skąd wziął się pomysł codziennych spotkań. Inspiracją był zespół rugby, który przygotowuje się do rozegrania meczu, omawiając swoją taktykę. Wymieniają się spostrzeżeniami, przypisują sobie zadania oraz ustalają plan na najbliższą rozgrywkę. Chodzi o to, żeby zespół szybko ustalił jak zwyciężyć, czyli w przypadku zespołu deweloperskiego – ukończyć sprint. Zebranie się zespołu na chwilę w jednym miejscu umożliwia szybkie omówienie taktyki, a także upewnienie się, że wszyscy o niej wiedzą i rozumieją ją w ten sam sposób. Załóżmy na chwilę, że zamiast tego członkowie zespołu rozmawiają pojedynczo z osobą, z którą chcą coś ustalić. Posługując się wzorem N(N-1)/2 możemy łatwo policzyć ilość kanałów komunikacji w zespole, w zależności od jego wielkości. Już przy zespole 4-osobowym mamy 6 różnych kanałów komunikacji. Jeżeli jednak w zespole jest 9 osób liczba ta rośnie do 36. Czy wyobrażasz sobie, że każdy rozmawiając z każdym osobno przekaże tę samą informację? Przecież to istny głuchy telefon, nie mówiąc już o tym, jak długo ta informacja będzie krążyć, szczególnie w sytuacji, gdy któraś z osób wnosi coś nowego do przekazywanej wiadomości. 

Uświadomienie zespołowi genezy i celu Daily Scrum oraz ilości kanałów komunikacji, przez które musiałaby przechodzić wiadomość bez tego spotkania jest dobrym początkiem, aby zorganizować je we właściwy sposób. Zwróć też uwagę na to, jak zorganizowałeś tablicę scrumową. Podzielenie jej według poszczególnych członków zespołu nastawia do myślenia tylko o swoich zadaniach. Spróbuj podzielić ją według historyjek użytkownika (ang. User Stories), dopisując członków zespołu do poszczególnych zadań. Omawiając user stories łatwiej zachęcić zespół do rozmowy na ten temat, niż omawiając zadania konkretnej osoby. 

Często słyszałem również, że podczas codziennych spotkań każdy z uczestników powinien odpowiedzieć na 3 pytania:

  1. Co zrobiłem od ostatniego Daily?
  2. Nad czym będę dziś pracował?
  3. Jakie mam blokery? 

Już w tym miejscu spotykamy podstawowy błąd. Nikogo na tym spotkaniu nie interesuje, że ktoś połowę dnia spędził na szkoleniu z BHP, a drugą część na rekrutacji nowych pracowników. Nie zapominajmy, że rozmawiamy jedynie o pracy, która dotyczy realizacji celu sprintu. Jako, że nie jest to spotkanie statusowe, pracownicy nie muszą udowodnić, że coś robili. Oryginalnie te trzy pytania w Scrum Guide brzmią:

  1. Co zrobiłem wczoraj, co pomogło Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?
  2. Co zrobię dzisiaj, co pomoże Zespołowi Deweloperskiemu przybliżyć się do osiągnięciu Celu Sprintu?
  3. Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu?

Zawsze namawiałem zespoły, żeby traktowały te pytania bardziej jako podpowiedź, a nie sztywną formę spotkania. Informacja, że komuś dostarczysz jakąś część pracy, aby mógł kontynuować albo, że Ty potrzebujesz dziś coś otrzymać, jest równie ważna i powinna być poruszana podczas spotkania. Moje odczucia odnośnie spotkania nie były osamotnione, gdyż w 2017 roku Scrum Guide dodał zapis, że wymienione pytania są jedynie sugestią, a zespoły deweloperskie mogą równie dobrze przeprowadzić to spotkanie w formie dyskusji. Ważne jest jedynie, aby było poświęcone postępowi prac związanych z osiągnięciem celu sprintu. 

Czasami Daily Scrum wygląda na perfekcyjny, jednak nie zawsze tak jest. Podczas pracy z jednym zespołem miałem wrażenie, że pomimo iż rozmawiamy w naszym ojczystym języku, to i tak się nie rozumiemy albo najzwyczajniej się nie słuchamy. Postanowiłem więc sprawdzić, czy spotkanie spełnia swój cel. Przygotowałem ankietę, w której zawarłem 3 pytania:

  • Czy idziemy zgodnie z planem? Jeśli nie, to dlaczego?
  • Czy mamy jakieś blokery? Jeśli tak, to co zamierzamy z nimi zrobić?
  • Jaki jest główny cel na dziś dla zespołu?

Wyniki ankiety nie były zbytnio zaskakujące. Część zespołu twierdziła, że realizujemy cel sprintu zgodnie z planem, inni, że nie zdążymy ze wszystkim. Jedni mieli blokery, inni twierdzili, że ich nie mamy, a jako główny cel większość wymieniła swoje zadania. Ankietę powtórzyłem kilka razy i wyniki były bardzo podobne.  

Chaos i niezrozumienie, które mieliśmy podczas Daily Scrum przekładało się na ogólną pracę zespołu. Brak priorytetów w ramach sprintu, brak zrozumienia blokerów i pracy nad nimi, a także niewiedza co robią poszczególni członkowie zespołu skutkowało brakiem zrozumienia obecnego postępu prac. Zwykle to, że nie zrealizujemy celu uświadamialiśmy sobie dwa dni przed końcem sprintu. Aby to naprawić wprowadziliśmy szereg usprawnień. Pytania, które zadawałem w ankiecie zostały wprowadzone do podsumowania Codziennego Scruma. Codziennie przed zakończeniem spotkania ktoś w ramach podsumowania odpowiadał na każde z 3 pytań. Ta osoba nie może być odgórnie wybrana i przede wszystkim nie może to być Scrum Master. Początkowo wskazywałem osobę, która robiła podsumowanie, jeżeli nie pojawiał się ochotnik. Jednak już po kilku spotkaniach nie było z tym żadnego problemu. Rozwiązało to kilka problemów:

  • Uczestnicy spotkania słuchali się nawzajem, ponieważ mogło się okazać, że będą robić podsumowanie.
  • W niespełna 2 minuty wszyscy upewniali się, że ich zrozumienie obecnego stanu jest takie samo. Jeżeli ktoś nie zgadzał się z treścią podsumowania, było to od razu wyjaśniane
  • Ustalony został priorytet dla całego zespołu na najbliższy dzień.
  • Do każdego zidentyfikowanego blokera został dopisany “właściciel”, który dbał o to, aby został on rozwiązany.  

Aby blokery nam nie umknęły, postanowiliśmy je śledzić. Utworzyliśmy osobną tablicę scrumową (ang. Scrum Board). Każda z kolumn odpowiadała poszczególnym dniom sprintu. W momencie, gdy pojawiał się jakiś bloker, przyklejaliśmy karteczkę w kolumnie odpowiadającej dniu, w którym się pojawił z jego nazwą, numerem zadania, które blokuje oraz imieniem “właściciela”. Jeżeli następnego dnia bloker nadal był aktualny, w kolumnie odpowiadającej następnemu dniu dodawaliśmy karteczkę ze znakiem “>”. W dniu rozwiązania blokera w odpowiedniej kolumnie lądowała karteczka ze znakiem “X”. W ten sposób widzieliśmy aktualne blokery, te które rozwiązaliśmy oraz jak długo przeszkadzały nam w obecnym sprincie. 

Scrum Board

Fot. 1. Tablica blokerów zaprojektowana i wykonana przez Paulinę Tor (zdjęcie z archiwum prywatnego autora)

Idąc za ciosem, wprowadziliśmy kilka dodatkowych zasad, które podpowiedział mi Scrum Master pracujący z drugim zespołem. Dzięki Grzegorz! 

  • Powiedz co zrobiłeś w kontekście realizacji celu, nie co robiłeś.
  • Ogranicz do minimum techniczne detale swojego zadania.
  • Powiedz konkretnie, co Cię blokuje, podaj propozycję co może Ci pomóc.
  • Powiedz czego potrzebujesz od innych członków zespołu przez najbliższe 24 godziny.
  • Oszacuj, czy posunąłeś się z zadaniem do przodu, oszacuj czy na tę chwilę dostarczysz zadania na czas.

Pamiętacie muppeta z “Ulicy Sezamkowej” o imieniu Elmo? On również przyczynił się do usprawnienia naszego daily. Na tablicy wisiała również kartka z rysunkiem muppeta z podpisem ELMO, który oznaczał Enough, Let’s Move On. Tej karty mógł użyć każdy z uczestników spotkania w momencie, gdy osoba obecnie mówiąca za bardzo zagłębiała się w detale, które nie wnosiły wartości dla zespołu. 

Całość wymienionych usprawnień przełożyła się na skrócenie Daily Scrum, przy jednoczesnym wzroście merytoryki. Nie jest to jednak złoty przepis, który w całości należy skopiować do innych zespołów. Jest to odpowiedź na problemy, które napotkałem, pracując z moim zespołem. Jeżeli spotykasz się z podobnymi trudnościami możesz użyć sprawdzonych metod. Zachęcam również do eksperymentowania i wprowadzania autorskich pomysłów. Nie traktuj tego spotkania zbyt sztywno. To nie forma jest istotna,  a fakt, aby Codzienny Scrum spełniał swój cel. Pamiętaj też, aby na siłę nie usprawniać tego, co działa. 

To pozornie nieistotne spotkania ma w sobie wielki potencjał. Jego odpowiednia organizacja pozwala nie tylko wyeliminować dodatkowe spotkania czy usystematyzować poziom wiedzy, ale również zwiększyć efektywność zespołu. Nie pozwól zmarnować tego potencjału.

Więcej wpisów autora: Piotr Opałacz

Przejęcie projektu IT – wszystko, co musisz wiedzieć w 11 krokach

Rozpoczynając nowy projekt, mamy możliwość układania jego organizacji od początku, niestety nie...
Czytaj dalej

7 komentarze

  • Mała poprawka do : “Codzienny Scrum (ang. Daily Scrum) jest spotkaniem zespołu programistów”. To jest spotkanie zespołu developerskiego a nie programistów. W skład zespołu developerskiego wchodzą ludzie z różnymi kompetencjami, nie tylko programistycznymi

  • Pierwszorzędny wpis! W 100% zgadzam się ze stwierdzeniem w tytule. Po daily faktycznie łatwo można rozpoznać prawdziwie zwinne i zaangażowane zespoły. Ciekawe jest to, że proste przeformulowanie pytań potrafi zupełnie zmienić charakter spotkania. A radę aby jeden uczestnik dokonał debrefingu muszę koniecznie zastosować w swoim zespole. Dzięki!

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *