Po co mi DoD?
Na początku, jako członek zespołu deweloperskiego nie bardzo rozumiałam, po co mi DoD. Traktowałam je jako buzzword, rodzaj oczywistości, coś co wiadomo, że i tak jest do zrobienia. Na którymś retro odkryłam, że wcale tak samo tego nie rozumieliśmy i zobaczyłam wartość w ustaleniu i spisaniu naszych wewnętrznych kryteriów jakości.
Potem zostałam Scrum Masterem i miałam możliwość pracować z naprawdę dobrym inżyniersko zespołem. Czasami rozmawialiśmy o DoD, ale ponieważ zespół sam cisnął na jakość, to jedynie facylitowałam te rozmowy i przynosiłam inspirację z innych zespołów. Rozumiałam wtedy DoD jako coś, co jest międzyzespołowym kontraktem, ułatwiającym współpracę i niwelującym konflikty.
Odgórne zarządzanie zależnościami- scena pierwsza
Duża firma, członkowie zespołów mają różne kompetencje, pozwalające pracować zespołowi nad różnymi funkcjonalnościami. Kilka zespołów w obrębie produktu. Spodziewałam się przy takim setupie dobrze funkcjonującej priorytetyzacji prac nad produktem. Tymczasem rozmowa z Product Ownerem ujawniła, że są ogromne, wielomiesięczne opóźnienia. Skąd ten problem?
Kilka tygodni później już wiedziałam. Była to mieszanka nacisków na szybkie dowożenia (bo i tak są opóźnienia) i wojny pomiędzy zespołami. Wspólne refinementy były trudne i nieefektywne, więc każdy zespół oczekiwał podanych na tacy rzeczy do zrobienia, zdefiniowanej “ich” części pracy. Kadra zarządzająca ratowała sytuację tak, jak potrafiła – grupą architektów i analityków, starających się pociąć i dobrze sprecyzować zadania. Ich doświadczenia i przekonania były takie, że nie da się z tymi zespołami inaczej.
Dało się. Wyszliśmy z tego, chociaż zajęło to ponad rok. Co było kluczem? Definicja ukończenia.
DoD jako kontrakt, świadoma decyzja na poziomie produktu
Kilka kolejnych firm pokazało mi, że moje pierwsze zespoły były raczej nietypowe i świadome dbanie przed deweloperów o przestrzeganie jakości nie jest czymś powszechnym. Pracowałam z zespołami, które nie umiały pisać testów jednostkowych, z firmami, gdzie były osobne działy testowania i wdrożeń. Pracowałam zarówno ze startupami, jak i dużymi firmami podlegającymi regulacjom. Dzięki Tomkowi Wykowskiemu zaczęłam spostrzegać DoD jako kontrakt, świadomą decyzję na poziomie produktu osadzoną w realiach biznesowych.
Dużo osób wiedziało, że specjalizuję się w zagadnieniach związanych z motywacją i samoorganizacją, więc często słyszałam pytanie, jak się ma samoorganizacja zespołu i autonomia poszczególnych osób do DoD w skalowanym Scrumie. Dało mi możliwość pracowania na dziesiątkach casów i uczenia się na tym, jakie były skutki różnych podejść.
Niewidoczna praca niewykonana – scena druga
Jeden ze znajomych Product Ownerów poprosił mnie o pomoc w wyjaśnieniu, dlaczego każdy ficzer, jaki robili przez ostatnie lata zajął im prawie dwa razy więcej czasu niż się spodziewali i był znacznie droższy. Zagadka była tym bardziej tajemnicza, że porównania estymat z realizacją pokazywały lekkie niedoszacowanie, ale nie uzasadniające aż takich różnic.
Pierwszy rzut oka na backlog i tablice zespołów nie pokazał niczego szczególnego. Były tam rzeczy do poprawy, ale raczej ich wpływ nie byłby tak duży. Poprosiłam w końcu o rozrysowanie pipeline na tablicy. Bingo, tutaj kryło się rozwiązanie. Był to klasyczny przypadek water-scrum-falla, gdzie iteracyjna praca zespołu była wciśnięta pomiędzy kaskadowe analizy i wdrożenia robione przez inny dział.
Następne parę miesięcy zajęło nam wyprostowanie tej sytuacji. Od czego zaczęliśmy – od pracy nad Definicją Ukończenia. Wypracowaliśmy ją nie tylko na chwilę obecną, ale też docelową, jaką chcemy osiągnąć w ciągu roku. Ustaliliśmy z wszystkimi zainteresowanymi działami, jak chcemy te zmiany przeprowadzić. Rozważaliśmy trzy modele, w końcu wypracowaliśmy własny, który najlepiej pasował do potrzeb tej organizacji.
Budowa kultury inżynierskiej w oparciu o miary z wykorzystaniem DoD jako narzędzia
Im dłużej wgryzałam się w leana, tym bardziej zmieniało się moje zrozumienie DoD. Myślenie o stratach w produkcji oprogramowania skłoniło mnie do przedefiniowania tego, jak w myśleć o DoD, zaczęłam używać Value Stream Mappingu do definiowania czynności, które tworzą wartość dla klienta. Dłuższy romans z teorią kolejek pokazał mi inne aspekty, związane z szybkością dostarczania. Jestem bardzo wdzięczna wszystkim osobom z którymi pracowałam, za wielogodzinne rozkminy, jak mierzyć i pokazywać nieefektywności. Dzięki menedżerom miałam możliwość głębokiego pochylenia się nad tematem budowy kultury inżynierskiej w oparciu o miary i z wykorzystaniem DoD jako narzędzia.
Aż kiedyś, po jakimś szkoleniu rozmawiałam z Radkiem Orszewskim na temat “kiedy Scrum a kiedy Kanban”. To był moment, kiedy zrozumiałam jak można pracować w sytuacji, kiedy DoD jest bardzo słabe, kiedy obejmuje jedynie niewielki wycinek tego, co trzeba zrobić aby wdrożyć produkt.
Konflikt ideologiczny w zespole – scena trzecia
Do jednej z firm trafiłam zaproszona przez menedżera IT. Opisał mi zespół, składający się z dobrych fachowców, z których każdy na rozmowach indywidualnych jest rozsądnym, rzeczowym człowiekiem. Jednocześnie większość rzeczy pisanych przez zespół ma błędy, które ewidentnie wynikają z niedogadania w obrębie zespołu.
Intrygujące było to, że na pytania, jak się zachowują ludzie względem siebie, uzyskałam odpowiedź, że w miarę w porządku. Nie przyjaźnią się ze sobą, ale też nie słychać kłótni. Tknięta przeczuciem poprosiłam o pokazanie repozytorium kodu. Po kilku minutach przeglądania komentarzy do pull requestów blady menedżer zapytał tylko “Co ja mam z nimi zrobić?”.
Odpowiedź nie była prosta, musieliśmy pracować dwutorowo. Z jednej strony załatwiliśmy zespołowi dobre warsztaty z komunikacji i konfliktu, które pozwoliły nazwać i zrozumieć pewne zachowania i dopuściły do głosu mniej zaangażowanych w konflikt członków zespołu. Z drugiej trzeba było jakoś przerwać wojnę ideologiczną pomiędzy deweloperami.
Wykorzystaliśmy do tego Definicję Ukończenia. Potrzebowaliśmy jednak zacząć od elementów, które nie były punktami zapalnymi. Ściągnięty do zespołu dobry Scrum Master przez kilka tygodni moderował im pracę nad kolejnymi prostymi elementami – stylem kodu, sposobem nazywania klas i testów, zakresem review kodu. Udało się – panowie zobaczyli, że mają podobne wartości i bardzo dużo wspólnych przekonań. Krok po kroku zespół wyszedł z konfliktu.
Jak różnie role pełni DoD w zależności od kultury i jak różnie należy z nim pracować
Kolejnym etapem mojej podróży przez zrozumienie DoD była praca, którą wykonywałam niezależnie dla dwóch skrajnie różnych organizacji. Obie potrzebowały zwiększyć przewidywalność dostarczania. Przekopaliśmy się wtedy przez wszystkie możliwe podejścia do estymowania, nie tylko teoretycznie, ale też praktycznie. Część inspiracji pochodziła z podcastów i tekstów, część z literatury.
Końcem drogi były warsztaty o kulturze organizacyjnej, prowadzone przez Kate Hobler, które pozwoliły mi zrozumieć, jak różnie rolę pełni DoD w zależności od kultury i jak różnie należy z nim pracować.
Czy standard powinien być narzucony czy wypracowany? – scena czwarta
To była luźna rozmowa przy obiedzie na konferencji, która przerodziła się w dłuższą współpracę. Na początku wydawało się, że nie ma problemu – świadomi menedżerowie chcą iść w kierunku ficzer teamów, budując z kilku zespołów komponentowych zespoły zdolne do wytwarzania przyrostu w każdym komponencie. Ponieważ wiedzieli, że kilkakrotnie robiłam taką zmianę, to mieli parę dodatkowych pytań, raczej dosyć typowych. Coś mi jednak nie pasowało. Jeden z nich był wyraźnie zaniepokojony tą zmianą, chociaż sam widział jej sens. Na wprost zadane pytanie czego się obawia zamilkł. Po dłuższym zastanowieniu powiedział “Nie ma standardów. Co mamy zrobić – narzucić je czy pozwolić im wypracować?”.
Kolejne sesje na konferencji się zaczynały i kończyły, a my siedzieliśmy i rozgryzaliśmy problem na kartce. W efekcie przejście na zespoły ficzerowe zostało na kilka miesięcy wstrzymane, a ten czas przeznaczony na intensywne szkolenia, warsztaty i pracę nad poprawą jakości. Do tej pory uważam reakcję tych menedżerów za najlepszą możliwą. Widziałam szereg firm, które wybrały inne rozwiązanie i widziałam wieloletnie konsekwencje odpuszczenia tej wstępnej pracy. Koszty szły w miliony i miesiące opóźnień.
Jak obecnie wykorzystuję DoD?
Teraz nadszedł czas, żeby się podzielić z innymi tym, czego się nauczyłam i jak obecnie wykorzystuje DoD. Pewnie tam nie ma nic, czego byście nie znaleźli w kilku książkach i paru szkoleniach. Na wiele wniosków można wpaść samemu, szczególnie, jak ma się możliwość długofalowego obserwowania różnorodnych organizacji. Tym niemniej, jeśli widzicie sens w tym, żeby tę wiedzę zaabsorbować w postaci uporządkowanej i poskładanej w całość, to warto udać się na warsztat dotyczący Definition of Done -> https://brasswillow.pl/szkolenie/definition-of-done-jako-narzedzie-transformacji/
