Każda ceremonia w metodologii agile zakłada równe szanse dla wszystkich. Władza pojawia się wtedy, gdy tych równych szans brakuje.

Planning poker pozwala uniknąć efektu zakotwiczenia tylko wtedy, gdy nikt przy stole nie może podważyć wyników kart. Retrospektywa jest bezpieczna tylko wtedy, gdy szczerość nie wiąże się z żadnymi konsekwencjami. Wskaźnik Velocity jest jedynie prognozą tylko wtedy, gdy nikt spoza zespołu nie dokonuje jego oceny. Jeśli usunie się te założenia (dodając menedżera zatwierdzającego awanse, wskaźnik przekazywany wyżej w hierarchii, szacunek, który staje się wiążącą obietnicą), ceremonia ta nie tylko przestaje przynosić oczekiwanych rezultatów. Jej działanie ulega odwróceniu. Zaczyna działać przeciwko osobom, dla których została stworzona. W niniejszym rozdziale wymieniono trzy najistotniejsze sposoby, w jakie to się dzieje, ponieważ ich zidentyfikowanie jest pierwszym krokiem do ich odrzucenia.

Mechanizm zapadkowy prędkości

Zacznijmy od najsilniejszego argumentu: osoba, która wymyśliła punkty fabularne, odcięła się od nich. „Lubię mawiać, że być może to ja wymyśliłem punkty fabularne, a jeśli tak było, to teraz przepraszam” – napisał Ron Jeffries w 2019 roku. Wyraził się konkretnie: „Uważam, że porównywanie zespołów pod kątem jakości szacunków lub prędkości jest szkodliwe”. Kiedy wynalazca danej jednostki mierzenia stwierdza, że jest ona wykorzystywana w sposób szkodliwy dla zespołów, ciężar dowodu spoczywa na każdym, kto nadal stosuje ją jako miernik wyników.

To właśnie poprzez mechanizm „ratchet” prędkości dochodzi do tych negatywnych skutków. Prędkość ma być prywatnym wskaźnikiem samokontroli zespołu: średnią kroczącą liczby zrealizowanych punktów, wykorzystywaną do prognozowania czasu potrzebnego na realizację zaległości. W momencie, gdy prędkość przestaje być jedynie wewnętrznym wskaźnikiem i staje się celem produktywności, zamienia się w mechanizm zapadkowy: wynik z ostatniego sprintu stanowi minimalny poziom dla bieżącego sprintu, a jedynym dozwolonym kierunkiem zmiany jest wzrost. Zespoły nie są głupie, więc reagują w jedyny sposób, na jaki pozwala im ten system motywacyjny. Zawyżają wyniki. Zadanie, które w poprzednim kwartale miało wartość 3, w bieżącym kwartale ma wartość 5 – liczba rośnie, a tempo dostarczania nie przyspiesza. Nawet Mike Cohn, autorytet w dziedzinie punktacji, przyznaje, że ten mechanizm działa: najmniejsza sugestia, że prędkości będą porównywane, powoduje stopniową i stałą inflację punktów.

Velocity over six sprints with two outliers pulling the average above the sustainable rate 0 30 60 points avg 35 actual 29 s1 s2 s3 s4 s5 s6 easy sprint carry-over plan to the teal line, not the orange one
Prędkość jest miarą tempa, a nie wydajności. Różnica między docelowym poziomem, do którego dąży dana osoba, a rzeczywistym poziomem, jaki zespół jest w stanie utrzymać, stanowi dokładnie tę lukę, którą wypełnia inflacja punktowa.

Najsilniejszą podstawą, na którą można się powołać, aby utrzymać wskaźnik prędkości w odpowiednich granicach, jest DORA. Dziesięć lat badań nad czynnikami pozwalającymi przewidywać wydajność dostarczania oprogramowania zaowocowało wyodrębnieniem czterech wskaźników (częstotliwość wdrażania, czas realizacji, wskaźnik niepowodzeń zmian oraz czas przywrócenia sprawności), a wskaźnik prędkości celowo nie znalazł się wśród nich, ponieważ punkty opowieści nie są porównywalne między zespołami i mierzą nakład pracy, a nie dostarczoną wartość. Zasada jest zatem prosta i uzasadniona: prognozujcie na podstawie prędkości, ale nigdy nie oceniajcie jej. Jeśli ktoś spoza zespołu zapyta: „Czy Państwa prędkość jest dobra?”, rozwiązanie leży przed samym wskaźnikiem. Szczera odpowiedź brzmi: „Co właściwie próbuje Pan/Pani zmierzyć?”. Nasz rozdział poświęcony prędkości pokazuje, jak zachować rzetelność, a planowanie prędkości i wydajności wyjaśnia, jak wykorzystać ten wskaźnik do jedynego celu, do którego się nadaje.

Wycena prania brudnych pieniędzy

