Na kiedy będzie?

Presja związana z goniącymi (częstokroć narzuconymi, nierealnymi, życzeniowymi) terminami udostępnienia nowej aplikacji/funkcjonalności klientom i klasyczne pytanie na kiedy będzie, to bez wątpienia powszechne i zarazem jedno z najbardziej znienawidzonych zjawisk w branży wytwarzania oprogramowania. Środowisko ukuło nawet na okoliczności pracy projektowej pod nieustającą presją, przy nierzadko bardzo dużej odpowiedzialności, okrutne sformułowanie marszu śmierci.

Agile’owa utopia?

Sam nieraz w tego typu projektach uczestniczyłem, na własnej skórze doświadczyłem tego z różnych perspektyw: tak “niewinnego”, poganianego dewelopera, jak i poganiającego, na pewno w jakimś stopniu nieraz współodpowiedzialnego za zaistniałą sytuację, menedżera projektu. Choć niezwykle cenię sobie bezcenne doświadczenie wówczas zdobyte, gwarantujące późniejszą impregnację na wiele z pozoru trudnych wyzwań i problemów, przed którymi inni uciekają, gdzie pieprz rośnie, to koszt tego wszystkiego był niemały.

Olbrzymie obciążenie psychiczne, odpowiedzialność i presja, którym podlega się w tego typu projektach, niezależnie od pełnionej roli, nierzadko skutkują problemami, które stanowią ciemną stronę branży. Tymczasem często bywa to lekceważone. Odnoszę wrażenie, że ci co bardziej zahartowani w boju, najczęściej wpadają w pewną pułapkę zobojętnienia, swoiste przyzwyczajenie do tego, że tak po prostu jest, jak śpiewali nam polscy rockowi klasycy. I zarażają tym podejściem innych. Jest to najprostsza droga do klasycznego zawodowego wypalenia.

Mając zatem niemałe doświadczenie w projektach realizowanych pod dużą presją, idee spokojnej, stabilnej pracy bez nadmiernych przeciążeń niesione przez ruchy agile’owe, początkowo traktowałem jako pewną utopię, bajkę z mchu i paproci, o której fajnie poczytać, ale która nie przystaje do rzeczywistości – tak, rzekomo tej najciemniejszej, korporacyjnej, ale i częstokroć jeszcze bardziej okrutnej (tu się walczy o przetrwanie!) – startupowej.

Trendy i zasady niesione przez Kaizen/Toyota Production System/Lean Management (zwalczanie 3M: Muda, Mura, a w szczególności Muri – nadmierne obciążenie pracą, nadmierny wysiłek), agile (Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy), eXtreme Programming (praca ciężka, ale w równym tempie, nacisk na równowagę praca – życie prywatne) czy w końcu Scruma (zrównoważone tempo) brzmiały intrygująco, ale jeszcze niedawno zdawały się całkowicie oderwane od realiów.

W ostatnim czasie sytuacja wydaje się jednak zmieniać na lepsze, choć bardzo powoli. Sprzyja temu wiele czynników, między innymi faworyzujący pracowników rynek pracy czy to, że współczesne pokolenie po prostu nie wyobraża sobie pracy w sposób, który jeszcze do niedawna uznawany był za naturalny.

Nieważne jak, ważne na kiedy?

Wprowadzenie agile w firmie wiele zmienia i z reguły szybko zauważalne są pierwsze profity. Zespół siada razem w jednym pokoju, nie ma sytuacji, że ktoś pracuje jednocześnie w kilku projektach/obszarach, planowanie dotyczy krótkiego wycinka czasu – już te podstawowe działania powodują znaczące usprawnienia. Poprawia się komunikacja, atmosfera, inaczej rozmawia się i wewnątrz zespołów, i z “biznesem”. To najprostsza i najprzyjemniejsza część transformacji. Sęk w tym, że często na tej podstawowej, fasadowej części całość utyka, bo koniec końców natrafia się na firmową rzeczywistość, która nierzadko brzmi: fajnie, że jest lepiej, ale tak naprawdę nieważne jak się organizujecie, jak pracujecie, istotne jest kiedy zobaczymy efekty. Kurtyna opada… Niejeden Scrum Master usłyszał już takie słowa od swoich przełożonych czy Zarządu. Niejeden jeszcze usłyszy.  Ileż to już razy spotkałem się z sytuacją, gdzie rozżalony orędownik Scruma opisywał, jak fajnie udało się wszystko rozkręcić, jak poprawiła się motywacja, zaangażowanie i… nagle wszystko posypało się jak domek z kart, bo bezduszna góra interesuje się tylko i wyłącznie terminami. Oto prawdziwe wyzwanie, któremu trzeba stawić czoło.

