Oto trzecia część cyklu artykułów na temat różnych przekłamań, których doczekał się Scrum w niejednej firmie. Jeśli ktoś nie czytał części pierwszej lub części drugiej, warto nadrobić to niedopatrzenie, niemniej każda z nich jest na tyle niezależna, że można zapoznać się z nimi w dowolnej kolejności.

A że była już mowa o Backlogu Produktu i Planowaniu Sprintu, pora uważniej przyjrzeć się temu, co ludzie nawymyślali na temat Sprintów oraz Daily Scrumów.

Mit 20: czas trwania Sprintu określony musi być w tygodniach

Nie jest niczym niezwykłym, że Sprinty planowane są tak, by zaczynać się i kończyć w określone dni tygodnia, a ewentualna zmiana następuje wyjątkowo, żeby ominąć świąteczne dni wolne.

Nie jest też zaskoczeniem, że wiele Zespołów rozpoczyna Sprinty w poniedziałki, a kończy w piątki, przez co iteracje pokrywają się z tygodniem roboczym, albo stają się ich wielokrotnością.

Dodatkowo Scrum Guide w historycznych wydaniach określał maksymalne czasy trwania niektórych zdarzeń przez odniesienie do długości samego Sprintu wyrażonego w tygodniach, np. Planowanie Sprintu mogło trwać maksymalnie dwie godziny na każdy tydzień długości Sprintu. Te reguły dawno już nie obowiązują, niemniej ich echo pozostaje w umysłach wielu osób.

Przy czym definicja Scruma w ogóle nie określa minimalnego czasu trwania iteracji – może to być np. zaledwie godzina. Jest zdefiniowana jedynie maksymalna jego długość, to jest miesiąc – bez wskazania, czy chodzi o miesiąc kalendarzowy, 30 dni, 31 dni, cztery tygodnie czy jeszcze co innego. Twórcy metody (przyjmijmy, że słusznie) założyli, że jej użytkownicy będą w stanie dokonać właściwej interpretacji tego zapisu i nie spróbują zrobić sobie krzywdy.

Sprinty mogą też zaczynać się i kończyć w dowolne dni tygodnia, co obserwuję ostatnio dość często. Ba, spotykam Zespoły, które rozwiązały problem różnej długości Sprintów spowodowanej przerwami świątecznymi w ten sposób, że iteracja u nich trwa np. przez kolejnych 10 dni roboczych. To ciekawy pomysł, choć powoduje, że np. Przegląd Sprintu odbywa się w różne dni tygodnia, więc trzeba zadbać, by interesariusze się w tym nie pogubili.

Mit 21: zakres prac w Sprincie nie może się zmieniać

Zasmucająco wiele osób uważa, że jeśli w trakcie Planowania Sprintu ustalona zostanie jakaś lista elementów Backlogu Produktu, które mają być realizowane, to od tego momentu do końca iteracji żadne zmiany nie mogą być dokonywane.

Nie mam pojęcia, skąd bierze się to przekonanie, być może łączy się z traktowaniem Planowania Sprintu jako kontraktu zawieranego między Zespołem a interesariuszami, który od tego momentu ma być wykonany co do joty, zgodnie z ustaleniami.

Oczywiście w Scrumie dowolne zmiany zakresu prac są możliwe w trakcie iteracji, a jedyne, czego nie można zmienić, to Cel Sprintu. Może wszak zdarzyć się, że już po Planowaniu Zespół odkryje, że Cel Sprintu jest nieosiągalny w sposób, jaki wydawał mu się sensowny. Czy ma bezmyślnie realizować plan, który z góry skazuje go na porażkę? Jasne, że nie. Musi plan zmienić tak, by Cel stał się osiągalny. Jeśli wymaga to wywalenia ze Sprintu połowy podjętych do niego rzeczy, a wciągnięcia na ich miejsce czegoś zupełnie innego, należy to zrobić.

Z kronikarskiego obowiązku dodam, że takie zmiany muszą odbywać się we współpracy Product Ownera z Developerami, a skala takich zmian zwykle nie jest duża. Nie należy jednak ich unikać, jeśli są konieczne, a jeśli dzieje się to zbyt często, warto (w ramach Retrospekcji Sprintu) zastanowić się, dlaczego i jak zjawisko to ograniczyć.

