Każda ceremonia w metodologii agile zakłada równe szanse. 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 ocenia jego wartości. Proszę usunąć te założenia – dodajmy menedżera zatwierdzającego awanse, wskaźnik przekazywany wyżej w hierarchii oraz szacunek, który przekształca się w obietnicę – a cała procedura nie tylko przestaje przynosić oczekiwane rezultaty. Działa ona odwrotnie. 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 nazwanie jest pierwszym krokiem do ich odrzucenia.

Mechanizm zapadkowy prędkości

Zacznijmy od najsilniejszego argumentu: osoba, która wymyśliła punkty fabularne, wyparła się ich. „Lubię mawiać, że być może to ja wymyśliłem punkty fabularne, a jeśli tak było, to teraz przepraszam” –https://ronjeffries.com/articles/019-01ff/story-points/Index.html napisał Ron Jeffries w 2019 roku – a 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 informuje, ż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 tej szkody. 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 przestaje ona funkcjonować jako cel produktywności, staje się mechanizmem zapadkowym: wynik z ostatniego sprintu stanowi dolną granicę 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 ta zachęta — zawyżają wyniki. Zadanie, które w poprzednim kwartale miało wartość 3, w bieżącym kwartale ma wartość 5; liczba ta rośnie, a tempo dostarczania produktów 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 właśnie przestrzeń, którą wypełnia inflacja punktowa.

Najsilniejszą podstawą merytoryczną przemawiającą za utrzymaniem wskaźnika „velocity” w odpowiednich granicach jest DORA. Dziesięć lat badań nad czynnikami wpływającymi na wydajność dostarczania oprogramowania zaowocowało czterema wskaźnikami — częstotliwością wdrażania, czasem realizacji, wskaźnikiem niepowodzeń zmian oraz czasem przywrócenia — a wskaźnik „velocity” celowo nie znalazł się wśród nich, ponieważ punkty fabularne nie są porównywalne między zespołami i mierzą nakład pracy, a nie dostarczoną wartość. Zasada jest zatem prosta i uzasadniona: należy prognozować na podstawie prędkości, ale nigdy nie oceniać jej. Jeśli ktoś spoza zespołu zapyta: „Czy Państwa prędkość jest dobra?”, rozwiązanie leży u źródła tej liczby — szczera odpowiedź brzmi: „Co właściwie próbuje Pan/Pani zmierzyć?”. W naszym rozdziale poświęconym prędkości pokazujemy, jak zachować rzetelność, a w rozdziale planowanie prędkości i wydajności wyjaśniamy, jak wykorzystać ten wskaźnik do tego 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 sformułowanego na podstawie 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 ten ulega przesunięciu, winą obarcza się programistę 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 przekwalifikowane na zobowiązanie, przybiera formę konkretnego terminu, a gdy nie uda się go dotrzymać, niepowodzenie zostaje przypisane zespołowi — po czym 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, to odpowiedzialność spada na Państwa. Szacunki są odrzucane — „to nie może być słuszne, proszę to powtórzyć” — aż zespół poda dowolną liczbę, która pozwoli dotrzymać terminu, a wtedy planowanie staje się farsą z z góry ustalonym wynikiem. W języku tym dostrzega się nawet wymowną asymetrię: jeśli powie się „to zajmie dziesięć dni”, kierownik zapyta „czy jest pan pewien, ż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 występuje. 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 konkretną datę.

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 wyraźnie oddzielać te dwa pojęcia. Proszę przewidzieć przedział wartości i określić założenia leżące u jego podstaw. Należy również uważać 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 agile opartym na szacunkach, lecz z metodą kaskadową w przebraniu. Dave West z firmy Forrester nazwał to zjawisko „water-scrum-fall”, a jego sercem jest „pranie szacunków”. W naszym rozdziale punkty fabularne a godziny wyjaśniamy, dlaczego przelicznik ten stanowi źródło problemów, a nie rozwiązanie.

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.

Te historie z życia zawodowego są konkretne i dotkliwe. Jeden z inżynierów opisał, jak jego wcześniejsze uwagi powróciły podczas corocznej oceny jako dowód na to, że „zbyt często narzeka”. 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 nauczyli się, ż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ść przestaje wiązać 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ące dwa lata i obejmujące 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 samooceny — dlaczego więc menedżer obecny w pomieszczeniu sporządza notatki?

Nie liczcie na bohatera

W samym rozwiązaniu tkwi potencjalna usterka. Te zniekształcenia są zazwyczaj powstrzymywane, ponieważ ktoś z kierownictwa — lider lub kierownik projektu z charakterem — osobiście chroni zespół: odmawia przekazywania danych dotyczących prędkości na wyższe szczeble, przekształca szacunki w 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 pełniąca rolę tarczy 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ę tymczasowo przychylną, a farsa powróci w dniu, w którym ta osoba odejdzie.

Na tym polega różnica między postrzeganiem władzy jako źródła niepowodzeń a postrzeganiem jej jako czegoś stałego. Rozdział poświęcony bezpieczeństwu psychologicznemu omawia budowanie atmosfery szczerości, która nie zależy od tego, kto znajduje się w pomieszczeniu, a Główna Dyrektywa dotyczy normy, która sprawia, że ta atmosfera się utrzymuje. Kiedy ta rytualna procedura w końcu prowadzi wyłącznie do kontrolowanych pozorów, dochodzi się do pustki w 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 nie są porównywalne między zespołami. Jeśli kierownik spoza zespołu zapyta, czy Państwa velocity jest dobre, uczciwą odpowiedzią będzie zadanie pytania w zamian: co właściwie próbuje Pan/Pani zmierzyć? Proszę raportować 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 zgłoszone podczas 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, w 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?

Należy świadomie i wyraźnie oddzielać szacowanie od podejmowania zobowiązań. Szacunek to prawdopodobieństwo; zobowiązanie to obietnica; zmywanie jednego w drugie, a następnie wymaganie od zespołu dotrzymania tego, do czego doszło w wyniku takiego zmywania, prowadzi do utraty zaufania. Proszę prognozować przedział czasowy, określać założenia i nigdy nie dopuszczać, by 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 nie musi wiązać się z wypowiedzeniem ani jednego słowa, by osłabić szczerość — osoba zatwierdzająca awanse sama w sobie stanowi czynnik zniechęcający. Proszę przekazywać zadania do realizacji w górę hierarchii, a nie zmieniać rozkład miejsc.

Warto przeczytać