Zawsze mam sporo zabawy, słuchając dyskusji zwolenników klasycznego i zwinnego zarządzania projektami. Zauważyłem, że czym mniejsze doświadczenie zawodowe, tym większe przekonanie, że metodyka, którą się lubi, jest najlepsza.

Podczas jednego z seminarium PMI w Bydgoszczy, z dużym zainteresowaniem śledziłem reakcję jednego z autorów książek o tematyce zwinnego zarządzania projektami – pana Krystiana Kaczora[1], kiedy podczas dyskusji jedna z prelegentek przekonywała wszystkich, że nawet most można zbudować przy użyciu metodyki Agile. Niestety, nie zapisałem sobie dokładnie słów, które padły, ale mam nadzieję że fraza „można, ale po co?” doskonale odda wypowiedź pana Krystiana. Warto sobie uświadomić, że metodyka to narzędzie, które używamy w konkretnym przypadku. Przecież, jeżeli pan Andrzej kupi sobie komputer do warsztatu samochodowego, to nie znaczy, że wyrzuci wszystkie inne narzędzia. Nie widzę większego sensu walenia klawiaturą w kopułkę rozdzielacza, kiedy wystarczy użyć zwykłego śrubokręta. Żyjemy w czasach, kiedy wszystko dzieje się szybko i dla laika, nieznającego dokładnie założeń metodyk, użycie metodyki zwinnej wydaje się oczywiste, bo przecież trzeba wszystko szybko, nowocześnie, zwinnie, bez zbędnych papierów, bo to takie fit! Nie mam zamiaru wchodzić w polemikę, bo pewnie skończyłoby się na rozważaniach podobnych do tych, które przedstawiał w swoich programach Jan Tadeusz Stanisławski – „O wyższości Świąt Wielkiej Nocy nad Świętami Bożego Narodzenia”, bardziej zastanawiam się, jak pomóc w wyborze odpowiedniego rodzaju metodyk.

We wrześniu 2017 roku, Project Management Instytut opublikował szóste wydanie zbioru dobrych praktyk w Zarządzaniu Projektami – PMBOK[2]. Znamienne jest połączenie dwóch oddzielnych podręczników w jedną edycyjną całość, tak więc na pierwszej stronie mojej elektronicznej kopii dokumentu mogę przeczytać: „Together for the first time – PMBOK Guide – Sixth Edition + Agile Practice Guide[3]”. Co to oznacza? Tylko tyle, że profesjonaliści widzą potrzebę stosowania obu tych narzędzi i nikt nie ma zamiaru ich wartościować przez pryzmat „nowoczesności”. Na marginesie, nie do końca zgadzam się z tezą, że metodyki zwinne to „powiew świeżości”. Ten wiaterek wieje już około 20 lat, co przy gwałtowności przemian w biznesie jest bardzo długim okresem. Chyba tylko prawdziwy miłośnik samochodów odważył by się nazwać 20 letni pojazd nowoczesnym, a podobno technologie starzeją się wolniej od idei.

W takim razie, co wybrać ?

Pan Robert Wysocki, w swojej książce[4], dosyć szeroko opisuje różnice pomiędzy metodykami. Na tyle szczegółowo, że postanowiłem zadać mu pytanie o algorytm decyzyjny. No bo, jeżeli będzie można opisać wybór algorytmem, to wystarczy dostarczyć danych i można to wyliczyć. Już widziałem program, do którego wrzuca się informacje, zaszumi, zakołacze i w sposób automagiczny wyskoczy nazwa metodyki. Wow, jakie to proste. Niestety, moja radość była dosyć krótka i trwała do momentu, kiedy w pierwszym zdaniu odpowiedzi przeczytałem „… automated tool, I don’t think that would be too practical”. W dalszej części wiadomości pojawia się lista książek, które warto przeczytać na ten temat. Po otrząśnięciu się z rozczarowania i zastanowieniu się przyznałem mu rację. Przecież każdy projekt to specyficzne zadanie odbywające się w specyficznym środowisku. Liczba zmiennych jest olbrzymia i praktycznie niepowtarzalna, dlatego też decyzji o wyborze metodyki nie można powierzyć automatowi. Są to wielokrotnie kompetencje osób zarządzających wynikające z ich wiedzy, doświadczenia i intuicji.

No dobrze, jeśli decyzji nie można pozostawić automatowi, to może są jakieś narzędzia wspierające, bo jednak podział metodyk odbywa się w oparciu o pewne kryteria, to wystarczy je sprawdzić i uzyskać jakąś podpowiedź „kierunkową”. Na ten wynik wystarczy nałożyć wszystkie znane „to zależy” i już mamy odpowiedź.

Szukane rozwiązanie było bliżej niż mi się wydawało, niestety trochę potrwało zanim dotarłem do ostatniego załącznika we wspomnianej powyżej publikacji PMI. Załącznik 13, „Agile suitability filter tools” okazał się tym, czego szukałem. Użycie prostego modelu z atrybutami organizacji i projektu pogrupowanymi w trzech kategoriach (kultura organizacyjna, zespół i projekt) wydaje się doskonałym narzędziem wspierającym decyzje o wyborze metodyki. Należy bardzo wyraźnie podkreślić, że to narzędzie wspomaga wybór, ale nie zastępuje „zdrowego rozsądku”.

Kategoria: Kultura organizacji - czy w organizacji jest otoczenie wspierające Agile?