Jak zatem radzić sobie z presją terminów w zwinnym, szczególnie nowo tworzonym, środowisku agile? Jak odpowiadać na pytania: na kiedy będzie jeżeli mamy do czynienia z większą inicjatywą, czymś co w dawnym świecie nazwalibyśmy projektem?

Za waterfalla było prościej?

Kiedy pierwszy raz zetknąłem się z tym zagadnieniem pracując jako Scrum Master w zespole scrumowym, szukając rozwiązania poczułem pewną beznadzieję i, przyznam, wróciło myślenie, że może ten agile to rzeczywiście ułuda, ściema. Sporo książek, w tym również tych najbardziej klasycznych, sprytnie prześlizguje się po temacie, oferując garść ogólników, bazujących na Story Points i prędkości zespołu. Są w nich i szlachetne porady mówiące, że należy wytwarzać aż do momentu satysfakcjonującego rezultatu, mając na względzie, że w środowisku agile należy ufać zespołom, ponieważ to co robią, jest robione, najszybciej jak to tylko jest możliwe. Cóż, miałem pecha, przestudiowałem masę publikacji, a nie wiedziałem wówczas o istnieniu na przykład Agile Estimating and Planning, Mike’a Cohna… Czarę goryczy przelały rozmowy z ekspertami od Project Managementu, z którymi wówczas miałem styczność. Większość bezradnie rozkładała ręce i sugerowała w temacie określania terminów powrót do technik kaskadowych, podkreślając, że na agile’owe szacowanie, podejście do dat wydania, to sobie mogą pozwolić duże firmy i to tylko przy okazji jakichś mniejszych, mniej istotnych projektów. Załamka…

Za waterfalla było w pewnym sensie prościej, bynajmniej nie dlatego, że szacowanie było lepsze (wręcz przeciwnie!), po prostu brak transparencji sprzyjał hochsztaplerce. Z efektami tego kombinowania mierzymy się w branży do dzisiaj.

W teorii – na starcie dostawaliśmy już gotową specyfikację i z reguły z już przeprowadzoną analizę techniczną. Mieliśmy zatem (ha, ha, ha) rozpoznany teren, ryzyka, potencjalne problemy – kiedyś wydawało się oczywiste, że późniejsze niesnaski wynikały właśnie z tego, że ktoś źle przeprowadził tę właśnie fazę.

Charakterystycznymi zjawiskami były tzw. szacowania eksperckie (rzeczywiści wykonawcy dostawali zadania z terminem realizacji, nie mając na ten termin żadnego wpływu) i głuchy telefon pod kątem daty, na kiedy coś będzie gotowe. Przykładowo, ekspert (najczęściej: architekt lub doświadczony deweloper) podawał jako czas realizacji projektu dwa tygodnie, jego przełożony dorzucał drugie tyle jako “bufor”, potem czasy te dynamicznie się zmieniały na kolejnych szczeblach, w zależności od ich ilości, aż w końcu ktoś musiał przekazać Zarządowi/Interesariuszom konkretną datę – i ten ktoś miał tutaj największy wpływ na to co się wydarzy. Tak, też byłem świadkiem jak 04.06 pod wpływem zmarszczonych brwi prezesa zarządu magicznie zmieniało się na 06.04. IT oczywiście miało i na to swoje sposoby, czemu sprzyjał wspomniany brak przejrzystości. Jeśli w projekcie było źle, istniały duże opóźnienia, natychmiast zaczynały się różne działania “pod stołem”: klasyczne dokładanie kolejnych osób, maksymalne skracanie fazy testów, nadgodziny odbierane poprzez wolne dni i tak dalej, i tak dalej. Wprowadzenie pracy agile w IT powoduje, że zyskując transparencję, traci się zarazem wszelkie możliwości tego typu sztuczek, co wiąże się z wieloma konsekwencjami, od upowszechnienia wiedzy w jakim tempie rzeczywiście zespoły pracują, po ujawnienie wszelkich zjawisk, które na to tempo wpływają. To tematy na osobny wywód.

