Scrum Master: co robi i jak pomaga zespołowi analitycznemu

Zespół ma przygotować raport, ale w połowie pracy odkrywa, że źródło nie rozróżnia dostaw opóźnionych od niepotwierdzonych. Ktoś proponuje dopisać filtr, ktoś inny chce przełożyć całość, a odbiorca właśnie dosłał pięć dodatkowych wymagań. W takim momencie dobrze widać, po co zespołowi sensowna organizacja pracy.

Ja chciałbym od Scrum Mastera pomocy w uporządkowaniu rozmowy: co próbujemy osiągnąć, czego się dowiedzieliśmy, kto może zdecydować o wartości i jak usunąć przeszkodę. Samo dopilnowanie obecności na spotkaniu niewiele tu zmieni. Zwłaszcza gdy wszyscy przyszli punktualnie, żeby przez godzinę opowiadać o tym samym zablokowanym pliku.

Poniżej używam syntetycznego scenariusza zespołu analitycznego. Przykładowe reguły raportu i propozycje działań są ilustracją mojego podejścia. Zasady Scruma odnoszę do źródeł autorów oraz Scrum.org. Nie opisuję wdrożenia konkretnej firmy i nie zakładam, że każdy analityk powinien pracować właśnie w tym modelu.

Agile i Scrum mają różny zakres

Manifest Agile wskazuje wartości związane między innymi ze współpracą, działającym oprogramowaniem i reagowaniem na zmianę. Jednocześnie uznaje wartość planów, dokumentacji i procesów. Z tego powodu nie wyciągałbym z niego pozwolenia na dowolną zmianę priorytetów co godzinę ani na wyrzucenie wszystkich ustaleń zespołu.

Scrum jest konkretnym frameworkiem z opisanymi odpowiedzialnościami, wydarzeniami i artefaktami. Punktem odniesienia w tym tekście jest Scrum Guide z listopada 2020. Sprint trwa miesiąc lub krócej. Dwa tygodnie mogą być wyborem zespołu, ale nie stanowią obowiązkowej długości każdego Sprintu.

Ja oceniałbym przydatność takiego sposobu pracy przez to, czy pomaga uzyskiwać informację zwrotną i dostarczać użyteczne rezultaty. Sama tablica z kolorowymi kartami niczego jeszcze nie dowodzi. W naszym przykładzie ważniejsze będzie wyjaśnienie wad źródła przed publikacją niż liczba zadań przesuniętych do ostatniej kolumny.

Warto też zapytać, co w ogóle jest produktem zespołu. Dla raportu dostaw może to być utrzymywane rozwiązanie analityczne wspierające pracę kierowników. Jeśli wrzucimy do jednej kolejki dowolne prośby całej organizacji, wspólny cel łatwo się rozmyje. Rozmowę o produkcie przeprowadziłbym przed próbą oceniania, czy zespół „robi dobrze Scrum”.

Za co odpowiada Scrum Master

Scrum.org opisuje odpowiedzialność Scrum Mastera za ustanowienie Scruma i skuteczność Scrum Teamu. Obejmuje to uczenie samozarządzania, pomoc w usuwaniu przeszkód oraz dbanie o produktywne wydarzenia. Ta odpowiedzialność dotyczy także współpracy z Product Ownerem i organizacją, więc wykracza poza prowadzenie spotkań.

W moim przykładzie Scrum Master mógłby pomóc ustalić, dlaczego pytanie o definicję danych od tygodnia nie ma adresata. Czy brakuje wskazanego właściciela źródła? Czy zespół wie, jak eskalować zależność? Czy odbiorca rozumie, że brak decyzji blokuje użyteczny wynik? To propozycje pytań, które skierowałyby rozmowę na konkretną przeszkodę.

Nie oczekiwałbym, że Scrum Master samodzielnie naprawi wszystkie daty, napisze zapytanie i zatwierdzi definicję terminowości. Chciałbym pomocy w doprowadzeniu do rozwiązania oraz w rozwijaniu zdolności zespołu do podobnych działań. Jeśli każda drobna rozmowa musi przejść przez jednego pośrednika, powstaje kolejna zależność, którą warto zauważyć.

Sprawdziłbym też, czy ta osoba ma możliwość pracy nad przeszkodami organizacyjnymi. Można świetnie moderować spotkania i nadal przegrywać z pięcioma sprzecznymi poleceniami z zewnątrz. W takim przypadku potrzebna jest rozmowa o sposobie współpracy firmy z zespołem. Kolejne ćwiczenie z karteczkami nie rozstrzygnie samoistnie sprzecznych oczekiwań.

Product Owner i Developers w zadaniu analitycznym

