Praca na termin w Agile

Czy sztywne terminy są zaprzeczeniem Agile’a? Czy można mówić o pracy zwinnej, jeżeli mamy narzuconą końcową datę projektu? Jakie korzyści może przynieść ustalenie deadline’u? O tym w 23. odcinku podcastu Porządny Agile.

Zobacz wersję wideo

Dodatkowe materiały

• Książka „Deadline. Zdążyć przed terminem” Toma DeMarco

TRANSKRYPCJA

Jacek: W dzisiejszym odcinku porozmawiamy o deadline’ach w Agile’u, czyli o sytuacji, w której mamy pewne ograniczenie czasowe i tę pracę, którą wykonujemy, musimy na konkretny termin mieć gotową.

Kuba: Teza, która gdzieś tak nas zainspirowała do nagrania, to taka myśl, że jeśli się ma sztywne deadline’y, sztywne terminy, jakąś datę końcową projektu czy datę wdrożenia konkretnej wersji produktu, to nie masz Agile’a, nie masz podejścia zwinnego. Już z samego faktu, że są sztywne deadline’y, które trzeba dotrzymać i to naprawdę trzeba dotrzymać, no to podejście zwinne już nie jest możliwe. I nie chcemy tutaj w tym odcinku mówić, że to jest jakiś mit albo że ktoś nam takie coś zaproponował. To jest bardzo osobiste, ale sam też miałem kiedyś z tym problem. O wiele prościej mnie samemu myślało się o podejściu zwinnym w takim świecie, w którym nie mam blokady na terminie, tylko po prostu realizuję jak najlepszą wartość i jak skończymy, to będzie. Czyli takie trochę: „Nie mogę ci podać terminu, bo jesteśmy przecież zwinni, mamy estymację, mamy możliwe zmiany w backlogu i po prostu jak skończymy, to będzie”. Wielu to denerwuje – zwłaszcza zarządzających organizacją lub osoby, które jednak tym światem takim zarządzanym przez terminy funkcjonują w biznesie, no i coś, co chcemy w tym odcinku mocno podkreślić to to, że takie myślenie, które sam też podzielałem, jest błędne. Tak naprawdę podejście zwinne umożliwia pracę z terminami czy nawet – chcemy zaryzykować taką tezę – że całkiem dobrze robią terminy, żeby w fajny sposób pracować zwinnie.

Jacek: Jak myślę sobie o pracy na konkretny termin, to przypomina mi się klasyczna książka Toma DeMarco, „Zdążyć przed terminem” – taki, powiedziałbym, project managerski klasyk, który zresztą sam czytałem bardzo, bardzo dawno temu. Natomiast dlaczego wspominam o Tomie DeMarco? Ponieważ natrafiłem na – nie pamiętam czy to był wywiad czy jakiś artykuł i tutaj niestety nie będę w stanie Wam precyzyjnie wskazać źródła, natomiast odtworzę to z pamięci. Natrafiłem na artykuł, gdzie Tom DeMarco opowiedział taką historię, że pomimo tego swojego bagażu i doświadczeń – w kontekście pracy takiej na konkretny termin – no to on powiedział coś takiego, że gdyby dzisiaj miał rozwijać produkt, to oczekiwałby od zespołu, że będą mieć produkt gotowy na koniec każdej iteracji i nie będzie się dzielił z zespołem informacją, do kiedy to ma być zrobione. Po prostu zespół ma pracować tak, jakby każdy Sprint mógł potencjalnie być ostatnim Sprintem, czyli ta gotować produktowa powinna być zawsze. Nie ma opcji, że mamy coś rozgrzebane, coś w połowie, coś nie jest zintegrowane. Zawsze na koniec Sprintu czy iteracji mamy potencjalnie gotowy produkt.

