Siedzisz na demo… Ze szkolenia scrumowego pamiętasz, że powinno ono trwać maksymalnie cztery godziny. Masz wielką nadzieje, że i tym razem Scrum Master odpuści wszystkim i jak zazwyczaj będzie krócej. W sumie siedzisz spokojnie. Czekasz na rozpoczęcie i zwyczajowe „witam wszystkich zgromadzonych”. Twoją uwagę przykuwa nowy element. Paprotki na stole konferencyjnym. Jak i kiedy się tu znalazły?! Dziwne. Siedzisz w kącie i wiesz, że nic nie może Ciebie zaskoczyć. Od czterech lat demo zawsze wygląda tak samo. Tym razem też z pewnością tak będzie. Product Owner 15 minut temu dostał od Ciebie info na Slacku, gdzie lepiej nie klikać. No chyba, że chce, żeby klient się dowiedział. Jego wybór. Nie ma obawy, że klient o coś zapyta. Nasza taktyka, żeby zanudzić go na śmierć, nigdy nie zawiodła! Nieprzypadkowo nasze demo jest nazywane przez wszystkich „Śmierć w Wenecji”. Fajna ta nazwa… Czy są jeszcze zespoły, w których tak właśnie wygląda Sprint Review? Dalej będzie o tym jak tego uniknąć…
Hasło: współpraca
Czym jest Sprint Review? Zgodnie z tym, co jest zapisane w Scrum Guide powinno to być nieformalnym spotkaniem. W jego trakcie, Zespół Scrumowy oraz kluczowi stakeholderzy współpracują i zastanawiają się co zrobić, aby użytkownik otrzymał jak największą wartość. Czy nieformalność oznacza brak paprotek i krawatów na spotkaniu? Niekoniecznie. Bardziej chodzi tutaj o to, aby każdy kto chce zabrać głos w dyskusji nad produktem, nie czuł oporów, żeby to zrobić. Jeżeli jest sztywno i głos ma tylko „przewodniczący” to ciężko o spontaniczne wypowiedzi. Niby oczywiste.
Stereotyp: protokół zdawczo–odbiorczy
Co w przypadku jeśli Sprint Review zostanie zredukowane tylko do demo? Jest to nic innego jak implementacja starodawnej techniki, jaką jest protokół zdawczo-odbiorczy. Podobno po raz pierwszy technikę tę zastosowano podczas budowy piramid w Egipcie. A tak zupełnie serio, to redukując spotkanie do demo, przekraczamy cienką czerwoną linię i świadomie lub nieświadomie znajdujemy się nagle po prawej stronie Manifestu Agile. A konkretnie prawej stronie jego trzeciego punktu. A jak wynika z dalszej lektury manifestu – kto chce być „agile”, ten powinien sobie cenić bardziej lewą stronę manifestu.
Redukcja do demo niesie ze sobą wiele nieoczywistych i negatywnych konsekwencji. Nie każdy zdaje sobie z tego sprawę. Demo jest zazwyczaj przejawem niskiego poziomu transparentności w organizacji. Przekłada się to w oczywisty sposób na jakość. Jakość kodu oraz skuteczność podejmowanych decyzji biznesowych. Demo podczas, którego klient „odbiera” oprogramowanie oznacza, że najprawdopodobniej działamy we wrogim środowisku. Rywalizujemy zamiast współpracować. Prowadzenie demo zamiast Sprint Review jest również przyczynkiem do niskiego morale i spadku motywacji pracowników.
Product Owner
W kwestii przebiegu i rezultatów Sprint Review dużo zależy od Product Ownera. Oczywiście Scrum Master i Zespół Deweloperski go wspierają. Product Owner jest osobą, która powinna zidentyfikować kluczowych interesariuszy i zaprosić ich na spotkanie. Od tego, kto przyjdzie na spotkanie, zależy jakość uzyskanej informacji zwrotnej. Nie zawsze musi to być ten sam stały skład osób. Wysyłając interesariuszom informację, jaki zakres będzie prezentowany i dyskutowany na Sprint Review, pozwalamy im dać feedback przy pomocy „dwóch stóp”.
Im bardziej Product Owner chce, aby demo było Sprint Review, tym więcej powinien współpracować z Zespołem Deweloperskim w czasie Sprintu. Powinien być na bieżąco informowany przez zespół na temat postępów prac. Dobrą praktyką, którą obserwowałem w wielu zespołach jest pokazanie skończonej funkcjonalności Product Ownerowi zanim zostanie ona uznana za done-done. Dzięki temu, możliwe są ewentualne poprawki jeszcze w aktualnym Sprincie. Nie jest niczym wyjątkowym, że w momencie, kiedy zobaczymy działającą funkcjonalność to przychodzą nam do głowy nowe pomysły. Właściwie po to też robimy Scrum.
Jeżeli Product Owner jest na bieżąco z uzyskanymi rezultatami Sprintu to oczywiście potrafi o nich opowiedzieć uczestnikom spotkania. Co jest przeciwieństwem sytuacji, w której to on się dowiaduje, co zostało ukończone. Kolejnym krokiem podnoszącym Sprint Review na wyższy poziom jest prezentowanie i dyskusja nad dalszym rozwojem produktu w oparciu o dane i fakty. Prezentowanie metryk w połączeniu z prezentowaniem funkcjonalności, które zostały dostarczone klientom bardzo uruchamia dialog na spotkaniu. Wtedy zaczyna być prawdziwie i naprawdę ciekawie.
Zespół Scrumowy
Obecność Zespołu Deweloperskiego jest niezbędna na Sprint Review. Skrócenie przepływu informacji pomiędzy deweloperami, a użytkownikami oraz interesariuszami zawsze pozytywnie wpływa na pracę w Sprincie. Deweloperzy mając dostęp do interesariuszy mogą uzyskać od nich pomoc w kwestiach utrudniających pracę nad produktem. Sprint Review korzystnie wpływa też na morale w zespole. Nic tak nie motywuje, jak możliwość zobaczenia na własne oczy, jak ktoś inny korzysta z naszego produktu. Przestajemy pisać software do przysłowiowej „szuflady”, a zaczynamy go pokazywać potencjalnym użytkownikom. Podmiotowość nas samych i naszej pracy rośnie. Jeżeli do tego, jako deweloperzy, zostaniemy zaproszeni do współdecydowania o produkcie, to jesteśmy na najlepszej drodze do wyciągnięcia maksa ze Sprint Review!
Interesariusze
Jak napisałem wcześniej, interesariusze (ang. steakholders) powinni zostać zidentyfikowani i zaproszeni przez Product Ownera. Może on oczywiście poprosić zespół o pomoc. Raz w swojej karierze zrobiłem z zespołem warsztat, w czasie którego zidentyfikowaliśmy wszystkich (no niemalże wszystkich) interesariuszy i pogrupowaliśmy przy pomocy macierzy RACI. Dzięki temu, Product Owner wiedział kogo, w zależności od realizowanego zakresu, ma zapraszać.
Bardzo ważną rzeczą na Sprint Review jest język jakim posługują się interesariusze. Powinniśmy oczywiście się do nich dopasować. Mówić ich językiem. Niby kolejna oczywistość, a jednak.
Pamiętam Sprint Review w jednej z firm, której pomagałem poradzić sobie ze Scrumem. Na spotkanie przyszło ok. 40-50 osób. Byli to głównie pracownicy biurowi korzystający z aplikacji. Programiści, prezentując działanie aplikacji, używali języka żargonowego. Pomimo tego, że przez blisko 8 lat byłem programistą, słuchanie prezentacji sprawiało mi sporą trudność. W pewnym momencie programista prowadzący spotkanie mówi: „a teraz przejdę do zaprezentowania bardzo ciekawego rozwiązania, które zastosowaliśmy i teraz będzie technicznie…”. Na twarzach zgromadzony osób zaczął malować się grymas bólu i znaki zapytania wołające o pomoc…
Język, który wszyscy rozumieją to kwestia transparentności na spotkaniu. Mówiąc do ludzi językiem technicznym minimalizujemy szansę na otrzymanie feedbacku. Mało kto zaryzykuje wyjście na „idiotę”, bo źle nie zrozumiał albo zadał banalne pytanie. Do użytkowników trzeba mówić ich językiem. Inaczej „Śmierć w Wenecji”.
Przebieg spotkania
Scrum Guide daje nam gotowy szablon agendy na Sprint Review. Praktyka pokazuje jednak, że nie każdy zespół jest w stanie taki Sprint Review przygotować. A szkoda. Szczególnie rzadko można zaobserwować zespoły, które w praktyce realizują trzy ostatnie punkty. Jak zawsze oznacza to, że jest pole do dalszego rozwoju. Nie będę się tutaj szczególnie mocno rozpisywał, bo punkty są dość jasne. Ważne, żeby pamiętać, że stanowią one niejako osnowę spotkania. I tak jak w przypadku trzech zaklętych pytań na Daily Scrum, lepiej jest jeśli zespół stworzy własną agendę inspirując się tym, co w Scrum Guide. Pamiętamy, że w złożonym środowisku od tego co zrobimy, ważniejsze jest, jak to zrobimy.
Co i jak pokazywać
Powinniśmy przede wszystkim pokazywać działający software, który jest done-done. Nie pokazujmy JIRY albo innego narzędzia. Chodzi o software. Powinniśmy tak prezentować, aby wywołać dyskusję. Dobrym patentem jest pokazywanie zmiany w aplikacji. Możemy na przykład na dwóch komputerach uruchomić poprzednią i aktualną wersję. Pokazując funkcjonalności opowiadamy przy tym, jak apka wyglądała „before” i jak wygląda „after”. Dobrym pomysłem jest oddać kontrolę nad myszką uczestnikom spotkania. Jeżeli użytkownik sam doświadczy naszego rozwiązania to jest to warte więcej, niż 1000 słów. Szczególnie tych technicznych. Taka prezentacja to jest wyższy level zarezerwowany dla zespołów, które przestrzegają Definicji Ukończenia. Poziom hard to pokazywanie działającego Przyrostu (ang. Inkrement) na produkcji.
Produkt spotkania
W efekcie w Sprint Review powinno stać się kilka rzeczy. Adaptacji powinien ulec Product Backlog. Zmiana elementów backlogu jest efektem dyskusji wszystkich uczestników i dowodem na podjęcie decyzji o dalszych losach produktu. Po spotkaniu Zespół Scrumowy powinien znać prawdopodobny zakres nadchodzącego Sprintu. Zmiana elementów backlogu oznacza, że wszyscy upewnili się co do aktualności i ważności jego elementów, być może odkryte zostały nowe możliwości.
W czasie spotkania powinna zostać podjęta decyzja czy produkt jest już wystarczająco dobrym, żeby pokazać go użytkownikowi końcowemu. Oprócz decyzji o releasie na produkcję, może zostać podjęta decyzja o zakończeniu rozwoju produktu. Product Owner razem z interesariuszami mogą dojść do wniosku, że przyszłe funkcjonalności nie dadzą już oczekiwanego zwrotu z inwestycji.
Podsumowanie
Dobre Sprint Review nigdy nie jest dziełem przypadku i nie przychodzi łatwo, a już na pewno nie z dnia na dzień. Wymaga przygotowania oraz wzrostu poziomu transparentności w organizacji. Jest to duże pole dla pracy Scrum Mastera. Choć nie jest on pierwszoplanowym aktorem tego zdarzenia scrumowego, to ma istotną rolę do odegrania. Spotkanie to jest skarbnicą wiedzy na temat dysfunkcji panujących w zespole oraz w organizacji. Zatem pamiętaj! Jeżeli zamiast entuzjazmu czujesz emocje jak przy oglądaniu filmu o facecie w łódce to wiedz, że coś jest nie tak…