Definition of Ready

Scrum Guide nie definiuje wprost pojęcia Definition of Ready. Jest to jednak rozszerzenie, które bywa stosowane na różne sposoby w wielu zespołach. Dowiesz się, dlaczego ta praktyka może być potrzebna w zespole i jak ją stosować. Damy Ci kilka przestróg oraz rad jak zacząć, a także czego należy unikać przy zastosowaniu Definition of Ready. Temat został zaproponowany przez jednego z naszych Słuchaczy w ankiecie dotyczącej podcastu.

Zobacz wersję wideo:

Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy.

TRANSKRYPCJA

Kuba: Przed tobą czterdziesty siódmy odcinek podcastu Porządny Agile, w którym poruszymy temat Definition of Ready. Jeden z naszych słuchaczy w ankiecie, którą robiliśmy jakiś czas temu, poprosił o to, żebyśmy właśnie poruszyli ten temat. W ramach odcinka zdefiniujemy, co rozumiemy pod Definition of Ready, co w sumie nie jest takie banalne, bo Scrum Guide tego bezpośrednio nie definiuje. Powiemy, dlaczego taka praktyka może być potrzebna w zespole, opowiemy też jak zacząć stosować Definition of Ready i na koniec opowiemy o paru przestrogach, kilka rad jak się do tego zabrać, ale też czego według naszych doświadczeń unikać przy zastosowaniu Definition of Ready. Zacznijmy tak, jak wspomniałem już wcześniej zaczniemy od definicji, co to jest Definition of Ready Jacek?

Jacek: Sama definicja Definition of Ready generalnie ma swoje źródło w okolicach Scruma. Pierwszy raz została użyta tak w sposób formalny około 2008 roku. Natomiast przez ten czas była wykorzystywana w tym frameworku, no i myślę, że w ten właśnie sposób zdobyła popularność. W największym skrócie jest to pewna umowa wewnątrz zespołu, która definiuje nam, po czym poznajemy, że konkretne elementy w naszym Backlogu Produktu wyglądają na gotowe do pobrania, gotowe do zaplanowania podczas planowania Sprintu.

Kuba: I tak metodologicznie bardzo mocno trzeba podkreślić, że Definition of Ready, a zwłaszcza tak rozumiane twardo jako ten trzyliterowy zbitek, nie występuje w Przewodniku po Scrumie, to jest raczej praktyka towarzysząca, która Scruma rozszerza. No i w szczególności mocno to podkreślmy, praktyka formułowania i przestrzegania Definition of Ready nie jest w Scrumie obowiązkowa. Ona jest dobrą praktyką. Praktyką, która warto zastosować, no ale w samym Scrum Guide, czyli tym takim wytycznej, co jest Scrumem, a co jest tylko okolicą Scruma. W tym Scrumie mówimy raczej o gotowości Backlogu Produktu, czy stanie gotowości, stanie gotowości tych poszczególnych elementów tego Backlogu Produktu, ale można to osiągnąć na różne sposoby. Do tego wątku jeszcze trochę wrócimy w przestrogach pod koniec odcinka.

Jacek: No dobrze, a gdybyś miał powiedzieć, dlaczego tak naprawdę taka, czy takie Definition of Ready, trzymając się angielskiej nazwy, do czego to nam jest potrzebne?

Kuba: Jest kilka powodów i taka najbardziej oczywista. Oczywiste tłumaczenia, oczywisty sens tego, żeby Definition of Ready funkcjonowało, to jest próba uniknięcia przez zespół brania na Sprint rzeczy z Backlogu Produktów, które są jakiś sposób. No przede wszystkim mi się wydaje niedogadane. Czyli rozpoczynamy pracę, być może nawet ją jakoś próbujemy planować. Grzecznie sobie jako zespół współpracujemy. No i  w zasadzie prawie natychmiast po rozpoczęciu pracy, już w środku Sprintu odkrywamy, że rzeczy są nieprecyzyjnie sformułowane. Nieprzemyślane, sprzeczne ze sobą i pewnie jeszcze kilka innych przypadków może się natrafić. Co nam rozwala kompletnie plan pracy, co nam rozwala możliwość realizacji celu Sprintu. Być może również gdzieś stawia pod znakiem zapytania sensowność realizowania jakichś sąsiednich tematów, bo to, co robimy, jest częścią czegoś większego. No to wszystko powoduje, że zespół nie realizuje Celu Sprintu. Ma bardzo niski procent skuteczności realizacji planowanych elementów Backlogu wziętych na Sprint. No i raczej mówimy tu o przypadku, gdzie jest chaos, gdzie jest jakieś może nawet już grupa wzajemnych pretensji, jakichś takich niedopowiedzeń. W każdym razie zespół, który zawodzi sam siebie, no i zawodzi też swoje otoczenie, ponieważ no nie może polegać na tym, co przewiduje, że zrobi w czasie planowania Sprintu

