3 czerwca 2019

Za dużo spotkań ! Kiedy mamy pracować?

Prawie zawsze scenariusz wygląda tak samo.

Z mroku wyłania się jasność, organizacja wprowadza w życie zasady Scruma, do zespołów trafiają Scrum Masterzy i chwilę później deweloperzy zaczynają odkrywać lub przypominać sobie o istnieniu funkcji kalendarza w programie pocztowym. Albowiem jedną z pierwszych rzeczy jaką Scrum Master robi, po pogadaniu z zespołem – wygłoszeniu swojego expose, przedstawieniu planu działania, zasad pracy, informacji o co tu w ogóle chodzi, zagrzaniu do boju etc. – jest wysłanie zestawu zaproszeń na spotkania. Na spotkania, dodajmy, cykliczne, wynikające z zasad Scruma, a zatem – Daily Scrum, Planowania Sprintu, Przeglądu Sprintu, Retrospektywy Sprintu, niemalże na pewno również i Doskonalenia Backlogu, a czasem zdarzy się, że wpadnie i coś jeszcze. Do tego najczęściej na samym początku są one planowane i wystawiane z maksymalnym czasem trwania zgodnym z zasadami Scruma. I nawet jeśli było to wszystko wspólnie przegadane z zespołem, a przecież bezwzględnie powinno być – po co, jak, gdzie i kiedy – to chwilę po wysłaniu tychże zaproszeń przez Scrum Mastera, w firmie słychać jeden wielki deweloperski krzyk: Cooooo to jest? A kiedy my mamy niby pracować?

Oto bowiem w skrzynce odbiorczej pojawiły się maile – zaproszenia od Scrum Mastera. I okazało się, że jest ich dużo. Po zaakceptowaniu spotkań wypełnił się kalendarz i dopiero w tym momencie widać co żeśmy poustalali… Cztery godziny na planowanie? Dwie godziny na przegląd? Kogoś tu chyba pogięło…

Kiedyś byłem świadkiem sytuacji, kiedy Scrum Master zrobił wszystko jak trzeba. Szczegóły były ustalone z deweloperami, którzy jasno mówili, że wiedzą po co te spotkania i wspólnie wypracowali harmonogram, kiedy będą się odbywać, jak jest dla nich najwygodniej. Po zatwierdzeniu planu działania, wspomniany Scrum Master siadł do komputera i wystawił spotkania. I dosłownie 15 minut później zadzwonił do niego pierwszy telefon. Nie zdążył skończyć pierwszej rozmowy z kierownikiem części swoich ludzi, kiedy w drzwiach pokoju stanął dyrektor IT, który zaprosił go do gabinetu. Tam odbyła się rozmowa, że może tych spotkań za dużo, że coś tu chyba nie gra, że może bardziej na spokojnie z tym Scrumem, tak krok po kroku, że ludzie się zdenerwowali, że chcą programować, a nie się spotykać.

Wtedy Scrum Master wdraża procedurę nr 345 – spotkanie to też praca. I zaczynają się tłumaczenia, wyjaśnienia. Że dzięki tym spotkaniom praca będzie sprawniejsza, wydajniejsza, a przede wszystkim jej efekty będą zgodne z oczekiwaniami. Albo będą bardziej zgodne niż są w tej chwili. Że zburzymy dzięki nim mury z biznesem, że stworzymy z grupy ludzi zespół. Że przecież dotychczas tych spotkań było jeszcze więcej, tylko odbywały się doraźnie, nie do końca miały swój cel, zabierały czas, a teraz będzie wszystko uporządkowane. I tak dalej, i tak dalej. Najczęściej rozmowy te toczą się tylko w zespole, ale bywa też, że i z “górą”. A jest jeszcze Product Owner, który uczestniczy w większości tych spotkań, a bywa, że i jest na każdym. I on też nierzadko się w to wszystko włącza, z pretensjami i komentarzem, że on nie ma na to czasu.

Te wątpliwości może rozwiać tylko praktyka – doświadczenie dobrych, efektywnych spotkań – gdzie ich uczestnicy namacalnie poczują, że to faktycznie ma sens. No nie oszukujmy się, że ktoś posłucha scrummasterskiego bajdurzenia o tym jak te nowe spotkania są inne, inspekcja, adaptacja, razem młodzi przyjaciele, blablabla... A, nie daj Boże, jeszcze ktoś nieopatrznie nazwał to wszystko ceremoniami… Powtórzę się. Zadziałają, przekonają tylko sensowne, dobrze przeprowadzane, przynoszące efekty spotkania. A na to potrzeba czasu

Postarajmy się jednak uniknąć nieporozumień już krok wcześniej, na etapie ustalania harmonogramu pracy Scrumowego zespołu. Jak to wszystko ogarnąć? Oto orzykładowy plan działania.

