Usprawnianie to więcej niż rozwiązywanie problemów - Code Sprinters

Usprawnianie to więcej niż rozwiązywanie problemów

Kluczowym aspektem działania zwinnego jest wykorzystanie empirycznej kontroli procesu nie tylko do rozwoju produktu, ale też doskonalenia zespołów developerskich i organizacji, w której działają. Niektóre metody, takie jak Scrum, wprost proponują zdarzenie (retrospektywę), która służy realizacji tego postulatu, w innych – na przykład w Kanbanie – trzeba samemu o to zadbać.

Na szkoleniach wyjaśniających podstawy Agile, również tych certyfikowanych realizowanych pod auspicjami Scrum.org, mnóstwo mówi się o empiryzmie, wiele ćwiczeń związanych jest pośrednio lub bezpośrednio z koniecznością zapewnienia, że pętla feedbackowa działa, a wnioski z każdego kolejnego kroku przy realizacji produktu są wyciągane. Przeważająca większość uczestników takich szkoleń kończy je ze świadomością, że nie da się przewidzieć, zaprojektować i zaplanować wszystkiego z góry „raz a dobrze”, dlatego dążyć do realizacji wizji produktu trzeba poprzez kolejne przybliżenia, rozwijając go w krótkich iteracjach, 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 samymi developerami – ich umiejętnościami, wiedzą, relacjami. Retrospektywa, o której na szkoleniach się mówi, często jawi się uczestnikom jako zdarzenie, w którym dokonuje się tylko przeglądu tego co i jak było robione, by w kolejnej iteracji dokonać zmian, rzecz jasna „na lepsze”. Prowadzi to do niekoniecznie słusznego traktowania procesu usprawniania jako działania tożsamego wyłącznie z naprawianiem tego, co jest popsute.

Czy usprawnienia wymagają empiryzmu?

W rzeczywistości jest to tylko część prawdy o usprawnianiu. Bo i owszem, jeśli coś poszło nie tak, warto dokonać zmiany, która zapobiegnie powtórzeniu się problemu. Przegląd tego, w jaki sposób działał zespół i organizacja w kończącej się iteracji jest rzeczą niezbędną, by tego dokonać. 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. Brak w tym pozytywnej wizji, do realizacji której dążyć powinien zespół. Ot, reagujemy na to, co się stało, i małymi kroczkami, mniej lub bardziej świadomie, dokonujemy usprawnień. To zadziała, ale jeśli mówimy o empirycznej kontroli procesu, to zdecydowanie za mało.

Wróćmy na moment do rozwoju produktu. Gdyby przyjąć, że empiryzm wykorzystywany jest do tego w taki sam sposób jak do udoskonalania procesu i zespołu, niepotrzebna byłaby żadna wizja produktu czy backlog produktu. Zamiast tego w pierwszej iteracji zrobilibyśmy cokolwiek, popatrzyli co wyszło i zastanowili się, co w tym produkcie jest zrobione źle. W kolejnej wyeliminowalibyśmy te rzeczy złe i zastanowili się, co jeszcze jest do poprawy (czyli: co nadal jest złe). Działając w ten sposób, a więc replikując postępowanie wielu zespołów w czasie retrospektyw, reagowalibyśmy wyłącznie na problemy. Czy w ten sposób miałby w ogóle szansę powstać jakiś wartościowy produkt? Być może tak, ale szansa na to byłaby niewielka, a i czas jego wytworzenia mógłby być niezmiernie długi. Takie postępowanie wydaje się zresztą już na pierwszy rzut oka idiotyczne. Dlaczegóż więc to samo nie wydaje nam głupie w kontekście dokonywania retrospektyw? Dlaczego skupiamy się na „naprawianiu zepsutego”, zamiast dążyć do realizacji pozytywnej wizji sprawnego i efektywnego zespołu?

Potrzeba wizji, ku której zmierzamy

Albowiem ważne jest, by ciągłe usprawnianie miało jakąś wizję. Zespół powinien być świadom tego, do czego dąży dokonując zmian. Źródeł takiej wizji zespołu doskonałego może być wiele, jednym ze sposobów jego wytworzenia jest określenie, czego dziś najbardziej brak i dążenie do tego, by ten deficyt został wyeliminowany. Innym sposobem jest chęć uzyskania możliwości, które dziś są nieosiągalne dla zespołu: wiedzy, umiejętności, sposobu komunikacji, tempa pracy, jakości wytwarzanych rozwiązań…