Kuba: Jeśli wygląda to na manipulację albo wygląda to na zbyt ostre podejście, to ja sam mam takie doświadczenia, że jeśli myślę o najsłabszym podejściu zwinnym, jakie spotkałem w jakichś organizacjach czy zespołach, to m.in. składową przyczyn, dla których ten Agile był słaby, był właśnie kompletny brak presji – albo faktyczny brak presji, albo brak zrozumienia, że ta presja jednak jest i koniec końców wreszcie się ujawni, tylko będzie już za późno. Żeby to zamienić na konkrety, naprawdę znam – czy przypominam sobie – chociażby zespół, który miał rozwijać zupełnie nowy produkt i miesiącami szykowali się do kolejnej wersji, zdążyli zmienić logo, zdążyli zmienić design strony, ale ta wersja nigdy nie ujrzała światła dziennego i koniec końców ten produkt nigdy nie ujrzał rynku, bo po prostu cierpliwość zarządzających się wyczerpała, no ale ten zespół absolutnie nie czuł presji, nie czuł, że tam trzeba się z czymś spieszyć, że trzeba zrealizować zadanie jak najwcześniej jest to możliwe. nawet jeśli nikt im nie sformułował nigdy deadline’u „Zróbcie to za trzy miesiące, bo pracujemy zwinnie”, to mimo wszystko uważam, że może by im bardzo pomogło, gdyby jednak postarali się zrobić coś całkiem dobrego jak najszybciej, a nie kisili się z kolejnymi wersjami przez długi, długi czas.

Jacek: No i jak komuś to się wydaje takie ekstremalne, że jak można pracować zwinnie w tak dużym ograniczeniu, to znów przypomina mi się dyskusja na Twitterze, gdzie m.in. wypowiadał się Alistair Cockburn, czyli jeden z współtwórców Manifestu Agile, no i ogólnie osoba będąca cały czas aktywna w społeczności i dzieląca się naprawdę wartościowymi przemyśleniami, no to tam była dyskusja, gdzie parę innych bardzo doświadczonych osób dyskutowało o tym – bardzo generalnie rzecz biorąc – czym jest zwinność, w sensie: jakie warunki brzegowe powodują, że ta zwinność jeszcze jest, a kiedy już jej nie ma i jeżeli dobrze pamiętam, to właśnie sam Alistair powiedział o tym, że jak on zaczynał pracę w sposób zwinny, no to zdarzało mu się pracować w warunkach, gdzie właściwie wszystkie boki trójkąta, czyli zarówno czas, jak i zakres, jak i ilość osób, którymi dysponujemy, były sztywne, no i tak naprawdę nadal można było pracować w sposób zwinny, na zasadzie dbania o zwinność na poziomie komunikacji. Czyli chociażby, pięknie tutaj możemy wrócić do pierwszej wartości Manifestu Agile, czyli ludzie oraz interakcje są ważniejsze niż procesy i narzędzia. I tam w ogóle ten wątek bardzo fajnie pokrywał to, że można mieć bardzo różne korzenie zwinności, no i jedna osoba może mieć takie doświadczenia, że zwinność to jest właśnie brak żadnych ograniczeń – no i wtedy łatwo powiedzieć, że „jesteśmy zwinni”, natomiast to, o czym dzisiaj chcemy porozmawiać, to to, że jest nieco trudniej, ale to nie jest złe podejście, kiedy jednak jakieś ograniczenia mamy.