Product Owner odpowiada za maksymalizowanie wartości produktu i zarządzanie Product Backlogiem. Może korzystać z pomocy innych, lecz zachowuje odpowiedzialność. W naszym scenariuszu chciałbym z nim uzgodnić, który problem kierowników dostaw jest najważniejszy i jak rozpoznamy, że pierwsza wersja rozwiązania przynosi im wartość.

Developers to nazwa odpowiedzialności w Scrumie, która może obejmować także analityków tworzących użyteczny Increment. Zespół sam ustala, kto, kiedy i jak wykona pracę. Nie wyprowadzałbym z angielskiej nazwy wniosku, że osoba przygotowująca model danych musi być poza tą grupą, bo jej stanowisko nie zawiera słowa programista.

Ja opisałbym wkład analityka przez konkret: definicja populacji, przygotowanie danych, model pomiaru, zrozumiała wizualizacja oraz kontrola ograniczeń. Odbiorca domenowy pomaga ustalić znaczenie dostawy i potwierdzenia. Osoba utrzymująca źródło wyjaśnia jego zachowanie. Potrzebujemy ich współpracy, ale nie oznacza to automatycznie powstania kolejnych formalnych odpowiedzialności w Scrumie.

Przy sporze o nowy wykres skierowałbym rozmowę do pytania o wartość i koszt względem celu. Przy sporze o poprawność złączenia poprosiłbym o wspólne sprawdzenie techniczne. To różne problemy. Scrum Master może pomóc prowadzić rozmowę, lecz nie musi zostać arbitrem każdej definicji biznesowej i każdego fragmentu implementacji.

Sprint Goal pomaga rozmawiać o zmianie zakresu

Przykładowy cel brzmiałby: kierownik potrafi wskazać dostawy z poprzedniego dnia, które wymagają wyjaśnienia. To propozycja celu w naszym ćwiczeniu. Lista zadań mogłaby obejmować pobranie danych, reguły statusów, widok wyjątków i udostępnienie rozwiązania. Cel opisuje powód wspólnej pracy, a lista opisuje wybrany sposób jego realizacji.

Zgodnie ze Scrum Guide zakres można doprecyzowywać i renegocjować z Product Ownerem w miarę uczenia się, bez zagrożenia Sprint Goal i obniżania jakości. Gdy cel staje się nieaktualny, Sprint może anulować Product Owner. Nie traktowałbym więc początkowej listy zadań jako niezmiennego kontraktu na każdą kartę.

W naszym scenariuszu może się okazać, że pełny ranking przewoźników wymaga historii, której jeszcze nie otrzymamy. Zaproponowałbym rozmowę o ograniczeniu pierwszego widoku do listy spraw wymagających wyjaśnienia. Trzeba sprawdzić, czy taki wynik nadal spełnia cel i standard jakości. Samo odcięcie trudnej części bez tej rozmowy byłoby ryzykowne.

Dodatkowa prośba o pięć kolorów wykresu mogłaby natomiast poczekać. Poprosiłbym odbiorcę o wyjaśnienie, jak wpływa na cel. Jeśli pomaga rozpoznać najważniejsze wyjątki, warto ją rozważyć. Jeśli dotyczy głównie gustu, można ją umieścić w dalszych planach. Wspólny cel daje zespołowi argument konkretniejszy niż „bo już zaplanowaliśmy”.

Przeszkoda potrzebuje opisu i następnego kroku

Zapis „czekamy na dane” jest dla mnie za mało precyzyjny. Chciałbym wiedzieć, na które pole czekamy, do czego jest potrzebne i co możemy zrobić bez niego. W naszym ćwiczeniu chodzi o rozróżnienie paczki niedoręczonej i potwierdzenia, które jeszcze nie dotarło. Bez niego nie potrafimy uczciwie ocenić terminowości.

Zespół mógłby przygotować dwa przykładowe rekordy, opis oczekiwanego znaczenia oraz pytanie do właściciela źródła. Scrum Master pomógłby znaleźć właściwą drogę rozmowy, jeśli dotychczasowa nie działa. Ustalilibyśmy, kiedy potrzebujemy odpowiedzi i kto wróci do tematu. Wtedy blokada staje się czymś, co można śledzić i rozwiązać.

Równolegle zaproponowałbym pracę, która nie wymaga zgadywania: opis ekranu wyjątków, uzgodnienie potrzeb odbiorcy albo przygotowanie jawnie syntetycznych przypadków do rozmowy o regułach. Nie oznacza to udawania, że produkcyjny problem zniknął. Chcę po prostu wykorzystać czas bez ukrywania zależności, która wciąż może uniemożliwić ukończenie części rozwiązania.