Drugie zniekształcenie jest bardziej subtelne, ponieważ sprawia wrażenie odpowiedzialności. „Pranie szacunków” polega na cichym przekształceniu szacunku (przypuszczenia opartego na minimalnej ilości informacji, jaką kiedykolwiek będą Państwo mieli) w zobowiązanie, a następnie wymaganiu od zespołu jego dotrzymania, tak jakby podpisali Państwo umowę. Przypuszczenie trafia na spotkanie planistyczne; ustalany jest termin; a gdy termin się przesuwa, winę ponosi programista za „niezrealizowanie szacunku”.

relabelled hardens it slips Estimate “Commitment” Deadline Blame a guess a promise a fixed date “you missed it” the guess is now treated as the team’s fault
Ten proces przebiega w pętli: przypuszczenie zostaje przemianowane na zobowiązanie, przybiera formę konkretnego terminu, a gdy termin ten nie zostanie dotrzymany, niepowodzenie zostaje przypisane zespołowi. Następnie wszystko zaczyna się od nowa.

Praktycy opisują cały cykl „prania” bez potrzeby, by ich do tego zachęcać: szacunki w magiczny sposób stają się zobowiązaniami, a jeśli nie uda się osiągnąć zakładanego wyniku, odpowiedzialność spada na Państwa. Szacunki są odrzucane („to nie może być poprawne, proszę to powtórzyć”) do momentu, aż zespół poda liczbę, która pozwoli dotrzymać terminu – w tym momencie planowanie staje się farsą z z góry ustalonym wynikiem. W języku tym dostrzegalna jest nawet wymowna asymetria: jeśli powie się „zajmie to dziesięć dni”, kierownik zapyta: „czy jest Pan/Pani pewien/pewna, że nie może to być dziewięć?”; jeśli powie się „to jest dziesięć punktów”, to z powodów, których nikt nie potrafi do końca uzasadnić, ten sam odruch nie pojawia się. Punkty fabularne miały częściowo służyć jako zbroja przeciwko właśnie takiej presji, a „pranie szacunków” to presja, która pokonuje tę zbroję, przekształcając punkty z powrotem w termin.

Klasycznym rozwiązaniem jest podejście Mike’a Cohna, które powstało jeszcze przed wprowadzeniem naszego terminu: oddzielenie szacowania od podejmowania zobowiązań. Szacunek to rozkład prawdopodobieństwa; zobowiązanie to decyzja podjęta przez zespół dotycząca tego, co z całą pewnością jest w stanie zrealizować. Należy te pojęcia wyraźnie od siebie oddzielać. Proszę przewidzieć przedział wartości i określić założenia leżące u jego podstaw. Proszę również zwrócić uwagę na przypadek kumulacji. Gdy zakres, czas i koszt są z góry ustalone, a praca jest jedynie podzielona na dwutygodniowe sprinty, nie mamy do czynienia z metodą agile opartą na szacunkach, lecz z metodą kaskadową w przebraniu. Dave West z firmy Forrester nazwał to zjawisko „water-scrum-fall”, a jego sednem jest „pranie szacunków”. W naszym rozdziale punkty fabularne a godziny wyjaśniamy, dlaczego przeliczenie to jest przyczyną niepowodzeń, a nie rozwiązaniem.

Bankowanie opinii

Trzecie zniekształcenie jest najpoważniejsze, ponieważ sprawia, że ceremonia, która wydaje się najbezpieczniejsza, staje się obciążeniem. Gromadzenie informacji zwrotnych polega na tym, że szczere uwagi z retrospektywy są gromadzone, a następnie dyskretnie wykorzystywane przeciwko Państwu w późniejszym czasie: podczas oceny wyników, ustalania wysokości premii czy nieoficjalnej rozmowy na temat „dopasowania”. Retrospektywa jest przedstawiana jako bezpieczna przestrzeń, w której można mówić szczerze. Gromadzenie informacji zwrotnych to odkrycie, że szczerość ma swój termin rozliczenia.

Opowieści z życia zawodowego są konkretne i dotkliwe. Jeden z inżynierów opisał, jak jego uwagi z retrospektywy powróciły podczas corocznej oceny jako dowód na to, że „zbyt często zgłasza zastrzeżenia”. Inny ujął to wprost: kierownictwo gromadzi wszystkie skargi, by wykorzystać je podczas corocznej oceny premii. Ten efekt zniechęcający nie wymaga nawet złych intencji. Osoba zatwierdzająca awanse nie musi w ogóle zabierać głosu podczas spotkania. Sama jej obecność wystarczy, by szczere uwagi stały się niejasne i by wszyscy zrozumieli, że najmądrzejszym posunięciem jest udawanie zadowolenia. W naszym rozdziale „Dlaczego retrospektywy kończą się niepowodzeniem” omawiamy sposób zaprojektowania sesji, dzięki któremu szczerość nie będzie już wiązała się z ryzykiem dla kariery.