Jacek: Definition of Ready może być też pomocne, gdy zależy nam na pamiętaniu o tym, żeby nie pominąć jakichś zależności zewnętrznych. Mam tu na myśli sytuacje, w których pewne kompetencje, bądź nawet pewne zmiany, które zespół chciałby wyprodukować, nie są stuprocentowo zależne od zespołu, tylko leżą, bądź w innych zespołach, bądź w innych działach, bądź w ogóle poza organizacją, której te zespoły funkcjonują. Przykładem takich zależności zewnętrznych, to może być np. pamiętanie o tym, żeby skonsultować jakąś zmianę prawnie. To tu to jest przykład na taką zależność, zarówno potencjalnie wewnętrzną, jeżeli mamy dział prawny wewnątrz organizacji, ale równie dobrze może to być kompletnie zewnętrzna organizacja, z którą po prostu mamy podpisaną umowę. To może być inny zespół, który np. będzie dostarczał nam jakieś dane albo będzie wykonywał jakąś pracę po swojej stronie. No i po prostu musimy się zsynchronizować w tej sprawie. No i w tym takim skrajnym przypadku to może być zewnętrzny dostawca w ogóle jakaś inna organizacja, która bądź coś dla nas produkuje, albo my korzystamy z jakichś produktów organizacji np. z bramki płatności. No i po prostu pewne zmiany najpierw muszą być wykonane po stronie dostawcy. Dopiero później my jesteśmy w stanie dopiąć pewne sprawy po naszej stronie. No i  warto takie zależności sobie troszeczkę wcześniej już uświadomić. Być może też uruchomić jakieś działania, których celem będzie to, żebyśmy nie odkryli tego, że czegoś nam brakuje, bo mamy zależność zewnętrzną w trakcie naszego Sprintu. Chcemy to ryzyko zminimalizować i wykryć to na odpowiednio wczesnym etapie.

Kuba: Podobnym kłopotem czy problemem, na które Definition of Ready może być odpowiedzią, jest przypadek, gdy jako zespół w miarę regularnie, czy w powtarzający się sposób zapominamy o jakimś aspekcie naszego produktu, który jest ważny albo wręcz krytyczny dla tego, co realizujemy. Bo być może jest to jakieś krytyczne wymaganie. Krytyczna potrzeba, jakiś wymiar naszego produktu, o którym ciągle musimy pamiętać. To może być np. SEO. To może być RODO, to mogą być jakieś właśnie rzeczy marketingowe związane z wizerunkiem, z brandem. Rzeczy, które wpływają na wymogi, czy wymagania, czy kryteria, co musimy zrealizować w każdym Sprincie. One są też do rozpoznania, czy do poznania, jeśli tylko będziemy o tym pamiętać przed rozpoczęciem pracy. Niektóre z tych elementów mogą być częścią definicji ukończenia w Sprincie, ale jeśli w ogóle nie będziemy o nich pamiętać przed rozpoczęciem pracy, to  fajnie też starać się trzymać również w definicji właśnie gotowości.

Jacek: Innym przypadkiem, kiedy Definition of Ready może być wartościowe, to jest moment, kiedy zespół chciałby się upewnić, że pamięta o tym, że umówili się na jakiś sposób utrzymywania elementów Backlogu Produktu. To może być na przykład prosta umowa, że chcielibyśmy do każdego elementu w Backlogu dołączać na przykład kryteria akceptacji. Zamieszczenie takiego zapisu, takiej przypominajki w Definition of Ready może być takim zdyscyplinowanym sposobem na to, żeby zespół pamiętał o tym, że na jakąś tam konwencję wspólną i na wspólne zrozumienie czym w ogóle jest element Backlogu Produktu się umówili.

Kuba: I ostatnim powodem, dla którego Definition od Ready w ogóle zespoły się decydują jest to, żeby po prostu sformalizować, czy tak jakby zgodzić się całym zespołem, na to jak rozumiemy pracę gotową do pobrania. Jeśli mamy tutaj jakieś niejasności, no to ta praca, tak już wymieniliśmy w kilku poprzednich powodach, może być niedoskonała. Może być chaotyczna. Są też zespoły, które po prostu chcą pewne reguły jasno postawić no i Definition of Ready jest przykładem takiej bardzo jasnej reguły na temat tego jak rozumiemy pracę, którą chcemy brać na początku sprintu do Backlogu Sprintu. Jest to po prostu czysta reguła przestrzegana przez cały Zespół Scrumowy. W takim razie opowiedzieliśmy trochę o powodach, dlaczego Definition of Ready jest przydatne, czemu jest przez niektóre zespoły stosowane. Czego pozwala unikać? To w takim razie jakbyśmy mieli poradzić Tobie słuchaczu jak zacząć? Co Jacek byś zaproponował, że trzeba zrobić, żeby Definition of Ready wprowadzić?

