W poprzednim artykule pisałam o tym, jak można pracować z Zespołem, aby zwiększać jego motywację. Dzisiaj skoncentruję się na tym, jaki jest sens Przeglądu Sprintu (Review), aby w kolejnym móc opisać, jak działania Właściciela Produktu i Scrum Mastera w kontekście Review mogą zwiększać zaangażowanie Zespołu.
Scrum jest frameworkiem umożliwiającym odkrywanie produktu w pewnych usystematyzowanych ramach. Zdarzenia scrumowe zostały tak wypracowane, żeby ułatwić współpracę i przekazywanie informacji w optymalny (pod względem poświęcanego czasu) sposób. Patrząc z tej perspektywy, celem Przeglądu Sprintu jest zdobywanie wiedzy o produkcie i najlepszych możliwościach jego rozwoju. Kto w takim razie i czego się dowiaduje?
- Klient oraz osoby zainteresowane produktem (zwane w skrócie interesariuszami) – jak działa dotychczas wytworzony Przyrost
- Zespół Scrumowy – jaki jest feedback do stworzonego Przyrostu
- Wszyscy (od siebie nawzajem) – jak wygląda i jak zmieniło się otoczenie produktu
- Wszyscy – jakie są obecne priorytety oraz bardziej długofalowe plany.
W swoich badaniach chciałam sprawdzić, na ile osoby pracujące w Scrumie rozumieją to zdarzenie. Pytałam uczestników o to, co jest, według nich, największą korzyścią z Przeglądu Sprintu. Pytanie było otwarte, więc udzielane odpowiedzi były opisowe. Aby móc ich użyć do dalszych obliczeń (będą w następnym artykule), uporządkowałam je na poniższej skali. Chciałam, żeby oddawała ona korzyści, jakie można osiągnąć z Przeglądu Sprintu, w kolejności od najmniejszych do największych. Oceny przypisywałam w ten sposób, że jeżeli ktoś opisał korzyści z kilku różnych poziomów, to przyporządkowywałam mu maksymalny wymieniony przez niego poziom.
| Skala | Słowa kluczowe używane przez badanych |
|---|---|
| 0 – Brak możliwości przypisania odpowiedzi | Brak odpowiedzi lub odpowiedź niezrozumiała typu „asdfgh”. Były uznane za braki danych i nie miały wpływu na wyniki. Dla Review było osiem takich odpowiedzi. |
| 1 – Brak korzyści | |
| 2 – Odbiór prac Zespół pokazuje Właścicielowi Produktu wyniki swojej pracy, które są następnie przez niego albo przez nią oceniane. |
Wykazanie PO, że cele sprintu zostały osiągnięte, ocena wykonania kontraktu pomiędzy zespołem a PO |
| 3 – Zobaczenie, co zrobiliśmy Możliwość zobaczenia przez wszystkich członków Zespołu Deweloperskiego, co zrobili w czasie Sprintu. |
Mogę zobaczyć co zrobili inni |
| 4 – Zobaczenie, co zrobiły inne zespoły Jeśli nad rozwojem produktu pracuje więcej niż jeden zespół to Przegląd Sprintu może służyć uzyskaniu informacji co robią pozostałe zespoły. |
Wiedza co robią inne zespoły |
| 5 – Pokazanie, co zostało zrobione interesariuszom Ten rodzaj Przeglądu Sprintu nazywany jest “demo”. Polega na zaprezentowaniu m.in. biznesowi albo przedstawicielom klienta, co zostało zrobione. |
Interesariusze, biznes Pokazanie, przekazanie, prezentacja |
| 6 – Uzyskanie feedbacku od interesariuszy W tym wypadku Zespół otrzymuje również informację zwrotną od osób zaangażowanych w rozwój produktu. |
Interesariusze, biznes Od poprzedniego poziomu różniło go użycie takich zwrotów jak: feedback, informacja zwrotna, uwagi klienta, reakcja klienta |
|
7 – Aktualizacja planu rozwoju produktu Omawiany jest dalszy plan rozwoju produktu |
Plan, co będzie realizowane, dalszy rozwój, cele na kolejne sprinty |
Po uporządkowaniu odpowiedzi na skali, sprawdziłam, jak często każda z nich była udzielana. Poniżej wykres, który to prezentuje.
Oczywiście ten wykres mówi głównie o badanych Zespołach i wskazuje na konkretne obszary do pracy. Dlatego popatrzmy na rozkład odpowiedzi w Zespołach. Gruba kreska oznacza średnią, górny wąs wskazuje maksymalną odpowiedź udzieloną w zespole, dolny – minimalną (dla tych, co są bardziej zaznajomieni ze statystyką odchylenie standardowe wynosiło odpowiednio: 0,71; 0,89; 1,67; 0,53; 1,56; 0,89; 0,58; 1,13; 0,49; 0,79; 1,72; 0,79 patrząc od lewej strony).
Dla mnie ponownie interesujące było to, że wiedza na temat sensu zdarzeń scrumowych nie jest współdzielona w zespołach. Nie było zespołu, w którym wszystkie odpowiedzi byłyby na poziomie 6 lub więcej. Stąd też pierwszy wniosek jest taki, że (podobnie jak przy Daily) –
Drugi wniosek jest jeszcze ciekawszy – nie ma powiązania pomiędzy tym, na ile Zespoły dobrze rozumiały Daily i Review. Pierwotnie sądziłam, że tak duży rozrzut odpowiedzi może być wynikiem tego, że w niektórych zespołach są osoby gorzej znające Scruma, które odstają od reszty zespołu. Nie potwierdziło się to, bo jeden Zespół lepiej rozumiał sens Przeglądu Sprintu, a inny Daily. Nie było czegoś takiego, jak ogólna wiedza Zespołu na temat Scruma, tylko pewne elementy były rozumiane lepiej, a pewne gorzej w każdym zespole.
Być może właśnie to jest czynnikiem utrudniającym rozwój Zespołów – nie wystarczy ogólnie uczyć o Scrumie. Każde ze zdarzeń musi być wyjaśniane osobno, tak, aby wszyscy członkowie Zespołu rozumieli jego wartość. Następnie należy z Zespołem po kolei je udoskonalać, aby Zespół osiągnał z nich maksymalne korzyści. Jest to trudne, bo zrobienie wartościowego Przeglądu Sprintu wymaga poprawienia wszystkiego, zaczynając od Pielęgnacji Backlogu, poprzez Planowanie po sam przebieg Sprintu.
Jak więc to robić? Zacząć od tego, co Zespołowi jest najbardziej potrzebne, a następnie pokazywać, co trzeba ulepszyć, żeby to osiągnąć. Przy takim modelu pracy z Zespołem inicjatywa jest po ich stronie i to im zależy na wprowadzeniu zmian. Ponieważ feedback do wykonanej pracy jest jedną z ważniejszych potrzeb, Przegląd Sprintu jest czymś, na czym zależy Zespołom. Bardzo dobrze pokazuje to wypowiedź jednego z badanych deweloperów: “W naszych realiach [Przegląd Sprintu] nie przynosi prawie żadnej wartości, co jest przykre. Gdybyśmy robili to dobrze to pewnie byłby to feedback od użytkowników.”
Jednak zanim coś zaczniemy zmieniać w sposobie pracy Zespołu, należy zrozumieć, jakie korzyści obecnie im to daje.
Na potrzeby można patrzeć bardzo szeroko, w tym artykule zdecydowałam się na perspektywę informacji albo nawet szerzej – wiedzy, jaka jest niezbędna Zespołowi do pracy. Osoby, które czytały poprzedni artykuł mogą to rozumieć jako potrzebę kompetencji.
Zależało mi na tym, żeby sprawdzić, czy Przegląd Sprintu jest odpowiednim czasem na zdobywanie tej wiedzy, czy można znaleźć na to lepszy moment. Przeanalizuję pod tym względem kolejne poziomy dojrzałości Przeglądu Sprintu.
2 – Właściciel Produktu podejmuje decyzję, czy “odbierze” dany element czy nie.
Dlaczego Zespół może czerpać korzyść z takiego Przeglądu Sprintu? W sytuacji, kiedy Właściciel Produktu jest proxy pomiędzy Zespołem a światem, może to być jedyny sposób, żeby dowiedzieli się, czy to, co zrobili w czasie Sprintu, jest w porządku.
Jak można w inny sposób zapewnić, że Zespół będzie pewien, że zrobił to, co trzeba? Zaczynając od samego początku – to Zespół Deweloperski powinien rozumieć, jak dana rzecz ma działać. W czasie Refinementu, podczas pisania historyjek (jeśli są stosowane) i dopracowywania Kryteriów Akceptacji, Zespół Deweloperski musi zrozumieć jaka jest potrzeba klienta, jak może ją zaspokoić i w jaki sposób sprawdzi, że mu się to udało. To oznacza duuużo rozmowy, trochę pisania (żeby informacje gdzieś nie umknęły) oraz (jeśli tylko jest to możliwe) kontakt z osobami dla których dana funkcja jest robiona, żeby uzgodnić szczegóły.
Może się zdarzyć, że nie jest do końca jasne, jak coś ma działać albo wyglądać, ale wtedy
Potrzebna jest również dobra Definicja Ukończenia (Definition of Done, DoD), która zapewnia jednolity zakres wykonanych prac i wymaganą jakość. Dzięki niej, Zespół Scrumowy (czyli również Właściciel Produktu) ma pewność, że “zrobione” oznacza, że wszystkie potrzebne prace zostały wykonane i zakończone sukcesem.
Jaka jest konsekwencja takiego Przegląd Sprintu jak opisany na początku tego punktu? Zespół Deweloperski dostaje o wiele za późno potrzebną mu informację. Tak późno, że nie jest w stanie jej wykorzystać do dobrego wykonania Przyrostu. Szansę na poprawienie czegoś będzie miał dopiero w następnym Sprincie. Poza tym nie zdobywa wiedzy biznesowej oraz nie otrzymuje feedbacku od klienta, więc nie jest w stanie zweryfikować koncepcji swoich i Właściciela Produktu.
3 – Zobaczenie przez wszystkich członków Zespołu, co sumarycznie zostało zrobione w czasie Sprintu.
Skąd się bierze takie Review? Zespół często nie zna przygotowanych przez siebie rozwiązań. Nie chodzi mi tutaj o silosy kompetencyjne, raczej o sytuację, że nie wszyscy Deweloperzy biorą udział w pracach nad każdym zadaniem. (Jak zwykle przez Dewelopera rozumiem każdego członka Zespołu innego niż Scrum Master i Właściciel Produktu.)
Jest to dosyć naturalne. W czasie Sprintu część informacji o przyjętych rozwiązaniach jest przekazywana w obrębie Zespołu, kiedy Deweloperzy robią review kodu albo testują. Część – w czasie Daily, ale wtedy koncentrują się na planowaniu i podziale pracy, a nie na kwestiach czysto technicznych. Dyskusja o szczegółach odbywa się zazwyczaj tylko w gronie zainteresowanych osób. Najczęściej dzielenie się wiedzą odbywa się w sposób nieformalny, na kawie czy w czasie lunchu, ale wtedy również nie wszyscy muszą być obecni.
Biorąc to pod uwagę, potrzeba Zespołu, żeby poznać wytworzony przez siebie Przyrost, jest jak najbardziej uzasadniona. Jednym z ważniejszych efektów Sprintu jest zwiększenie się wiedzy Zespołu dotyczące kwestii technicznych albo domenowych.
Jakie są konsekwencje Przeglądu Sprintu polegającego na pokazywaniu przez Zespół, co technicznie wytworzył? Trudno na niego zaprosić osoby z biznesu albo przedstawicieli klienta, ponieważ przekazywane informacje są najczęściej zbyt szczegółowe i techniczne, aby mogły zainteresować kogoś spoza Zespołu. Drogą do bliższej współpracy z interesariuszami jest bardziej biznesowe, skoncentrowane na potrzebach klienta Review.
4 – Możliwość zobaczenia przez Zespół, co zrobiły inne Zespoły.
Takie Review daje dużo korzyści, jeśli nad rozwojem produktu pracuje więcej niż jeden zespół. Pozwala budować ogólne zrozumienie, jak cały produkt działa oraz jak będzie się rozwijał w najbliższym czasie.
Pamiętajmy tylko o tym, że informacje o wpływie swoich zadań na inne zespoły (i odwrotnie) Zespół powinien mieć dużo wcześniej. Żeby coś zintegrować pomiędzy Zespołami trzeba najpierw ustalić, jak to ma działać. Żeby sprawdzić, czy działa, trzeba najpierw zaplanować, a potem przygotować i przeprowadzić testy. Są to informacje, jakie Zespół powinien mieć przed wejściem w Sprint. W Sprincie przy występujących zależnościach pomiędzy Zespołami, konieczne jest ciągłe sprawdzanie czy całość danej funkcji (albo procesu biznesowego) działa poprawnie, a więc Ciągła Integracja (Continuous Integration) oraz wspólne testy. Tylko pod takim warunkiem na koniec Sprintu Zespół może powiedzieć, że coś naprawdę działa i to tak, jak zakładano.
Problemem może być sytuacja, kiedy brakuje na takich Przeglądach Sprintu przedstawicieli klienta i osób z Biznesu. Wtedy może przyjąć ono formę technicznych ustaleń, a więc pozbawi Zespół bardzo wartościowej informacji jaką jest feedback i wiedza biznesowa.
5 – Pokazanie, co zostało zrobione interesariuszom.
Jest to statusowe spotkanie, nie pozwalające na otrzymanie przez Zespół feedbacku ani na uzyskanie przez Właściciela Produktu cennych informacji. Przy takim Przeglądzie Sprintu pojawia się pokusa malowania trawy na zielono i pokazywania elementów, które nie są ukończone, bo jego celem często jest wykazanie, że Zespół “realizuje projekt zgodnie z planem”.
Dlaczego “Demo” może mieć wartość dla Zespołu? Ludzie generalnie chcą być dumni z tego, co robią i chcą, żeby ich praca była doceniana. Dlatego samo zaprezentowanie, co zrobili, jest dla Zespołu cenne, bo mogą pokazać wynik swojej pracy. Bardziej ten temat będę rozwijała w następnym artykule, teraz zależy mi na tym, żeby podkreślić, jak bardzo istotną kwestią jest zauważanie i docenianie pracy wykonanej przez Zespół.
Nie jest to jedyna korzyść, jaką zespół może mieć z takiego Review. Pisałam wcześniej o zdobywaniu wiedzy technicznej, o zastosowanych rozwiązaniach, przez Zespół. Jest jeszcze kwestia perspektywy biznesowej. Większość członków Zespołu zagrzebana jest przez Sprint w robieniu konkretnych zadań. Mają, owszem, czas na popatrzenie na cel biznesowy Sprintu podczas każdego Daily, ale i tak raczej spostrzegają go przez pryzmat pracy, jaką mają jeszcze do wykonania. Przygotowanie Review, zastanowienie się
Inną kwestią jest wartość biznesowa niektórych prac. Spłacanie długu technicznego, refactoring, tworzenie dodatkowych testów to wszystko rzeczy, które nie są “widzimisię” Zespołu Deweloperskiego, ale przynoszą wymierne korzyści biznesowe. O ile Właściciel Produktu powinien być świadomy ich wartości, o tyle może to być zupełnie niezrozumiałe dla interesariuszy.
Najczęściej zebranie takich danych nie jest banalne i przygotowanie ich wymaga pewnego czasu. Można tego nie pokazywać, tylko wyjaśnić na Review dlaczego to jest wartościowe, jednak klient i osoby z biznesu dużo łatwiej zrozumieją ważność technicznych zagadnień, kiedy będzie ona przełożona na język wymiernych korzyści biznesowych opartych na twardych danych.
“Demo” może mieć miejsce w dwóch sytuacjach. Pierwsza, to pseudowspółpraca z klientem, malowanie trawy na zielono i tworzenie pozorów. Jest to bardzo złe i nie chcę w tym artykule omawiać takich dysfunkcji. Drugi przypadek dotyczy sytuacji, kiedy brak jest bliskiej współpracy pomiędzy biznesem, klientem i Zespołem z uwagi na brak zaangażowania biznesu. Wtedy może to być maksymalny poziom dojrzałości Review, jaki może osiągnąć Zespół Deweloperski. Dalszy rozwój wymaga intensywnej pracy Właściciela Produktu i Scrum Mastera. Pracy polegającej nie tylko na przygotowaniu samego Przeglądu Sprintu, ale również wyjaśnieniu interesariuszom jak mogą, w wartościowy sposób, współpracować z Zespołem.
Jakie są konsekwencje takiego Przeglądu Sprintu? Brak jest nadal weryfikacji pracy Zespołu Scrumowego (w tym założeń Właściciela Produktu) oraz wspólnego wypracowywania najbardziej wartościowego podejścia do rozwoju produktu.
6 – Uzyskanie feedbacku od interesariuszy.
Wreszcie dotarliśmy do prawdziwego Review. Aby było możliwe uzyskanie wartościowego feedbacku, Właściciel Produktu musi się odpowiednio do tego spotkania przygotować (pomijam już kwestie zaproszenia właściwych osób). Warto, żeby przedstawił na początku Review informację o tym, jaki był stan wiedzy na poprzednim Przeglądzie Sprintu i dlaczego takie, a nie inne rzeczy zostały uznane za najbardziej wartościowe do zrobienia. Takie podejście pozwala budować kulturę ciągłego uczenia się, czyli podejmowania najlepszej możliwej decyzji w świetle posiadanej wiedzy. Oczywiście, część z tych decyzji będzie się okazywała nietrafiona, ale chodzi o świadomość, że gdybyśmy jeszcze raz znaleźli się w tamtej sytuacji, to zadecydowalibyśmy tak samo, bo wydawało się to najlepszym rozwiązaniem.
Po tym powinna następować prezentacja ukończonych funkcji, najlepiej w formie jak najbardziej fizycznej.
Przekazanie informacji o tym, co zostało zrobione, a co nie, pozwala budować zaufanie, że klient zna rzeczywisty postęp prac. Powiedzenie, co poszło dobrze, jakie napotkano problemy i jak je rozwiązano, umożliwia wypracowanie wspólnego zrozumienia trudności, jakie są związane z wytwarzaniem produktu. Jednocześnie pozwala to uzyskać od interesariuszy wartościowe informacje o tym, jak można dany problem rozwiązać, albo nawet zaangażować ich w rozwiązywanie niektórych z nich.
Warto też, żeby
Podsumowując – w czasie takiego Review
Czego tutaj brakuje? Czy są jakieś negatywne konsekwencje? Takie Review jest skoncentrowane na przeszłości i teraźniejszości. Aby było w pełni wartościowe warto też spojrzeć w przyszłość i wspólnie wypracować najlepszy sposób rozwijania produktu.
7 – Aktualizacja planu rozwoju produktu.
Review to czas na zaprezentowanie przez Właściciela Produktu aktualnego Backlogu i poinformowanie o tym, jakie są prognozy dotyczące dostarczenia następnych funkcji oraz ogólnie, jaki jest plan rozwoju produktu.
Warto w tym miejscu powiedzieć o wszystkich twardych ograniczeniach (takich jak budżet, kwestie prawne lub ustalone terminy), aby wszyscy mieli podobne dane przed dalszą dyskusją. Często pozwala to też uzyskać nowe informacje, nieznane do tej pory Zespołowi, a dostarczane przez interesariuszy. Z punktu widzenia Zespołu jest to niezwykle wartościowa wiedza pozwalająca im podejmować przemyślane, świadome decyzje o sposobie rozwijania produktu. Znając długofalowy plan rozwoju wiedzą, jakie zmiany będą wprowadzali w przyszłości i mogą wybierać optymalne, z tego punktu widzenia, rozwiązania.
Jeśli Właściciel Produktu zaniedba ten punkt Przeglądu Sprintu, to i tak będzie musiał to Zespołowi powtórzyć, bo są to niezbędne dla nich informacje. Za to siebie pozbawi w ten sposób możliwości uzyskania informacji od interesariuszy, przez co może czegoś ważnego nie zweryfikować.
Informacje, jakie Zespół może uzyskać w tym przypadku pochodzą od Właściciela Produktu i od interesariuszy. Wszyscy budują wspólne zrozumienie sytuacji rynkowej produktu, ryzyk, zagrożeń i ograniczeń (ale też szans i okazji), jakie wpływają na jego rozwój. Dzięki temu
Zespół ma szansę usłyszeć bezpośrednio od osób zainteresowanych, dlaczego dana funkcja jest dla nich ważna, jaki mają bez niej problem i jak ona wpłynie na nich, jak zostanie dostarczona. Często dzięki temu
Ten najwyższy poziom dojrzałości Przeglądu Sprintu pozwala Zespołowi współpracować blisko z klientem, rozumieć jego potrzeby, kontekst biznesowy oraz ważność wykonywanej przez siebie pracy. Tutaj już niczego nie brakuje, wszystkie potrzebne informacje są przekazane osobom, które ich potrzebują.
Podsumowując – wszystkie informacje wymienione powyżej, na kolejnych poziomach, są Zespołowi potrzebne, jednak wiele z nich powinno zostać przekazanych wcześniej, w czasie Refinementu albo Sprintu. Należy ostrożnie podchodzić do wytykania Zespołowi błędów w Review, bo najczęściej są one konsekwencją ogólnie słabo funkcjonującego procesu. Aby Przegląd Sprintu poprawił się, trzeba ulepszyć poprzednie elementy – Refinement, Planowanie i sam sposób pracy i komunikacji w czasie Sprintu.
Pomysł na doskonalanie Przeglądu Sprintu (ćwiczenie na Retrospektywę)
Cel ćwiczenia:
- Zbudowanie wspólnego zrozumienia, jakie są korzyści z Review
- Ustalenie, czego Zespołowi brakuje w obecnym Przeglądzie Sprintu
- Zaplanowanie, jak Zespół będzie wprowadzał zmiany w Review
Co będzie potrzebne?
- Tyle kopii tego artykułu, ile jest osób w Zespole
- Sticky notes i coś do pisania dla każdego
- Tablica lub flipchart i mazaki
Sposób wykonania:
Tym razem proponuję innego typu ćwiczenie. Na początek dajmy każdemu członkowi Zespołu do przeczytania ten artykuł. W trakcie czytania każdy wypisuje na karteczkach te elementy, które jego zdaniem są najważniejsze, które chciałby, żeby zaistniały na ich Przeglądzie Sprintu. Na jednej karteczce powinien być jeden element.
Następnie, jak już wszyscy skończą, należy przykleić karteczki na tablicy i uporządkować je tak, aby powtarzające się elementy zgrupowane były razem. W efekcie powinniśmy dostać listę rzeczy, których Zespół potrzebuje. Zaczynając od najliczniejszych grup, całym Zespołem omawiamy, co trzeba zrobić, aby opisane w nich elementy mogły zaistnieć w czasie Przeglądu Sprintu. Konkretne pomysły, jak Zespół chce zmodyfikować swoją pracę zapisujemy na tablicy.
Następnie Zespół tworzy z tego plan wprowadzania zmian. Najlepiej go zrobić w ten sposób, żeby na pierwszy Sprint wziąć rzeczy, które nie wymagają dużego nakładu pracy, a dają szybki efekt (tak zwane quick wins). Na następne Sprinty należy zaplanować rzeczy, które wymagają poprawy od samego początku procesu, czyli najczęściej od Refinementu oraz jedną lub dwie modyfikacje samego Review. Dobrze jest określić, jaką poprawę chcemy w konkretnym Sprincie osiągnąć.
W ten sposób, na koniec ćwiczenia mamy plan zmian, jakie Zespół chce wprowadzić w sposobie swojej pracy w kolejnych Sprintach. UWAGA! Bardzo ważna na tej retrospektywie jest obecność Właściciela Produktu, gdyż zrobienie wartościowego Przeglądu Sprintu wymaga od niego nakładu pracy i często zmiany podejścia do wielu kwestii.
Na kolejnych Retrospektywach należy sprawdzić, na ile udaje się ten plan wprowadzić w życie i jak trzeba go zaktualizować.