IT Project
Zarządzanie organizacją i Projektami IT
Agile – święty graal IT ?
W ostatnim czasie dużo mówi się o metodyce Agile. Zarówno po stronie Klienta jak i Dostawcy usług IT. Z dużą dozą entuzjazmu przedstawia się jej zalety, natomiast nieco mniej mówi się o jej słabszych stronach. Ten artykuł dedykuję wszystkim bezkrytycznym entuzjastom Agile i rozsądnie myślącym.
Od lat prowadzę projekty różnymi metodykami, w tym również wykorzystujące elementy metodyki Agile. Sam również kilkukrotnie tworzyłem dedykowane metodyki wykorzystujące różne elementy innych metodyk, w celu i optymalnego dopasowania do przedmiotu projektu. Mam w związku z tym jakiś bagaż doświadczeń, które skłaniają minie do postawienia pytania "Agile - święty graall IT?". Szukając odpowiedzi na to pytanie w Internecie znalazłem bardzo ciekawą publikację. Na podstawie badań w UK i USA stwierdzono, że firmy stosujące metodykę Agile mają, aż o 268% większą szansę na to, że projekt zakończy się porażką.
268% Higher Failure Rates for Agile Software Projects, Study Finds | Engprax
Ten artykuł potwierdza, że znak zapytania w tytule niniejszego artykułu ma jak najbardziej sens. Jednak zagadnienie jest bardziej złożone i w mojej opinii wynika, przede wszystkim z faktu, że nie metodyka Agile jest zła, ale jej bezkrytyczne jej stosowanie (zresztą jak każdej innej metodyki również) prowadzi do porażki projektu, rozczarowania Klienta i Dostawcy.
Dlaczego tak się dzieje? Wynika to z pewnego niezrozumieniu, czym jest projekt, czym jest metodyka oraz nie wystarczającej wiedzy i doświadczenia w prowadzeniu projektów (ew. marketingowo dobrze wykonanej pracy różnych "mesjaszy biznesu" w tym głównie "handlowych mesjaszy"😊, którzy nigdy nie zrobili żadnego projektu).
Dlatego postanowiłem zrobić mała analizę przyczyn tego stanu rzeczy i podzielić się nią z Wami, licząc na Wasze zdanie w tym temacie. O to kilka zagadnień:
- Zarówno Klient, jak i Dostawca, często deklaratywnie i/lub bez większego zrozumienia próbują zastosować Agile. Mimo, że jak każda metodyka, to zbiór dobrych praktyk, a nie przepis na udaną realizację projektu. Dlatego ZAWSZE należy dostosować je do realiów konkretnego projektu tj. celów projektu, przedmiotu Projektu, zespołów Dostawcy i Klienta, terminów i budżetów itd.
- Zwykle Klient oczekuje, że Dostawca w Umowie „krwią się podpisze” pod terminami, budżetem dla bliżej nie określonego zakresu projektu przy równoczesnych niedookreślonych deklaracji Klienta co do wymagań oraz zaangażowania własnych zasobów w Projekt. Klient oczekuje dzieła w postaci działającego rozwiązania IT. O zakresie projektu to Klient powie Dostawcy w czasie projektu, bo przecież „tak działa Agile”. W sprintach będzie oceniał czy powstające prototypy to jest to o co mu chodziło, czy jednak nie. Przy takim podejściu Klienta, to raczej przepis na katastrofę lub co najmniej zaprojektowane przyszłe rozczarowanie Klienta, że projekt, ani w tym zakresie, ani w tym budżecie i ani w tym terminie się nie wydarza/wydarzył.
- Dostawca (zwykle nieco bardziej wyedukowany w Agile, bo to powinno być jego narzędzie pracy) oczekuje dużego zaangażowania zespołu Klienta w definiowaniu wymagań, ciągłej współpracy (planowaniu sprintów, pracy w sprintach, rozliczeniach sprintów itd.). Co więcej czasem kierowania pracami, nadawanie tonu w projekcie prze Klienta. No bo, w końcu mamy Agile i on swoje wymogi ma... Gdzieś tu się gubi myśl, że Klient nie prowadzi działalności biznesowej mającej na celu budowanie i wdrażanie rozwiązań IT, tylko prowadzi swój biznes, a rozwiązania IT mają mu w tym pomóc. Praca nad rozwiązaniem IT jest dodatkowym ogromnym wysiłkiem Klienta. Dlatego po entuzjastycznym rozpoczęciu projektu Klient zaczyna orientować się, że Agile w praktyce oznacza zbyt duże obciążenie dla jego ludzi . Choć może gdyby przed projektem wiedział co to znaczy projekt typu Agile, to by się odpowiednio do tego przygotował tworząc przestrzeń dla swoich ludzi na realizację projekt i zwiększył prawdopodobieństwo sukcesu projektu. Należy pamiętać, że Klient stając przed problemem, czy biznes czy projekt zawsze wybierze biznes i tak ma być. Dlatego na projekcie jak nie starcza zasobów Klientowi to Klient zaczyna podejmować 'działania zaradcze', czyli stosować ‘obejścia’ typu, a może "profesjonalny" Dostawco, sam tam sobie popracuj w sprintach, bo my musimy zarobić na to wszystko i przyjdź z czymś działającym... itd. itp. No i z cała idea Agile powoli przekształca się w chaos. Zaczynają się wzajemne pretensje, Dostawcy do Klienta, że Klient nie współpracuje i Klienta do Dostawcy, że jest nieprofesjonalny, niedoświadczony, bo sam powinien wiedzieć co i jak zrobić. Mamy narastające problemy w projekcie, choć to obie Strony go same generują.
- Klient zwykle na początku Projektu nie uświadamia sobie, że projekt oznacza bardzo duże zaangażowanie jego najlepszych zasobów w Projekt, które głównie prowadzą jego biznes. Często widzę, że Klient po prostu w warstwie deklaratywnej świetnie się przygotował do Projektu, jednak potem widać na Projekcie, że tak naprawdę nie wiele zrobił lub nie tak jak powinien (np. wynajmując firmę konsultingową, która z definicji nie realizuje projektów IT, więc wiedzę ma raczej mocno teoretyczną w tym zakresie). Z doświadczenia wiem, że przygotowanie Klient do projektu i praca wew. zespołu Klient na Projekcie jest kluczowa dla sukcesu Projektu. Czasem nawet ważniejsza niż sam Dostawca (piszę to z pełną odpowiedzialnością za to stwierdzenie). W szczególności w Projektach prowadzonych metodyką Agile, która wymaga dobrego przygotowania i czasowego przeprojektowania części organizacji Klienta na czas projektu. W przeciwnym wypadku ucierpi i biznes, i projekt, i "znikną" pieniądze Klienta.
- Dostawca jest o tyle w komfortowej sytuacji, że zgodnie z Agile bardziej on czeka na Klient niż sam wykazuje dążność do zrealizowania projektu. Poza tym ma zawsze dobre wytłumaczenie dlaczego projekt się przeciąga, staje się coraz droższy, a zakres nieustannie się rozszerza. Choć tu różnie bywa. Dobry Dostawca będzie chciał zrealizować projekt dobrze, więc w końcu nieco przejmie rolę Klienta na siebie (przy okazji kolejny punkt z manifestu Agile upada) i aktywnie zacznie proponować działania, rozwiązania, które może będą trafne, a może nie. Kiepski Dostawca będzie się czuł w tym jak ryba w wodzie. Brak aktywności Klient na Projekcie generuje ryzyko porażki projektu, którą de facto projektuje Dostawca próbując jakoś zrobić projekt.
- Metodyka Agile zakłada sukcesywne odkrywanie i realizowanie potrzeb Klienta. To oznacza, że nie do końca wiadomo jak duży jest Projekt, kiedy zostanie zrealizowany i w jakim budżecie. Na przykład dla Projektu wdrożenia dużego system ERP, o dużym stopniu wewnętrznego zintegrowania między modułami oraz wieloma integracjami, odkrywanie właściwej konfiguracji, potrzebnych modyfikacji i interfejsów w jednym sprincie (lub prototypie) może nie przystawać do ustaleń w kolejnych sprintach projektu. Czasem trzeba czekać na stabilne ustalenia w zespołach lub mieć jakąś generalną koncepcję rozwiązania i się jej trzymać, aby uniknąć nietrafionych rozwiązań (głównie chodzi o zagadnienia między obszarowe). Dlatego Dostawcy bardzo trudno jest zadeklarować Klientowi terminy, budżety, a w szczególności zarządzać transparentnie dla Klienta zmianą w Projekcie (bo w Agile wszystko jest zmianą i równocześnie jest analiza, implementacja i testy) oraz powiedzieć właściwie jaki jest status Projektu. A Klient, co zrozumiałe, nie chce się zapisać na Projekt gdzie nie wie kiedy, co i za ile otrzyma. No i mamy sytuację w której, albo Strony na początku projektu udają, że nie ma problemu (np. Klient na początku godzi się na ten "układ niewiedzy" licząc na profesjonalnego Dostawcę, co jest zwykle na rękę Dostawcy), albo Klient nie ma wyjścia i godzi się na taki układ narzekając na terminy, budżety i nieprofesjonalnego Dostawcę, albo w skrajnym przypadku mamy pat na projekcie i strony rozstają się z niesmakiem….
- Jeszcze jeden aspekt, który rzadko jest podnoszony, a ma długofalowe skutki. Agile bardzo podkreśla ważność rozwiązania nad dobrą dokumentację rozwiązania. W związku z tym po takim Projekcie prowadzonym metodą Agile zwykle zostaje kiepskiej jakości dokumentacja, albo wcale jej nie ma (!). Wiem, że zaraz znajdą się osoby i powiedzą, że to nie prawda, a ja piszę o praktyce Agile na realnych projektach, a nie o teorii. Jak dla mnie jest to mocno kontrowersyjne założenie i więcej powiem, szkodliwe. Dlaczego? Jeśli nie ma porządnej dokumentacji zarówno merytorycznej jak i projektowej (np. kto kiedy, dlaczego zmienił z jakich na jakie ustalenia w Projekcie) to często te ustalenia każdy rozumie jak uważa. Obiektywna ocena Projektu staje się coraz bardziej subiektywna (zależna kto kogo pyta i "dla kogo ten wywiad"). To ma też dalsze konsekwencje w zjawisku pełzających wymagań/ustaleń, a tym samym pełzającego zakresu projektu, a za nim zmieniającego się budżetu i terminów. Oczywiście ktoś powie po to są sprinty, aby to robić od razu, po to się spotykają PMowie i Komitety Sterujące, aby to kontrolować, ale w praktyce zwykle jest to pozorna kontrola. Głównie przez problemy wskazane w punktach powyżej. Poza tym trudno jest bez dobrej dokumentacji realizować testy, szkolenia, modyfikacje, interfejsy w trakcie wdrożenia, potem serwis i rozwój systemu opierając się ”na zbiorowej pamięci ustaleń”. Dodatkowo, brak dobrej dokumentacji, to też obszar potencjalnych sporów co Dostawca miał dostarczyć, a co dostarczył. Co jest zmianą założeń, rozwojem, a co podlega gwarancji itd.
Oczywiście Agile, jak każda metodyka ma swoje zalety, o ile zastosujemy ją właściwie, do odpowiednich projektów i przy odpowiednim podejściu Klienta i Dostawcy. Czyli zastosowaną jej z głową! Moje doświadczenie podpowiada mi, że Agile dobrze sprawdza się w mniejszych projektach, gdzie faktycznie rozwiązanie IT pisane jest od podstaw. Także w projektach gdzie biznes Klienta czuje potrzebę biznesową przełożyć na rozwiązanie IT, ale nie umie jej zdefiniować na początku projektu i godzi się na wspólne budowanie rozwiązania z Dostawcą i na konsekwencje wynikające z natury Agile. Dodatkowo jest dobrze przygotowany do tego typu projektu. W projektach Agile, strony muszą mieć świadomość i to akceptować, że ze względu na nieokreślony/niedookreślony zakres projektu, zarówno termin jak i budżet mogą być jedynie szacowane i potem sukcesywnie weryfikowane podczas realizacji projektu. Natomiast nie mogą one być celem samym w sobie i być traktowane jako dostarczane dzieło o takich parametrach tj. o z góry określnym zakresie, terminie i budżecie. Zarządzanie zmianą w Projekcie Agile jest trudne, bo właśnie istotą Agile, jest poszukiwanie przez zespół projektowy najlepszego rozwiązania – czyli ciągła zamian.
Na koniec:
Preferuję metodyki zoptymalizowane pod dane przedsięwzięcia, projekt, a nawet zespoły i terminy, które czerpią z różnych dobrych praktyk, z różnych metodyk. I to jest jeden z istotniejszych elementów pracy dobrego Project Managera tj. umiejętność dobrania właściwych praktyk do konkretnego Projektu. Tu nie ma dróg na skróty. Potrzebne jest doświadczenie projektowe i szerokie spojrzenie na temat, aby to zrobić dobrze i osiągnąć sukcesu w projekcie.
Ostatnie wpisy
Zaproszenie
Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.
Zaproszenie
Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.