Jacek: Pierwsze pytanie, które może przychodzić do głowy Słuchacza, może być: Dobrze, czym w ogóle jest to Definition of Ready w sensie, jaką to fizyczną formę przyjmuje? Najczęściej, z mojego doświadczenia to jest po prostu forma spisana, gdzie zespół zgadza się na pewne, konkretne punkty. To może przybrać formę też jakiejś checklisty. Na zasadzie, że sobie punkt po punkcie przechodzimy i upewniamy się, że nasze elementy spełniają tę listę, a jeżeli nie spełniają, no to warto mieć na to jakieś sensowne wytłumaczenie. Natomiast, no też generalnie sensowną wskazówką jest to, żeby to było spisane w miejscu takim, gdzie każdy wie, gdzie tego szukać. No i oczywiście najlepiej korzystać z Definition of Ready w takiej formule, że nie tylko wiemy, gdzie leży, ale też w praktyce wykorzystujemy. No i tutaj tak, w świecie przed pandemicznym, no to mieliśmy luksus przyczepiania sobie tego w przestrzeni zespołu na ścianie, na tablicy ilustrującej postęp prac. No możemy szukać sposobów, żeby też dostęp do tego mieć w formule online. Myślę, że tutaj kwestia też pewnych nawyków, być może po prostu jakaś reguła stylu przypomnijmy sobie jakiś czas, że mamy Definition of Ready, no po prostu może mieć sens.

Kuba: Twoje pytanie jest całkiem dobre, żeby może przypomnieć, czy opowiedzieć jakiś przykład Słuchaczom. Tak się zupełnie przypadkowo składa, że mam ze sobą książkę, której takie przykładowe Definition of Ready jest zawarte. To może zacytuję: „Przykładowa definicja przygotowania wygląda tak, element Backlogu Produktu jest zapisany w formie User Story. User Story spełnia zasady Invest. Kryteria akceptacji są jasno określone. Wielkość elementu jest oszacowana. Oszacowanie jest mniejsze niż trzynaście punktów”. A cytat pochodzi z książki Labirynty Scruma, Jacka Wieczorka.

Jacek: Hmm, gdzieś kiedyś chyba mi mignęła.

Kuba: Niezależnie od tego, że przywołałem ten przykład, to teraz, jeśli byś Słuchaczu lub Słuchaczko chciała szybko przerwać słuchanie i natychmiast zacząć wprowadzać tę definicję do swojego własnego zespołu, no to mój najważniejszy punkt jak zacząć z Definition of Ready, to jednoznacznie zdefiniować sobie, czy zacząć definicję od tego, żeby sobie powiedzieć, jaki problem my w ogóle chcemy rozwiązać. Czyli, nie bierzmy takich rozbudowanych Definition of Ready, czy to przykładowych, czy to zobaczonych w jakimś zespole, czy przeczytanych w jakiejś mądrej książce, tylko zastanówmy się, co jest dla nas problemem. Jak jako zespół współpracujemy na tym Backlogiem Produktu, czy są właśnie takie elementy, o których wspominaliśmy wcześniej. Powtarzające się problemy, powtarzające się rzeczy, o których zapominamy. Jakaś specyfika nasza lokalna naszego zespołu, która mówi właśnie zależnościach. I autentycznie rozwiązujemy sobie tylko, co jest prawdziwym problemem coś, do czego będzie przekonanie całego zespołu, żebyśmy faktycznie wprowadzali sobie zdyscyplinowane rozwiązanie na problem, który nas boli, a nie wprowadzali sobie modną praktykę albo jakieś rozbudowane narzędzie, które w sumie trochę nie wiemy, dlaczego jest. Możemy wtedy łatwo wpaść pułapkę takiej nadmiernej mechaniki, czy taki mechanizacji Scruma. Tego byśmy naprawdę nie chcieli, bo jest wtedy duże prawdopodobieństwo, a może nawet pewność, że jak sobie zaaplikujemy zbyt rozbudowane Definition of Ready, to nam się to nie utrzyma. Nie będziemy przestrzegać tej praktyki, a nawet może ją spalimy już na przyszłość, już na zawsze w naszym zespole.