Mit 22: Cel Sprintu nie podlega negocjacji po jego ustaleniu

Zmiana Celu Sprintu jest niedopuszczalna w trakcie Sprintu, a jedyne, co da się zrobić, to przerwać Sprint, do czego ma prawo wyłącznie Product Owner. Przy czym oznacza to, że cała kadencja Sprintów się przesuwa, więc ta opcja atomowa jest mocno teoretyczna – mało kto po nią sięga.

Nie o anulowaniu Sprintu chciałem jednak napisać, ale o micie, że brak możliwości zmiany Celu Sprintu czyni ten Cel absolutnie nienegocjowanym.

A tymczasem jak najbardziej dopuszczalne i sensowne jest ustanowienie Celu Sprintu, który pozostawia przestrzeń do podjęcia niektórych decyzji już w trakcie developmentu. Oczywiście chodzi o decyzje, w jaki sposób i w jakim zakresie Cel ten zostanie osiągnięty, a nie co tym Celem będzie.

Najlepiej zobrazować to na przykładzie Zespołu, który buduje aplikację internetową i postanowił, że Celem bieżącego Sprintu będzie umożliwienie pierwszym rzeczywistym użytkownikom rejestracji, żeby zaczęli korzystać z dostępnych już funkcjonalności. Aby ten Cel osiągnąć, niezbędna jest sama rejestracja (dokonywana na różne sposoby), możliwość zalogowania się, wylogowania itd.

Jeśli okaże się, że Developerzy są w stanie udostępnić jedynie połowę planowanych sposobów rejestracji i że nie zdążą rozwiązać problemów, na jakie natrafili, implementując mechanizm samodzielnego resetu hasła, to w porozumieniu z Product Ownerem Zespół może uznać, że Cel Sprintu i tak został osiągnięty. Wszak da się udostępnić pierwszym użytkownikom produkt, który budują, choć może niekoniecznie w taki sposób, jak Zespół prognozował na początku Sprintu.

Nie dałoby się tak zrobić, gdyby Cel Sprintu zdefiniowany był np. tak: „Umożliwić rejestrację za pomocą mechanizmów X, Y oraz Z, logowanie, wylogowanie oraz zmianę i reset hasła”. Ponieważ ten Cel (a ja powiedziałbym, że pseudo-Cel, bo nie wyjaśnia, jaka korzyść wynika z jego osiągnięcia) stanowi opis kluczowych zmian w produkcie, jeśli choć jednej z nich nie uda się zrobić, Zespół Celu nie osiągnie.

Przy czym elastyczność nie oznacza ucieczki w ogólniki, pod które podciągnąć da się cokolwiek. Oto antyprzykład Celu: „Umożliwić tworzenie i zarządzanie kontami użytkowników”. Jako zarządzanie można potraktować cokolwiek, więc przestrzeń do bezsensownej dyskusji czy Cel został osiągnięty, czy jednak nie, jest mnóstwo. Nie o taką elastyczność chodzi.

Mit 23: nie wolno wciągać do Sprintu nieplanowanych rzeczy

Cel Sprintu nie może się zmieniać, ale może być elastyczny. Zakres prac w Sprincie może się zmieniać, zwłaszcza jeśli jest to niezbędne, by Cel Sprintu osiągnąć. To już mamy wyklarowane.

Czy jednak Zespół ma prawo podejmować się realizacji czegoś, czego nie planował i co nie jest niezbędne do osiągnięcia Celu Sprintu? Przykładem takiej sytuacji jest pilna potrzeba, z którą przychodzi do Developerów Product Owner, albo odkrycie przez nich samych, że mają czas zrobienie czegoś dodatkowego w Sprincie.

Są osoby przekonane, że takie postępowanie jest niedopuszczalne, bo prowadzi do tzw. przeciekania procesu, to jest omijania Planowania Sprintu i wpychania dodatkowej roboty do Sprintu bokiem. Znów czkawką odzywa się mit o „stałości zakresu prac” w Sprincie, aczkolwiek tutaj pada dodatkowy argument, że w ten sposób Developerzy pozbawiani są stabilności potrzebnej do ukończenia zaplanowanych prac.

