Blog

Kluczowym aspektem działania zwinnego jest wykorzystanie empirycznej kontroli procesu nie tylko do rozwoju produktu, ale też doskonalenia Zespołów i organizacji. Niektóre metody, jak Scrum, wprost proponują zdarzenie (Retrospekcję Sprintu), która służy realizacji tego postulatu. W innych trzeba samemu o to zadbać.

W trakcie szkoleń z zakresu Agile, w tym tych akredytowanych przez Scrum.org, mnóstwo mówi się o empiryzmie. Pośrednio lub bezpośrednio związanych jest z nim wiele ćwiczeń, podkreślana jest konieczność istnienia i działania pętli informacji zwrotnej od interesariuszy i reagowania na udzielony feedback. Przeważająca większość uczestników takich szkoleń kończy je ze świadomością, że nie da się przewidzieć, zaprojektować i zaplanować rozwoju produktu z góry, raz-a-dobrze, dlatego trzeba robić to w krótkich iteracjach i przyrostowo.

Dużo mniej podkreślana jest na szkoleniach potrzeba czynienia tego samego z procesem, narzędziami i praktykami, jakie go wspierają, technikami, które wykorzystuje Zespół, komunikacją, a wreszcie samym Zespołem – umiejętnościami tworzących go ludzi, ich wiedzą, relacjami.

Retrospekcja Sprintu, o której na szkoleniach się mówi, często jawi się uczestnikom jako zdarzenie, w którego trakcie dokonuje się tylko przeglądu tego, co poszło źle podczas budowania produktu, by w kolejnej iteracji dokonać zmian na lepsze. Prowadzi to do niekoniecznie słusznego utożsamiania procesu usprawniania wyłącznie z naprawianiem tego, co jest popsute, wyłącznie w kontekście produktu, jaki buduje Zespół.

Czy usprawnienia wymagają empiryzmu?

Jeśli coś w Sprincie poszło nie tak, należy dokonać zmiany, która zapobiegnie powtórzeniu się problemu. Retrospekcja Sprintu jest między innymi po to, by zapewnić przestrzeń (czas) do przeglądu sposobu pracy Zespołu, wyciągnięcia wniosków i zaplanowania zmian, które zrealizowane zostaną w kolejnej iteracji.

Zespół nie może jednakże ograniczyć się tylko do naprawiania tego, co dziś działa źle. Już w samym założeniu, że aby dokonać usprawnienia, konieczne jest odkrycie, co robimy nie tak, tkwi pułapka negatywnej motywacji. A ta jest zwykle zbyt słaba, by nakłonić ludzi do podejmowania wysiłków większych, niż absolutne niezbędne minimum.

Poza tym zawężenie usprawniania wyłącznie do usuwania problemów ogranicza rozwój Zespołu. Rozwój nie polega przecież na eliminowaniu zidentyfikowanych ograniczeń, ale przede wszystkim na odkrywaniu nowych możliwości i skutecznym ich wykorzystaniu. Jeśli coś dobrze działa, nie trzeba dokonywać usprawnienia, ale jeśli jest ono możliwe i się powiedzie – skuteczność działania Zespołu zdecydowanie wzrośnie.

Wróćmy na moment do rozwoju produktu. Co by się stało, gdyby podejść do niego w taki sam sposób, jak wiele Zespołów postrzega proces usprawniania? Czyli reagując wyłącznie na problemy zgłaszane przez użytkowników?

Niepotrzebna okazałaby się tak wizja produktu, jak i wynikający z niej Backlog Produktu. Kluczowa natomiast stałaby się lista błędów. Zespół naprawiałby je, naprawiał i naprawiał, do upadłego. Produkt z jednej strony stawałby się coraz lepszy, ale czy rozwijałby się jakkolwiek? Absolutnie nie, ponieważ nie powstawałyby żadne nowe funkcjonalności, a jedynie doskonalone byłoby to, co istniało do tej pory. W praktyce produkt stawałby się coraz mniej wartościowy, bo nie podążałby za zmiennymi potrzebami użytkowników.

Widać wyraźne podobieństwo między procesami rozwoju produktu i Zespołu. I jeden i drugi, skupiwszy się wyłącznie na usuwaniu problemów, dojdzie do punktu, w którym dalsze jego działanie będzie zbędne (bo przestaje przynosić jakiekolwiek korzyści). Jednocześnie i jeden i drugi może funkcjonować potencjalnie w nieskończoność, jeśli ciągle będzie poszukiwał nowych możliwości.

