agile

Agile to taki waterfall… tylko całkiem na odwrót.

Agile wywraca do góry nogami klasyczny trójkąt projektowy. Zakres, który w Watarfallu jest podstawą planowania w Agile’u stanowi pochodną czasu i budżetu. Brzmi absurdalnie dla tych, którzy zjedli zęby na harmonogramowaniu i budżetowaniu projektów w oparciu o zadany zakres. Czy to może mieć sens i ma prawo działać?

Jeśli jesteś wzrokowcem, to w ramach wprowadzenia możesz rzucić okiem na prezentację:

Tak wygląda relacja w Złotym Trójkącie zarządzania projektem w Agile i Waterfall.

Źródło: Materiały szkoleniowe SAFe Core 4.5. Rysunek własny na podstawie Scaled Agile Framework

W podejściu Waterfall do zarządzania projektami wychodzimy z założenia, że cele są jasne, uzasadnienie biznesowe przekonujące, a wymagania jesteśmy w stanie określić na tyle dokładnie, że możemy w oparciu o nie dość precyzyjnie oszacować zakres projektu i wynikające z niego: koszt i czas realizacji. Plan zbudowany na tej bazie, z początku jeszcze ogólny, z czasem uzupełniany i aktualizowany, powinien z założenia być dość stabilny i możliwy do kontrolowania. W tym podejściu ten plan staje się osią zarządzania projektami. Na początku przedsięwzięcia ponosimy duże nakłady na to, żeby opracować go możliwie najdokładniej, a następnie w trakcie realizacji skupiamy się na jego monitorowaniu i niwelowaniu odchyleń.

Jednym z powodów pojawienia się idei zwinnej realizacji projektów było to, że w większości środowisk wytwórczych klasyczne założenia nie mają uzasadnienia. Wymagania są często zbyt ogólne, aby na ich bazie budować plany, a nawet jeśli byłyby precyzyjne i kompletne, to i tak najczęściej w takich projektach harmonogramowanie i budżetowanie ma miejsce przed opracowaniem projektu rozwiązania, czyli na długo przed tym kiedy nasze wyobrażenie o zakresie prac jest wiarygodne.

Zwinne podejście mówi o tym, że w złożonych przedsięwzięciach rzetelne zdefiniowanie wymagań i oszacowanie zakresu jeszcze przed uruchomieniem projektu jest bardzo trudne, a czasem wręcz niemożliwe, na przykład wtedy kiedy sukces projektu uzależniony jest od subiektywnego odbioru jego użytkowników i nie jesteśmy w stanie zasymulować ich reakcji, a zamiast tego musimy obserwować reakcję rynku po wdrożeniu wersji produkcyjnej.

W takich przypadkach budowanie poważnych projektów na tak mało wiarygodnej bazie jest absurdalne, a powstałe plany nie będą przez interesariuszy wewnętrznych, ani zewnętrznych traktowane poważnie. Zamiast skupiać się zatem tak mocno na przewidywaniu zakresu prac, szacujemy swój budżet i ustanawiamy system pracy definiujący w jakich iteracjach i jakimi narzędziami będziemy tworzyć przyrosty produktu. Umawiamy się, że każdą iterację będziemy planować w oparciu o najistotniejsze na dany moment i najpilniejsze wymagania, a plany te nie będą zbytnio wybiegać w przyszłość, żebyśmy nie tracili czasu na wróżenie z fusów.

Zapraszamy na szkolenie

Szkolenie Leading SAFe®

Okiełznać koszt i czas realizacji zwinnych projektów

Jak to jest możliwe, że za ograniczenia projektowe możemy przyjąć czas i koszt realizacji, skoro do tej pory były one pochodnymi zakresu, który to z kolei w podejściu zwinnym definiowany jest iteracyjnie?

Zawsze miałem problem z zarządzaniem tymi parametrami w projektach zwinnych. Popularne frameworki agile’owe nie przekonywały mnie zbytnio do siebie, pozostawiając zbyt wiele pytań odnośnie, między innymi, tego, co się dzieje z wymaganiami przed uruchomieniem pierwszego sprintu oraz jak budżetować takie projekty przy planowaniu nie wybiegającym dalej niż na dwa, a rzadziej na trzy sprinty w przyszłość. Dopiero SAFe (Scaled Agile Framework) przekonał mnie do Agile’a. Głównie dzięki temu, że mówi o zwinności w różnych obszarach funkcyjnych i na wszystkich poziomach organizacji wychodząc daleko poza zespoły scrumowe. Dopiero skalowanie Agile’a pokazało mi jak mechanizmy, które próbuję wdrażać z mozołem w swojej pracy mogą być zrozumiałe w organizacji i funkcjonować w dużych przedsięwzięciach. SAFe proponuje dwa główne mechanizmy umożliwiające zastosowanie odwróconego trójkąta ograniczeń projektowych:

• Lean Budgeting, czyli “szczupłe” (a dla uproszczenia możemy je nazywać: zwinne) budżetowanie
• Kadencyjność, czyli rytmiczność i miarowość rytmu prac