Jest to rzecz jasna półprawda. Product Owner nie ma prawa nakazać Developerom podjęcia czegokolwiek do Sprintu nawet w trakcie Planowania Sprintu, nie mówiąc już o robieniu tego po jego zakończeniu. Nie oznacza to, że nie może tego zaproponować. Jeśli wspólnie Zespół dojdzie do wniosku, że proponowana zmiana jest możliwa, czemu nie miałby jej dokonać?

Ważne, by nie spowodowało to zmiany Celu Sprintu ani nie zagroziło jego osiągnięciu. Każde inne dostosowanie Backlogu Sprintu jest dopuszczalne.

Przy czym Developerzy, jeśli mają dodatkową przestrzeń na zrealizowanie kolejnego nieplanowanego wcześniej elementu Backlogu Produktu, nie powinni sami decydować o tym, co zrobić i który element wybrać. Dyskusja i w tym przypadku powinna odbywać się z udziałem Product Ownera.

Mit 24: tylko Developerzy pracują nad osiągnięciem Celu Sprintu

Nietrudno napotkać osoby, które są przekonane, że skoro to Developerzy wytwarzają w Scrumie kolejne zmiany w produkcie (czyli tworzą kolejne Przyrosty), to tylko oni działają na rzecz osiągnięcia Celu Sprintu.

W skrajnym przypadku można usłyszeć nawet i taką opinię, jakoby tylko Developerzy brali w Sprincie udział, co jest to tyle karkołomne, że przecież Sprint zaczyna się Planowaniem i kończy Retrospekcją, nie wspominając już o poprzedzającym ją Przeglądzie, a wszędzie tam obecny ma być cały Zespół Scrum.

W rzeczywistości cały Zespół Scrum bierze udział w Sprincie przez cały czas jego trwania, a zarówno Product Owner, jak i Scrum Master pracują nad tym, by osiągnięty został Cel Sprintu. I nie, nie ma tu sprzeczności, ani nie oznacza to, że muszą być półetatowymi Developerami.

Chodzi o to, że osiągnięcie Celu Sprintu nie sprowadza się wyłącznie do developmentu – potrzebne jest podejmowanie na bieżąco różnych decyzji, zarówno produktowych, jak i procesowych. Konieczne jest usuwanie utrudnień, pozyskiwanie informacji od interesariuszy i innych Zespołów… Jest więc mnóstwo pracy innej niż ta, którą wykonują Developerzy.

Szczególny obowiązek spoczywa tu na Product Ownerze, który odpowiada w Scrumie za to, by produkt był maksymalnie wartościowy dla interesariuszy. Nie wystarczy zdefiniować elementy Backlogu Produktu, by tak się stało. Trzeba też współpracować z Developerami w trakcie Sprintu, aby na bieżąco pomagać im w wytworzeniu tego, co faktycznie będzie wartościowe.

Przy okazji to pozwala uniknąć konieczności ustalania wszystkich szczegółów z góry, bo skoro Product Owner jest dla Developerów wystarczająco dostępny, może o wielu rzeczach zdecydować na bieżąco. Może też i nawet powinien zapoznawać się z wczesnymi wersjami różnych funkcjonalności, aby potwierdzić, że rozwiązania są dobre, zanim jeszcze Developerzy włożą wysiłek w ich dopracowanie.

Mit 25: Daily Scrum ma odbyć się rano, bo rozpoczyna dzień pracy

Daily Scrum to czas zarezerwowany dla Developerów, by dokonali oceny postępu prac nad Celem Sprintu i zaplanowali kolejny dzień pracy, uwzględniając przy tym wszystko, co skutkuje koniecznością adaptacji Backlogu Sprintu. Ma się odbywać codziennie, bo to bezpieczny interwał – na tyle krótki, by ograniczyć ryzyko zbyt późnej reakcję na problemy.

