Blog: Zwinne zarzadzanie | Agile

Rewolucja Agile wzbogaca tradycyjne metody zarządzania projektami

Rewolucja Agile wzbogaca tradycyjne metody zarządzania projektami
  • 1 749 views

Model kaskadowy i Agile w praktycznym zarządzaniu projektem.

Udostępnij!

Wraz z ruchem Scrum, wywodzącym się z Agile i będącym najpopularniejszą implementacją filozofii Agile, idzie rewolucja nazwana Agile. Scrum to implementacja Agile, ale rozprzestrzenia się w odmienny sposób – mówi o niej management i wyższe kierownictwo firm. Często powołuje się na doświadczenia automotive i nawołuje do zmian globalnych w zarządzaniu projektami.

Decydenci myślący o Agile i nawet próbujący to podejście wdrożyć, często odkrywają, że mają u siebie gdzieś, na najniższych szczeblach realizacyjnych, dobrze mającego się Scruma.

Rewolucja, moda, trend, mainstream

Czy Agile (w tym Scrum) ma na tyle sił, argumentów, powodów, aby wyprzeć stare, sprawdzone podejście? Aby odpowiedzieć na tak poważne, futurologiczne pytanie należałoby odpowiedzieć prowokacyjnie pytaniem – a niby po co podejście Agile miałoby wyprzeć podejście tradycyjne (najczęściej kaskadowe)? W czym Agile jest lepsze od PMBOK® Guide czy PRINCE2®, czy jest panaceum na wszelkie ich słabostki? Które elementy Agile są uniwersalne i bezwzględnie lepsze od tych tradycyjnych?

Po pierwsze:

Agile zmienia paradygmat planowania – zastępuje przekonanie o konieczności zaplanowania przedsięwzięcia na starcie postulatem planowania iteracyjnego. Przyszłość jest nieznana, im dalszy horyzont czasowy, tym mniej celowe jest jego dokładne planowanie, zastępowane przez wizję rozwiązania i biznesu po zmianie.

Ale:
Faktem niezaprzeczalnym jest istnienie takich sytuacji, w których projekt będzie musiał zostać zaplanowany szczegółowo na starcie, z powodu np. wielu krytycznych powiązań z innymi inicjatywami, kiedy integracja będzie wymagała w pełni funkcjonalnych produktów z każdego projektu.

Po drugie:

Rozwiązanie/produkt konstruowany jest empirycznie, nic doskonałego nie powstaje za pierwszym podejściem, zasada EDUF (Enough Design Up Front), im później coś zaprojektujemy, tym lepiej.

Ale:

W dającej się przewidzieć przyszłości nie zanikną sytuacje, w których produkt końcowy projektu będzie mógł być opisany i zaprojektowany od początku, szczegółowo, wystarczająco dokładnie, aby oprzeć na tym plan projektu z harmonogramem i budżetem (np. dzięki CAD). Ba, nie znikną sytuacje, w których taki produkt będzie musiał zostać opisany przed rozpoczęciem projektu, choćby ze względów prawnych czy braku zaufania
między stronami kontraktu.

Po trzecie:

Ścisła współpraca Klienta/Zamawiającego z Dostawcą realizowana między innymi poprzez role Product Ownera czy Wizjonera Biznesu.

Ale:

Nietrudno znaleźć przykłady firm zamawiających rozwiązania oparte na unikalnym know-how Dostawcy, a Zamawiający jest raczej biernym odbiorcą całości rozwiązania biznesowego.

Po czwarte:

Przejrzystość procesu wytwórczego w obu kierunkach na linii Klient – Dostawca.

Ale:

Jest wiele powodów obiektywnych (nie mówiąc o subiektywnych), dla których jedna ze stron kontraktu nie chce lub nie może ujawniać szczegółów dotyczących współpracy, nawet jeśli miałoby to zaszkodzić (opóźnić lub zwiększyć koszt) przedsięwzięciu.

Po piąte:

Zespoły wytwórcze – stabilne, nie za duże, nie za małe, skoncentrowane na jednym temacie (projekcie), dedykowane.

Ale:

To często obiektywnie nie opłaca się Dostawcy, dla którego elastyczność zasobów ma większą wartość niż efekty pojedynczego kontraktu, nawet nazwanego Agile. Odpowiednie wyskalowanie agile’owych zespołów wytwórczych dla niektórych technologii może być nieopłacalne. Utrzymywanie
takich wielofunkcyjnych zespołów dla jednego projektu/kontraktu musi się opłacać. Z drugiej strony często Klienci/Zamawiający nie są w stanie nakarmić ich odpowiednim wolumenem szczegółowych wymagań na dłuższy ciąg sprintów/timeboxów.

Losy obu podejść będą realizowały się na naszych oczach i już teraz widać, że o ile wyparcie metod tradycyjnych nie nastąpi szybko, jeśli w ogóle, to rewolucji Agile udało się tchnąć nową energię i wzbogacić tradycyjne podejście o nowe elementy. Spotkania na stojąco, krótkie interwały między przeglądami postępów, Historyjki Użytkownika – to się już dzieje w wielu projektach dalekich od nazywania siebie „agile”. Także tradycyjne metodyki ocknęły się w nowej rzeczywistości. Aż miło posłuchać i przeczytać w publikacjach Axelos, że PRINCE2® od zawsze był w pewnym sensie „agile” i nigdy nie wykluczał takiego sposobu realizacji projektów, a PMI pisze, że PMBOK® Guide w samej swojej konstrukcji formalnej jest otwarty na realizowanie wielu podejść – nie tylko kaskadowego.

Autor Witold Janicki – trener Altkom Akademii.

Artykuł pochodzi z 14 numeru kwartalnika „Strefa PMI”.