Antykultura zobowiązań

Pewnego dnia w firmie zjawił się nowy dyrektor. Chciał poznać ludzi, dowiedzieć się jak działa firma – wśród jego rozmówców znalazłem się i ja. Zapytał, co mogę mu powiedzieć o realiach pracy zwinnej, na co odpowiedziałem mniej więcej:

– Ludzie super, procesy gorzej, a odkąd odszedł Pan X, to kultura pracy trochę podupadła.

Wtedy on powiedział coś, co dobrze zapamiętałem, coś co czekało dobre 10 lat w mojej głowie, żebym mógł otworzyć ten artykuł:

– Jeśli jeden człowiek odszedł i kultura się zmieniła, to nie była to kultura.

Dlatego mówiąc ​kultura ​będę miał na myśli utrwalony, powszechny, wypracowany przez lata, zakodowany w głowach, narzędziach i procesach sposób postępowania. A ​antykultura​? Antykultura to anty-wzorzec, kultura, która jest w jakiś sposób niepożądana, niewłaściwa, szkodliwa. Jednocześnie masowa i trwale wpisana w sposób działania organizacji.

A ​zobowiązania?​ W końcu będziemy mówić o ​antykulturze zobowiązań​. Podam Wam kilka przykładów zobowiązań z życia:

• kupuję kopertę i znaczek, prawidłowo adresuję a poczta zobowiązuje się dostarczyć mój polecony do adresata w ciągu 5 dni (ha!),
• budzę dziecko, daję śniadanie i zobowiązuję się zawieźć je na 8.00 do szkoły,
• zostawiam majstrowi 2 rolki tapety i klej, o które poprosił, a on do jutra zobowiązuje się wykleić je w moim pokoju,
• rozbijam Backlog na 20 mniejszych, szacuję, że praca potrwa 5 sprintów, proszę o 10k$ na niezbędne narzędzia, 2 sprinty na bufor i zobowiązuję się dostarczyć funkcjonalność na koniec sierpnia.

Co łączy te przykłady? Każdy z nich można zapisać w formie takiego schematu: ​wiedząc jakie zasoby są mi potrzebne oraz świadomie wykonując określone działania na tych zasobach, z dużym prawdopodobieństwem wypełnię swoje zobowiązania​. Oczywiście zdarza się, że dziecko ma gorączkę, poczta zajęta jest utylizacją kart wyborczych, a majstrowi w poniedziałek trzęsą się ręce. Tym niemniej i takie ryzyka można ograniczyć odpowiednio długo myśląc w przód i po prostu planując. Przykład ostatni, to mała prowokacja z mojej strony. Tak naprawdę powinien brzmieć:

• rozbijam Backlog na 20 mniejszych, szacuję, że praca potrwa 5 sprintów, proszę o 10k$ na niezbędne narzędzia, 2 sprinty na bufor i zobowiązuję się dostarczyć funkcjonalność na koniec sierpnia. ​Niestety, okazuje się, że nie 5 sprintów tylko 8, nie 10k$, tylko 20k$ i nie ta funkcjonalność, tylko jej chudy wariant. I to nie jest bynajmniej wyjątek.

(Anty) kultura zobowiązań dostarczania oprogramowania w firmach często prowadzi do sytuacji, w której ani obiecany zakres, ani koszt, ani termin nie są dotrzymywane, co prowadzi do frustracji, rozczarowań i negatywnego wpływu na biznes. Dlaczego długoterminowe obietnice dostarczania z reguły się nie sprawdzają? Albo inaczej – jakie elementy tej antykultury sprawiają, że nie wypełniamy zobowiązań? Jest ich kilka:

