Informacja zwrotna w scrumie czyli feedback na wielu płaszczyznach

Trafiłem ostatnio na bardzo interesujący krótki film z wystąpieniem Billa Gatesa. Tak, wiem, “Microsoft i te klimaty”.

feedback

Feedback

Ale z drugiej strony jest to mimo wszystko człowiek, który zbudował od zera jedną z największych firm IT na świecie, więc chyba musi mieć coś mądrego do powiedzenia. I z takim też nastawieniem go obejrzałem.

Oglądając to wystąpienie, problemy i ich rozwiązania, o których mówi Bill, od razu naszły mnie skojarzenia z pracą w scrumie. Wychodząc z założenia, w które głęboko wierzę, że jest słuszne i prawdziwe, a mianowicie że uczymy się na własnych błędach, spróbowałem przełożyć to na nasz scrumowy świat. Wyodrębniłem następujące sytuacje, w których informacja zwrotna jest niezbędna, aby zrobić krok do przodu, a równocześnie framework scrumowy to mocno wspiera:

1. Interesariusze dają informację zwrotną dla zespołu i Product Ownera w trakcie Review

2. Scrum Masterzy dają informację zwrotną dla Scrum Mastera i zespołu

3. Zespół daje informację zwrotną dla Scrum Mastera

Przy okazji jest jeszcze czwarty punkt mocno skorelowany z powyższym filmem:

4. Obserwacja przez Junior Scrum Mastera starszego kolegi w “trakcie pracy”

Punkt pierwszy jest tak oczywisty, że nie ma w sumie o czym pisać :). Ale czy na pewno? Ilu z Was, pracując jako Product Ownerzy czy Scrum Masterzy, zaprasza interesariuszy na Review swojego zespołu? Ile razy zdarzyło się, że interesariusze podzielili się konstruktywną krytyką. Jeżeli wiele razy, to super! Jednak doświadczenie podpowiada mi, że jest z tym różnie. A jest to doskonała okazja, aby porozmawiać z zainteresowanymi, zbudować z nimi relacje, przyjąć konstruktywną krytykę i zaangażować te osoby w rozwój produktu. I tak naprawdę wyjść trochę z modelu waterfallowego tworzenia wymagań, kiedy interesariusze składają je na piśmie, a później przychodzą, po kilku tygodniach, ocenić ich realizację.

Scrum Masterzy dają informację zwrotną dla Scrum Mastera – kolejny element, który jest nieoceniony, a chyba jednak dość rzadko wykorzystywany. W czasie, kiedy aktywnie chodziłem na ceremonie innych zespołów, po ich zakończeniu zarówno Scrum Master jak i sam zespół chłonęli każde słowo, jakie im przekazywałem. Z rozmów z innymi Scrum Masterami wiem, że wręcz oczekiwano przekazania informacji, co się widziało. Sam będąc Srum Mastera, miałem co ceremonię uczucie, że potrzebuje tutaj, teraz, kogoś, kto obiektywnie by spojrzał na sytuację i przekazał swoje obserwacje. I nie chodzi bynajmniej o ocenę. Obserwujący Scrum Master ma być w tym przypadku jak lustro – przekazać tylko to, co widział. Oczywiście, jeżeli odwiedzany zespół, tudzież SM czy PO poproszą o wsparcie mentorskie, to nic nie stoi na przeszkodzie, aby to zrobić. Ale przede wszystkim odwiedzając zespół,jesteśmy dla nich kamerą jak na filmie powyżej – rejestrujemy i pozwalamy im samym odtworzyć ceremonie, ocenić ją i wyciągnąć konstruktywne wnioski.

Znacie bardzo prostą, a jakże przydatną technikę Happiness Door? Ktoś mi ostatnio mówił, że był kiedyś na jakieś konferencji i była tam cała 1,5 godzinna prelekcja o tej technice. Nie zamierzam Was zanudzać w takim stopniu. Chcę Wam tylko zwrócić uwagę na kolejny bardzo istotny element doskonalenia własnej pracy. Jeżeli jesteście Scrum Masterami, poproście po zakończonej retrospektywie o informację zwrotną. Jeżeli jesteście Product Ownerami, zróbcie to po refinement’cie. Możecie do tego użyć właśnie przytoczona technikę, ponieważ jest szybka i anonimowa. Ale możecie użyć też jakiejkolwek innej. Najistotniejsze jest tutaj zebranie informacji zwrotnej, jej analiza i wyciągnięcie wniosków. Aby było lepiej.

O ostatnim punkcie też wspominał Gates: obserwacja doświadczonych nauczycieli przez właśnie uczących się. Innymi słowy, uczenie się od najlepszych. Obserwuj, podpatruj, może znajdziesz coś dla siebie. A przy okazji będziesz miał okazję zrealizować punkt 2 i 3.

Oczywiście możecie powiedzieć, że nie piszę tutaj nic odkrywczego. Zgadzam się. Tym bardziej, że przecież sam Jeff Sutherland podaje feedback loop jako jedno z głównych narzędzi/ elementów scruma.

Rysunek obok odnoszący się bezpośrednio do Xtreme Programming (z którego bardzo wiele elementów ma scrum; a może odwrotnie?) pokazuje, na jak wielu płaszczyznach i w jakim czasie jako developer mam okazję się uczyć, otrzymując informację zwrotną.

Jeżeli byśmy na rysunek nanieśli Continous Integration jako kolejny element weryfikacji kodu, Continous Deployment w kontekście możliwości szybkiego rozpoznania zadowolenia naszych użytkowników oraz cztery w/w punkty, to byśmy mieli pewnie system idealny.

Nic tylko analizować, wyciągać wnioski i uczyć się na własnych błędach. Przecież to jest takie proste…

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x