Kuba: I chcę przytoczyć taki przypadek, który bardzo wcześnie w mojej karierze się przydarzył – mogłem go obserwować, może nie osobiście w nim uczestniczyć, ale dosyć blisko obserwować – gdzie jeden z zespołów w pewnej organizacji miał za zadanie zrealizować zmiany związane ze zmianą prawa podatkowego. Jakiś czas temu zmieniła się stawka VAT, organizacja zorientowała się w tym trochę późno – tak żartując, czasem tak bywa, że się zaskakujemy, że raz do roku są święta Bożego Narodzenia. No i ta organizacja trochę wpadała w tę pułapkę, że zaskakiwały ją różne terminy, które można było przewidzieć – no, wtedy prawo akurat zmieniało się trochę rzadziej, teraz akurat to jest dosyć popularny temat, że zmieniają się jakieś przepisy prawa i w zasadzie wszystko trzeba przebudować – mało tego, wdrożenie przepisów prawa nie będzie czekać, jest konkretna wskazana data – i jakieś zmiany w organizacji, w jej systemach, procesach trzeba zrealizować. No i ten zespół, o którym wspominam, który miał zrealizować zmianę stawki VAT, na początku wydawało się, że to jest absolutnie niewykonalne, w ogóle zadanie na wiele miesięcy dłużej niż w praktyce ten zespół miał do dyspozycji, ale to, że pracowali w sposób zwinny, to, że mieli ten konkretny termin końcowy zmiany prawa, po prostu pomogło im pracować zwinnie. Wymusiło na nich selekcję zakresu i faktyczne obcięcie z absolutnie każdego kawałka tłuszczu tego, co jest do zrealizowania – z wszystkich „chciejek”, zachcianek i jakichś tam „nice to have’ów” – tylko po prostu musieli zrealizować dokładnie to, co było zbędne, dostarczać to po kawałkach, bo po prostu „chociaż miejmy coś”, ale też pomogło im np. wyseparować rzeczy, które są niezbędne na 1 stycznia od tych, które być może możemy dostarczyć w połowie stycznia albo za parę miesięcy, żeby faktycznie skupić się na tym, co jest najważniejsze – i cały czas dostarczać tą wartość – tą, która jest najpilniejsza, tą, którą być może bez tego po prostu firma już nie może dalej funkcjonować.

Jacek: No, to jak mówisz o tym przykładzie, to mnie od razu też przypomina się historia, w której wspierałem firmę, w której Product Owner na pytanie, na kiedy będzie produkt, który rozwija, no, zwykle odpowiadał, że będzie za dwa miesiące. No i ta odpowiedź ciągnęła się miesiącami – zawsze to były „za dwa miesiące”.

Kuba: Od teraz, tak?

Jacek: Od teraz, oczywiście. Czyli w zależności, od kiedy pytasz – dwa miesiące. No i w pewnym momencie skończyła się cierpliwość bardzo, bardzo istotnego stakeholdera, który po prostu podpisał umowę z jednym z partnerów i tym sposobem wyznaczył taką faktyczną datę, na kiedy to ma być gotowe. No i po początkowym popłochu zespół wraz z Product Ownerem, przy pomocy Scrum Mastera, rozłożyli sobie pozostały, ich zdnaiem, zakres na storymapę, wiedząc już jakiś cel, byli w stanie z tej storymapy powybierać rzeczy, które są istotne, które są nieistotne. Pewne rzeczy, które początkowo chcieli zrobić w wersji takiej absolutnie luksusowej zdecydowali się dostarczyć w wersji superprostej, ale działającej – no i to jest bardzo fajny case na to, że faktycznie taka presja czasu pozwala nam albo popycha nas w stronę tego, że musimy nad zakresem i nad tym, co jest ważne faktycznie, a co nam się wydawało, pochylić i popracować.

Kuba: No i zwłaszcza np. takie narzędzie jak storymapa pozwala rozdzielić te jakieś większe kawałki zakresu czy większe wyobrażenie wizji produktu, na mniejsze elementy i bardzo często pokazuje się taki problem, że te mniejsze elementy same w sobie mają różny poziom krytyczności czy ważności. Jest jakiś kawałek, który jest absolutnie niezbędny, ale też są takie rzeczy, które albo nie są ważne dla wszystkich albo będą używane później, albo jak się dobrze nad nimi zastanowimy, to się okaże, że używane nie będą wcale. Więc, no, tutaj deadline zmusza do kombinowania, a efektem tego kombinowania może być pocięcie zakresu na bardzo małe kawałki i wybranie czy wyselekcjonowanie z tych kawałków, które są naprawdę ważne i zrobienie ich w pierwszej kolejności, bo po prostu nie mamy innego wyboru. Całego zakresu na ten termin nie zrobimy, zwłaszcza jeśli mamy usztywnione jakieś jeszcze inne boki tego trójkąta projektowego, np. na szybko w żaden sposób nie skombinujemy więcej członków zespołów albo firma ma zdrowe podstawy i zdrowe zasady, więc również na jakości przyciąć nie możemy.