• nieprawdziwe założenie, że zespół ma bardzo dużą kontrolę nad tworzeniem oprogramowania na założoną datę (​przecież wystarczy dokładnie policzyć potrzebne zasoby i przypilnować zachowań zespołu)​ . Inaczej mówiąc: nieuprawnione przeniesienie doświadczeń zobowiązań życia codziennego na domenę software’ową. Dave Snowden nazywa to domeną ​Complex ​w ramach klasyfikacji Cynefin. Pokrewnym wytłumaczeniem jest tutaj nieświadomość istnienia błędów poznawczych (​cognitive bias​) oraz ​dowodów anegdotycznych,
• nieświadomość faktu, że prawdopodobieństwo opóźnienia zobowiązania jest większe od prawdopodobieństwa ukończenia go przedwcześnie, ponieważ jest tylko skończona liczba działań, jakie można podjąć, by zobowiązanie przyspieszyć i nieskończona liczba okoliczności, jakie mogą zobowiązanie opóźnić. Pisze o tym Mike Cohn w “Agile Estimating and Planning”,
• nieelastyczny backlog lub definicja funkcjonalności, czyli taka definicja zakresu pracy, która daje mało elastyczności. Raz zaczęta, musi zostać w całości zakończona, bo nieukończenie choćby jej małego fragmentu powoduje niedziałającą całość,
• i wreszcie – sama treść zobowiązania, w formie kontraktu lub umowy, nie pozwala na elastyczność, przerzuca większość ryzyka na wykonawcę (firmę IT), a elastyczność zakresu prac postrzega jako porażkę, często usankcjonowaną karami umownymi. Chyba najwięcej można się dowiedzieć od Łukasza Węgrzyna, prawnika, specjalisty w dziedzinie ​zwinnych kontraktów,​ k​tórego miałem przyjemność poznać.

Dodatkowo, w swoim życiu zawodowym, spotkałem już skrajne podejścia do zobowiązań. Oba są wg mnie niepraktyczne. Nazywam je “lewe” i “prawe”:

• lewe – ​zobowiązań długoterminowych nie da się składać, ostatecznie można na długość sprintu, ale życie i tak pokaże, co zdążymy zrobić i mówi się trudno,
• prawe ​– zobowiązania, nawet odległe, można precyzyjnie zdefiniować, zaplanować i mając dobry aparat matematyczny i dobrego PMa, dopilnować ich wykonania.

Podejście pierwsze jest niepraktyczne, bo biznes chce i będzie się opierał na jakichś długoterminowych obietnicach. Podejście drugie, to agresywny project management, który większość z nas dobrze zna, który kładzie nacisk na obliczenie i wykonanie statycznego planu, a potem szukanie winnych i “lessons learned” dla przyszłych pokoleń.

No więc jakie jest rozwiązanie? Jak żyć z problemem zobowiązań? Konfucjusz mawiał, że naprawę państwa trzeba zacząć od naprawy pojęć​. Zastanówmy się w takim razie, jak naprawić pojęcie ​zobowiązanie​ (​commitment)​ . Na początek, spróbujmy zastąpić go słowem ​forecast (​prognoza)​ . Jakie cechy ma to pojęcie?

• Prognoza z definicji jest niedokładna. Tak samo jak zobowiązanie w IT, ale przynajmniej nie obiecuje swoim znaczeniem czegoś innego. Słysząc w TV prognozę pogody na weekend, zarówno nadawca jak i odbiorcy zgadzają się, że może się nie sprawdzić.
• Prognoza wymaga częstej, konstruktywnej dyskusji o tym, czy jeszcze jest prawdziwa, a jeśli nie – jak stworzyć lepszą prognozę. Zobowiązanie, dla odmiany, najczęściej wywołuje dyskusję, jak uratować je w niezmiennym kształcie, kto zawinił, a w skrajnych przypadkach jak sprawić, żeby nikt nie poznał, że się nie wywiązaliśmy. Kojarzycie historię ​Boeing 737Max​?
• Prognoza (np. pogody) ma tę cechę, że jej dokładność maleje z czasem i to pomimo zaawansowanych metod jej tworzenia, np. algorytmów pogodowych. Nie da się więc pogodzić dokładności prognozy i jej czasu, to bardzo ważny kulturowy aspekt.