1. Zinwentaryzuj wszystkie firmowe spotkania, w których uczestniczą członkowie Twojego zespołu. Nie zapominaj o Product Ownerze.

Zanim zaczniemy organizować zespołowi życie w scrumowym świecie, przyjrzyjmy się dobrze jak wygląda jego świat dotychczasowy

Porozmawiajmy z deweloperami – w jakich spotkaniach uczestniczą w chwili obecnej? Zebrania całego IT, spotkania w ramach specjalizacji, cykliczne spotkania w ramach uczestnictwa w jakichś dodatkowych projektach, jakieś konsultacje, spotkania “raportowe” z kierownikami?

To samo zróbmy z Product Ownerem. Dziwny błąd Scrum Masterów, który zdarza mi się od czasu do czasu obserwować, polega na tym, że wszelkie ustalenia dotyczące spotkań robione są z deweloperami, a Product Owner otrzymuje je do wiadomości. Ma się dostosować i już. Najczęściej wynika to z całkowitego skupienia Scrum Mastera na implementacji Scruma w dziale IT, bo właśnie tam ma zrealizować zmiany. Ale o tym może innym razem.

Znając spotkania, w których uczestniczą osoby z Twojego zespołu – ich częstotliwość, czas trwania, a przede wszystkim cel, przyjrzyj się im bliżej. Kto w nich uczestniczy? Czy wszystkie nadal będą miały sens? Czy ich godziny są optymalne?

Jeżeli widzisz rzeczy ewidentnie do zmiany, wyeliminowania – nie spiesz się. Nie wszystko musi się zadziać w ciągu tygodnia. Porozmawiaj z organizatorami tych spotkań. Jakieś istniejące spotkanie straci sens? Opowiedz dlaczego, zaproś na to, które je zastąpi albo pokaż jak jego efekty uzyskać w inny sposób. Godzina jest nieoptymalna albo kłóci się z tym co zaplanowaliście w zespole? Wyjaśnij dlaczego prosisz o zmianę, czym to uzasadniasz. I bądź cierpliwy. Jeśli ktoś stanie okoniem, a Ty dobrze ułożysz proces w zespole, sami uczestnicy tych spotkań będą się domagać zmian. I uzyskają je. Prędzej niż ty. Sorry, Winnetou

2. Ustal godziny pracy w zespole

Z założenia próbujecie stworzyć Zespół Scrumowy. A zatem – wspólny pokój, bliska współpraca…

A tu już na początku schody – Jeden przychodzi o siódmej, drugi o dziesiątej trzydzieści, a trzeci o jedenastej… Dla jednego wspomniana jedenasta to środek dnia pracy, drugi właśnie piję kawę i w sumie to chętnie zabiłby czas słuchaniem kto co zrobił, yyy, wróć, raczej czego nie zrobił, bo to jest ciekawe! A trzeci ledwie przed chwilą wstał z łóżka i w sumie to kawę by sobie zrobił…

No i właśnie – trzeba spróbować jakoś się dogadać, żeby faktycznie można było działać zespołowo, a jednocześnie nie spowodować tego, że zaraz ktoś się zwolni, bo nie będzie wstawał w środku nocy, albo wychodził po piętnastej, bo musi wcześniej odebrać dzieci ze szkoły..

Wypadałoby porozmawiać z każdym z członków zespołu i dowiedzieć się jak wygląda jego podejście do tematu – o której przychodzi/wychodzi, z czego to wynika czy są możliwe jakieś kompromisy z jego strony.

Z tą wiedzą można zacząć cokolwiek planować.

3. Zacznij od Daily

Proponuję rozpocząć ustalanie godzin i dat spotkań scrumowych od Daily, choć… równie dobrze możesz zacząć od Planowania i też będzie to w porządku. Układać kalendarz zespołu od Daily jest o tyle dobrze, że spotkanie to odbywa się codziennie i buduje pewien rytm działania zespołu, reguluje cały jego dzień. W zasadzie tu wypadałoby zaplanować dzień pracy i ustalić co i jak. Dobrze zatem, żeby odbyło się to w miarę wcześnie. Dobrze, ale nie – koniecznie. To ważne, żeby ludzie sami zdecydowali która godzina jest dla nich najodpowiedniejsza, pamiętaj że jako Scrum Master powinieneś eliminować jednoznacznie złe decyzje. Daily z planem na następny dzień, przeprowadzane dzień wcześniej o 15:50 nie wydaje się najlepszym pomysłem. Ale jeśli zespół ma jakieś ciekawe wizje, potrafi to dobrze uzasadnić, czemu nie spróbować? Jeden z moich zespołów przez wiele lat prowadził Daily o “okrągłej” wedle świata IT godzinie 10:24.

Przy okazji Daily warto zarezerwować jeszcze jakieś 20 minut po jego zakończeniu. Na co – zdecydujecie w przyszłości. Czy to klasyczne technikalia po spotkaniu, szacowanie zadań z backlogu czy codzienne odśpiewanie hymnu zespołu