Lean Budgeting, to sposób budżetowania na poziomie zarządzania portfelami projektów, który przedziela fundusze nie na poszczególne inicjatywy (projekty, programy, portfele) tylko na strumienie wartości, zmieniając w pewnym sensie koszty zmienne na stałe.

Kadencyjność, to nadawanie cyklom wytwórczym stałego rytmu, zarówno na poziomie programów, jak i zespołów. Na poziomie zespołów Agile’owych realizujemy dwutygodniowe lub trzytygodniowe (rzadziej czterotygodniowe) Sprinty, które tworzą cykle w ramach których planujemy prace, realizujemy je stale monitorując, a na koniec każdego z nich podsumowujemy przedstawiając interesariuszom efekty i omawiając rezultaty oraz przebieg danej Iteracji. Te iteracje zrównoleglamy dla wszystkich zespołów współpracujących w ramach jednego programu. Agregujemy tworząc Przyrosty Programu (Program Increment, PI), czyli iteracje na poziomie programu w których skład wchodzi po parę  Sprintów (najczęściej cztery do sześciu). Rytuały sprintowe skalowane są na poziomie programu, tak że skoro na początku każdego Sprintu mamy jego planowanie, to na początku każdego Program Increment mamy planowanie PI’a i tak analogicznie postępujemy z pozostałymi procesami: scrum scrum’ów, demo dem, retro retr. Dzięki takiemu sposobowi skalowania Agile z jednej strony zachowujemy zwinność zespołów na poziomie Sprintów, a jednocześnie budujemy większe plany wybiegające nieco bardziej w przyszłość (mniej więcej na kwartał) nadające wspólny kierunek współpracującym ze sobą zespołom.

Przykład funkcjonowania zwinnego budżetowania i kadencyjności

Firma produkująca oprogramowanie biurowe posiada suitę rozwiązań: MyOffice, jest to pakiet składający się z aplikacji MyPresenter, MySheet i MyWriter; każda z tych aplikacji, mimo iż integrują się na jednej platformie, stanowi osobny strumień wartości zarządzany przez osobne jednostki biznesowe i sprzedawane częściowo wspólnymi, a częściowo osobnymi kanałami. Firma posiada zatem cztery strumienie wartości, którym w danym roku przydziela następujące budżety, odpowiadające priorytetem biznesowym i szacunkowym nakładom pracy:

• platforma integracyjna MyOffice – 5 milionów PLN
• aplikacja MyPresenter – 40 milionów  PLN
• aplikacja MySheet – 30 milionów PLN
• aplikacja MyWriter – 20 milionów  PLN

Każdy z tych strumieni zarządza rozwojem swojego produktu. W ramach rozwoju dostarczona zostanie część komponentów współdzielonych w ramach jednej platformy, ale reszta budżetów zostanie wykorzystana na wdrożenie pomysłów zgrupowanych w długie backlogi wymagań, po jednym na każdą linię produktową. W żadnym ze strumieni wartości nie starczy budżetu na przetworzenie wszystkich pozycji backlogu w działające funkcjonalności, bo ilość pomysłów na usprawnienia jest ogromna ilość, dlatego backlogi są na bieżąco hierarchizowane, a w ramach poszczególnych Przyrostów Programów (Program Increment, PI) wybierane są każdorazowo najpotrzebniejsze z ich elementów, w liczbie możliwej do przerobienia przez zespoły deweloperskie w zadanym czasie. W momencie budżetowania strumieni wartości nie wiemy dokładnie na rozwój jakich funkcjonalności zostaną wydane te pieniądze w poszczególnych PI’ach, ale inne mechanizmy zadbają o to że będą to funkcjonalności najpotrzebniejsze dla danego produktu na daną chwilę, a jednocześnie spójne z wizją i roadmapą rozwoju zarówno poszczególnych produktów, jak i całej suity MyOffice.

W odwróconym trójkącie projektowym wiemy ile jesteśmy w stanie ponosić kosztów stałych związanych z dostarczaniem nowych rozwiązań, wiemy też w jakich cyklach będziemy planować i realizować prace, jedynym nieznanym parametrem pozostaje zakres rozwiązań jakie dostarczymy w poszczególnych iteracjach. Tą zmienną będzie sterowała wartość biznesowa wymagań czekających w kolejce do implementacji oraz oczekiwana przez nas jakość.

Mechanizm ten jest uzupełnieniem dla procesów sterowania zespołami opisanymi w Scrum Guide i jedną z korzyści ze skalowania Agile, do poziomu zarządzania całą organizacją. Usuwa on wiele ograniczeń i przeszkód na jakie często natrafiają zwinne projekty. Bez takiego kompleksowego podejścia Agile w organizacji może mieć wielkie problemy z rozwinięciem skrzydeł i może być traktowany, jako stricte technika deweloperska o swobodzie działania i zasięgu ograniczonej klasycznymi mechanizmami projektów Waterfallowych.

Wniosek:  siłą napędową naszych projektów i punktem uwagi staje się wartość biznesowa, a nie harmonogram, wymaga to jednak pracy z całą organizacją i nie tylko w obrębie zespołów projektowych i głównych interesariuszy.

Użyta grafika została zaprojektowana przez Freepik.