Tymczasem w agile wygląda to trochę inaczej. Dla odmiany, na starcie mamy Product Ownera z pomysłem, który nie został jeszcze dokładnie przeanalizowany, rozpisany na zadania. Bez zmian pozostaje kwestia Interesariuszy, naciskających, domagających się odpowiedzi na pytanie: na kiedy?

Trudna praca u podstaw

Nie mamy jeszcze wymagań, co więcej teoria podpowiada nam, że na tym etapie za mało wiemy o projekcie, że powinniśmy jak najszybciej zacząć działać i w ten sposób się uczyć, a nie teoretyzować, co by było gdyby. Czyli, nie tracimy sprintów na analizy, tylko od początku programujemy i planujemy, doprecyzowujemy na bieżąco. A zatem – ustalamy priorytety zadań, omawiamy te z najwyższym, szacujemy je i działamy w sprincie. I robimy tyle takich pętli, ile trzeba.

Kiedyś nie rozpoczęlibyśmy prac nie mając dokładnie rozpisanego wszystkiego z góry. Teraz wiemy – a przynajmniej wierzymy – że istotna jest tu zasada just in time. Że większą wartość będzie miało po dwóch tygodniach cokolwiek działającego, niż sterta teoretycznych rozważań/analiz, która za miesiąc może być już nieaktualna. Nie znaczy to, że mamy gwarancję skuteczności i prawidłowości naszych działań. Zagwarantować możemy jedynie to, że jeśli się okaże, że obrana droga jest mylna, że założenia są błędne, to dowiemy się o tym znacznie wcześniej, niż w przypadku, gdy realizowalibyśmy to kaskadowo.

Wiemy już też, że tworzenie oprogramowania jest skomplikowane, złożone i, że:

choćby przyszło tysiąc architektów
z doświadczeniami z milionów projektów
i każdy ekspercko by estymował
i wszystkie detale by przygotował, to
NIE JESTEŚMY W STANIE
PRZEWIDZIEĆ WSZYSTKIEGO

Wiedza o zawiłej naturze wytwarzania oprogramowania, świadomość o sporej dawce nieprzewidywalności i wieloaspektowości tego procesu wzrasta – przebicie się do powszechnego dyskursu tej świadomości to jeden z większych sukcesów ruchów i trendów okołoagile’owych.

To jednak robota każdego Scrum Mastera, aby pokazać to wszystko w swojej organizacji nie tylko na bazie teorii i przekonać do innego sposobu pracy Interesariuszy czy Zarząd. To bardzo trudny, czasochłonny i złożony temat, ale zarazem jeden z ważniejszych aspektów, jeżeli w ogóle chcemy rozmawiać o terminach i zmieniać do nich podejście u tzw. “Góry”. Nie liczmy tu na szybkie sukcesy, ani na łatwe recepty jak to zrobić. Trzeba zdobyć zaufanie Zarządu, glejt na swoje działania, trzeba też w praktyce udowodnić, dlaczego ten sposób jest lepszy i mieć na to konkretne przykłady. Droga do tego jest długa i kręta i wymaga wielu kompromisów – pamiętajmy, że czasem trzeba będzie zrobić w niej krok do tyłu, może niejeden. Kluczowy dla firmy projekt nie jest dobrym miejscem na wprowadzenie nowości i eksperymenty. Można jednak powoli wprowadzać w nim nowe zasady, asekurując się metodami, które dotychczas powodowały pewien spokój ducha u “decyzyjnych”.

To przecież Scrum – nie można żądać od nas dat!