Po wyjaśnieniu sprawy wróciłbym do jej przyczyny. Jeśli nikt nie znał opiekuna danych, warto utrwalić kontakt i definicję. Jeśli pytanie zadaliśmy dopiero pod koniec pracy, trzeba wcześniej badać podobne zależności. O problemach źródłowych przeczytasz również w tekście o złych danych przed analizą. Samo odblokowanie dzisiejszego zadania nie wyczerpuje możliwej nauki.

Daily Scrum powinno pomagać dostosować plan

Daily Scrum trwa 15 minut i służy Developers do oceny postępu ku Sprint Goal. Struktura spotkania jest ich wyborem. Trzy popularne pytania nie są obowiązkowym formularzem. Z tego powodu nie oczekiwałbym od analityka recytowania listy czynności wyłącznie po to, żeby ktoś mógł ją odnotować.

W naszym przykładzie powiedziałbym: „Nie potrafimy jeszcze oddzielić brakującego potwierdzenia od opóźnienia. Dzisiaj potrzebujemy rozstrzygnięcia definicji i dostosowania widoku wyjątków”. Taka informacja pozwala zespołowi omówić wpływ na cel. Komunikat „wczoraj robiłem SQL, dziś też robię SQL” daje zdecydowanie mniej materiału do wspólnej decyzji.

Szczegółowe wyjaśnianie całej historii statusów przeniósłbym do rozmowy osób, które są potrzebne do rozwiązania. Krótkie spotkanie powinno pomóc ustalić plan, a dalsza praca może trwać po nim. Nie chciałbym, żeby kilka osób słuchało pół godziny o polu, z którym nie mają związku, tylko dlatego, że rozmowa zaczęła się przy wszystkich.

Po spotkaniu sprawdziłbym, czy rzeczywiście coś ustaliliśmy. Kto podejmuje rozmowę ze źródłem? Kto przygotuje propozycję zakresu? Co zrobimy, jeśli odpowiedź nie przyjdzie? Jeżeli przez kilka dni powtarzamy tę samą blokadę bez zmiany planu, problem warto nazwać. Punktualne rozpoczęcie i zakończenie wydarzenia nie gwarantuje jeszcze jego użyteczności.

Ukończony fragment musi nadawać się do użycia

Scrum Guide wiąże Increment z użytecznością i Definition of Done, czyli formalnym opisem wymaganego stanu jakości. Ja dla naszego przykładu zaproponowałbym sprawdzalne wymagania dotyczące zgodności danych, widocznego momentu odświeżenia i możliwości przejścia od wyjątku do szczegółu. To przykłady standardu do uzgodnienia, a nie uniwersalna lista wpisana w Scrum.

Jeśli rozwiązanie pokazuje nieaktualne dane bez ostrzeżenia, nie uspokajałbym się tym, że wszystkie przyciski działają. Jeśli reguła myli brak informacji ze spóźnieniem, piękny wykres nadal nie odpowiada na uzgodnione pytanie. Przy ocenie użyteczności chciałbym przejść przez konkretny scenariusz kierownika, zamiast sprawdzać wyłącznie zgodność z makietą.

Rozróżniłbym też kryteria konkretnego elementu i wspólny standard jakości. Wymóg filtrowania po magazynie może dotyczyć jednego widoku. Sprawdzony sposób odświeżenia może obowiązywać całe rozwiązanie. Takie rozdzielenie ułatwiłoby zespołowi zauważenie, które warunki dotyczą wybranej funkcji, a które musimy spełniać przy każdej kolejnej zmianie produktu.

Pracy niespełniającej Definition of Done nie przedstawiałbym jako gotowego Incrementu. Pokazałbym stan uczciwie i uzgodnił dalszy los niedokończonego elementu. Ukrycie brakującej kontroli pod etykietą „prawie działa” przenosi niepewność na odbiorcę. W analityce ten odbiorca może podjąć na podstawie wyniku decyzję, zanim zdążymy dokończyć wyjaśnienie.

Review i retrospektywa rozwiązują inne pytania

Na Sprint Review zespół i interesariusze wspólnie oceniają rezultat oraz dalsze dostosowania. To wydarzenie robocze. W naszym scenariuszu poprosiłbym kierownika o wskazanie dostawy wymagającej działania i wyjaśnienie, co zrobi z otrzymaną informacją. Sam pokaz ekranów nie odpowie, czy widok pomaga w pracy.

Zanotowałbym pytania, które zmieniają rozumienie produktu. Może kierownik potrzebuje kontaktu do opiekuna przewoźnika, a kolejny wykres jest mniej istotny. Taka obserwacja może wpłynąć na następne priorytety. Nie próbowałbym bronić wcześniejszej makiety za wszelką cenę, jeśli właśnie dowiadujemy się czegoś użytecznego o rzeczywistym zadaniu odbiorcy.