Jacek: Tu mam przykład obrazujący takie, jak można wpaść w tą pułapkę, myślenia, że wszystko jest krytyczne. Pracowałem z grupą osób odpowiedzialnych za produkt i rozmawialiśmy o tym, właśnie jak dzielić duże bloki na mniejsze części, no i tam podzieliłem się z nimi takim przykładem, który bardzo często spotykam, kiedy firmy budują produkty wymagające zalogowania się, no to zwykle gdzieś tam pojawia się w Backlogu, że trzeba zrobić stronę logowania. No i domyślne myślenie o stronie logowanie, no to jest właśnie takie, że to jest pewien taki duży klocek, składający się z wielu funkcjonalności, no i po prostu wszystkie te funkcjonalności trzeba dostarczyć. Jak zaczęliśmy sobie dyskutować, z czego się składa strona logowania, no to okazało się, że tam jest niesamowite pole do tego, żeby powycinać rzeczy, które są nieistotne. Bo żeby zalogować się, no to de facto potrzebujemy zwykle pole, gdzie wpisujemy jakiś login oraz hasło i jest przycisk „zaloguj się”, natomiast wszystko to, co jest dookoła, czyli możliwość przypomnienia hasła, jakiś automat, który sprawdza, czy co miesiąc zmieniamy hasło, dodatkowa jakaś funkcja, która sprawdza, czy aby to hasło nie jest zbyt podobne do hasła, które mieliśmy ostatnio, jakieś zmieniające się w tle tej strony logowania obrazy, jakaś możliwość zalogowania się przez Facebooka, możliwość zalogowania się przez Google’a itd. itd. Domyślnie to wszystko jest traktowano jako strona logowania, natomiast jak się tak poważnie zastanowimy, no to przestrzeń na to, co jest do zrobienia później albo wcale – jest niesamowita. I to tylko wszystko zależy od tego, jak bardzo jesteśmy otwarci i jak bardzo, myślę, nabierzemy sobie wprawy w tym, żeby umieć oddzielać rzeczy krytyczne czy ważne od rzeczy, które są „nice to have”, mówiąc po staropolsku i po prostu nie trzeba się nad nimi pochylać – ani teraz, ani być może w ogóle nigdy.

Kuba: I to jest też – idąc tym tropem rady Toma DeMarco – takie pytanie, które warto sobie zadawać na każdym kroku, co byśmy zrobili, gdybyśmy z góry wiedzieli, że mamy tylko jeden Sprint na to, żeby zrealizować ten projekt, a potem już będzie deadline. I wtedy często się okazuje, że kreatywność się buduje – nie będziemy robić rozbudowanych stron logowania, po prostu „na pałę” zrobimy logowanie przez Facebooka albo w ogóle brak logowania. I tyle. I po prostu w idealnym świecie byśmy tutaj mieli rozbudowane narzędzia, jakieś piękne zabezpieczenia, ale nie mamy tego idealnego świata, bo mamy deadline i musimy po prostu zrealizować wszystko to, co jest absolutnie niezbędne – i ostro, ostro priorytetyzować na pograniczu tego, że po prostu realizujemy prace absolutnie, wręcz bym powiedział, prymitywnymi rozwiązaniami biznesowymi, co jeśli na szali jest funkcjonowanie dalsze firmy, bo prawo będzie od nas tego wymagało, żebyśmy jakieś elementy zmienili albo dodali, to to musimy zrobić, nie ma wyboru. A niestety w wielu projektach, w których jest komfort tego wyboru, że „najwyżej zrobimy to pół roku później”, wtedy wpadamy w taki szał dokładania feature’ów, odmawiania sobie tej ostrej selekcji i też przewidywania czy planowania, że absolutnie nic się nie wydarzy złego, mamy te pół roku i ze spokojem sobie będziemy mogli „dziubać” tą naszą kolejną wersję w tym najbardziej rozbuchanym zakresie, jaki nam przyszedł do głowy, gdzieś tam na jakichś wczesnych etapach projektu.