Tymczasem, niejednokroć rozmawiając z menedżerami, słyszałem sformułowania typu: agile ucieka od odpowiedzialności wskazania terminów lub Scrum nie pozwala na wyznaczenie dokładnych dat wydania funkcjonalności. Najczęściej to efekt działań właśnie Scrum Masterów, którzy – w szlachetnych intencjach – czynią dużo zła w organizacji, niosąc błędny przekaz typu: chcecie agile, to zaufajcie nam i poczekajcie aż zrobimy, co mamy zrobić. Nierzadko obserwowałem Scrum Masterów – buńczucznych wojowników, walczących do ostatnich sekund spotkań, aby tylko nie czynić ani jednego kroczku, odchodzącego od scrumowych zasad. Czasami tonący brzydko się chwytają, bez żadnych oporów, hamulców, a często i bez taktu, tłumacząc swoim przełożonym, że w agile jest inaczej, i że nic nie rozumieją.

Ich główny problem to najczęściej it-centryczność, zapominają, że gotowy produkt jest tylko częścią naczyń połączonych w firmie. Trzeba zaplanować budżet, działania promocyjne, nierzadko związane ze współpracą z firmami zewnętrznymi – a to reklamy, a to blogerzy, a to “wpływowi” (lub modniej: influencerzy). Czasem trzeba wdrożyć coś w określonym czasie, bo potem to wszystko traci sens. A czasem chodzi po prostu o szybkie stwierdzenie, czy warto w dany projekt ładować pieniądze, czy inwestycja w niego jest opłacalna.

Mówiąc wprost – daty są potrzebne i od nich nie uciekniemy. I w żaden sposób nie kłóci się to ze zwinnym podejściem.

No pasaran!

Wcześniej wspomniałem o kompromisach. W dwóch aspektach tematu musimy być jednak twardzi jak skała.

Po pierwsze – agile zabetonował nam jakość jako rzecz nienaruszalną i niewątpliwie powinniśmy się tego mocno trzymać. Tu faktycznie walczmy niemalże do upadłego i jeśli trzeba się będzie ugiąć, to tylko przy bardzo mocnym uzasadnieniu i na ustalonych warunkach późniejszego odrobienia strat. Cięcie jakości się mści. Zawsze. Prędzej czy później, z reguły w najmniej oczekiwanym momencie, na powierzchnię wypłynie to i owo, a towarzyszące temu walory zapachowe mogą mieć szeroki zasięg.

Po drugie, należy bezwzględnie unikać zmiany wymiaru kosztu, a zatem prostych waterfallowych metod – zwiększyć koszt, żeby mieć szybciej. Taa… Skoro zatem zespół mówi, że robimy najszybciej, jak to możliwe, a końca nie widać, z miejsca padają hasła o nadgodzinach czy dodatkowych zasoba.., pardon, osobach w zespole. To często prawdziwy koszmar Scrum Masterów. Opowiadają, tłumaczą, że tracimy zespołowość, że każda taka zmiana w zespole to de facto nowy zespół, że dopiero co udało się zbudować zaufanie w wartości agile, w spokojną, stabilną pracę, koniec marszów śmierci, a tu znów nadgodziny… Tymczasem po drugiej stronie – owszem argumenty te znajdują zrozumienie – ale w odpowiedzi jest prosty komunikat: dla dobra firmy nie możemy zrobić inaczej. I tu właśnie mamy jedną z bardziej niebezpiecznych dróg do zabicia świeżych agile’owych inicjatyw. Coś, co niestety miałem nieprzyjemność nieraz obserwować. Naruszając zespołowość, przymuszając do ponadnormatywnej pracy czy dokładając kolejne osoby – najszybciej doprowadzimy do upadku agile’a. Pal zresztą licho czy to agile czy cokolwiek innego. Po prostu zabijemy motywację ludzi i doprowadzimy do co najmniej zniechęcenia ich do codziennej pracy.

Co zatem nam pozostaje?

Zasady gry

