Dzisiaj mam dla was scenkę w formie dialogu pomiędzy Developerem a Scrum Masterem. To zapis tego, jak może wyglądać i często wygląda rozmowa w Zespołach, które posługują się Scrumem. Jej tematem jest Daily Scrum, a dokładniej postulat, który w większości Zespołów wcześniej czy później stawiają Developerzy: by nie realizować tego zdarzenia.

Jak może taka rozmowa wyglądać?

– Daily Scrum nie jest nam potrzebny i postanowiliśmy go nie robić – informuje Scrum Mastera jeden z Developerów.

– Ale w Scrumie Daily nie jest czymś opcjonalnym. Musi się odbywać, jeśli chcemy twierdzić, że pracujemy w Scrumie.

– Jeśli nic nam nie daje, to po co mamy go robić?

Scrum Master drapie się za uchem i pyta:

– A po co jest Daily?

– No, właśnie doszliśmy do wniosku, że po nic – śmieje się Developer.

– To dlaczego w Scrumie zdefiniowano takie zdarzenie?

Developer wzrusza ramionami.

– Ty jesteś Scrum Masterem, to mi wytłumacz. Albo nie – kręci głową – nie chce mi się tego słuchać po raz kolejny.

– Faktycznie, już o tym parę razy rozmawialiśmy – ciężko wzdycha Scrum Master. Szybko się jednak opanowuje. – Jak rozumiem, wszyscy wiecie, po co jest Daily i uznaliście, że jest wam zbędne?

– Wreszcie załapałeś.

– Cóż, nie powiem, żebym nie był zaskoczony, ale nawet mnie cieszy, że nie chcecie robić zbędnych spotkań.

Developer wygląda na autentycznie zdziwionego.

– Serio? A wszyscy myśleli, że będziesz się upierał przy robieniu Daily…

– Czemu? Jeśli udaje się wam osiągnąć ten sam efekt, jaki daje to zdarzenie, bez spotykania się, to nie ma powodu, by się spotykać. A tak rozumiem to, o czym mówisz. Przeanalizowaliście to, jak pracujecie w Sprincie i wyszło wam, że Daily w formie spotkania jest czymś nadmiarowym. Czy tak?

Zapada kłopotliwa cisza.

– Ale mam też pytanie – dodaje Scrum Master po chwili.

– Wiedziałem. Aż się boję jakie. Ale pytaj.

– W jaki sposób uzyskaliście to, że Daily jest wam niepotrzebne? Bo twórcy Scruma od lat wywalają z tej metody wszystko, co nie służy Zespołom, a skoro nadal jest tam Daily Scrum i uznawany jest za coś bardzo ważnego, to chyba jednak większość Zespołów tego spotkania potrzebuje. A u nas jest inaczej. Więc sam rozumiesz, że jestem ciekaw dlaczego.

Developer zastanawia się przez chwilę.

– No… to proste przecież – odpowiada w końcu. – Nie potrzebujemy spotkania synchronizacyjnego, bo pracujemy na bieżąco ze sobą i komunikujemy się w zasadzie non-stop. Nie ma sensu odrywać się od pracy i robić jakichś sztucznych ceremonii, skoro i tak każdy cały czas wie, co się dzieje.

– A myślisz, że Developerzy w innych Zespołach ze sobą na bieżąco nie gadają?

– Nie wiem, może gadają, a może nie. Co to zresztą ma do rzeczy? My koordynujemy się bardzo często, więc Daily nic nam nie daje. I dlatego robić go nie będziemy.

Scrum Master kiwa głową ze zrozumieniem i mówi:

– Jeśli nic wam nie daje i faktycznie taka jest wasza percepcja tego spotkania, to nie ma co na niego tracić czasu. Ale zaryzykuję stwierdzenie, że w takim razie do tej pory, mimo że spotykaliście się codziennie, nie robiliście Daily tylko… jakieś spotkanie synchronizacyjne. Dobrze się domyślam?

– No, spotkanie synchronizacyjne, czy jak ty tam to nazywasz, Daily – ostrożnie mówi Developer.

– Niezupełnie. To nie są synonimy. W Daily Scrumie nie chodzi przecież tylko o wymianę informacji o tym, co się dzieje, bo jak słusznie powiedziałeś, Developerzy mogą i powinni robić to na bieżąco. Chodzi o upewnienie się, że z tej wspólnej wiedzy wszyscy wyciągają takie same wnioski.

– A mogliby wyciągnąć inne?

– Oczywiście – kiwa głową Scrum Master. – Powiedzmy, że robisz coś już dwa dni. Marek i Tomek wiedzą, że robisz to dwa dni. Tobie wydaje się, że idzie ci dobrze. Marek uważa, że zasuwasz w zaskakująco szybkim tempie, a Tomek martwi się, że chyba robota idzie ci wolniej, niż powinna. Wiecie to samo, ale różnie oceniacie sytuację. Jeśli nie pogadacie na czas, Sprint może wymsknąć się wam spod kontroli.

– Ale w tym rzecz właśnie, że gadamy.

– I dokonujecie wymiany takich opinii o stanie prac w Sprincie, jak przed chwilą pokazywałem na przykładzie?

Developer wzrusza ramionami, ale widać, że już nie jest tak pewny, iż Daily Scrum jest niepotrzebny.

– Nie wiem. Pewnie nie. Ale przecież na Daily Scrumie tego też nie robimy.

– Więc może to nie Daily Scrum jest bez sensu, ale formuła, w jakiej on się odbywa, czyni go bezużytecznym dla was? Użyjcie Daily tak, by coś wam dawało.

Developerowi niemal wyrywa się „łatwo powiedzieć!”, ale zamiast tego pyta po prostu:

– Czyli jak?