Nie ma więcej wymogów w Scrumie. Jest podpowiedź, że ten sam czas i to samo miejsce (fizyczne lub wirtualne) ułatwi organizację zdarzenia, bo nie trzeba się będzie zastanawiać, czy i gdzie się ono odbywa, czy już było itd. Nie ma natomiast wskazówek, czy Developerzy mają się spotkać rano, po południu, w kuchni czy na podwórku.

Mit 26: Daily Scrum musi odbywać się na stojąco

A skoro o formie Daily Scrumów mowa, to nie można nie wspomnieć o nazywaniu tego zdarzenia stand-upem ze względu na rzekomy obowiązek prowadzenia spotkania na stojąco. Taka forma codziennej synchronizacji, choć popularna, nie jest jednak w Scrumie wymagana. Ba, byłoby to dziwne, bo przecież są Zespoły pracujące zdalnie i ciężko wyobrazić sobie, że ludzie będą w takim przypadku stać na baczność przed komputerami, o ile sami nie będą tego chcieli np. z powodów zdrowotnych.

Mit ten jest niemożebnie stary i wykpiwałem go wiele lat temu, a wciąż ma się świetnie… ale jest na tyle nieszkodliwy, że jeśli już ktoś musi, to niech robi te Daily Scrumy na stojąco. Byleby tylko uczestnicy nie byli przekonani, że to najważniejsza rzecz, o którą trzeba zadbać na spotkaniu.

Mit 27: Daily Scrum ma odbywać się raz dziennie

Wydaje się oczywiste, że Daily Scrum to jedno spotkanie dziennie. W większości przypadków tak właśnie się dzieje, ale nie zawsze.

Jeśli środowisko Zespołu jest aż tak niestabilne, że Developerzy zwiększenie częstotliwości Daily Scrumów uznają za właściwe, mogą to zrobić bez obaw, iż naruszają zasady Scruma. Dodam, że to nie rozważania teoretyczne – zetknąłem się dwukrotnie z takimi Zespołami.

Mit 28: pominięcie Daily Scrumów jest niedopuszczalne

Jeśli w nazwie zdarzenia zawarty jest przymiotnik codzienny (a Daily Scrum to inaczej Codzienny Scrum), nie pozostaje wiele przestrzeni do dyskusji: ma odbywać się codziennie i basta!

I to niemal prawda, a taka interpretacja nie wyrządzi żadnej krzywdy, niemniej trochę prowokuje do podejrzeń, że propagatorom fundamentalnego podejścia do Daily Scrumów może umykać kluczowy aspekt tego zdarzenia, a mianowicie to, że celem jest planowanie (dostosowanie planów) działań Developerów.

Wyobraźmy sobie, że Zespół rozpoczął dzień od Planowania Sprintu, które trwało do południa i zakończyło się ustaleniem przez Deweloperów, kto i czym się zajmie zaraz po lunchu.

Czy na pewno pominięcie Daily Scruma tego dnia będzie katastrofalnym błędem, jeśli Developerzy organizują to zdarzenie każdego ranka? Po cóż im takie Daily Scrum tuż przed Planowaniem?

Czy na pewno pominięcie Daily Scruma będzie niedopuszczalne, jeśli Developerzy organizują to zdarzenie nie rankiem, ale w środku dnia? Po cóż im Daily Scrum tuż po Planowaniu, skoro na jego koniec zrobili dokładnie to, czemu służy Daily Scrum?

Natomiast jeśli Developerzy organizują Daily Scrumy na koniec dnia roboczego, to faktycznie, jego pominięcie w tej sytuacji byłoby nieporozumieniem. Takie zdarzenie ma się odbyć, bo kolejne nastąpi dopiero dobę później.

Dokładnie to samo dotyczy ostatniego dnia w Sprincie, gdzie nie ma sensu organizować Daily Scruma, po którym od razu Zespół udaje się na spotkanie z interesariuszami w ramach Przeglądu Sprintu – taki Daily Scrum już nic nie wniesie. Równie bezprzedmiotowy byłby Daily Scrum odbywający się w przerwie między Przeglądem Sprintu a Retrospekcją Sprintu albo po zakończeniu tej ostatniej (bo to kończy Sprint).

Mit 29: trzy pytania w trakcie Daily Scruma są obowiązkowe