Zadbaj też i o to, żeby po Daily było trochę czasu, aby kuć żelazo póki gorące. I móc w zespole przedyskutować pewne sprawy w mniejszych grupach, a nie pędzić na kolejne spotkanie.

4. Kiedy zaczynać sprint? A kiedy kończyć?

Jedni lubią żyć zgodnie z rytmem natury i nieprzyjemne (planowanie) robić w poniedziałek, a przyjemne – pod warunkiem dobrych efektów (przegląd, retrospektywa) w piątek. Drudzy nie lubią poniedziałków i wolą planować we wtorki, a sprinty kończyć w poniedziałki.

Są tacy, którzy uważają, że planować trzeba od rana. A są uparci, którzy mówią, że najlepiej po dwunastej.

Inni twierdzą, że najlepiej wszystko robić jednego dnia i zamiast mieć dwa poszatkowane dni na zasadzie: praca przerywana spotkaniami (tak, to też praca, pamiętam), poświęcić raz w sprincie jeden dzień, żeby załatwić całość i “pojechać” ciągiem przegląd – retrospektywa – planowanie.

I wszystkie te podejścia są w porządku. A te które sprawdzą się w jednym zespole, będą katastrofą w innym.

Zaufaj swoim ludziom. Wspólnie ustalcie od czego zaczniecie. I spróbujcie. Inspekcja i adaptacja, na tym to polega. Gdy zaproponowałem początkującemu Scrum Masterowi zmianę istniającego w zespole cyklu, inne dni, godziny spotkań, usłyszałem To tak można? No pewnie!

Przegląd Sprintu – porozmawiaj z Product Ownerem, kluczowymi interesariuszami. To wydarzenie dla całej firmy, fakt, ale powinniście z PO zadbać przede wszystkim o to, żeby trafili na nie ci najbardziej zainteresowani efektami waszej pracy. Owszem, czasem zdarzy się, że trzeba będzie dostosować się pod jedyne wolne okienko czasowe kogoś z Zarządu. I to od Przeglądu zaczniecie układanie całości. Trudno, działajcie dalej w ramach znanego ograniczenia.

Ważna uwaga – pójście w stronę trzech ważnych spotkań scrumowych (przegląd – retro – planowanie) jednego dnia jest ryzykowne. Jeśli jednak tak chcecie działać, w tym układzie planowanie powinno być załatwione wcześniej – zadania omówione, przygotowane i ułożone. Na samym spotkaniu powinniście się ograniczyć do omówienia organizacji pracy, raz jeszcze upewnić się czy planowane zadania są rozumiane i realne do realizacji w ramach sprintu, całość nie powinna trwać więcej niż godzinę. Inaczej będzie robione po łebkach, na zmęczeniu z podejściem wszystko jedno, byle skończyć i stąd wyjść. Zadbajcie też o przerwy.

5. Spotkanie to też praca. Ale nie zapominaj, że najważniejsze jest programowanie.

No właśnie – po wystawieniu wszystkich spotkań, spójrzcie wszyscy w zespole na układ spotkań i rzućcie okiem na kalendarz przede wszystkim od strony deweloperów. Czy każdego dnia sprintu (no, może z wyjątkiem dnia przeglądowo – retrospekcyjnego) deweloperzy mają zapewniony ciągły czas na programowanie, kilka godzin spokoju, w których mogą sami zorganizować swój czas?

Ciągły, bo można mówić, że przecież spotkania zajmują w ciągu dnia tylko 2h, ale jeśli jest ich pięć porozrzucanych po całym dniu, to nie ma kiedy siąść do komputera i się porządnie skoncentrować. A po powrocie do tematu, nawet 15 minut później, często zapomina się co właściwie się robiło i dlaczego i trzeba zaczynać wszystko od nowa.

6. Optymalizuj

Nieustannie optymalizuj spotkania. Ich czas, częstotliwość, a przede wszystkim efekty. Czy wszyscy są zawsze potrzebni na każdej pielęgnacji? Czy Daily – o zgrozo – musi się odbywać codziennie? Czy nie lepiej skrócić retrospektywę, za to skupić się na mniejszej ilości rzeczy i je rozwiązywać?

Zachęcaj deweloperów do dawania informacji zwrotnej o spotkaniach, o ich wrażeniach. Czy to na Retrospektywie, czy to podczas luźnej pogawędki przy kawie. Czy czują, że mają sens, czy nie mają poczucia straty czasu. Co według nich wnoszą. Wsłuchuj się w ich opinie i odpowiednio na nie reaguj

I jeszcze jedno. Drogi Scrum Masterze, pamiętaj – ty tu jesteś najmniej ważny. Nie ustawiaj zespołu wedle swojego kalendarza i wygody.

#Scrum#ScrumMaster