Jacek: Jeśli kogoś przeraża myśl, że w podejściu zwinnym mamy jakiś deadline, no to warto przypomnieć sobie, że de facto każda iteracja czy każdy Sprint, który realizujemy de facto ma jakiś określony deadline – czy to jest iteracja jedno- czy dwutygodniowa, no to – w szczególności w Scrumie – spodziewamy się, że na koniec Sprintu dostaniemy przyrost produktu. To jest istotne, a jednocześnie wielokrotnie pomijane przez zespoły, które traktują Scruma po prostu jako takie pudełka, w których coś tam realizujemy, ale wcale nie odczuwają ani presji, ani nie czują sensu tego, żeby jednak na koniec pojawiło się coś namacalnego, żeby można było to poddać inspekcji, żeby można było dostać informację zwrotną, więc de facto pracując – w szczególności Scrumem, czy po prostu pracując w iteracjach – ten deadline jest z nami, no, jeśli oczywiście oczekujemy od siebie nawzajem, żeby na koniec takiej iteracji dostarczyć coś namacalnego, co jest, uważam, krytyczne z wielu powodów, które jeszcze właściwie za chwilę pokryjemy.

Kuba: I na pewno warto sobie zrobić w zespole rachunek sumienia. Nieważne czy jesteś Scrum Masterem, czy Agile Coachem, czy Product Ownerem, czy po prostu członkiem Zespołu Deweloperskiego – warto się zastanowić, jakie podejście do deadline’u, takiego końca iteracji macie. Czy to jest po prostu moment, że trzeba wiedzieć, jak się wytłumaczyć z tego, co się udało, a co się nie udało zrobić – nie polecam. Czy może właśnie taka perspektywa, że to jest faktycznie moment, gdy chcemy skończyć i mieć gotową do wdrożenia kolejną wersję naszego produktu. I już nieważne czy to są jakieś tickety czy to są jakieś feature’y, czy to są jakieś user story, ale już od samego początku Sprintu myślimy tą perspektywą na koniec tego, co planujemy, mamy do osiągnięcia cel i ten cel składa się w gotowy, kolejny kawałek produktu – bardzo mały, być może – tak jak już wspomniałem – być może ocierający się o prymitywne rozwiązanie, ale jednak każda kolejna wersja działa. To jest to rozwiązanie, które nam bardzo pomoże też realizować po prostu większe przedsięwzięcia, które mają deadline – że każda kolejna iteracja, która wykonujemy, jest działającym kolejnym przyrostem, jest kolejnym przybliżeniem nas do tego, co jest niezbędne, na koniec tego dużego deadline’u, który gdzieś tam wisi nam nad głową czy przypomina nam się w kalendarzu.