Jacek: Tak, i myślę, że to, co mówisz na końcu, czyli takie właśnie no próbowaliśmy, z takim poczuciem, że to był jakiś balast, a nie coś, co pomaga zespołowi. Taką zbliżoną regułą, do tego, co powiedziałeś, jest reguła KISS, czyli Keep it Simple. Tłumaczona w tym przypadku, z mojej perspektywy tak, że staramy się maksymalnie uprościć to nasze Definition of Ready. Jakby tutaj nie ma dodatkowych punktów za to, że to będzie pięknie rozbudowany dokument na trzy strony, jakiś skomplikowany. No bo najprawdopodobniej zespół się zmęczy bardziej, korzystając z tego, niż będzie z tego pożytek. Tak więc tutaj jakby punktów nie ma za to,  jak bardzo to będzie na rozbudowane. Raczej punkty będą za to, żeby to pomogło zespołowi w codziennej pracy. No i  zwykle moje doświadczenie pokazuje, że to naprawdę mogą być takie pewne myśli uchwycone, w jakichś tam punktach. Nic skomplikowanego, nic rozbudowanego. Tak skomplikowane, w sensie maksymalnie uproszczone jak to tylko możliwe.

Kuba: Idąc tym tropem KISS, nie da się już nic więcej z tych Definition of Ready, jakie stosujemy nic odjąć, a nie, że jest też coś do dodania. Nie musimy się tu popisywać, ale też jest taki trop również podobny. Może też zgadzając się jakieś zapisy w Definition of Ready dobierajmy też proste środki rozwiązujące ten problem, o którym wspominałem chwile temu. Jest wiele rozwiązań na problem precyzyjnego sformułowania kontekstu biznesowego, ale może nie porywamy się na ten najtrudniejszy i najbardziej wymyślny i najbardziej modny, że zwykłe proste User Story albo wręcz nawet jedno zdanie kontekstu, to jest wystarczająco na start i później poprawiamy, to jeśli będzie to potrzebne. Następna porada jak zacząć, już trochę Jacek to powiedziałeś, a ja to tak docisnę takie stwierdzenie. Jacek wspominał o tym, że Definition of Ready musi być dostępne. Ja mocno zachęcam do tego, że jeśli już decydujemy jako zespół na skorzystanie z Definition of Ready, to przynajmniej na początku mocno przypominajmy sobie i używajmy tego podejścia na Refinemencie. Być może Scrum Master, być może Product Owner, być może ktoś zespołu może na początku Refinementu przypomnieć, jak sobie zdefiniowaliśmy to Definition of Ready. Być może możemy sobie przypomnieć, jeśli ono ma jakąś formę checklisty, to na koniec omawiania danego elementu czasie Product Backlogu Refinementu, możemy sobie jeszcze raz się upewnić, czy wszystkie punkty, na które się jakiś czas temu zgodziliśmy, są w tym elemencie zawarte. Tak, żeby to wchodziło nam w nawyk, musimy to wielokrotnie powtarzać, no i przede wszystkim będziemy jeszcze parę razy tego słowa używać. To jest akurat praktyka wspomagająca zdyscyplinowane podejście do pracy, więc musimy też ją po prostu powtarzać, przypominać, no i po prostu stosować. Zadeklarowanie sobie Definition of Ready, a później jego niezastosowanie na najbliższym Refinemencie, po prostu skazuje nas na porażkę i być może cofa nas do punktu wyjścia, być może znowu, w ogóle już tego nie wrócimy, bo u nas nie zadziałał. Nie zadziałało albo nie zadziała takie Definition of Ready.

Jacek: To, co jeszcze nie padło w trakcie naszej rozmowy to, że Definition of Ready nie jest wykute w Kamieniu. Jest to artefakt, który podlega zmianom i zwykle zespoły wykorzystują Retrospektywę, żeby ten dokument poddawać usprawnieniom, pochylać się nad nim, dodawać pewne elementy, bądź usuwać. Powiedziałbym, że to jest taki, no znów, tak Retrospektywę tutaj traktuję trochę jako taki bezpiecznik, który no zabezpieczy nas przed tym, że stworzymy sobie Definition of Ready, no i wyląduje sobie gdzieś tam zakamarkach Confluence lub jakiegoś innego narzędzia. Nigdy do niego nie wrócimy. Tak więc, jeżeli zespół nie jest jeszcze tak dojrzały, żeby sobie tak powiedziałbym ad hoc. Zrobić jakieś krótkie spotkanie, żeby zmodernizować Definition of Ready, no to na pewno takim sensownym punktem w  trakcie Sprintu jest Retrospektywa, kiedy możemy, bądź przygotować tematyczne Retro skupione na Definition of Ready, bądź może to wypłynąć po prostu jako jeden z tematów istotnych dla zespołu do omówienia i do przygotowania jakiegoś usprawnienia.