A skoro do rozwoju produktu w złożonym środowisku używany jest empiryzm, czy można zastosować go także do rozwoju Zespołu? Jak najbardziej tak, bo ten proces również polega na zmaganiu się ze złożonością (zmiennością i nieprzewidywalnością).

Potrzeba wizji, ku której zmierzamy

Proces rozwoju produktu napędzany jest jego wizją i definiowanymi przez Product Ownera kolejnymi Celami Produktu. Podobnie jest z rozwojem Zespołu – ważne jest, by ciągłe jego usprawnianie również miało jakąś wizję i cel. Zespół powinien być świadom tego, do czego dąży i poszukiwać sposobu na osiągnięcie tego.

Przy czym nie chodzi tu o cele wyznaczone przez organizację, które najczęściej da się zredukować do prostego oczekiwania, by Zespół dostarczał jak najwięcej rozwiązań w jak najkrótszym czasie.

Co może więc być taką wizją? Na przykład zmiana roli Zespołu w organizacji z wytwórców produktu, którzy tylko pracują na rzecz interesariuszy i stanie się kluczowym interesariuszem swojego produktu. Czyli przejście od Zespołu samodzielnie zarządzającego swą pracą do Zespołu, który zaczyna sam wytyczać cele, jakie będzie osiągał poprzez rozwój produktu (ang. self-directing team). Inną wizją może być uzyskanie zdolności do tworzenia rozwiązań prawdziwie innowacyjnych, np. poprzez wykreowanie zupełnie nowych technologii.

To oczywiście tylko przykłady, jedynymi ograniczeniami w tym zakresie są wyobraźnia członków Zespołu i zdrowy rozsądek. Wizja nie musi zresztą być tak ambitna – czasami jest wręcz przyziemna. Ważne, by była atrakcyjna dla Zespołu, który autentycznie chce ku niej podążać, i by nie wypaliła się w Sprint lub dwa.

Gdy już mamy w Zespole taką wizję samych siebie za jakiś czas, dużo łatwiej jest zastanawiać się, jaki powinien być pierwszy, następny i kolejne kroki. Dzięki tej wizji łatwiej dokonać oceny, czy idziemy w dobrą stronę, czy w ogóle się do realizacji wizji zbliżamy. Zamiast wyłącznie reagować na to, co poszło niezbyt dobrze w czasie kończącej się iteracji, zastanawiamy się też, jaki kolejny krok chcemy zrobić. Podkreślam: chcemy, nie musimy.

Zespoły, które traktują Retrospekcję Sprintu w ten sposób, często zaczynają tworzyć własny rejestr planowanych usprawnień, który przypomina jako żywo Backlog Produktu. Po czym realizują jego elementy, dodają nowe, zmieniają ich kolejność itd. Co Sprint dokonują zmian, które niekoniecznie wynikają z problemów w iteracji zakończonej, ale z chęci rozwoju i robienia czegoś jeszcze lepiej niż do tej pory.

Usprawnianie to nie tylko rozwiązywanie problemów

Z doświadczenia w pracy Scrum Mastera i Agile coacha mogę powiedzieć, że większość Zespołów grzęźnie w trakcie Retrospekcji Sprintu w dyskusjach o tym, co poszło źle. Oczywiście jest w tym często wartość i z reguły opłaca się spostrzeżone problemy rozwiązać, więc ciężko zarzucać ludziom, iż robią coś złego.

Być może jednak o wiele lepszy efekt Zespół uzyskałby, decydując się zamiast tego na wprowadzenie jakiejś nowej praktyki, użycie nowego narzędzia, fundamentalną zmianę procesu itd. Czyli robiąc coś, co nie stanowiłoby rozwiązania istniejących problemów, ale wyeliminowałoby w ogóle możliwość ich wystąpienia.

Oczywiście nie stawiam tu tezy, że należy machnąć ręką na to, co poszło nie tak i za każdym razem dokonać ucieczki do przodu. Żadna skrajność nie byłaby dobra. Chodzi o to, by wykorzystywać Retrospekcje Sprintu (lub jakiekolwiek inne mechanizmy dokonywania usprawnień, jakimi dysponuje Zespół) zarówno do naprawiania tego, co działa źle, jak i do rozwoju – wykształcania nowych umiejętności.