W klasycznym trójkącie projektowym mieliśmy do sterowania: czas, koszt i zakres. A wszystko to miało wpływać na jakość. Skoro o kosztach i jakości już pisałem, pozostały nam dwa czynniki. Ustalmy na którym z nich najbardziej zależy naszym Interesariuszom – czy istotniejsza jest dla nich data (w danym momencie wchodzą jakieś regulacje prawne, musimy być gotowi na ważną branżową konferencję czy po prostu – dana funkcjonalność ma sens tylko w określonym momencie) czy zakres funkcjonalności (tylko określony zestaw funkcjonalności ma sens, nie godzimy się – przynajmniej na początek – na jego zmniejszenie).

Mając tę wiedzę, wiemy którym aspektem w razie czego “sterować”, w którym negocjować ewentualne zmiany.

Jeśli mamy zamrożony czas, konieczność wydania funkcjonalności na konkretną datę,  wiemy, że działać będziemy pod większą presją i w razie czego będziemy zmuszeni eliminować mniej ważne funkcjonalności. Kluczowa jest zatem bardzo dobra priorytetyzacja zadań i ciągła weryfikacja co jesteśmy w stanie do tej daty zrealizować.

Z kolei w przypadku konieczności wydania dopiero w momencie wytworzenia określonych funkcjonalności, do sterowania pozostaje nam data. Albo będziemy dłużej wytwarzać, albo w którymś momencie, zdecydujemy się jednak na udostępnienie klientom produktu z mniejszą ilością funkcjonalności.

W obu sytuacjach na pewno należałoby najpierw z grubsza skategoryzować projekt w kategorię typu: mały, średni, duży, gdzie mały, to przykładowo, 1-2 dwutygodniowe sprinty, średni – 3-4 sprinty, a duży – 5 lub więcej. Do umieszczenia inicjatywy w konkretnym przedziale, nie potrzebujemy dogadywać niskopoziomowych szczegółów. Kategoryzacji tej powinien dokonać zespół, który ma całość realizować.

Po drugie – podkreślmy, że będziemy podawać z każdym sprintem coraz szczegółowsze informacje. Trzeba jasno komunikować – im mniej wiemy o tym, co realizujemy, tym podawana data jest mniej realna, obarczona większym ryzykiem. I będzie tak, nawet jak estymować będzie największy Znawca spośród wszystkich Znawców…. Trzeba także wyjaśniać dlaczego w niczym nie pomoże nam ścieżka waterfallowa – a zatem dokładna wstępna analiza rzeczy do wykonania, na bazie której oszacujemy czas realizacji.

Po trzecie – musimy dokonać wstępnego planowania. Nieważne, czy chodzi o oszacowanie co jesteśmy w stanie zrobić na konkretną datę czy o podanie prognozowanej daty, kiedy zrealizujemy dane funkcjonalności. Musimy wiedzieć z czym się mierzymy.

W obu przypadkach siadamy całym zespołem Scrumowym, zapraszamy ewentualnych Ekspertów, rozpisujemy, omawiamy wysokopoziomowo zadania i próbujemy wstępnie zaplanować sprinty. To nie jest proste i jest zdecydowanie wbrew programistycznym przyzwyczajeniom. Sam nieraz usłyszałem: za mało informacji, żeby cokolwiek powiedzieć. I owszem, nie możemy oczekiwać podania estymacji typu: 2 dni. Ale przedział: maksymalnie dwa dni, dwa – pięć dni, dwa tygodnie, masa roboty – z tym sobie zawsze poradzimy. Istotne jest, żeby na początku wszystkim jasno wytłumaczyć o co tutaj chodzi, dlaczego tak estymujemy, dlaczego ma to sens.

Nie potrzebujemy na tym etapie nawet Story Pointów, wystarczą nam z grubsza omówione zadania. Rozpiszmy nawet wirtualne sprinty. Oznaczajmy przy każdym zadaniu poziom niepewności, kategoryzujmy je. Wypiszmy ryzyka. Zostawmy sobie tradycyjny bufor. Może cały sprint, a może dwa. Technik jest wiele, nie bójcie się eksperymentować.

Ważne jest, że w całości uczestniczyć będzie także Product Owner. Od samego początku i on będzie miał wiedzę na co się porywamy, jakie mamy wyzwania, co może nas spowolnić, co może być największym ryzykiem.