Kuba: Bardzo ważnym punktem, który doradzam też, żeby uwzględnić, gdy takie Definition of Ready chcemy wprowadzić to to, że jest to umowa całego zespołu i akcent położy na to cały zespół. Jeśli już wprowadzamy taką praktykę i np. jesteśmy z perspektywy zespołu, jesteśmy Scrum Masterem, może Product Ownerem, może jakimś czas fascynatem podejścia zwinnego, jako jeden z członków zespołu. No to zadbajmy o to, żebyśmy zawiązali ten kontrakt, tę umowę całym zespołem, zgodzili się wszyscy, zrozumieli to tak samo, ale też wszyscy szczerze i bardzo rzetelnie się zgodzili, że będziemy tego przestrzegać. Za chwilę Jacek o tym powie, bo jest w zasadzie taka ostatnia rada na koniec, związana ze złamaniem Definition of Ready, ale przestrzegać go będziemy musieli wszyscy. Przestrzeganie tego Definition of Ready może być nieprzyjemne, żmudne, bo teraz, zamiast iść po prostu do przodu i skończyć spotkanie, to jeszcze też musimy uzupełnić jakieś pole, albo sprawdzić, czy jeszcze nie mamy jakiejś zależności, czy dopisać jakieś jeszcze jedno zdanie do naszego narzędzia elektronicznego, w którym trzymamy Backlog Produktu. No i w niektórych zespołach może być dosyć szybko poczucie, ej zrezygnujmy z tego albo gdy tylko przyjdzie czas wdrażać w życie, to ci najmniej przekonani zaczną sabotować nasze działania i one spełzną na niczym. Więc z powrotem wraca do wszystkich tych reguł, które wymieniliśmy do tej pory, ale powtórzę. Definition of Ready jest rodzajem kontraktu takiego proceduralnego kontraktu, który przestrzegać muszą wszyscy członkowie zespołu. Muszą w niego wierzyć, muszą się zgodzić na to, że będą go przestrzegać. Wiedzieć, po co to robią i wiedzieć, jak dokładnie będziemy postępować w dalszym rytmie funkcjonowania zespołu, Więc nie bądźmy nadmiernymi optymistami, bądźmy tutaj można realistami albo wręcz pesymistami. Upewnijmy się, że mamy poparcie absolutnie całego zespołu, Product Ownera, Scrum Mastera, wszystkich członków zespołu wytwórczego. Bo inaczej niestety, ale możemy wpaść w łatwe złudzenia i później się mocno poróżnić, czy skonfliktować tylko, dlatego że niektórzy od początku wcale nie chcieli pewnej praktyki stosować, no ale już tak dla Świętego spokoju się zgodzili, a może nawet za bardzo nie słuchaliśmy, jak oni dawali swoje głosy sprzeciwu, czy jakieś takie uwagi, że nie może niekoniecznie jest dobry pomysł.

Jacek: To już taki komentarz oparty na doświadczeniu. Jeżeli chodzi o ten ostatni punkt, czyli złamanie Definition of Ready, no to generalnie to, co bym chciał, żeby wybrzmiało w tym kontekście to, że no na pewno to jest tak bardzo znaczący moment w takim sensie, że złamanie z mojej perspektywy powinno prowadzić do dyskusji. Na takiej zasadzie, że jeżeli to puścimy, w sensie, że zauważymy, ale nie komentujemy i to bardzo łatwo doprowadzić tak trochę regułą wybitej szyby do tego, że no po prostu dostanie się kompletnie martwym artefaktem. Tak więc z mojej perspektywy nie mam odpowiedzi na to, co się stanie, jak to zrobić w swoim zespole, czy jak Twój zespół zdecyduje się zignorować Definition of Ready, no bo to jest kwestia indywidualna, zespołowa. Natomiast no z mojej perspektywy,  jest to na pewno ważny moment. Moment złamania pewnej umowy i to akurat tutaj Definition of Ready. No i po prostu z mojej perspektywy jest to temat, którego nie powinniśmy odpuścić, nie powinniśmy przeoczyć, no i porozmawiać tak naprawdę i też zrozumieć, dlaczego tak się stało. Może bardzo duża presja z zewnątrz, może przemęczenie zespołu, na a może jakiś zupełnie inny powód. No i bez zrozumienia tej przyczyny źródłowej no to też trudno rekomendować jakieś konkretne kroki.