Jacek: No i z mojej perspektywy nie znam bardziej empirycznego, takiego namacalnego, sposobu radzenia sobie z ryzykiem, czy aby na pewno ten progres prac występuje, jak właśnie oczekiwanie, żeby efektem prac było coś namacalnego – tak więc o wiele bardziej do mnie przemawia kontrolowanie progresu prac na zasadzie: „pokazujmy sobie co tydzień nasz produkt i spróbujmy go poużywać, zobaczmy, jak on funkcjonuje” niż jakaś tam dyskusja, czy to jest 78 czy 79% w jakimś tam arkuszu w MS Project czy w czymkolwiek, w jakimkolwiek narzędziu, którego używamy do śledzenia postępu prac. I tak ten deadline – taki na zasadzie „musimy mieć na za tydzień, na za dwa kolejny raz coś namacalnego”, uważam, że jest bardzo zdrowe, no i może w konsekwencji doprowadzić do tego, że ten nasz produkt będzie – tak wracając do Toma DeMarco – wiecznie gotowy. W sensie – co itereację będziemy mieć tą opcję, że jeśli będzie trzeba, z różnych powodów, przyspieszyć wdrożenie produktu, no to będziemy mieli taką opcję.

Kuba: I to mi przypomina jeszcze jedną historię zespołu – taką dosyć powtarzającą się, pewnie wielu z Was ma takie przeżycia albo zna kogoś, kto ma takie przeżycie, że robili Scruma zanim się dowiedzieli, że to już jest Scrum albo – jeszcze rozszerzając – pracowali w sposób zwinny, zanim poznali, że to ma jakąś konkretną nazwę. I zespół, który mi przyszedł do głowy z pewnej jeszcze innej organizacji – również akurat z powodu zmiany w prawie – wymagał przebudowania w zasadzie całkowicie jednego kawałka systemu, który obsługiwał konkretny i pewien kraj – i proces biznesowy funkcjonujący w tym kraju – no i ten zespół pracował w organizacji, która była stricte waterfallowa – i to tak, no, do przesady, z rocznymi planami prac, z dwuletnimi jakimiś horyzontami rozplanowania portfela projektów, ale ta zmiana prawa dosyć szybko weszła w życie i dosyć zaskoczyła całą organizację, no i pomimo swojego takiego waterfallowego przyzwyczajenia, no, ci ludzie wymyślili, jak można zrealizować taki projekt, który musi być zrealizowany na „za trzy miesiące” – zwołać ludzi, poświęcić ich temu konkretnemu projektowi, nie rozpraszać ich na nic innego, zaangażować managerów i Interesariuszy ważnych, żeby pewne informacje były dostarczone do zespołu bezpośrednio, pewne decyzje były podejmowane na bieżąco, no i – nazwę to po waterfallowemu – kontrolować ten zespół w bardzo częstych spotkaniach, które doprowadziły do tego, że ten zespół co tydzień, co dwa tygodnie miał działającą kolejną wersję i też tą perspektywą działającego rozwiązania się rozliczali – czy mamy chociaż jeden z procesów kilku, które obsługuje ten system, załatwiony, jak stoimy z ryzykami, czy wyszło coś nowego, co nas zaskakuje, jak na dzisiaj estymujemy realizację projektu na damy termin i coś, co się okazało, że na początku ten zespół startował z perspektywą „trzy miesiące to zdecydowanie za mało, rety, rety, ratunku!”, a potem się okazało, że w zasadzie wyrobili się przed terminem i, mało tego, wszyscy wokół nich chcieli, żeby kontynuowali swoją pracę, żeby ten zespół już został taki, jak jest, deadline’u już nie mają, ale ten system dalej wymaga dalszego rozwoju – i niech tak już zostanie. I ta firma mniej więcej w tym samym czasie zaczęła realizować większą transformację ku Scrumowi, no i wszyscy powiedzieli: „Chcemy pracować tak jak tamten zespół kryzysowy, ratunkowy, realizujący zmianę związaną z wyjątkową sytuacją”. Bo czasem takie kryzysy, czasem taka silna presja, jest jedynym, co pobudzi organizację do tego, żeby się wytrącić z tego takiego miłego poczucia, że jest wszystko zgodnie z planem, wszystko jest rozplanowane, budżety są okej, ludzie w zespołach są poukładani we właściwy sposób, nic nie trzeba zmieniać. Deadline może być bardzo korzystny również na poziomie transformacji całej organizacji.