1. Akceptacja podejścia: Czy przełożeni i sponsorzy rozumieją i wspierają użycie metodyki zwinnej w tym projekcie ?

1 – TAK
5 – częściowo
10 - NIE

2. Zaufanie do zespołu: Czy interesariusze mają pewność że zespół zrozumie ich wizję i potrzeby?

1 – TAK
5 – prawdopodobnie
10 - mało prawdopodobne

3. Decyzyjność: Czy zespół może uzyskać autonomię i uprawnienia do podejmowania decyzji dotyczących jego pracy?

1 – TAK
5 – prawdopodobne
10 – mało prawdopodobne

Kategoria: Zespół – czy mamy odpowiedni zespół?

1. Wielkość zespołu: Jaka jest wielkość zespołu projektowego ?

1 – od 1 do 9
2 – od 10 do 20
3 – od 21 do 30
4 – od 31 do 45
5 – od 46 do 60
6 – od 61 do 80
7 – od 81 do 110
8 – od 111 do 150
9 – od 151 do 200
10 – więcej niż 201

2. Poziom doświadczenia: Jaki jest poziom doświadczenia członków zespołu projektowego ?

1 – duże
5 – średnie
10 – brak

3. Dostępność klientów: Czy zespół ma łatwy dostęp do klientów biznesowych?

1 – łatwy
5 – średni
10 - brak

Kategoria: Projekt – czy przewidywane są zmiany w zakresie? Czy możliwe jest podejście iteracyjne?

1. Prawdopodobieństwo zmian: Jaki procent wymagań prawdopodobnie ulegnie zmianie w ciągu miesiąca ?

1 - 50%
5 – 25%
10 – 5%

2. Krytyczność produktu lub usługi: Jaka jest skala wpływu niepowodzenia projektu?

1 – czas
5 – pieniądze
10 – ludzie

3. Przyrostowość produktu: Czy produkt można dostarczyć w iteracjach ?

1- TAK
5 – być może
10 – NIE

No, to teraz wystarczy otworzyć arkusz kalkulacyjny, trochę pracy przy przygotowaniu wykresu radarowego  i można używać narzędzia.

Sposób interpretacji wykresu – obszar zaznaczony kolorem pomarańczowym to metodyki Agile, żółty metodyki pośrednie – hybrydowe, pozostała część to metodyki klasyczne.

W Załączniku 13, PMBOK, 6 edycja, opisane są 2 przykłady (case studies). Pierwszy to projekt apteki on-line, realizowany Agile.  W ramach projektu stworzono internetowy sklep z lekami, aby sprzedawać tańsze kanadyjskie leki na receptę, głównie klientom z USA. Sprzedaż leków jest przedmiotem sporów zarówno w Kanadzie, jak i USA, a przemysł ten charakteryzuje się szybką zmianą regulacji i ostrą konkurencją. Projekt spotkał się z wyjątkowo niestabilnymi wymaganiami, z dużymi zmianami w ciągu tygodnia. Używał bardzo krótkich iteracji (2 dni) i cotygodniowymi wersjami oprogramowania, aby stawić czoła wysokim wskaźnikom zmian.

Jak widać na wykresie, wysoki poziom akceptacji podejścia zwinnego i zaufanie do zespołu jest oczywiste. Wizualny charakter strony internetowej ułatwił pokazywanie nowych przyrostów funkcjonalności, czyli była wyraźna możliwość oddawania produktu w iteracjach. Z drugiej strony, krytyczność systemu była dość spora, miało to związek z przychodami apteki. Projekt charakteryzował się dużą zmiennością. Wszystkie zmiany były bardzo sprawnie obsługiwane przez mały, doświadczony zespół. Olbrzymie znaczenie miał łatwy dostęp do kompetentnego przedstawiciela handlowego, który w tym wypadku pełnił rolę klienta.

W porównaniu z pierwszym przykładem, w drugim mamy do czynienia z dużym projektem dotyczącym opracowania wojskowego systemu przesyłania komunikatów.

W tym przypadku podejście "zwinne" nie było brane pod uwagę. Zaufanie do dostawców (zespołu) było mieszane. Podejmowanie decyzji nie odbywało się lokalnie, lecz w ramach zobowiązań dotyczących architektury rozwiązania i wymogów opisanych wcześniej. Elementy projektu mogły być testowane przyrostowo w laboratorium, ale nie można ich było zebrać i przeprowadzić demonstracji funkcjonalności. W przypadku niepowodzenia projektu, wiele osób było potencjalnie zagrożonych , więc krytyczność była bardzo wysoka. Zmiany zostały zablokowane, ponieważ miały wpływ na wiele organizacji i podwykonawców. Projekt był duży i pracowało w nim ponad 300 osób w ramach firmy jednego dostawcy. Wielu z pracowników to wysokiej klasy specjaliści, doświadczeni praktycy. Dostęp do klienta nie był możliwy, aczkolwiek analitycy kontraktowi mogli zadawać pytania dotyczące specyfikacji. Niestety, komunikacja była bardzo wolna – każde pytanie i odpowiedź to około 10 dni. Na podstawie analizy projektu stwierdzono, że część (szczególnie badawcza) można było wyodrębnić  i uruchomić jako zwinny projekt, ale podstawowa część projektu musiała być prowadzona w sposób klasyczny.

Podsumowując, istnieje dobre narzędzie wspierające podejmowanie decyzji o wyborze stylu zarządzania projektami, ale nigdy nie powinno zastępować „zdrowego rozsądku” a czasami intuicji osoby decyzyjnej.