Dużo ostatnio piszemy na tematy ogólne, a wręcz można wypowiedzieć, że „filozoficzne”. Dziś postanowiłem zmienić ten trend i dać kilka praktycznych porad na temat jednego z naszych ulubionych nie-wydarzeń w Scrumie. Mowa oczywiście o refinemencie.
Zapisujmy co się da
Bez zbędnych wstępów zacznijmy od pierwszej i najważniejszej porady, którą mogę dać każdemu, kto przeprowadza jakiekolwiek spotkanie: zapisujemy co się tylko da, w taki sposób aby wszyscy to widzieli w trakcie notowania. Będąc w jednej sali – wykorzystajmy projektor bądź telewizor, a jeśli takowego nie mamy, to usiądźmy tak, aby wszyscy widzieli co piszemy.
Brzmi znajomo? Nie piszemy o tym pierwszy raz! Jeżeli jesteś zainteresowany/a innymi poradami dotyczącymi przeprowadzania krótkich i efektywnych spotkań, polecam nasz tekst o kozie czyli GOAT. Dziś skupię się na uszczegóławianiu i rozpoznawaniu wymagań czyli refinemencie.
Zapisując nasze ustalenia czy przemyślenia przechodzimy od „wydaje mi się” do „zapisane słowa interpretuję w następujący sposób”. Jest to ogromna zmianach koncepcyjna! Zamiast dyskutować o tym, co wszyscy mają w głowach, zaczynamy rozmawiać o tym, co jest napisane. Bez spisanego punktu odniesienia pozostajemy w sferze domysłów i wyobrażeń które zawsze obarczone są jakimś błędem.
Oczywiście, nie znaczy to, że zapisując najważniejsze ustalenia na bieżąco nie wpadniemy w jakąś pułapkę. Natomiast szanse są o kilka rzędów wielkości mniejsze.
Ta porada nie znaczy też, że będziemy wspólnie pisać kilkunasto- bądź kilkudziesięciostronicowe dokumenty. Po to mamy chociażby kryteria akceptacji, żeby wyłuskać z naszych rozmów to, co jest absolutnie najważniejsze. Jeżeli mowa o wymaganiach, to notatki robione na bieżąco zwykle będą dotyczyły właśnie wspomnianych kryteriów. Jeżeli chodzi o bardziej skomplikowane rzeczy, pewnie będą omawiane w podgrupach bądź indywidualnie. Jeśli natomiast myślimy o procesach, diagramach, itp. to pewnie i tak spotkamy się na osobnych warsztatach, gdzie wykorzystamy jakąś technikę na wspólne dojścia do konsensusu.
Wdzwaniajmy potrzebne osoby od ręki
Druga porada jest cokolwiek kontrowersyjna, ale też mam trochę nadzieję że wywoła dyskusję. Brzmi ona: wdzwaniajmy potrzebnych ludzi na refinement, jak tylko pojawi się taka potrzeba.
Wielokrotnie byłem świadkiem sytuacji, w których kilka-kilkanaście osób spotykało się, żeby przedyskutować jakiś temat. Gdzieś w trakcie tych rozmów pojawiało się pytanie techniczne bądź biznesowe. Szybko okazywało się, że nie ma kto na nie odpowiedzieć. Odruchowa reakcja większości ludzi w takiej sytuacji to zapisanie tego pytania i ustalenie osobnego spotkania w innym terminie.
Mój odruch i coś, co wydaje mi się, że o wiele szybciej przybliża nas do osiągnięcia celu to wdzwonienie tej osoby (zadzwonienie do, pójście do biurka po) i próba uzyskania odpowiedzi na to konkretne pytanie od ręki. Bardzo często taka osoba jest dostępna, całe „zamieszanie” trwa dosłownie kilka minut i możemy ruszyć dalej.
Kontrowersja pojawia się oczywiście w związku z przerywaniem wykonywanej pracy. Jeżeli wdzwaniamy osobę techniczną, to zaraz usłyszymy, że oderwanie się od kodu powoduje że przez najbliższe pół godziny czy dwie godziny taka sama nie będzie pracowała efektywnie (patrz: multitasking). W skrajnym przypadku dowiemy się, że rozbijamy komuś cały dzień pracy, bo takie telefony i wdzwonienia będą następowały co chwilę.
W praktyce, terminy cyklicznych refinementów są stałe. Refinement to proces ciągły, ale często mamy z góry przewidziane jakieś przedziały czasowe. Jesteśmy w stanie przewidzieć, kiedy możemy być potrzebni. Z drugiej zaś strony, zwinne podejście jest podejściem zespołowym i czasami należy postawić dobro zespołu ponad dobro jednostki. Jeżeli musimy jedną osobę wybić z rytmu, żeby kilka bądź kilkanaście osób spędziło efektywnie czas na refinemencie, to czasami jest to warte. Wydaje mi się, że o wiele więcej czasu tracimy organizując kolejne, kolejne i kolejne spotkania w różnych składach osobowych.
Oczywiście, jeżeli nasza praca jest przerywana pięćdziesiąt razy dziennie przez telefony, wdzwaniania na spotkania i różne inne rzeczy, które się dzieją obok naszych zadań w Sprincie, to też nie jest to efektywne. W takiej sytuacji musimy się zastanowić, jak zoptymalizować nasz sposób działania. Tylko biedny refinement rzadko kiedy jest tu głównym winnym.
Nie tylko „Jak?”, ale przede wszystkim „Po co?”
Trzecia porada brzmi: zamiast spędzać mnóstwo czasu nad zastanawiałem się „jak” coś zrobić, poświęćmy więcej energii na kwestie „po co”, „dla kogo” i „co się stanie jeżeli tego nie zrobimy„.
W zespołach zwinnych nie płacą nam za machanie łopatą, czyli bezmyślne realizowanie wszystkich pomysłów, które do nas wpadają. Jesteśmy zatrudnieni do kreatywnego rozwiązywania problemów biznesowych i/lub spełnianie biznesowych potrzeb. W troszeczkę mniej zwinnym wydaniu (ale ciągle agile’owym) płacą nam za realizowanie wymagań. Tu zawsze podkreślam, że nie powinny to być tylko i wyłącznie zadania do realizacji. To my jesteśmy odpowiedzialni za sposób i za samą koncepcję spełnienia potrzeb.
Wiem, że bardzo łatwo się o tym mówi, jeżeli miało się okazję pracować w takim środowisku. Niestety, większość udawanych Zespołów Scrumowych w Polsce to nic innego niż miejsca, gdzie kierownik przebrany za Product Ownera przychodzi na planowanie przydzielać zadania na kolejny Sprint. Ale przecież możemy to zmienić! Jako Scrum Masterzy, jako członkowie zespołów, jako wszyscy dookoła możemy zadawać wspomniane pytania. Po co? Dla kogo to robimy? Jakie mają być korzyści? Co się stanie, jeżeli tego nie zrobimy? Czy na pewno każda jedna rzecz musi być zrobiona? Co właściwie chcemy osiągnąć i jak to zmierzymy? I tak dalej, i tak dalej…
Organizujmy refinementy w postaci warsztatów, dyskusji z biznesem, rozwiązywania problemów. Zaprośmy naszych partnerów do rozmów i do wspólnej pracy nad produktem albo chociaż nad opracowaniem sposobu spełnienia potrzeb. Nie róbmy „refinementu biznesowego”, gdzie obecny jest tylko i wyłącznie Product Owner bądź jakiś główny analityk i interesariusze. Analogicznie, nie róbmy „refinementu technicznego”, gdzie jest tylko i wyłącznie zespół, a nie ma nikogo od klienta czy przedstawicieli szeroko rozumianego „biznesu”. Pracujmy razem i pamiętajmy, że możemy tego oczekiwać niezależnie od tego, czy jesteśmy Deweloperem, Product Ownerem czy Scrum Masterem.
Jeżeli mamy pracować zwinnie, to ten sposób pracy z wymaganiami powinien być dla nas naturalny. Przecież gramy do jednej bramki i próbujemy znaleźć najlepsze możliwe rozwiązanie. W końcu nie jesteśmy od machania łopatą.