– Każdy z was robi coś w Sprincie i wie, jak mu idzie. Więc wymieńcie się tymi własnymi ocenami postępu prac i ryzyka przynajmniej raz na dzień. Inaczej mówiąc, na moment odłóżcie to, co każdy robi i upewnijcie się, czy każdy robi rzeczywiście to, co powinien. Bo może okazać się, że wcale tak nie jest i że trzeba coś rzucić i zająć się innym, pilniejszym tematem.

– Ale sam mówisz, że musimy się odrywać od roboty, żeby zrobić takie Daily – stwierdza triumfująco Developer. – Więc lepiej poczekać, aż będzie coś skończone i wtedy pogadać, co dalej.

– Nie mówiłem o odrywaniu się od roboty, ale o odłożeniu tego, czym się zajmuję. Odłożyć można coś w sposób planowy, jeśli wiem, że spotkanie się odbywa i jeśli tak sobie rozplanuję moją pracę, żeby nie musieć się od niej odrywać. Jeśli będziemy czekać na jakiś odpowiedni moment, kto zdecyduje, że on właśnie nadszedł?

– Będziemy decydować na bieżąco… – zaczyna tłumaczyć Developer, ale Scrum Master wchodzi mu w słowo.

– To dopiero będzie odrywać ludzi od roboty, jeśli spotkania odbywać się będą w losowych momentach. Jest szansa, że przed końcem Sprintu żadne Daily się nie odbędzie.

– A mnie nadal wydaje się, że każdy Developer potrafi ocenić, jak mu idzie. Gdybyś był Developerem, to byś wiedział, co mam na myśli.

Scrum Master nie daje po sobie poznać, jak bardzo irytuje go powtarzany co jakiś czas zarzut o to, że nie jest jednocześnie Developerem. Faktycznie, nie ma doświadczenia jako programista czy tester, ale sporo wysiłku włożył, by zrozumieć, na czym polega budowanie oprogramowania, jakie wytwarza Zespół. To jednak nie jest dobry moment na dyskusję o takich kwestiach.

– Faktycznie, nie jestem Developerem – mówi spokojnie – ale chyba wracamy do punktu wyjścia. Jeśli Developerzy nie mają wspólnej oceny tego, jak idzie praca w Sprincie, może im długo wydawać się, że jest dobrze. A kiedy jakiś problem wybuchnie im w twarz, może być za późno, by sobie z nim poradzić. Sam pomyśl, ile razy zdarzyły nam się Sprinty, w którym przez większość czasu była mowa, że nie ma żadnych problemów, a na koniec ledwo co udało się skończyć.

– Jakbym był złośliwy, to bym powiedział, że na tym polega ta cała złożoność…

Scrum Master uśmiecha się, nieco rozbawiony, ale szybko poważnieje.

– Owszem, ale nie po to używa się Scruma, żeby kompletnie zdać się na los i zobaczyć, co się uda zrobić – wyjaśnia. – Skoro środowisko, w jakim pracujemy, jest nieprzewidywalne, trzeba regularnie sprawdzać, czy plan działania, jaki realizujemy, nie wymaga pilnej zmiany. Nawet za cenę spotykania się codziennie. Przy czym moim zdaniem wcale nie wymaga to odrywania się od roboty.

– Mam pisać kod i być jednocześnie na spotkaniu? Przecież ciągle trujesz nam, że nie powinniśmy robić wielu rzeczy naraz… – wytyka nieco złośliwie Developer.

– Chodziło mi o to, że jeśli spotkanie odbywa się w sposób regularny, to można układać sobie robotę tak, żeby w momencie Daily nie mieć niczego rozgrzebanego. Nie trzeba się będzie odrywać, a do tego łatwiej będzie ocenić, czy plany nie wymagają uaktualnienia.

Developer kiwa głową.

– Pięknie, ale to wymagałoby robienia Daily mniej więcej o tej samej porze i żeby wszyscy do tego podeszli na serio.

– Cóż, na to chyba wy sami, Developerzy, macie największy wpływ, prawda? O tym też wam truję od dawna, ale jakoś odbija się to jak grochem od ściany. Sam widzisz, że Daily miałoby więcej sensu, gdyby było regularne i gdyby skupiło się nie na tym, że każdy opowie, co robi, ale na wspólnej ocenie, czy to, co wszyscy robią, jest tym, co robić powinni.

– Strasznie długie zdanie… dobra, trzeba to będzie przegadać z resztą Zespołu. Wychodzi na to, że jednak z tym Daily nie jest tak prosto, jak nam się wydawało – mówi Developer.

Na tym rozmowa się kończy. Ciąg dalszy odbędzie się już w szerszym gronie (opiszę go w kolejnym artykule).

A jak ty poradzisz sobie z taką rozmową?

Oczywiście nie jest to „rozmowa wzorcowa”, a wielu słusznie stwierdzi, że prawdopodobnie można było poradzić sobie lepiej na miejscu Scrum Mastera. Ta sytuacja i przebieg rozmowy to wytwór mojej wyobraźni, ale też jest to pewne zgeneralizowanie szeregu podobnych dyskusji, w których przyszło mi wziąć udział, niekoniecznie zawsze jako Scrum Master. Mam nadzieję, że dialog okaże się inspirujący, nie tylko dla Scrum Masterów, ale również, a może przede wszystkim, dla Developerów. I że ciąg dalszy (wkrótce go opublikuję) pozwoli zrozumieć wybory, jakich dokonał opisywany Scrum Master.

Przy okazji: czy wiesz, po co jest Daily Scrum? I jeśli jesteś Scrum Masterem, potrafisz przekonać Developerów w swoim Zespole, że nie należy z niego rezygnować? Oraz wytłumaczyć, że jeśli „nie jest potrzebny”, to niewykluczone, że robicie coś źle?