W tym miejscu literatura poświęcona bezpieczeństwu przestaje opierać się na ogólnikowych stwierdzeniach. Badania Amy Edmondson dotyczące bezpieczeństwa psychologicznego oraz Projekt Arystoteles firmy Google – trwający dwa lata projekt obejmujący analizę 180 zespołów – wykazały, że bezpieczeństwo psychologiczne jest najsilniejszym z pięciu zidentyfikowanych czynników: tym, na którym opierają się pozostałe cztery. Zespół, który zdał sobie sprawę, że jego informacje zwrotne są gromadzone, z definicji nie odczuwa bezpieczeństwa psychologicznego, a retrospektywa, która udaje, że jest inaczej, jest jedynie przedstawieniem niosącym ze sobą ryzyko prawne. Przewodnik po Scrumie określa retrospektywę jako proces, w ramach którego zespół dokonuje samokontroli. Dlaczego więc menedżer obecny w pomieszczeniu sporządza notatki?

Nie należy liczyć na bohatera

W samym rozwiązaniu tkwi potencjalna usterka. Takie nieprawidłowości są zazwyczaj powstrzymywane, ponieważ ktoś z kierownictwa (kierownik, kierownik ds. zarządzania projektami o silnym charakterze) osobiście osłania zespół: odmawia przekazywania danych dotyczących prędkości na wyższe szczeble, przedstawia szacunki jako prognozy oraz dba o to, by treść retrospektywy pozostała w gronie uczestników. To działa, ale tylko dopóki ta osoba pozostaje na stanowisku. Osoba ta nie stanowi systemu. Jeśli uczciwość Państwa ceremonii opiera się na gotowości jednego menedżera do przyjmowania na siebie presji, nie mają Państwo bezpiecznych ceremonii. Mają Państwo ceremonię, która jest tymczasowo przychylna, a farsa powraca w dniu, w którym ta osoba odejdzie.

Na tym polega różnica między „Władzą” jako trybem niepowodzenia a „Władzą” jako czymś stałym. Rozdział poświęcony bezpieczeństwu psychologicznemu omawia budowanie szczerości, która nie zależy od tego, kto znajduje się w pomieszczeniu, a Główna Dyrektywa dotyczy normy, która zapewnia jej trwałość. Kiedy uformalizowana ceremonia w końcu nie przynosi nic poza kontrolowanym pozorem, dochodzi się do próżni realizacji: czwartego trybu, w którym gromadzenie informacji zwrotnych wyrządza najcichsze szkody.

Najczęściej zadawane pytania

Jak mogę zapobiec sytuacji, w której kierownictwo wykorzystuje wskaźnik prędkości przeciwko mojemu zespołowi?

Proszę nie przywiązywać do tego zbytniej wagi. Velocity stanowi dane wejściowe do prognozowania, a nie wskaźnik wydajności. W badaniach DORA celowo pominięto ten wskaźnik, ponieważ wyniki poszczególnych zespołów nie są porównywalne. Jeśli kierownik spoza zespołu zapyta, czy Państwa velocity jest dobre, uczciwą odpowiedzią będzie odwrócenie pytania: co właściwie próbuje Pan/Pani zmierzyć? Proszę przedstawiać wyniki i realizację zadań, a nie sumy punktów.

Czy informacje retrospektywne mogą zostać wykorzystane przeciwko mnie podczas oceny wyników pracy?

Zdarza się to, a obawa ta jest uzasadniona. Uczestnicy spotkań informują, że szczere uwagi z retrospektywy powracają po kilku miesiącach w postaci zarzutu, że zbyt często zgłaszają zastrzeżenia. Jest to zjawisko zwane „gromadzeniem informacji zwrotnej” i właśnie dlatego istnieją zasady anonimowości, wykluczenia przełożonych oraz „zasada Vegas”. Retrospektywa, podczas której szczerość stanowi zagrożenie dla kariery, nie zapewnia bezpieczeństwa psychologicznego i żadna technika facylitacji tego nie naprawi. Należy zmienić układ relacji władzy, a nie sam sformułowanie.

Jak zapobiec sytuacji, w której terminy orientacyjne stają się terminami ostatecznymi?

Proszę wyraźnie i świadomie oddzielać szacowanie od podejmowania zobowiązań. Szacunek to prawdopodobieństwo; zobowiązanie to obietnica; zacieranie granicy między nimi, a następnie wymaganie od zespołu dotrzymania tego, co z tego wynikło, prowadzi do utraty zaufania. Proszę prognozować przedział wartości, określać założenia i nigdy nie dopuszczać, aby przypuszczenie sformułowane podczas spotkania planistycznego zostało przytoczone jako termin, do którego zespół się zobowiązał.

Czy mój przełożony powinien uczestniczyć w retrospektywie, czy też poprowadzić spotkanie stand-up?

Zasadniczo nie. Przewodnik po Scrumie określa retrospektywę jako proces samooceny zespołu, a codzienne spotkanie jako formę koordynacji działań samych programistów. Obecność osoby sprawującej władzę w pomieszczeniu może zniechęcić do szczerości, nawet jeśli nie wypowie ani jednego słowa. Osoba zatwierdzająca awanse z natury rzeczy wywiera efekt zniechęcający. Proszę przekazywać zadania do realizacji w górę hierarchii, a nie zmieniać rozkład miejsc.

Warto przeczytać