Retrospektywa dotyczy jakości i skuteczności sposobu pracy zespołu. Tutaj wróciłbym do opóźnionego rozpoznania zależności od źródła. Zamiast ogólnego „musimy lepiej komunikować” zaproponowałbym małą zmianę: przy następnym podobnym zadaniu wskazujemy opiekuna definicji przed wyborem zakresu realizacji. Potem sprawdzimy, czy pomogło.

Wybrałbym niewiele działań, które zespół potrafi rzeczywiście podjąć. Lista dziesięciu dobrych postanowień może wyglądać bardzo ambitnie i pozostać dokładnie tą samą listą za miesiąc. Chciałbym znać osobę podejmującą pierwszy krok i moment sprawdzenia efektu. Samo poczucie, że dobrze porozmawialiśmy, jest przyjemne, lecz trudne do wykorzystania przy kolejnej blokadzie.

Niewiadoma też potrzebuje ograniczonego pytania

Przy nowym źródle danych zaproponowałbym najpierw rozpoznanie jednej ryzykownej zależności. Na przykład: czy potrafimy dla trzech wybranych paczek odtworzyć historię statusu i wskazać moment otrzymania potwierdzenia? To konkretne pytanie, które może wpłynąć na plan. Ogólne „poznamy system” jest trudniejsze do zakończenia i jeszcze trudniejsze do wykorzystania przy decyzji o zakresie.

Ustalilibyśmy, ile czasu warto poświęcić na tę próbę i jaki rezultat potrzebny jest do dalszej rozmowy. Wynikiem może być potwierdzona możliwość, opis brakującego pola albo informacja, że potrzebujemy pomocy opiekuna źródła. Nie obiecywałbym gotowej funkcji tylko dlatego, że udało się obejrzeć fragment eksportu. Rozpoznanie daje wiedzę, a użyteczne rozwiązanie nadal wymaga wykonania odpowiedniej pracy.

W naszym ćwiczeniu analityk mógłby pokazać dwie interpretacje pustego statusu i ich wpływ na ekran wyjątków. Product Owner dostałby wtedy konkretny wybór do omówienia z odbiorcą. Scrum Master mógłby pomóc zadbać o rozmowę, kiedy obie strony używają tych samych słów w różnych znaczeniach. Nie musimy czekać na kompletną implementację, żeby odkryć takie nieporozumienie.

Zachowałbym wnioski obok definicji źródła, żeby kolejna osoba nie zaczynała rozpoznania od zera. Dopisałbym również, czego nie sprawdziliśmy: na przykład korekt statusu po kilku dniach albo historii starszych przesyłek. Granice małej próby są równie przydatne jak odpowiedź. Dzięki nim zespół może korzystać z odkrycia bez przypisywania mu większej pewności, niż rzeczywiście uzyskał.

To moja propozycja organizacji pracy nad niepewnością, a nie dodatkowe wydarzenie wymagane przez Scrum. Dostosowałbym ją do produktu i kosztu błędnego założenia. Jeżeli najważniejsza wątpliwość jest już rozstrzygnięta w aktualnej dokumentacji źródła, zacząłbym od jej przeczytania i rozmowy o konkretnym przypadku, zamiast organizować osobne badanie dla samej procedury.

Jak przygotowałbym się jako analityk

Przed rozpoczęciem zadania opisałbym, jak mój wkład łączy się z celem produktu i Sprintu. Sprawdziłbym znaczenie wiersza, dostępność potrzebnych pól i drogę uzgodnienia definicji. To nie daje pewności, że nic nas nie zaskoczy. Daje natomiast materiał do sensownej rozmowy, kiedy odkrycie zmusi nas do dostosowania planu.

W trakcie pracy komunikowałbym wpływ problemu, a nie tylko jego istnienie. „Brakuje pola” można doprecyzować: bez tego pola nie odróżnimy dwóch kategorii wyjątków, ale nadal możemy pokazać listę spraw do wyjaśnienia. Taki opis ułatwia wspólną ocenę alternatyw. Odbiorca ma szansę porównać użyteczność ograniczonej wersji z kosztem czekania na pełną.

Jako ćwiczenie weź prosty raport i zapisz jeden proponowany cel, trzy elementy planu oraz jedną odkrytą zależność. Następnie usuń z planu element, którego nie da się wykonać. Spróbuj wyjaśnić, czy pozostały rezultat nadal realizuje cel i spełnia wymagania jakości. Jeśli odpowiedź wymaga decyzji odbiorcy, wskaż konkretnie, co powinien rozstrzygnąć.

O samej pracy analitycznej przeczytasz w artykule co robi analityk danych. Współpraca ze Scrum Masterem może pomagać ten proces usprawniać. Ja oczekiwałbym po niej przede wszystkim lepszej zdolności zespołu do rozwiązywania podobnych problemów, także wtedy, gdy osoba prowadząca spotkania akurat jest na urlopie.