Ma to znaczenie zwłaszcza w Zespołach, które pracują już ze sobą długo, i które najbardziej palące problemy już rozwiązały. Jeśli nie pojawi się atrakcyjna wizja, w której stronę należy podążać, jest ryzyko, że umiejętność dokonywania usprawnień zacznie zamierać.

Z drugiej strony w Zespołach, które wciąż borykają się z masą problemów, potraktowanie procesu usprawniania jako synonimu naprawiania tych problemów może wywołać autentyczny wstręt do zdarzeń takich, jak Retrospekcja Sprintu, która zacznie się ludziom kojarzyć (zapewne słusznie) z miejscem kaźni.

Jak dokonywać udoskonaleń?

Przede wszystkim należy eksperymentować. Brzmi to banalnie, ale niesie w sobie bardzo istotny przekaz. Eksperyment nie polega jedynie na skorygowaniu działań, które były realizowanie mało optymalnie i powodowały problemy. Eksperymentowanie oznacza, że próbujemy czegoś nowego w nadziei, że efekty będą dla nas korzystne. To oznacza, że aby dokonywać udoskonaleń, trzeba poza rozwiązywaniem problemów, testować nowe podejścia, narzędzia, praktyki i techniki.

Zmiana dla zmiany

Bardzo ważnym aspektem dokonywania usprawnień jest umiejętność określenia, co zmiana, jakiej chcemy dokonać, ma nam dać. W czasie trwania eksperymentu (bo zmiana może być rozłożona na kilka iteracji) dokonać można wtedy oceny, czy efekty są dla nas korzystne, czy też lepiej z tej zmiany zrezygnować, przerwać eksperyment i zaplanować w jego miejsce kolejny.

Ku mojemu nieustannemu zaskoczeniu Zespoły bardzo łatwo potrafią wpaść w pułapkę dokonywania zmian, które nie dają żadnych mierzalnych rezultatów. Albo inaczej: dają, ale nie w tym obszarze, dla którego usprawniające działania były podejmowane. Sama zmiana dokonuje się, a jakże, tylko nie przekłada się na wymierne efekty, na jakie liczył Zespół, decydując się na jej przeprowadzenie.

Posłużę się przykładem jednego z Zespołów, który przez wiele iteracji dokonywał zmian w sposobie przeprowadzania pielęgnacji Backlogu Produktu tak, by móc dzięki temu sprawniej planować iteracje. Po pewnym czasie rzeczywiście zmiana zaczęła być zauważalna: Planowanie Sprintu przebiegało płynnie, sprawnie powstawały niezbędne artefakty… więc teoretycznie Zespół odniósł sukces. Niestety, sukces pozorny, ponieważ dokonywane zmiany usprawniały samo zdarzenie (Planowanie), ale nie miały realnego wpływu na jakość i skuteczność samego planowania. Inaczej mówiąc, dzięki „usprawnieniom” bardzo efektywnie i szybko tworzony był kiepski plan działania w iteracji, co spowodowało, że kolejne Sprinty były coraz bardziej chaotyczne.

Stąd przestroga dla dokonujących usprawnień: zastanówcie się dobrze, co chcecie dzięki nim osiągnąć. Dzięki temu będziecie wiedzieć nie tylko, czy planowana zmiana się dokonała (bo to zazwyczaj się udaje i jest łatwe do stwierdzenia), ale też czy dała skutek, o jaki chodziło – realne usprawnienie (to udaje się już o wiele rzadziej i nie zawsze da się jednoznacznie stwierdzić).

Miary sukcesu

Aby uniknąć „technicznego sukcesu”, w którym dokonujemy wszystkich zamierzonych zmian w zakresie, w jakim to zaplanowaliśmy, ale nie dokonujemy realnych usprawnień, warto pomyśleć nad miarami sukcesu. Nie takimi, na jakie patrzy kierownictwo, ale takimi, które Zespołowi pokażą, czy faktycznie coś usprawnia.

Jakie to mogą być miary? Na przykład skuteczność osiągania ustalonych w czasie Planowania Sprintu Celów Sprintu. Lub to ile wymagań z prognozy na Sprint (ang. Sprint forecast) udaje się rzeczywiście zrealizować. Dla Zespołu miarą może być również od biedy velocity, które dzięki usprawnieniom może zacząć rosnąć nie dlatego, że zaczynamy zwiększać oszacowania wymagań, ale dlatego, że udaje nam się więcej wymagań zrealizować w iteracjach.