Zwinność wodospadu, czyli agile mindset

Turkusowe zarządzanie, samoorganizujące się zespoły, zwinność organizacji. Znamy to, prawda? Te i inne hasła przewijają się przez szkolenia, konferencje, artykuły. W jednych rozpalają emocje, w innych budzą ostrożność myślenia krytycznego. Bo może to tylko jakaś kolejna moda?

A jednak coraz więcej branż szuka pomysłów na to, jak mimo sztywnej ramy zakresów projektów skorzystać z tego, co w agile dobre i skuteczne.

Zanim rozwinę temat, chcę coś "odszczekać". Około 10 lat temu napisałem artykuł, który dość sceptycznie traktował rosnące w siłę zwinne zarządzanie projektami. Nie dlatego, że się z tym podejściem nie zgadzałem. Dlatego, że w podpisanym w 2001 roku Manifeście Agile nie znalazłem niczego nowego, czego nie widziałbym w obowiązującym dotychczas klasycznym, kaskadowym podejściu do zarządzania projektami.

Mijający czas pokazał jednak, że zwinne zarządzanie rozwinęło własne, bardzo sprawne narzędzia, udowodniło swoją skuteczność w znanych statystykach Standish Group International, wzmocniło satysfakcję zespołów realizujących projekty. I wyszło szeroko poza ramy wytwarzania oprogramowania.

W tym artykule chcę pokazać, jak realizując projekt, który wymaga podejścia klasycznego, stworzyć hybrydę z narzędziami agile.

Kluczowa różnica

Zacznijmy od przypomnienia treści Manifestu:

Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywa się lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkłada się:

· ludzie i interakcje ponad procesy i narzędzia

· działające oprogramowanie ponad obszerną dokumentację

· współpracę z klientem ponad formalne ustalenia

· reagowanie na zmiany ponad podążanie za planem

Według Manifestu agile docenia się to, co wymieniono po prawej stronie, jednak bardziej ceni się to, co po lewej.

Praca w czystym podejściu agile wymaga spełnienia kilku warunków. Punktem wyjścia jest to, że sami użytkownicy, czy też zlecający, nie są w stanie rzetelnie dokonać dokładnego opisu produktu projektu. W związku z tym wszystkie strony godzą się na to, że dochodzące elementy zakresu nie będą traktowane jako zmiany, a wszystkie szczegóły będą ustalane tak późno, jak to jest tylko możliwe. Mówiąc krótko - wszyscy akceptują filozofię agile. Proste? To teraz spróbujmy w ten sposób wybudować fabrykę albo nową linię produkcyjną, gdzie braki w założeniach funkcjonalnych mogą na etapie budowy wygenerować konieczność przebudowy już postawionej konstrukcji albo zamówienia nowej maszyny o innej wydajności, wielkości czy spójności z innymi elementami systemu. Albo przekonajmy do zwinnego podejścia urzędników realizujących projekt w trybie zamówień publicznych.

Różnica między klasycznym modelem a zwinnym osadza się w innym podejściu do priorytetów tzw. "Złotego Trójkąta": ograniczeń czasu, zakresu, budżetu i wynikającej z nich jakości. W podejściu zwinnym najbardziej elastyczny jest zakres zdeterminowany silnie ograniczonym terminem i budżetem. W klasycznym ujęciu to zakres jest kluczowy (postawienie 90% stanu budynku nadal nie daje możliwości jego użytkowania), więc wszelkie odchylenia będą ostatecznie zawsze odbijać się na powiększającym się budżecie i opóźnieniach.

Tajemnica tkwi w ludziach

A jednak Manifest Agile dał wytyczne. I pewnie dlatego kiedyś tak krytycznie na niego spojrzałem, bo czułem, że da się to wykorzystać w metodykach klasycznych. Ba! Nawet odsądzana od czci i wiary za przerost formalizmu metodyka PRINCE2 może być całkiem zwinna. Tajemnica tkwi w ludziach.

Zatem, kiedy już Drogi Kierowniku Projektu bierzesz się za tworzenie Karty Projektu, Specyfikacji Wymagań, tworzenia zakresu poprzez Strukturę Podziału Prac, budowy Harmonogramu, Planu Jakości, Planu Zarządzania Ryzykiem itd., spójrz, co mówi do Ciebie Manifest Agile:

Ludzie i interakcje ponad procesy i narzędzia

Dbaj o zespół i relacje. Organizuj sprawne spotkania. Koncentruj się na rozwiązaniach. Jesteś przede wszystkim Liderem, a nie Kierownikiem. Okazuj zainteresowanie nie tylko postępem prac, ale i tym, co się dzieje z energią zespołu, czy budzą się wątpliwości, czy rozmawiacie o ryzykach.

Działające oprogramowanie ponad obszerną dokumentację

Wiem, że nie programujesz. Czytaj: "produkt, który spełnia funkcję oczekiwaną przez klienta/użytkownika". Ale nie oczekiwaną w dokumentacji. Klient ocenia sukces projektu nie po tym, czy dostał na końcu to, co chciał na początku. Ocenia po tym, czy dostał na końcu to, co chciał na końcu.

Współpracę z klientem ponad formalne ustalenia

Jak wyżej. I Ty i Klient/Użytkownik chcecie tego samego - dostarczone rozwiązanie ma satysfakcjonować i tych, którzy je tworzyli i tych, którzy będą go używać.

Reagowanie na zmiany ponad podążanie za planem

Jak to robić w sztywnym harmonogramie przy uciekającej ścieżce krytycznej? No to posłuchajmy, co rekomenduje SCRUM albo AgilePM:

· Podziel plan na etapy, wyznaczając Kamienie Milowe,

· Nie planuj 100% zakresu. Zostaw przestrzeń na to, co wpadnie jako pilne i ważne,

· Każdy etap podziel na RÓWNE Sprinty (1-4 tygodnie) tak, aby zawsze na koniec sprintu dało się zmierzyć wartość użytkową tego, co dowieziecie z zespołem,

· Rób regularne, codzienne przeglądy postępów prac w Sprincie. Podtrzymasz w ten sposób zaangażowanie. Zachęcam do używania prostej tablicy KANBAN (To do / Doing / Done).

Pamiętaj: To ludzie robią projekty.

Przemysław Lisek, Trener GRUPY ODITK