Wiedząc to, możemy usprawnić proces planowania i formułowania zobowiązań (od teraz: prognoz​). Byłem kiedyś w roli konsultanta na kilkudziesięcioosobowym planningu w stylu SAFe, który polegał z grubsza na tym, że kilka zespołów scrumowych, tworzących razem duży produkt, próbowało przez kilka dni zapełnić wspólną siatkę pustych sprintów, planując zobowiązania na ok. 3 miesiące do przodu. W sprintach umieszczano Backlog Itemy wg jakichś priorytetów aż do momentu, kiedy cała pusta siatka sprintów zapełniła się pracą, zostawiając jeden sprint buforowy. Na koniec każdy zespół wyjaśnił kierownictwu, do czego się zobowiązuje (​czyli wszystko, co zmieściło się w siatce)​ i odbyło się spotkanie, gdzie świętowaliśmy planistyczny sukces. Uświadomiłem sobie, że zawarliśmy tzw. ​zobowiązanie binarne,​ ​​a więc takie, które nakazuje nam dostarczyć każdy Backlog Item z siatki sprintów na umowną datę. Co więcej, w naszym zobowiązaniu potraktowaliśmy każdy Backlog Item jednakowo – co najwyżej różniły się estymowaną wielkością/rozmiarem wyrażonym w skali Fibonacciego.

Dlaczego więc po tych 3 miesiącach, jedne Backlog Itemy zostały dostarczone, a inne nie, psując binarne zobowiązanie i wywołując frustracje i rozczarowania? Uświadomiłem sobie wówczas, że na planningu oraz w trakcie tych 3 miesięcy zabrakło nam konstruktywnej dyskusji o wiarygodności naszych prognoz, zabrakło języka do wyrażania wiarygodności prognoz za pomocą liczb, zabrakło nam wreszcie umiejętności konstruktywnej dyskusji na temat: ​jak podnieść wiarygodność naszej prognozy​. W dodatku taka rozmowa powinna być prowadzona dla każdego Backlog Itemu lub ich ciągu tworzącego np. EPIC, a nie dla całego trzymiesięcznego projektu/release’u. Backlog Itemy (BI) są bowiem bardzo różne. Uświadomiłem sobie wtedy, że:

• BI, które mają zależności, mają ​niższe ​prawdopodobieństwo dostarczenia, niż te niezależne.
• BI umieszczone w pierwszych sprintach siatki mają ​większe ​prawdopodobieństwo dostarczenia, niż te w ostatnich.
• BI wymagające specyficznej wiedzy mają ​mniejsze prawdopodobieństwo dostarczenia, niż te wymagające wiedzy ogólnej.
• BI, które już raz się spóźniły, mają ​większe p​rawdopodobieństwo kolejnych opóźnień.
• BI podobne do takich, które już robiliśmy mają ​większe ​prawdopodobieństwo dostarczenia, niż te prototypowe/awangardowe.
• BI, które są małe, mają ​większe p​rawdopodobieństwo dostarczenia, niż duże.

Od tej pory zamiast ​zobowiązań binarnych​ ​zacząłem myśleć o ​prognozach probabilistycznych.​ Takich, gdzie każda funkcjonalność (BI, Epic itp.) ma pewne prawdopodobieństwo dostarczenia, biorąc pod uwagę powyższe cechy (zależności itp.). Natychmiast potem wyobraziłem sobie kolejny planning, gdzie prowadzimy już inną dyskusję:

• funkcjonalność A ma niską szansę na ukończenie, bo pomimo że mieści się w pustej siatce, to:
  • już się 2x spóźniła,
  • umieściliśmy ją w ostatnim sprincie siatki,
  • wymaga ekspertów, których mamy tylko trzech,
  • jest zależna od innych funkcjonalności z zespołu X.
