Agile czy nie Agile? – oto jest pytanie

Artykuł został opublikowany na łamach kwartalnika Strefa PMI
w numerze 4, w 2014 r.

Nawet tak klasyczne pytanie w odniesieniu do „Agilowych” (czyli zwinnych) metod stosowanych w zarządzaniu projektami wywoła zdziwienie, a być może protesty już na starcie. Metodyki „Agilowe” okrzyknięto głośno rewelacyjnym remedium na wszelkie kłopoty w zarządzaniu projektami i przeciwstawiono je tradycyjnym podejściom opartym na tzw. Waterfall. Uważa się, że metodyki takie jak PRINCE2 są bardzo trudne i niemożliwe do zastosowania w organizacji, dlatego należy je porzucić. Co innego podejście „Agile”. Zwinne podejście w obiegowym przekonaniu da się wprowadzić do organizacji bez większego wysiłku, co w naturalny sposób zintegruje wszystkich uczestniczących w pracach projektowych i szybko zaowocuje skutecznie wykonywanymi projektami.

Podczas wielu spotkań, wykładów, artykułów internetowych i prasowych oraz innych wystąpień, pojawiają się głosy które na zasadzie argumentów ad ignorantum namawiają do stosowania „Agile” i tylko „Agile”, przeciwstawiając go np. PRINCE2 i pomijając inne warstwy ładu. Trzeba przyznać, że te obietnice łatwych sukcesów porywają wielu, w tym często informatyków, którzy chcieliby ułatwić sobie relacje z zawsze niesfornym „biznesem”.

Ponieważ stosuję zasadę: „Amicus Plato, sed magis amica veritas” (co się wykłada, że niezależnie od okoliczności trzeba mówić prawdę), pragnę przypomnieć czym jest ład każdej organizacji i pokazać, gdzie jest w tym ładzie właściwe miejsce dla „Agile”. Zatem w czym może nam pomóc „Agile”, a jakich obszarów to podejście absolutnie nie jest w stanie obsłużyć?

Poniższy rysunek prezentuje uproszczoną mapę ładu każdej organizacji: małej, średniej i tak dużej jak całe państwo.

Każda organizacja realizuje swoją strategię przy pomocy zwykłej działalności biznesowej (rutynowej, operacyjnej), gdzie osiągane są korzyści. To ze strony zwykłej działalności biznesowej przychodzi zapotrzebowanie na zmiany. Celem tych zmian jest dostosowanie do zmieniającej się strategii, dogonienie lub przegonienie konkurencji. To dlatego mamy w organizacji inicjatywy zmiany przybierające kształty programów i projektów, w sumie razem budujących zaplanowany portfel.

Projekty mogą być samodzielne lub wchodzić w skład programów. Organizacja projektu może obejmować jeden lub więcej zespołów, które dostarczają produkty specjalistyczne (np. informatyczne, marketingowe itd.).

Zarządzanie projektem, programem i portfelem to strefa ładu każdej organizacji. Poniższy rysunek pokazuje, która metodyka lub poradnik pomoże we wprowadzeniu ładu na odpowiednich poziomach zarządczych.

I tak MoP wspomaga zarządzanie portfelem organizacji, MSP daje ramy do zarządzania programem, a PRINCE2 jest podstawową metodyką zarządzania projektem. PRINCE2 poza wyznaczeniem roli Kierownika Zespołu nie obejmuje wewnętrznego środowiska pracy zespołu ani inżynierii wytwarzania produktu. AgilePM potrafi wspomóc budowanie ładu w warstwie zarządzania niewielkich projektów oraz w warstwie związanej z zarządzaniem zespołem, ale nie wchodzi w specjalistyczną warstwę dostarczania produktów. Na ten obszar produkcji oprogramowania ukierunkowane są XP oraz Lean, natomiast SCRUM tworzy kulturę pracy zespołu specjalistycznego.

Metodyki zwinne można łączyć ze sobą oraz metodykami zarządzania projektami. Bardzo często spotkamy się ze środowiskiem, gdzie warstwa zarządzania projektem będzie pod kontrolą PRINCE2, zarządzanie zespołem przebiegać będzie w oparciu o AgilePM lub SCRUM, a wytwarzaniu oprogramowania przewodzić będzie XP. W miejscu, gdzie kończy się władza PRINCE2 szczególnie cenne jest właśnie podejście do budowania zespołu złożonego z użytkowników i specjalistów technicznych. Za te sugestie i techniki pracy zespołów złożonych z różnych interesariuszy trzeba cenić „Agile” najbardziej, w tym jako receptę na zakończenie wzajemnej wojny świata IT z biznesem.

