Od kilku lat coraz większą popularność zdobywa podejście zwinne (ang. agile) do zarządzania projektami. Manifest Agile powstał 11 lat temu. Od tego czasu agile ma silny wpływ na to co robimy i jak robimy. Niektóre organizacje podjęły wyzwanie wdrożenia agile. Wyzwanie, bo agile w swojej istocie jest bardzo prosty, jednak bardzo trudno jest go wdrożyć. Agile ma wielu sympatyków, a także wielu sceptyków. Dyskusje na temat tego, czy to dobry ruch dla zarządzania projektami są bardzo silne. Niektóre tematy dyskusji urosły do rangi mitów. Poniżej przedstawiam 7 mitów z punktu widzenia zarządzania projektami i Project Managera.


1. Agile to sposób na osiąganie sukcesu w projektach

Kilka razy słyszałem, że jak zastosujemy agile to na pewno projekt będzie sukcesem. Niestety nie jest to prawdą. Nie mamy tutaj zapewnienia osiągnięcia sukcesu. Jednak agile zwiększa prawdopodobieństwo osiągnięcia sukcesu czego dowodzą ostatnie badania Standish Group (patrz rysunek nr1).

The CHAOS Manifesto, The Standish group

2. Agile nadaje się tylko do projektów programistycznych

Owszem ruch agile został zapoczątkowany w obszarze rozwoju oprogramowania i w tym obszarze jest najbardziej dojrzały. Jednak z powodzeniem stosuje się zwinne podejście w wielu innych projektach typu rozwój nowych produktów, wprowadzanie nowych urządzeń. Z mojej perspektywy podejście zwinne można zastosować do każdego projektu szczególnie na warstwie organizacji zespołu.

3. W agile można robić to co się nam podoba, nie ma procesu

To jest całkowicie fałszywe stwierdzenie. U podstaw agile, jest prosty i bardzo sztywny proces. Zespół wykonuje dokładnie to co jest wymagane (backlog) przez Product Ownera, jednocześnie wymusza bardzo duże zaangażowanie po stronie PO. Wymaga skupienia na wytwarzanej wartości w często zmieniających się warunkach. W agile wartością jest też transparentność – każdy w organizacji może widzieć, nad czym zespół pracuje.

4. Agile znaczy szybciej i bez dokumentacji

Pewnym błędem było nazwanie iteracji sprintem. Z tego powodu kojarzy się z szybkim dostarczaniem produktu. W agile nie dyskutujemy na temat jakości, jednak kwestionujemy wszystkie elementy produktu, które nie dodają wartości lub dodają w małym stopniu. Na tej podstawie można obciąć zakres projektu i dostarczyć szybciej wystarczająco dobry produkt.

Brak dokumentacji to jeden z najbardziej znanych mitów i w pewnym stopniu możemy winić tutaj zdanie z Manifestu Agile: „Działające oprogramowanie ponad obszerną dokumentację”. Przez wielu z nas odczytywane jako brak dokumentacji. Agile z powodzeniem stosuje się w środowiskach mocno regulowanych jak medycyna, finanse czy wojsko. Środowiska te wymagają dokumentacji, która jest stosowana. Jednak nie tracimy czasu na dokumentację, która nie dodaje wartości projektowi.

5. Agile nie można zastosować do zespołów rozdystrybuowanych

Prawdą jest, że najlepiej projekt prowadzi się, z zespołem dedykowanym, który jest w jednej lokalizacji. W dzisiejszych czasach w wielu przypadkach nie jest to realne. Jednak agile i w tym przypadku podnosi produktywność zespołów, szczególnie gdy zastosujemy nowe technologie videokonferencji. Zespół może być w różnych miejscach, tak długo jak jest dostępny w odniesieniu do ustalonego modelu komunikacji.

6. Agile nie nadaje się do kontraktowania

W Manifescie Agile możemy przeczytać: Współpraca z klientem ponad formalne ustalenia.” Znaczy to, że cały czas potrzebujemy umów i formalnych ustaleń, lecz bardziej cenimy współpracę i relacje z klientem. Kontrakty nie są złe i powinny być stosowane, aby pomóc stronom zbudować wspólne zrozumienie celu i zaangażowania. W ostatnich latach kontrakty zyskały złą reputację poprzez przerzucanie ryzyka między stronami oraz bardzo długie negocjacje.

Często też słyszymy, że w agile nie można zastosować kontraktu ze stałą ceną (ang. Fixed Price Contract). Nic bardziej mylnego. W agile stosujemy backlog i na podstawie backlogu estymujemy czas i budżet wymagany do jego realizacji. Na te warunki możemy podpisać kontrakt ze stałą ceną. Warunkiem jest bardzo duża transparentność strony dostarczającej produkt oraz otwarta rozmowa w przypadku wprowadzania zmian do backlogu. W takim przypadku możemy zrezygnować z funkcjonalności niskiego priorytetu. Z badań firmy Genesis Consulting po przeprowadzonych 22 projektach wdrożenia SAP wynika, że klienci dodają funkcjonalności na poziomie 22%, jednocześnie rezygnując z 18%. To wszystko przy bardzo dużym zadowoleniu obu stron.

7. Agile znaczy brak planowania

Kolejny bardzo często spotykany mit. Agile u swoich podstaw ma wbudowane w procesie co najmniej 20% czasu na planowanie. Nikt tutaj nas nie zwalnia z planowania i estymowania końca projektu oraz budżetu. Planowanie odbywa się na dwóch poziomach: projektu i sprintu. Empirycznie estymujemy backlog projektu oraz backlog sprintu. W dalszym ciągu musimy wiedzieć co będzie zrobione w najbliższej przyszłości tak aby zaangażować zespół oraz inne wymagane zasoby oraz sprawdzić zależności. W agile planowanie jest krokowe, skupione na dostarczaniu wartości a sam proces pomaga dostosowywać plany projektu do aktualnie posiadanej wiedzy.

I na koniec dodatkowy na w pół prawdziwy i najbardziej intrygujący dla Project Managerów mit:

W Agile nie ma Project Managera

Brzmi jak zagrożenie dla zawodu Project Managera. Jak przyjrzymy się zespołowi scrumowemu, to nigdzie nie znajdziemy roli Project Managera. Jednak w agile wymagane są kompetencje zarządzania projektami. Propozycja Agile Project Management została także sformułowana w książce Jima Highsmith’a – jednego z autorów Manifestu Agile. Project Manager i jego kompetencje są wymagane tak po stronie zespołu projektowego, jak i po stronie Product Ownera. Project Manager zna organizacje, umie współpracować z dostawcami, ma narzędzia i umiejętności zarządzania zależnościami, ryzykiem i budżetem. Te kompetencje są szczególnie potrzebne przy dużych i wymagających projektach. Oczywiście wymagania co do Project Managera rosną i to bardzo dobrze dla rozwoju. Można łatwo zaobserwować, że na rynku amerykańskim jest bardzo duże zapotrzebowanie na Project Managerów ze znajomością praktyk agile. Zmiany w kierunku agile to dla Project Managera duża szansa.