Inspect and Adapt

Inspect and Adapt to termin wielokrotnie pojawiający się w Przewodniku po Scrum. Sami nie jeden raz przywoływaliśmy go na naszym blogu, nigdy jednak nie był on głównym tematem. Aż do dziś.

 

Regularna retrospekcja

Wiele razy przy okazji filmów na naszym kanale na YouTube czy we wpisach na blogu wspominaliśmy o zasadzie Inspect and Adapt. Wiele razy mówiliśmy też o wykorzystaniu I&A w codziennym życiu jak również o tym, że wierzymy w jego działanie.

Wielokrotnie w obliczu wyzwań czy badaniu co poszło nie tak posługiwaliśmy się tym podejściem. Zwykle nasze działania w tym kierunku są zaplanowane i dzieją się regularnie – zgodnie z podejściem iteracyjnym. Niczym w scrumowym Sprincie, na koniec każdego etapu przyglądamy się naszym procesom i ich rezultatom.

Działanie zgodne z Inspect and Adapt polega na ciągłej weryfikacji sposobu, w jaki pracujemy i dostosowywaniu przyszłych działań do wyciągniętych wniosków. Aby było to możliwe, zgodnie z wpisem Tomka Jak znaleźć czas, pieniądze i nie tylko?, musimy zmierzyć wielkość nas interesującą, bo jak mawiał Lord Kelvin

“To measure is to know.”

 

Wykorzystanie Inspect and Adapt

Tytułowa zasada może zostać zastosowana absolutnie wszędzie. Bardzo lubimy pisać i mówić o wykorzystaniu podejścia zwinnego poza informatyką, a nawet poza pracą. Robimy to dlatego, że mamy silne przekonanie o użyteczności tych technik w każdym aspekcie naszego życia.

Na przykład w dość popularnym filmie o Timesheetach popełniliśmy wiele prostych błędów, które przełożyły się na ostateczną ocenę naszej pracy jako chaos. Być może nie było tego widać w ostatecznym materiale (inkrement spełniał wymagania jakościowe), ale sam proces zdecydowanie był chaotyczny.

Sumiennie i rzetelnie przeanalizowaliśmy co poszło nie tak i wyciągnęliśmy z tego wnioski. Na ich podstawie podjęliśmy działania, które miały zapobiec podobnym problemom w przyszłości. I tak się stało! Napotkaliśmy za to mnóstwo innych, nowych wyzwań, z którymi też radzimy sobie w taki sam sposób.

Z Inspect and Adapt korzystamy na koniec każdej iteracji albo po dużych wydarzeniach (np. retrospektywa przetargu czy cyklu szkoleń Scrum wykonanych dla jednej firmy). Podczas retrospektywy, przy użyciu wielu różnych technik i ćwiczeń, zastanawiamy się co jest warte podtrzymania w naszej pracy, a z czego powinniśmy zrezygnować. Uzbrojeni w tę wiedzę poszukujemy możliwości poprawy.

Ale koniec iteracji to nie jedyne miejsce na Inspect and Adapt. W ramach metodyki Scrum podobnie postępujemy podczas Sprint Review, gdzie wspólnie z Interesariuszami dokonujemy przeglądu Backlogu Produktu i podejmujemy decyzje co do zmiany kolejności realizowanych wymagań w przyszłości. Inspect w tym przypadku to przegląd Backlogu, Adapt – ewentualna zmiana w priorytetyzacji.

Przykładów można by mnożyć, bo przecież jest jeszcze Daily Scrum Meeting, na którym ten sam proces dotyczy Sprint Backlogu.

 

Warunki skutecznego Inspect and Adapt

Nie będzie skutecznego Inspect and Adapt bez absolutnej transparentności. Bez niej nie mamy nawet co myśleć o zbieraniu dobrych praktyk i nurtujących nas problemów. Zadbać o właściwy poziom szczerości możemy na wiele sposobów, ale u jej podwalin zawsze będzie bezpieczne środowisko w którym pracujemy.

Nie będzie też skutecznego Inspect and Adapt bez właściwego nastawienia. Nie powinniśmy podchodzić do Sprint Retrospective czy Daily Scrum Meeting na zasadzie “skoro mi każą, to pójdę”. Trzeba uwierzyć w wartość tych elementów dla nas samych. Jeżeli Scrum Master zadba, żeby każdy na własne oczy widział, jak dzięki takim spotkaniom poprawia się jakość i wygoda naszej pracy, to na pewno przełoży się to na jakość wniosków z Inspect and Adapt.

Kolejnym ważnym elementem sesji Inspect & Adapt jest właściwa facylitacja. Pomoże nam ona ukierunkować spotkanie w taki sposób, aby możliwe było osiągnięcie zakładanych celów. Oczywiście nie w każdym przypadku będzie ona niezbędna. W dojrzałym, świadomym zespole może się ona okazać zbędna albo wręcz przeszkadzać. Warto jednak trzymać rękę na pulsie.

Zapewniając przynajmniej te aspekty będziemy w stanie dobrze wykonać naszą pracą, czyli nie tylko znaleźć sam problem, ale także jego rozwiązanie.

 

Po co w ogóle to robić?

Często przy wprowadzaniu zwinnych technik spotykamy się z niemal automatycznym oporem, związanym z reakcją na każdą zmianę. “Po co w ogóle to robić, możemy przecież osiągnąć efekt poprawy w inny sposób?”

Jeśli chcemy pracować lepiej i jeśli wiemy, że mamy z czymś problem to nie możemy pozostawać bierni i oczekiwać, że rozwiąże się on bez naszego udziału. A przecież tak niewiele trzeba, żeby przeanalizować to, w jaki sposób pracowaliśmy i spróbować znaleźć satysfakcjonujące nas rozwiązanie.

Nie powinniśmy jednak oczekiwać, że znajdziemy rozwiązanie trapiącego nas problemu podczas jednej sesji np. Sprint Retrospective. Czasem będzie to trwało dłużej, ale pamiętajmy, że dochodzenie do rozwiązania iteracyjnie będzie zgodne z Agile Mindsetem.

Bo przecież liczy się efekt końcowy. A w tym przypadku będzie nim poprawa jakości naszej pracy.

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: