Kiedy Agile działa, a kiedy nie: Mity, ograniczenia i realna skuteczność dla biznesu

Agile stał się jednym z najczęściej wspominanych podejść do zarządzania projektami. Postrzega się go jako narzędzie zwiększające elastyczność organizacji, umożliwiające szybsze reagowanie na zmiany oraz sposób na realizację projektów w krótszym czasie i z wyższą efektywnością. Zastosowanie Agile w pojedynczych projektach, warunki i ograniczenia, a także kluczowe różnice w stosowaniu „zwinnego” i „kaskadowego” podejścia do zarządzania projektami – to właśnie temat niniejszego artykułu.

Typy projektów

Zgodnie ze standardami zarządzania projektami, w zależności od cyklu życia produktu wyróżnia się następujące typy projektów:

Przewidywalne (plan-driven) — projekty, w których główne ograniczenia są planowane (z określonymi odchyleniami) na etapie początkowym i realizowane zgodnie z cyklem PDCA (Plan-Do-Check-Act).

Adaptacyjne (change-driven) — projekty, w których główne ograniczenia są planowane na całej długości trwania projektu, a sam projekt dzielony jest na części zwane iteracjami. Sens tego podziału polega na świadomości, że projekt w fazie realizacji będzie podlegał wielu zmianom, a podejście do jego zarządzania musi zakładać stałą modyfikację wymagań.

Hybrydowe — projekty, w których elementy (fazy lub części produktu) mogą być realizowane zarówno w sposób przewidywalny, jak i adaptacyjny

Z kolei projekty adaptacyjne opierają się na dwóch podejściach do realizacji:

• Podejście iteracyjne — projekt realizowany jest w krótkich cyklach zawierających pełen obieg PDCA (Plan–Do–Check–Act). To podejście stosuje się w projektach, w których początkowe wymagania nie są szczegółowo określone, a ich doprecyzowanie lub zmiana następuje w trakcie realizacji.
• Podejście przyrostowe (inkrementalne) — produkt powstaje i przekazywany jest klientowi etapami — po częściach. W tym modelu wymagania klienta są realizowane zgodnie z ich priorytetami, ustalanymi na podstawie kilku czynników, z których kluczowe to wartość biznesowa danego wymagania oraz ryzyko związane z jego realizacją.

Agile to adaptacyjny typ projektu, który łączy zarówno podejście iteracyjne, jak i przyrostowe. Na jego bazie powstało i jest stosowanych wiele metod (frameworków).

To zestaw metod zaprojektowanych z myślą o realizacji następujących celów:

• Jak najszybsze dostarczanie rezultatów projektu klientowi (przyrosty);
• Stałe wprowadzanie korekt w projekcie (iteracje);
• Ograniczenie czasu i kosztów związanych z planowaniem projektu.

Agile często postrzegany jest jako nowocześniejsze i bardziej efektywne podejście w porównaniu z klasycznym modelem „wodospadowym”. W praktyce jednak nie wszystkie projekty prowadzone w duchu Agile kończą się na czas, w ramach budżetu lub z oczekiwanym rezultatem. Co więcej, wraz z popularyzacją metod zwinnych obserwujemy również odwrotny trend — powrót firm do tradycyjnych modeli zarządzania. Aby zrozumieć, dlaczego tak się dzieje, warto przyjrzeć się ograniczeniom każdego podejścia i ich wpływowi na skuteczność realizacji projektów.

Poznaj możliwości modułu Project Management & Accounting w Microsoft Dynamics 365 Finance.

Dowiedz się więcej

Popularne mity

Błędne przekonania często prowadzą do problemów w praktycznym zastosowaniu danej metodyki i, jak pokazuje doświadczenie, wynikają zarówno z braku doświadczenia, jak i narzuconych stereotypów, które podkreślają zalety, ale przemilczają ograniczenia.

Mit 1. Nie trzeba planować, trzeba działać. Ten slogan można znaleźć jako jeden z zasad Agile. Brzmi dobrze, ale rodzi wiele pytań: co robić? w jakiej kolejności? jakimi zasobami? z jakimi kosztami? jak dostarczać produkt klientowi? itd. W rzeczywistości w Agile konieczne jest uproszczone planowanie (w porównaniu z „wodospadem”) z dwóch powodów:

• Projekt realizowany jest krótkimi iteracjami (sprintami) trwającymi od 2 do 4 tygodni, więc planowanie takiej iteracji nie powinno wymagać tyle wysiłku, co projekt „wodospadowy” trwający 3 lata.
• Jeśli od początku zakłada się dużą liczbę zmian, sensowne jest szczegółowe planowanie tylko każdej iteracji (sprintu), a nie wydania (release) czy całego projektu, ponieważ to pozbawione jest praktycznego sensu. Nie zmienia to faktu, że przed rozpoczęciem projektu należy oszacować jego koszt i czas trwania.

Mit 2. Każdy projekt można zrealizować metodami Agile. To oczywista przesada, ponieważ istnieje zestaw czynników decydujących o wyborze metodyki zarządzania projektem, uwzględniających mocne i słabe strony metody oraz jej naturalne ograniczenia (zob. niżej).

Mit 3. Agile to „nadmuchany balon”, wypromowany, ale nieprzydatny w praktyce. To odwrotna strona błędu nr 2 – i również niezgodna z rzeczywistością. Agile doskonale sprawdza się w niektórych typach projektów (np. Change Management, Six Sigma, rozwój IT) jako model realizacji całego projektu oraz jest nieodłączną częścią projektów hybrydowych, które wkrótce staną się dominujące, zwłaszcza biorąc pod uwagę rozwój nowoczesnych technologii, szczególnie w branży IT.

Mit 4. W zespole Agile nie trzeba zarządzać, ponieważ jest on samoorganizujący się i sam podejmuje wszystkie decyzje. Samoorganizacja zespołów projektowych i zasobów ludzkich rzeczywiście jest niezwykle pożądanym elementem skutecznego osiągania celów w nowoczesnym zarządzaniu. Jednak twierdzenia, że

1. a) zespół z założenia jest samoorganizujący się,
2. b) zarządzanie projektem nie jest potrzebne, oraz
3. c) jeśli zespół nie jest samoorganizujący się, to nie jest Agile – są, delikatnie mówiąc, dyskusyjne.

Oczywiście zdolność zespołu do samoorganizacji zależy od jego wielkości, psychologii członków, ich doświadczenia, kwalifikacji, stresu związanego z projektem, znaczenia projektu dla klienta, kultury zarządzania w organizacji oraz innych czynników. Dlatego w praktyce metoda zarządzania zespołem projektowym (dyrektywna lub wspierająca) powinna być wybierana w zależności od rzeczywistej sytuacji, zarówno w przypadku projektów „adaptacyjnych”, jak i „przewidywalnych”, i może się różnić na różnych etapach.

Mit 5. Model wodospadowy jest przestarzały, a Agile to nowoczesne podejście do zarządzania. W rzeczywistości podejścia inkrementalne i iteracyjne do realizacji projektów stosowane są od wielu lat. To, co jest stosunkowo nowe, to metoda „time-boxed” ze ściśle określonym czasem trwania iteracji, stosowana np. w Scrum. Ma ona swoje oczywiste zalety i wady, które omówiono poniżej. Ważne jest również, że efektywność i celowość stosowania danej metodyki zależy od zestawu czynników, a nie od „nowoczesności” czy „przestarzałości”.

Mit 6. Przypinanie i przesuwanie karteczek na tablicy Kanban to całe Agile. Kolorowe karteczki podzielone według statusów na tablicy Kanban rzeczywiście przyciągają uwagę. Tym „kluczowym” umiejętnościom przenoszenia karteczek poświęca się często wiele czasu i wysiłku. Niektórzy ludzie szczerze uważają, że to najważniejszy element Agile i zarządzania projektami w ogóle. Nie chcąc nikogo rozczarować, warto zaznaczyć:

• Kanban został stworzony nie do zarządzania projektami,
• Tablica statusów to tylko narzędzie wizualizacji i może, ale nie musi być używane do śledzenia rzeczywistego stanu projektu. Istnieją znacznie bardziej zaawansowane narzędzia do tego celu.

Celowość

W każdym projekcie istnieje „potrójne ograniczenie” (triple constraint). Oznacza to, że przed rozpoczęciem projektu z klientem ustalane jest jedno z ograniczeń (Zawartość/Czas/Koszt), któremu będą podporządkowane wszystkie działania zespołu projektowego związane z planowaniem i realizacją. Ustalenie dwóch ograniczeń znacznie utrudnia realizację projektu, a trzech – przekształca projekt w wyzwanie. Jeśli w modelu wodospadowym (prognozowanym typie) kluczowym ograniczeniem jest Zawartość, czyli to, co musi zostać wykonane, aby osiągnąć wynik, to w metodach Agile – zazwyczaj czas. Oznacza to, że zastosowanie Agile to przede wszystkim próba jak najszybszego dostarczenia klientowi produktu (zwykle w częściach, czyli inkrementalnie).

W ten sposób stosuje się swoisty „kompromis” między zakresem (i jakością) a szybkością dostarczenia produktu. Oprócz tej ogólnej zasady, przy wyborze konkretnego podejścia do realizacji projektu należy uwzględnić następujące czynniki:

• Stopień powiązania funkcji produktu między sobą – czyli na ile dana funkcja może być używana niezależnie od pozostałych funkcji produktu.
• Poziom szczegółowości (i jakości) specyfikacji technicznej projektu – niski poziom szczegółowości niesie ryzyko zmian w zakresie projektu w trakcie jego realizacji, co z kolei wymusza stosowanie iteracji przy tworzeniu ostatecznego rezultatu, a także ograniczenie długości tych iteracji.
• Rodzaj umowy w przypadku realizacji projektu kontraktowego – np. umowa o stałej cenie zakłada, że specyfikacja techniczna jest szczegółowa, a ryzyko zmian w zakresie niewielkie; w takim przypadku podejście iteracyjne traci sens.
• Wielkość zespołu projektowego – im większy zespół, tym trudniejsze staje się zarządzanie nim, co często wymaga jego podziału na mniejsze grupy, utrudniając jednocześnie pracę w krótkich iteracjach.
• Poziom jakości końcowego rezultatu – im wyższe wymagania wobec produktu końcowego i im większe jego znaczenie dla Klienta, tym ważniejsze staje się ograniczenie dotyczące zakresu, a tym mniej pożądane są jakiekolwiek zmiany w tym zakresie.

Zalecenia i ograniczenia dotyczące stosowania poszczególnych podejść do realizacji projektów:

Idealne warunki dla projektów Agile:

• Nieokreślony zakres prac, czyli przewidywana duża liczba zmian w trakcie realizacji.
• Potrzeba jak najszybszego dostarczenia końcowego rezultatu projektu Klientowi.
• Możliwość dostarczenia końcowego wyniku projektu klientowi etapami.
• Projekt realizowany na potrzeby wewnętrzne organizacji (brak kontraktu).
• Projekt realizowany dla zewnętrznego Klienta w modelu rozliczenia „Time & Materials” – czyli płatność za faktycznie wykonane prace lub dostarczone rezultaty.
• Zespół projektowy liczący do 6 osób.

Warunki odpowiednie dla projektów Waterfall:

• Jasno określony zakres prac, co oznacza, że liczba zmian jest przewidywalna i stosowanie iteracji nie ma uzasadnienia.
• Czas realizacji projektu ma znaczenie drugorzędne.
• Funkcje produktu są silnie ze sobą powiązane, co uniemożliwia lub znacząco ogranicza podejście przyrostowe.
• Projekt wewnętrzny lub zewnętrzny, realizowany w ramach dowolnego typu umowy.
• Dowolna liczba członków zespołu projektowego.

Jeśli projekt i jego warunki są „graniczne”, tj. występują przesłanki zarówno pierwszej, jak i drugiej grupy, to taki projekt może być realizowany w podejściu hybrydowym:

• Określone fazy projektu – według Agile, inne – według Waterfall.
• Część funkcji produktu – według Waterfall, część – według Agile.

Przedstawione powyżej listy „mitów” i „celowości” nie są wyczerpujące, ponieważ istnieją inne czynniki wpływające na efektywność stosowania konkretnego podejścia do realizacji projektu. Na przykład ważnym i aktualnym tematem jest ogólna „elastyczność” organizacji realizującej projekt oraz jej klienta (jeśli projekt jest realizowany w ramach umowy). Środowisko, w którym realizowany jest projekt, jest krytycznym czynnikiem jego sukcesu.

Niemniej jednak kwestie, ograniczenia i rekomendacje omówione w tym artykule są kluczowe dla zrozumienia, które podejście do zarządzania projektem jest najbardziej odpowiednie w danej sytuacji.

Warto również pamiętać, że właściwy wybór sposobu realizacji projektu może znacząco wpłynąć na jego powodzenie, ale nie gwarantuje, że projekt zostanie zrealizowany w ramach ustalonych ograniczeń ani nawet że zostanie ukończony w ogóle. Zestaw ryzyk towarzyszących każdej inicjatywie — zarówno na etapie jej oceny i priorytetyzacji (poziom portfela projektów), jak i na etapie realizacji (poziom operacyjny) — ma bezpośredni wpływ na ostateczny rezultat działań i możliwość jego osiągnięcia.

Optymalizuj swój biznes za pomocą funkcjonalności Project Management & Accounting w Microsoft Dynamics 365 Finance.

Dowiedz się więcej

Vlad Berezin

Business Development Manager, SMART business

Ponad 20 lat doświadczenia w zarządzaniu biznesem, projektami i sprzedażą. Prezes Project Management Institute (PMI), Kyiv Chapter w latach 2007–2012. Posiada praktyczne doświadczenie w realizacji projektów z zakresu planowania zasobów przedsiębiorstwa (ERP), zarządzania zasobami ludzkimi (HR), marketingu, organizacji, EPM, PPM, BPMS oraz procesów biznesowych (BP).