Kuba: Ja tu dopowiem coś takiego, jak dla mnie bardzo ważnego, że Definition of Ready, to jest nie tylko ta lista punktów jak przeczytana przekładu książki Jacka, ale to też jest sposób postępowania zespołu. Czyli będziemy tego przestrzegać, będziemy tego pilnować. Zgadzamy się, że będziemy w zdyscyplinowany i szczelny sposób postępować zawsze w ten sam sposób. To złamanie Definition of Ready, to jest nietrywialna sprawa, bo warto o tym pogadać, jak jesteśmy w spokojnej sytuacji. No bo jest niezerowa szansa, że złamanie Definition of Ready nam zagrozi, gdy pojawi się coś pilnego i ważnego w ostatniej chwili leciał, o może tuż przed planningiem Product Owner albo wymyślił albo dostawą prośbę, żeby coś szybko zrobić. No i wtedy powiedzmy sobie głośno, jak będziemy postępować, żeby nie wyszła taka sytuacja, że pomimo pewnej zgody, jednak pewne rzeczy zupełnie nieprzygotowane do Sprintu wchodzą. No i być może możemy się zgodzić na jakiś algorytm postępowania np. zrobić dodatkowy szybki Refinement dla danego elementu lub jednak odesłać na później, odesłać na przyszłe Refinementy i nie zgodzić się twardo, nie zgodzić się na to, że nie weźmiemy czegoś do Sprintu. Nie będziemy tego realizować, bo nasze dotychczasowe doświadczenia oraz nasza zgoda całego zespołu mówi, no wzięcie czegoś na szybko bez przemyślenia, bez przegadania, bez przygotowania według naszych jakichś kanonów, prowadzi według naszych doświadczeń do problemów i nie chcemy ich ciągle powtarzać.

Jacek: To, co powiedziałeś, trochę zabrzmiało, jak przestroga i parę takich przestróg mamy na koniec dla ciebie Słuchaczu. Gdzie byś Kuba widział potencjalne ryzyka, na co uważać podczas korzystania z Definition of Ready?

Kuba: Największe ryzyko, jakie z Definition of Ready widzę to, że zwłaszcza jeśli zespoły chcą zbyt mocno sobie postawić się tę definicję, zbyt wysoko zbyt ambitnie. To może ona prowadzić do swego rodzaju Waterfalla, czy takiego Scrum Waterfalla, że w zasadzie, żeby w ogóle podjąć jakikolwiek temat, to musimy mieć go tak mocno, bym potocznie rozpykananego, rozpisanego oraz rozbitego na kawalątki. Przejdzie przez szereg praktyk około produktowych. Rozpisane są role, rozpisane są szczegóły jakieś diagramy, makiety. No, prawie że cała specyfikacja napisana do pojedynczego itemu na kilka Story Pointów, który jest jedną z wielu rzeczy, które zespół robi w Sprincie. I o ile jestem ok z tym, jeśli zespół sobie cierpliwie, krokowo, rozbudowuje to podejście i z każdym kolejnym dodatkiem to Definition of Ready ma sens, natomiast zaczynam być bardzo sceptyczny, czy podejrzliwy, jak widzę, że zespół jest relatywnie świeży, a już ma Definition of Ready ustawione tak, że w zasadzie jestem w środku jakiegoś właśnie sformalizowanego procesu, w którym całe wielkie połacie dokumentów i innych artefaktów muszą powstać, żeby zespół zgodził się na wzięcie tego do Sprintu i rozpoczęcie developmentu. Ten  Waterfall, tu nie chodzi nawet o to, czy tam Waterfall jest be, a Agile zawsze dobry, bo jesteśmy w odcinku o Definition of Ready i jednak odrobina przygotowania to jest coś, co jest pozytywną stroną tego odcinka. Natomiast ja w tym Waterfallu przede wszystkim przestrzegam przed takim rozłożeniem czasowym możliwej pracy do wykonania, czyli mnóstwo energii musimy poświęcić, być może więcej niż jeden Sprint przed rozpoczęciem development, po to, żeby w ogóle ten development rozpocząć. Nie dajmy się tutaj zwariować i jakby szukajmy tego optimum, tego balansu między tym, że dobrze jest mieć pewne rzeczy opisane, wyjaśnione, wyklarowane, ale też, żeby czasem się nie okazało, że czy to interesariuszy, czy Product Owner, czy nawet sam zespół musi wykonać mnóstwo energii, która nie jest tym dostarczaniem wartości, tylko jest próbą przebrnięcia przez kolejną bramkę decyzyjną, tym razem ustawioną przez teoretycznie z nazwy zespół zwinny, no ale jednak zachowujący się jak w starym dobrym czasie jakiś taki Gatekeeper, na jakiś wczesnych etapach kolejnych faz Waterfalla.