Koniec końców wyjdzie nam potencjalna ilość sprintów. Przekażmy tę informację. Podkreślmy również raz jeszcze, że to wstępna prognoza i zobowiązujemy się aktualizować ją co sprint. Musimy zbudować tutaj zaufanie na linii Zespół – Interesariusze. Komunikujmy zawsze uczciwie, w pełni opisując to się dzieje, informując o wzlotach, ale i upadkach, popełnianych błędach. Nie uniknięcie ich. Mając jednak pełen obraz sytuacji, Interesariusze będą mogli podejmować najlepsze na dany moment decyzje.

Działajmy zatem trochę na zasadzie branży muzycznej, gdzie dany artysta, zapowiada w pewnym momencie, że nowa płyta ukaże się jesienią przyszłego roku. Ma zabukowane studio, rozpoczyna prace i w ich trakcie okazuje się czy album ukaże się we wrześniu, styczniu kolejnego roku, a może… w ogóle nic z tego nie będzie. No dobra, to ostatnie się prawie nie zdarza.

Presja

Kwestię estymacji terminu omówiliśmy, co z presją na Zespół w trakcie jego pracy? Bo, znów – na papierze to wszystko brzmi fajnie. Robimy się, uczymy, odkrywamy nowe rzeczy, dowiadujemy się o nich tak wcześnie, jak to możliwe. Z każdym sprintem coraz wyraźniej widać horyzont, możemy przekazywać coraz szczegółowsze informacje. W praktyce wszyscy jednak nerwowo wyczekują końca prac, podpytują, dociekają, próbują w różny sposób uzyskać informację kiedy, albo – co wcale nie jest reliktem przeszłości – w różny sposób zmotywować do klasycznego szybciej.

Tutaj musi działać i reagować Scrum Master. Który powinien nieustannie obserwować i odczytywać to, co dzieje się wokół prac i odpowiednio na to reagować. Codziennie rozmawiać z Product Ownerem i zespołem, co jakiś czas pytać o nastroje Interesariuszy, uzupełniać, uszczegóławiać informacje na Przeglądach Sprintu. Pilnować tego czy wszystkie najistotniejsze informacje docierają do zainteresowanych i czy nie są po drodze przeinaczane. Dbać o dobry, transparentny przebieg informacji. Może warto rozwiesić w firmie wielką kartkę z bieżącymi informacjami, a może powinna to być dedykowana strona w firmowym intranecie czy wiki. Takie jedno miejsce z wszystkimi najważniejszymi informacjami, a może i z listą problemów i historią spraw rozwiązanych, na pewno pomoże.

Choć wielu uzna to za kontrowersyjne, uważam też, że Scrum Master musi też na początku zdjąć presję z zespołu, nie pozwolić, żeby odczuł on naciski i zewnętrzną presję. Nawet, jeśli to niezgodne z czymś, co zapisano w Wielkich Księgach, jeśli wykracza poza książkowe zasady pełnienia tej roli. Powinien działać jak dobry waterfallowy Project Manager i roztaczać ochronny parasol nad zespołem, biorąc czasem ciężar i odpowiedzialność na siebie. Nie twierdzę, że to ma trwać permanentnie. Twierdzę, że zbyt szybkie dopuszczenie zespołu do wszystkich informacji zewnętrznych, oczekiwań, celów może się skończyć wspomnianą już demotywacją. W początkowych fazach kształtowania się agile’owej kultury w firmie, pewne sprawy lepiej jednak załatwić z interesariuszami w kuluarach ich gabinetów, aniżeli publicznie na przeglądzie sprintu. A zespoły niech rosną w pewnym inkubatorze i powoli nabierają skrzydeł, pewności i wiary w siebie.

Podsumowanie

Zasady estymacji to bardzo złożony problem. Właściwie każdy z poruszonych tu wątków można by przekuć w osobny artykuł, a całość w niemałą książkę (czego przykładem wspomniana publikacja Cohna). Mam jednak nadzieję, że udało mi się jednak uchwycić najważniejsze zjawiska i pokazać kilka sposobów, jak z nimi wszystkimi sobie radzić. Powodzenia!