Trudno zgadnąć: cieszyć się, czy trapić, ale nasz artykuł o syfie, który można usłyszeć – bądź wypowiedzieć – podczas zdarzeń scrumowych, spotkał się z dość ożywionymi reakcjami. A skoro ożywionymi, to ciśnie się na usta (a właściwie klawiaturę) pytanie: czy naprawdę jest tak źle? Cóż, z pewnością bywa. Głupio i demotywująco byłoby jednak poprzestać na utyskiwaniu, ewentualnie kpinach. Niniejszym inaugurujemy zatem mikro-serię Na miotle, w której zaproponujemy kilka przetestowanych w boju rozwiązań. Nie jesteśmy na tyle pyszni, by sądzić, że rozwiążą one każdą bolączkę, ale wobec patologii, które opisywaliśmy, gorzej to już raczej i tak być nie może.
W pierwszej odsłonie mierzymy się z wynaturzeniami spotykanymi podczas przeglądu sprintu. Dla przypomnienia, poniżej fragment wpisu Syf, który słyszysz podczas zdarzeń scrumowych. I mówisz. Lub milczysz w osłupieniu.
#1:
D: Będą dziś jacyś goście?
PO: Tak. Wysłałem zapro do PMa.
D: Tego nowego? Przecież znów będzie cisnął, a nie domknąłem historyjki z autentykacją.
PO: Dużo tam zostało do zrobienia?
D: Nie mam code review od architekta. Pojechał na konferencję do San Francisco i się nie loguje na Skypie.
PO: Mam pomysł!
D: No?
PO: Zrób w Jirze taska „obkodowanie autentykacji”, przesuń na „zrobione”, a na planowaniu weźmiemy „code review + testy”.
D: Trochę słabo…
PO: Czemu?
D: Lepiej podzielmy na dwa zadania: „code review”, a „testing” osobno.
PO: Genialne! I jeszcze scrum master się ucieszy.
#2
SM: O której zaczynamy dziś sprint review?
D: Nie robimy w tym tygodniu.
SM: Czemu?
D: Jira nie działa.
Gość w dom, Bóg w dom.
Zapraszaj – a ściślej: nakłaniaj Product Ownera do zapraszania – na przegląd kluczowych interesariuszy. Jeśli kluczowi interesariusze z jakiegoś powodu są niedostępni, na przykład mają nieprzyjemność stacjonować w chińskim Wuhan, spróbuj zachęcić ich przynajmniej do udziału za pomocą narzędzi zdalnej komunikacji. Jeśli i to nie wchodzi w grę, dołóż starań, by członkowie zespołu nie byli jedynymi uczestnikami przeglądu. Cała wartość tego wydarzenia sprowadza się ostatecznie do interakcji, więc jeśli nawet nie uda się zdybać sponsora produktu – z reguły nie jest to aż tak trudne, jak się często powtarza, ten człowiek ma przecież okazję pooglądać, na co wydaje swój hajs – to warto zainteresować przeglądem potencjalnego użytkownika. Bywa takowym chociażby kumpel z sąsiedniego zespołu. Albo portier. Bądź twoja ciocia.
JAK TO ZROBIĆ? Najprościej porozmawiać z Product Ownerem, by ustalić listę osób spoza zespołu, które powinny wziąć udział w wydarzeniu, a następnie zaprosić je z koniecznym wyprzedzeniem i poinformować, jak istotny dla przyszłego rozwoju produktu (przy okazji również dla morale zespołu) może być ich wkład. Nie zaszkodzi również ekspozycja informacji o dacie i miejscu najbliższego przeglądu, na przykład w lokalizacjach często odwiedzanych przez członków innych zespołów.
Zerwij na kilkadziesiąt minut stosunki dyplomatyczne z Jirą.
Daj sobie spokój z Jirą bądź jakimkolwiek innym narzędziem, w którym utrzymujecie backlog. Jeśli trzeba, proś administratorów Jiry – bądź jakiegokolwiek innego narzędzia, w którym utrzymujecie backlog – o symulowaną przerwę w dostawie usług. Zakładam, że każdy umiarkowanie przytomny zespół scrumowy śledzi zmiany w backlogu sprintu co najmniej raz dziennie, więc aktualizacja tego backlogu po raz szósty w sprincie – przy założeniu sprintu tygodniowego – na przeglądzie naprawdę nie zrobi nikomu różnicy. I nikogo na przegląd nie przyciągnie. Przecież jest powód, dla którego sprint review to okazja do inspekcji przyrostu, a nie obrazu prognozowanego przyrostu (czyli na przykład Jiry). Update narzędzia ma się do przeglądu produktu mniej więcej tak, jak czytanie listy dialogowej filmu do oglądania filmu.
JAK TO ZROBIĆ? Być może warto uwzględnić w planie sprintu proste zadanie, na przykład ograniczone timeboxem o długości nieprzekraczającej długości przeglądu sprintu, którego celem jest przygotowanie samego sprint review. A jednym z kryteriów akceptacyjnych takiego zadania byłoby: Hands off Jira, dudes & dudettes!
Pętla, pętla, pętla.
Nie, nie na szyi. No, chyba że twój przegląd sprintu zawsze wygląda tak, jak w dialogach przytoczonych powyżej. Wówczas jest to może jakaś perspektywa… Ale jeśli już uda się wam wyobrazić sprint review bez Jiry, a na dodatek sprowadzić jakichś gości, to zróbcie sobie przysługę i nie poprzestańcie na prezentacji przyrostu. Pokuście się jeszcze o dyskusję o tym przyroście, a nawet – mimo że procesowi w o wiele większym wymiarze poświęcona jest retrospektywa sprintu – o tym, jak przyrost powstawał (nie bez powodu Scrum Guide rekomenduje: Zespół Deweloperski omawia, co poszło dobrze w trakcie Sprintu, jakie napotkano problemy oraz jak te problemy rozwiązano). Co zwróciło uwagę interesariuszy w zaprezentowanym przyroście produktu? Co wzbudziło jego wątpliwości? Co im się spodobało? A co nie? Zacieśniajcie pętlę informacji zwrotnej tak bardzo, jak to tylko możliwe.
JAK TO ZROBIĆ? Choć może się to wydać nienaturalne, to dla zespołów, które nie przywykły jeszcze do otwartej dyskusji o produkcie na przeglądzie, warto przygotować listę pytań skierowanych i do interesariuszy, i do członków zespołu, które pobudzą dialog. Oto kilka przykładów:
- Które spośród oczekiwań klienta uchwyconych w planie kończącego się sprintu okazały się dla zespołu najłatwiejsze do realizacji?
- A które najtrudniejsze?
- Który spośród ukończonych elementów backlogu produktu przerósł oczekiwania interesariuszy?
- A który je zawiódł?
- Z realizacji którego elementu backlogu interesariusz by zrezygnował, gdyby mógł cofnąć czas?
- A w realizację którego zainwestowałby więcej?
Back to the future.
Jeśli dyskusja się już wyzwoli, to w dziewięciu na dziesięć przypadków zabrnie prędzej czy później na terytoria oczekiwań interesariuszy co do dalszego rozwoju produktu. Być może to najcenniejszy wkład, jaki można wynieść z przeglądu. Nie pozwól sobie na to, by go zmarnotrawić. Uchwyćcie perspektywy przyszłego rozwoju produktu w backlogu.
JAK TO ZROBIĆ? Backlog produktu to żywy artefakt. Nic nie stoi na przeszkodzie, by oczekiwania interesariuszy przekuć w jego nowe elementy. Może okazać się, że te nowe elementy będą wymagać pogłębionego refinementu, ale może zdarzyć się i tak, że wpłyną bezpośrednio na plan najbliższego sprintu. Nie mówiąc o tym, że interesariusz zyskuje dzięki takiej praktyce poczucie realnego wpływu na rozwój produktu, natomiast zespół – uwagę interesariuszy.
Patrz szerzej, aż do granicy zeza rozbieżnego.
Dyskusje w ramach przeglądu nie muszą, a właściwie nie powinny, kończyć się na prezentacji produktu i oczekiwaniach interesariuszy. Żaden produkt nie istnieje w próżni, dlatego zespół ma szansę pozyskać o wiele cenniejsze spektrum informacji, jeśli osadzi te dyskusje w szerszym kontekście rzeczywistości rynkowej.
JAK TO ZROBIĆ? Zanim tego rodzaju refleksja wejdzie w skład DNA zespołu, można przeznaczyć na nie jeden z punktów przygotowanej wcześniej agendy (powstanie takiej agendy może być natomiast jednym z kryteriów wspomnianego wcześniej zadania sprintowego polegającego na przygotowaniu review). Można również pokusić się o kilka pytań, które wystrzelą i zespół, i gości wydarzenia poza perspektywę tygodnia (lub dwóch, lub trzech, lub czterech). Na przykład:
- Jak data najbliższego wydania ma się do przyrostu kończącego się właśnie sprintu?
- Jak podobne rozwiązania produkuje nasza konkurencja?
- Czy ostatni przyrost dał nam punkty mocy w dziedzinie przewagi konkurencyjnej?
- Kiedy ten produkt ma szansę być gotowym?
- Czy najnowszy przyrost otworzył nam drogę do zastosowania produktu, którego wcześniej nie przewidzieliśmy?
- Czy najnowszy przyrost zamknął nam drogę do któregokolwiek z zastosowań produktu, które rozważaliśmy w przeszłości?
- Czy najnowszy przyrost sprawia, że nadarzają się nam jakieś okazje rynkowe?
Nie wszystko krawat, co się świeci.
Przegląd sprintu to spotkanie nieformalne, a nie statusowe. Agenda? Tak, czemu nie, jeśli tylko pozwoli nam utrzymać timebox i usprawnić przebieg wydarzenia. Lista pytań, o które można się pokusić? Pewnie, lepsze to niż niezręczna cisza. Godzina w sprincie poświęcona na przygotowanie samego przeglądu? Ćwiczenie czyni mistrza. Ale to nie znaczy, że musimy odbywać przegląd – jak daily scrum – zawsze w tym samym miejscu i w tej samej formie.
JAK TO ZROBIĆ? Uruchomić fantazję. Jeśli produkt powstaje z komponentów rozwijanych przez dostawców spoza zespołu, może warto spotkać się przy okazji sprint review również w siedzibie takiego dostawcy? Może warto różnicować listę zapraszanych gości spoza zestawu obligatoryjnych uczestników? Może zorganizować głosowanie na najwartościowszy zdaniem uczestników spoza zespołu element backlogu ukończony w sprincie? Może – w razie zastosowanie któregoś z tych wariantów, bądź jakiegokolwiek innego – na gorąco zebrać feedback od uczestników?
A jak Wy dążycie do podniesienia jakości przeglądów sprintów? Zlokalizowaliście rozwiązania, które przyniosły wymierne skutki, wpływając na efektywność i jakość wydarzenia? Każda sugestia będzie na wagę złota.
Obraz: Kevin Phillips z Pixabay + Enrique Meseguer z Pixabay