Jacek: Kolejna przestroga, którą chcielibyśmy się z Tobą podzielić dotyczy przesadnego traktowania Definition of Ready. Kuba trochę o tym opowiedział przed chwilą, natomiast jak ja bym chciał zaakcentować to, że takie bardzo silne Definition of Ready, takie mocno opisane, szczelne, rozbudowane, może być w pewnym sensie przeciwieństwem współpracy, która tak naprawd, no jest pewnego rodzaju fundamentem zwinności i może być zespół odebrany jako taki trochę silosowaty, jako taki zespół, który się okopuje. Bo tak naprawdę, właściwie na każdą próbę porozmawiania z zespołem wyjmuje Definition of Ready i mówi: Tutaj jest punkt wyraźny, który mówi jak nie ma makiety, to w ogóle na drzewo.

Kuba: Nie podchodź.

Jacek: Nie podchodź, nie rozmawiamy, wszystko mamy doskonale opracowane, wszystko jest przygotowane, właściwie no interfejs wystawiony na zewnątrz jest. To jakby mówi wszystko, więc tak naprawdę to weź już nie zadawaj pytań. Rozmawiaj z naszym Definition of Ready. Trochę przerysowuję, ale wielokrotnie spotykałem się z taką sytuację, gdzie ktoś się odbijał od zespołu, i był tak trochę traktowany w sposób proceduralnym, gdzie to jakby też znów przeciwieństwo trochę tego podejścia, gdzie chcemy raczej wchodzić w interakcję i budować relacje. No i właśnie Definition of Ready było często pokazywane tak na twarz, na zasadzie tu masz wszystko, weź zobacz, zobacz tutaj czegoś brakuje, wróć jak będziesz gotowy. To na pewno mówiąc o Definition of Ready z Kubą w superlatywach, no to nie mamy na myśli tak przesadzonego, czy niewłaściwego traktowania tego wzorca.

Kuba: Idąc tym tropem, trochę negatywnych przestróg. To też w niektórych zespołach Definition of Ready może wyglądać obiecująco, jako sposób na poradzenie sobie niedoskonałym Product Ownerem. Osoba, która może niewystarczająco dobrze priorytetyzuje, może nie ma wystarczająco dużo czasu, żeby Backlog uporządkować. No to jak tak przywalimy tutaj mocne Definition of Ready, mocno wypiszemy obowiązki, to się wszystko naprawi. No i tutaj Definition of Ready no nie uważam, że będzie rozwiązaniem na problem współpracy z Product Ownerem albo z Klientem, czy Interesariuszem. To owszem jest praktyka, do której możemy wspólnie razem dojść, ale nie bez rozmowy. Czyli jeśli chcielibyśmy zacząć stosować Definition of Ready z powodu niedoskonałości współpracy z tymi od, których wymagania do zespołu docierają, to może jednak atakujmy autentyczny problem, z czego wynika ten problem źródłowy, z czego wynika to, że nasza relacja, czy nasza interakcja się tutaj nie do końca układa. Obłożenie się mądrze brzmiącymi technikami, obłożenie się historiami z innych zespołów, że to w czymś pomaga, może nie być ścieżką. Może nas jeszcze bardziej poróżnić, jeszcze bardziej nas od siebie oddalić, czy odgrodzić. Nie dość, że nie współpracujemy dobrze, to jeszcze się wzajemnie okładamy jakimiś procedurami, czy cytatami, czy jeszcze czymś się tego typu. Więc tutaj spośród wielu przyczyn, dla których Definition of Ready można wprowadzać – zwróć uwagę, że akurat o słabym Product Ownerze, czy o słabym Kliencie akurat nie wspominaliśmy. Definition of Ready jest raczej praktyką całego Zespołu Scrumowego, który ma pomagać temu zespołowi, a nie zespołowi przeciwko komuś.

Jacek: To, co jest istotne, jeszcze, na co warto zwrócić uwagę, to taki trochę paradoks, że można mieć bardzo dobrze przygotowany Backlog Produktu, jednocześnie nie mając Definition of Ready. I o tym sobie trochę powiedzieliśmy na początku odcinka, ale warto, żeby to wybrzmiało. Istnieją zespoły, znam zespoły, czy pracowałem z zespołami, które miały bardzo dobrze przygotowany Backlog Produktu. Te elementy pojawiające się na planowaniu faktycznie były gotowe w takim znaczeniu, że ta dyskusja na temat tego jak podejdziemy do realizacji pracy,  no raczej była krótka. W sensie większość niewiadomych była już jakoś tam odsłonięta, bardziej to była kwestia prognozy ile jesteśmy w stanie zrealizować i jakby nie było dyskusji o tym, że coś jest niejasne albo nie gotowe. Te zespoły często nawet nie słyszały o tym, że jest w ogóle taka praktyka jak Definition o Ready. Tak więc, nie jest to coś, co musi wystąpić w każdym zespole, czy musi się pojawić. Raczej tutaj jest to coś, co po traktowałbym jako pewnego rodzaju wsparcie. Przy czym niektóre zespoły mogą poradzić sobie i funkcjonować sensownie, kompletnie, używając Definition of Ready.