Przed laty w definicji Scruma pojawiły się niesławne trzy pytania, które Developerzy powinni zadawać sobie w trakcie Daily Scrumów. Ich forma zmieniała się nieco z czasem, choćby po to, by przesunąć skupienie z wykonywanej pracy na Cel Sprintu, niemniej od samego początku do końca funkcjonowania tych pytań w Scrum Guide, były one jedynie podpowiedzią. Sugestią i przypomnieniem, o czym należy porozmawiać.

A jak to przełożyło się na praktykę w niejednym Zespole? Tu i ówdzie Scrum Master odpytywał Developerów, zadając literalnie te trzy pytania, oni zaś dukali coś w odpowiedzi, najczęściej nie mając zielonego pojęcia, po co to robią. A nierzadko nawet tam, gdzie Scrum Master był na tyle ogarnięty, by nie zawłaszczać w ten sposób Daily Scrumów, Developerzy wciąż sięgali po owe trzy pytania…

W listopadzie 2020 w końcu zniknęły i nic się nie zawaliło. Mit, że są wymagane, trzyma się natomiast całkiem nieźle. Cóż, najczęściej taki mamy Scrum, jakich mamy Scrum Masterów.

Mit 30: Scrum Master jest moderatorem w trakcie Daily Scruma

Czyż to nie oczywiste? Przecież Daily Scrum to integralna część procesu empirycznego w Scrumie, a zatem Scrum Master powinien być przynajmniej facylitatorem, a najlepiej moderatorem. Musi dbać o to, by Developerzy nie rozgadali się przesadnie, bo w końcu jest gospodarzem tego spotkania, czyż nie?

No, właśnie nie. Choć takie przekonanie nie jest niespotykane nawet wśród Scrum Masterów, to wciąż mit. Daily Scrum to zdarzenie dla Developerów, w którym uczestniczą jedynie oni. Uczestniczą, czyli biorą aktywny udział, decydując tak o formie spotkania, jak i przebiegu dyskusji. Ktokolwiek inny tam się pojawi, jest jedynie obserwatorem i Developerzy mają prawo go wyprosić, jeśli przeszkadza.

Scrum Master faktycznie ma zatem prawo pojawić się w trakcie Daily Scrumów jak każdy potencjalny inny obserwator. Ma też – jako Scrum Master – prawo wtrącić się do dyskusji, jeśli uzna to za niezbędne z racji swojej odpowiedzialności za skuteczność Zespołu Scrum i w ramach dbania o prawidłowe stosowanie Scruma. Czym innym jednakże jest punktowa interwencja, a czym innym stałe uczestnictwo lub zawłaszczanie Daily Scrumów przez Scrum Mastera na jego potrzeby. A tak właśnie stanie się, jeśli Scrum Master będzie stałym moderatorem.

Jeśli więc Scrum Master bywa obecny na Daily Scrumie, to po to, żeby upewnić się – nie przeszkadzając – że to, co tam się dzieje, to faktycznie Daily Scrumy. I reaguje wtedy, gdy dochodzi do wniosku, że jest to konieczne. Niekoniecznie w trakcie zdarzenia, częściej po jego zakończeniu.

Pewien wyjątek może stanowić sytuacja, gdy Zespół Scrum dopiero uczy się podstaw metody i nikt w jego składzie nie ma pojęcia, czym jest Daily Scrum. Wtedy to naturalne, że kilka razy Scrum Master poprowadzi to zdarzenie po to, by pokazać, jak można je realizować. Musi przy tym pamiętać, by nie narzucić tej formuły jako jedynej dopuszczalnej i zachęcić Developerów, by w przyszłości, jeśli będą mieli lepszy pomysł, organizowali Daily Scrumy inaczej.

Ciąg dalszy

W części czwartej kontynuuję wędrówkę przez scrumowe mity, tym razem powiązane z pracą w Sprincie, a więc Backlogiem Sprintu, sposobem monitorowania postępu prac nad osiąganiem Celu Sprintu, ale też Przyrostem i różnymi dziwnymi pomysłami na temat tego, kiedy powstaje, jak często i co nim może być.