Gdy już mamy w zespole taką wizję samych siebie za jakiś czas, nieprecyzyjną, ale taką, ku której warto podążać, 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 czasie kończącej się iteracji, zastanawiajmy się też, jaki kolejny krok chcemy zrobić. Podkreślam: chcemy, nie musimy.

Zespoły, które traktują retrospektywę w ten sposób, często zaczynają tworzyć własny backlog usprawnień, który następnie świadomie realizują, i którym zarządzają dodając nowe elementy, zmieniając ich kolejność. Co sprint dokonują zmian, które niekoniecznie wynikają z problemów w iteracji zakończonej, ale z chęci rozwoju, robienia czegoś jeszcze lepiej niż do tej pory.

Usprawnianie to nie tylko rozwiązywanie problemów

Z doświadczeń w pracy Scrum Mastera i Agile Coacha mogę powiedzieć, że większość zespołów grzęźnie na retrospektywach w analizie, co poszło źle, i próbie naprawiania tego. Oczywiście jest w tym bardzo duża wartość, i z reguły opłaca się spostrzeżone problemy rozwiązać, bo ułatwi to pracę zespołowi. Tyle, że skupianie się na naprawianiu powoduje, że retrospektywa jako zdarzenie bywa trudna, a zespoły kończą ją w poczuciu, że trudności się piętrzą i wiele wody w Wiśle upłynie, nim uda się je usunąć.

Często jest tak, że w tych samych zespołach, które borykają się z jakimiś drobnymi problemami, bardziej niż rozwiązanie tychże problemów przydałoby się wprowadzić nową praktykę, zmienić fundamentalnie proces, użyć nowego narzędzia, które usprawni pracę i ułatwi pracę developerom. Zysk ze zrobienia czegoś nowego, zamiast z naprawiania rzeczy niedoskonałych, ale już robionych, często bywa dużo większy. Cała sztuka, by dostrzegać takie możliwości i aktywnie ich poszukiwać. Mając cel – wizję sprawnego, efektywnego zespołu – i dążąc do jego realizacji, możemy odkryć i dokonać takich zmian, które przełożą się w przełomowe usprawnienia.

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 stronę której należy podążać, jest ryzyko, że umiejętność usprawniania się zacznie zamierać. Bo jeśli doskonalimy wszystko to, co było ułomne, i nic takiego już nie dostrzegamy, wydaje się, że nie sposób już dokonać dalszych usprawnień.

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 usprawnienia działania były podejmowane. Sama zmiana dokonuje się, a jakże, tylko nie przekłada się na wymierne efekty, na jakie liczyliśmy 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 tak, by móc dzięki temu sprawniej planować iteracje. Po pewnym czasie rzeczywiście zmiana zaczęła być zauważalna: planowanie 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 efektywność działań zespołu podczas tego zdarzenia (plan, a potem praca w iteracji). Dzięki „usprawnieniom” bardzo efektywnie tworzony był kiepski plan działania w iteracji, a i realizacja tego planu pozostawiała wiele do życzenia.

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 zaś udaje się już o wiele rzadziej i nie zawsze da się jednoznacznie stwierdzić).

Metryki

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 metrykami. Nie takimi, na które patrzy management, ale takimi, które zespołowi pokażą, czy faktycznie coś usprawnia.

Jakie to mogą być metryki? Na przykład skuteczność osiągania ustalonych w czasie planowania celów sprintów. Lub to ile wymagań z prognozy na sprint (forecast) udaje się rzeczywiście zrealizować. Dla zespołu metryką może być również velocity, które dzięki usprawnieniom może zacząć rosnąć nie dlatego, że zaczynamy zwiększać oszacowania pracochłonności, ale dlatego, że udaje nam się więcej wymagań zrealizować w iteracjach.


SZKOLENIA ZWIĄZANE Z TEMATYKĄ ARTYKUŁU


O autorze: Rafał Markowicz
Scrum Master z wieloletnim doświadczeniem, w branży IT od 2001. Praktyk Agile, ekspert w zakresie inżynierii testów i zapewnienia jakości. Pracował jako analityk systemowy i biznesowy, jest doświadczonym developerem, managerem i konsultantem.

Inne artykuły tego autora