Kuba: I kontynuując taki wątek naszych obserwacji, takich autentycznych zespołów pracujących w dłuższym czasie, czy też rozwijających coraz bardziej rozbudowane podejścia do tego jak organizują sobie pracę. Patrząc na Definition of Ready w autentycznych, zaawansowanych zespołach, zgadzamy się obaj z Jackiem, że jest taki wzorzec, że te Definition of Ready to jest coś, co rośnie wraz ze wzrostem dojrzałości doświadczenia zespołu. Czyli bierzmy poprawkę na to, miejmy świadomość tego, że dobre Definition of Ready, to jest szereg kolejnych warstw, kolejnych udoskonaleń, kolejnych jakichś przeformułowań, wynikających również się po prostu doświadczeń również tych przykrych, czy negatywnych w danym zespole. I tak się buduje dobre i mocne Definition of Ready, że ono przyrasta, że ono spokojnie się rozwija w szeregu kolejnych Retrospektyw, szeregu kolejnych inicjatyw zrealizowanych przez zespół. I czasami łatwo wpaść w taką właśnie pułapkę, czy zachwyt, że tutaj mamy do czynienia z jakiś pięknym Definition of Ready, elegancko zawierającym dużo różnych fajnych punktów, które są, no wszyscy zgadzają się, że bardzo potrzebne i bardzo wartościowe. W zasadzie gotowy wzorzec, żeby pokazać to na jakieś konferencji zwinnej, ale nie kupujmy tego. Skopiujmy model dojścia przez te zespoły do Definition of Ready. Czyli zacznijmy od czegoś prostego i rozbudowujemy o poszczególne kolejne, autentycznie przez zespół potrzebne elementy, przeformułowane i ciągle doskonalone. Usprawnianie się jest takim motywem, który regularnie wraca naszych odcinkach, to jest jeszcze jedno miejsce, gdzie taka praktyka Definition of Ready jest świetnym przykładem na to w dłużej funkcjonujących zespołach na to, że to doskonalenie prędzej czy później daje bardzo fajne rezultaty. I w przypadku Definition of Ready to, to jest dobry przykład na coś, co bywa nazywane tak metodycznie wzorcem, czyli zespoły zupełnie niezależnie od siebie nie wiedząc nawet swoim istnieniu, dochodzą do dosyć podobnych rozwiązań po prostu, wymyślając tak na logikę, na intuicję, czerpiąc z inspiracji z powszechnie znanych praktyk, wymyślają sobie podobne podejście do Definition of Ready. I to jest fajne, to jest zawsze bardzo lokalne, bardzo kontekstowe, bardzo dopasowane do szeregu złożonych tutaj czynników, które mają wpływ na to, jakim zespołem jesteśmy, jaki produkty rozwijamy.

Jacek: I tak właściwie dobrnęliśmy do końca tego odcinka. Notatki do niego znajdziecie jak zawsze na naszej stronie internetowej porządnyagile.pl/47. Znajdziecie tam też transkrypcję tego odcinka oraz zapis wideo.

Kuba: Zapraszamy Ciebie na Live’a na Facebooku, który odbędzie 19 października w poniedziałek o 20:00. Będzie to już piąty nasz Live. Jak zwykle odpowiemy na trochę pytań zebranych przed Live’em oraz na odpowiemy też na pytania na czacie. Myślę też, mogę już polegać na tym, że w konwencji będzie również to, że oprócz naszych odpowiedzi na czacie będzie równolegle toczyła się żywa dyskusja z dzieleniem się materiałami i jakimiś przykładami. Jest to zdecydowanie bardziej wyluzowana forma i trochę bardziej spontaniczna niż odcinek. Jest okazja do trochę większej ilości interakcji też trochę pożartowania, ale mimo wszystko to dalej pozostaje merytoryczna dyskusja na temat zwinności. Okazja do pogadania sobie o przykładach, o jakichś może takich punktowych case’ach, które niekoniecznie nadają się na cały odcinek, ale za to w parę minut jesteśmy w stanie albo coś doradzić, albo coś odradzić, albo opowiedzieć co sądzimy o danym temacie. Na stronie odcinka i na Facebooku znajdziecie link do zgłaszania propozycji tematów. Zapraszam też do zapisania się na wydarzenie i propagowanie informacji o tym, że ten Live się będzie odbywać. A jeśli jest tak, że słuchasz tego odcinka już po 19 października dwudziestego roku, to prawdopodobnie na Facebooku znajdzie się wideo z zapisem tego Live’a, całej sesji, do czego również sprawdzenia zachęcam.

Jacek: To by było wszystko dzisiaj dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.