Jednakże „Agile” to nie wszystko. Nie można go traktować w izolacji od pozostałych warstw ładu. Sam „Agile” bez wsparcia warstw wyższych nie będzie efektywny. Spójrzmy, co się stanie, gdy będziemy chcieli pominąć którąś z warstw ładu.
Czy można zrezygnować z programu? Nie. Gdy bowiem spróbujemy potraktować inicjatywę wymagającą ładu programu jako projekt nieuchronnie przegramy. Przykładem takiego niepowodzenia w skali kraju jest klęska inicjatywy wprowadzenia elektronicznych (chipowych) dowodów osobistych pod nazwą PL-ID, która została potraktowana jako projekt… informatyczny, a bezwzględnie powinna zostać przeprowadzona jako program.

Czy można zrezygnować z portfela? Nie. Typowymi objawami braku właściwego zarządzania portfelem jest uruchamianie projektów niepotrzebnych (tzw. projektów pupilków) lub nawet będących między sobą w sprzeczności. Innym objawem jest uruchamianie pakietu inicjatyw niemożliwych do realizacji z powodu braku zasobów.

Żadna metodyka „Agilowa” sama nie wspomaga zarządzania programem i portfelem, choć oczywiście w programie i portfelu mogą znaleźć się niewielkie projekty zarządzane przy pomocy AgilePM.
Duże zdziwienie budzą też wypowiadane konkluzje, że tradycyjne podejścia do zarządzania projektami jak PRINCE2 uniemożliwiają jakoby zastosowanie podejścia „Agile”. Więc albo PRINCE2 albo „Agile”. W mojej ocenie PRINCE2 jako metodyką zarządzania projektami jest znakomicie przygotowana do połączenia się z zespołami specjalistycznymi stosującymi podejście „Agile” co najmniej poprzez:

• stosowanie zasady delegowania, gdzie Kierownik Projektu udziela Kierownikowi Zespołu kontrolowanych uprawnień do samodzielnego zarządzania zespołem
• proponowanie aż 6-ciu tolerancji, jakie można delegować zespołom: czas, budżet, jakość, zakres, ryzyko, korzyści (jak wiadomo w podejściu Agile czas, budżet i jakość są stałe, ale można zmieniać zakres kontrolując go przy pomocy priorytetów)
• elastyczny proces Zarządzanie Dostarczaniem Produktów stanowiący interfejs pomiędzy projektem a zespołem.

Wreszcie obalić trzeba mit o tym, że „Agile” wprowadzi się do organizacji sam. Niestety, same szkolenia i konferencje nie spowodują, że wszyscy uczestnicy zastosują się do pryncypiów „Agile”. Tak samo, jak w przypadku wszystkich warstw ładu i tutaj musi być odgórnie nadane właścicielstwo metodyki czyli musi być ktoś, kto ustali reguły, będzie wspierał korzystających w ich przestrzeganiu i zadziała jako policjant, gdyby ustalone reguły były naruszane. Tym „kimś” może być zbudowane w organizacji z uprawnienia zarządu P3O (Biura Portfeli, Programów i Projektów), które potrafi zapewnić, że wdrożenie „Agile” będzie odbywać się w synergii z wprowadzaniem ładu wszystkich warstw P3. Wielu dobrych ekspertów „Agile” podkreśla zresztą, że do „Agile” organizacja musi dorosnąć i to wymaga rozłożonych w czasie działań. Nie można obiecywać natychmiastowych korzyści.

Pora zatem na podsumowanie:

• w podejściach „Agilowych” jest ogromna siła i wartość dla organizacji
• „Agile” nie pokrywa wszystkich niezbędnych poziomów ładu P3, dlatego promowanie „Agile” w izolacji jest bardzo szkodliwe
• przeciwstawianie „Agile” tradycyjnej metodyce projektowej takiej jak PRINCE2 jest całkowicie nieuzasadnione
• „Agile” nie wdroży się sam, gdyż powinien zostać formalnie przyjęty i wdrożony w organizacji wraz z innymi warstwami ładu.

Quod erat demostrandum (czyli co było do wykazania). By dyskusjom o „Agile” nadać konstruktywne ramy do rozważań z entuzjazmem ale i cum grano salis (dosłownie ze szczyptą soli czyli z pewną dozą rezerwy).