• zatem jeśli bardzo nam na tej funkcjonalności zależy, porozmawiajmy co zrobić, żeby podnieść​ prawdopodobieństwo jej ukończenia. Jakie akcje możemy zdefiniować na tym planningu? Redukcja dependencji? Więcej ekspertów? Wyższy priorytet w siatce sprintów?

Jak definiować to prawdopodobieństwo? Jak wyrazić za pomocą liczb ocenę ryzyka niedostarczenia funkcjonalności? Można zrobić to w ten sposób:

• zdefiniuj cechy backlogu, które mają wpływ na ryzyko jego niedostarczenia. Mogą to być te zaproponowane przeze mnie, mogą być inne – najlepiej żeby organizacja wypracowała je jakąś metodą, których Scrum Masterzy znają mnóstwo,
• dla każdej cechy backlogu zaproponuj 3 dyskretne wartości, na przykład:
  • zależności: brak – nieliczne – wiele
  • miejsce w harmonogramie sprintów: początkowe – środkowe – końcowe
  • unikalność: wyjątkowe – trochę podobne – bardzo podobne do poprzednich
  • (…)
• dla każdej z tych dyskretnych wartości zaproponuj wartość liczbową, na przykład:
  • zależności: 1 – 5 – 10
  • miejsce w harmonogramie: 10 – 70 – 90
  • unikalność: 100 – 200 – 700
  • (…)
• wartości mogą mieć różne rzędy wielkości, jeśli na przykład uważamy, że pewne cechy silniej wpływają na ryzyko niedostarczania niż inne,
• dla każdej prognozowanej funkcjonalności należy wykonać dodawanie (lub inną operację, np. mnożenie) czynników ryzyka. Wynik operacji to sumaryczna wartość ryzyka wynikająca z cech backlogu, która stanowi ważną informację obok klasycznych estymat, budżetu itp.

Planning i wykonanie oparte o ciągle aktualizowane prognozy, wyrażone liczbowo w skali rozumianej przez całą organizację, mają szansę skutecznie zmieniać kulturę zobowiązań, dostarczają bowiem nie tylko metodykę prognoz probabilistycznych, ale też konkretne mechanizmy liczbowe do oceny wiarygodności tychże prognoz.

Tradycyjne zobowiązania w IT, często zapożyczone z otaczającego nas świata zjawisk prostych lub co najwyżej skomplikowanych, nie są właściwym sposobem składania obietnic w systemach złożonych wg Cynefin. (Anty)kultura używania tradycyjnych zobowiązań ma szansę ustąpić miejsca prognozom, pod warunkiem zdefiniowania mechanizmów konstruktywnej rozmowy na ich temat, głównie liczbowej oceny ryzyka dostarczenia danej funkcjonalności. Mam szczerą nadzieję, że przedstawione tutaj doświadczenia będą pomocne w:

• wytłumaczeniu organizacjom dlaczego tradycyjne zobowiązania w IT nie są najlepszym sposobem na składanie obietnic,
• znalezieniu właściwych słów, argumentów i przykładów wzmacniających siłę przekonywania do modelu opartego na prognozach, a nie zobowiązaniach,
• zaprojektowaniu usprawnień do procesów planowania i dostarczania zobowiązań software’owych w oparciu o model probabilistyczny, a nie binarny.

Naprawę państwa należy zacząć od naprawy pojęć, naprawę organizacji – z pewnością też!

Artykuł dla Agile Polski napisał Michał Rosołowski.
Michał jest ekspertem Motoroli Solutions w tematyce Agile oraz jednym z organizatorów cyklicznej międzynarodowej konferencji Agile Swarming. Na co dzień pomaga liderom i zespołom krakowskiego oddziału firmy wprowadzać bardziej zwinny sposób pracy. O Agile’owej transformacji wie prawie wszystko, a swoją wiedzą i doświadczeniem dzieli się wspólnie z zaproszonymi gośćmi za pośrednictwem autorskiej serii podcastów  „Twoja transformacja jest lepsza niż moja”.