Od kilku lat Scrum staje się standardem lub pożądanym podejściem wytwarzania oprogramowania. Początkowo „przywlekany” do firm i działów IT przez entuzjastów, apostołów Nowego, rozprzestrzeniał się oddolnie i spontanicznie. Był i jeszcze bywa kręgiem wtajemniczenia, zakonem elitarnym klubem formą „ucieczki do przodu” od tego, co stare, wielokrotnie skompromitowane.
Razem z ruchem Scrum, wywodzącym się z Agile i będącym najpopularniejszą (?) implementacją filozofii Agile, kroczy sama rewolucja nazwana Agile. Choć Scrum to przecież implementacja Agile, a jednak 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, nie tyko IT, 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 zalęgniętego i 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, fakt, często zawodzące, 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 wyłania się, 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 rolę 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 zwinnymi. 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.
Architekt rozwiązań w obszarze Zarządzanie Projektami i trener w Altkom Akademia. Posiada wieloletnie doświadczenie w zarządzaniu projektami w bankowości, ubezpieczeniach, telekomunikacji. Prowadził m. in. projekty migracji systemu bankowego, wdrożenia systemów zapewnienia jakości i metodyk projektowych, rozwoju systemu wspomagającego zarządzanie projektami. Jako trener realizuje szkolenia w obszarze Project Management: metodyka PRINCE2, PMI/PMBOK, AgilePM, Scrum, harmonogramowanie i kontrola realizacji projektów, zarządzanie ryzykiem w projektach, zarządzanie dostawcami, zarządzanie jakością, komunikacja w zespołach projektowych. W obszarze Inżynierii Oprogramowania prowadzi szkolenia z zarządzania wymaganiami i analizy wymagań. Jest twórcą autorskich szkoleń i programów szkoleniowych Altkom Akademia.