Jacek: I tak domykając powoli tą ciekawą dyskusję, chcielibyśmy pokazać, że ten krótki deadline, raz, że jest wartościowy – to już trochę powiedzieliśmy, ale też trochę rozważyć to, co podpowiada nam w przypadku krótkiego deadline’u intuicja, a co faktycznie w praktyce przynosi wartość. No i pierwszy taki przykład jest następujący – często zespoły tak intuicyjnie, kiedy jest krótki deadline, no to mówią: „to róbmy, wydłużmy iterację”, często nawet „w ogóle porzućmy, porzućmy Sprinty, zróbmy jeden długi Sprint od teraz aż do za dwa, trzy miesiące, kiedy będziemy musieli przedstawić swój produkt, w sensie już jako gotowy”, no i nie do końca ta intuicja jest sensowna, no bo wszystkie te argumenty, które podaliśmy w trakcie odcinka, one przestają być do zastosowania i w praktyce wcale nie dłuższe iteracje, tylko właśnie krótsze iteracje mogą okazać się sensowne, gdy mamy jakiś konkretny deadline na horyzoncie, żeby lepiej czuć to, czy faktycznie ten progres prac postępuje czy robimy bardzo dużo pracy i wszyscy są absolutnie zanurzeni w robotę, tylko nie do końca są namacalne, widoczne efekty tej pracy.

Kuba: Ty mówisz, że intuicja podpowiada dłuższe iteracje, a ja czasem widzę, że intuicja podpowiada kompletny brak iteracji, czyli jeśli mamy pół roku do deadline’u i nam się wydaje, że się nie da tego zrobić, no to wpadają mądre głowy na pomysły: „No to teraz porzućmy Scruma, zaoszczędzimy 10% czasu na te wszystkie spotkania scrumowe, które przecież nic nam nie wnoszą, zamknijmy oczy, rozdajmy sobie zadania i do zobaczenia za pół roku”.

Jacek: „Skupmy się na pracy”.

Kuba: „Tak. Może niech jedna osoba gdzieś tam kontroluje wszystko tak, jak jest dobrze realizowane, ale cała reszta to niech po prostu naparza w stronę końcowego terminu zgodnie z wybranym zakresem”. Spotykam takie przypadki i takie pomysły i jeszcze nie spotkałem przypadku, żeby po kilku tygodniach – o ile ta organizacja pracowała już do tej jakoś w zwinny sposób – to najpóźniej po kilku tygodniach wszyscy głośno mówią: „Wróćmy do tych Sprintów, bo już się rozjechaliśmy, co do zakresu, co do wartości, już się okazało, że jakieś zmiany są potrzebne, ktoś tam, kto miał kontrolować, jednak nie kontroluje i się wszystko rozpadło”.

Jacek: Tak. Innym takim intuicyjnym pomysłem w obliczu krótkiego terminu dostarczenia czegoś namacalnego, jest pomysł, że „Skupmy się na produkcie, a integracje sobie robimy na końcu”. W szczególności to może być pomysł, kiedy pracuje więcej zespołów, no i tak właśnie „zaoszczędźmy ten czas, kiedy tam się synchronizujemy, no przecież wiadomo, co jest do zrobienia – no, wy robicie to, my robimy tamto, tamci mogą…”.

Kuba: „Trzymajmy się tych reguł, każdy niech zrobi to, co jest w jego zakresie…”.

Jacek: Dokładnie. „Dobrze to spisaliśmy, wszyscy wiedzą, co mają robić, skończmy gadać”. No i niestety, w sensie: ta integracja na koniec może się okazać wielkim wybuchem i też, no, w wielu organizacjach wiele takich inicjatyw widziałem, gdzie komunikat do zarządu idzie pod tytułem: „Właściwie zakres mamy gotowy, wystarczy się TYLKO zintegrować” no i potem tłumaczenie się i ciężkie rozmowy i jakieś tam dywaniki, na zasadzie: „Mówiliście, że potrzebujecie chwilkę, żeby się zintegrować. Czemu to trwa już trzeci tydzień?”. No i znów, ta intuicja trochę tutaj błędnie podpowiada, bo w obliczu krótkiego deadline’u, no to te integracje powinny być częste. Dlaczego? No bo one są dla nas takim bardzo binarnym wskaźnikiem, czy ten produkt jesteśmy w stanie zintegrować i czy on ma szansę w ogóle być używalny.

Kuba: Czy działa.

Jacek: Czy działa. Czy – raz – nie jesteśmy w stanie, bo się nie dogadaliśmy. Dwa, czy w ogóle mamy środowisko, narzędzia i umiejętności, które pozwalają taką integrację wykonać, co też nie jest wcale tak oczywiste.

Kuba: No i już ironizowaliśmy, ale też podkreślmy to jeszcze raz, że intuicja też w obliczu krótkiego deadline’u podpowiada: „Trzymajmy się planu, realizujmy go, jest on już zaklepany, jeśli tylko będziemy chcieli odejście od planu jakiekolwiek zrealizować, to na pewno nie zrealizujemy deadline’u”. To akurat intuicja, która może czasami być całkiem słuszna, że ślepe trzymanie się planu może pozwolić zrealizować zgodnie z planem prace na dany termin – tylko rozjedziemy się, jeśli tylko ktoś nas zapyta, czy zrealizować to, co było faktycznie potrzebne, a nie tylko to, co było zaplanowane na samym początku. No bo tutaj praktyka podpowiada, zwłaszcza w obliczu krótkiego terminu, najlepsze, co możemy zrobić, to mieć rękę na pulsie, czy zmieniają się wymagania czy odkrywamy szanse, żeby coś przyciąć, coś ściąć, jednak z czegoś zrezygnować, ale też, żeby najwcześniej jak to możliwe zareagować, jeśli odkryjemy, że nie dość, że mamy krótki dealdine, to jeszcze niestety, ale zmieniają nam się wymagania.

Jacek: Podsumowując, skupiliśmy się dzisiaj na rozmowie o tym, jak to jest z tą pracą na termin, jak to jest z deadlinem w Agile’u, mam nadzieję,że przekonaliśmy Cię do tego, że nie dość, że można pracować zwinnie w sytuacji, kiedy mamy pewien określony koniec naszej pracy, to, co więcej, sensowne, takie świadome wykorzystanie tego, że istnieje pewne ograniczenie czasowe, może paradoksalnie okazać się bardzo wartościowe dla rozwoju produktu.

Kuba: No i nim skończymy ten odcinek, przypomnimy o tym, że realizujemy warsztaty, które pokrywają właśnie takie tematy, jak tematyka tego odcinka, który właśnie się kończy. Warsztaty 7.-8. listopada w Poznaniu, zanurkujemy głęboko w tematy zwinności, wyciągniemy tematy trudne, wyciągniemy tematy nieoczywiste, podywagujemy na temat tego, czym podejście zwinne tak naprawdę jest i jak możliwe jest pracowanie w sposób zwinny w bardzo trudnych sytuacjach, bardzo trudnych warunkach. Poruszymy tematy, które są ważne naszym zdaniem, mocno też zgłębimy tematy, z którymi przyjdą wszyscy uczestnicy tego warsztatu. Zapraszamy Ciebie na stronę porzadnyagile.pl/szkolenie, gdzie opisany jest planowany zakres tego szkolenia, warunki handlowe i informacja, czy są jeszcze miejsca, bo nagrywając ten odcinek, jeszcze nie mamy pewności czy, gdy już on ujrzy światło dzienne i trafi do Twoich uszu, czy miejsca jeszcze będą. Na pewno nie warto odwlekać tego na później.