Agile wywodzi się ze środowiska IT, to jest niezaprzeczalny fakt. Praktyka pokazuje, że ta metodyka idealnie nadaje się do wytwarzania produktów w sposób przyrostowy (iteracyjny) i to nie tylko w branżach IT. W krótkim czasie dostarcza minimalną oczekiwaną przez biznes wartość (MVP), doskonale reaguje na częstotliwość zmian, jest metodyką transparentną; gdzie klient ma szybki wgląd do zaawansowania postępu prac. Wydaje się, że Agile może być lekarstwem na każdą bolączkę typowej metodyki waterfall, ale czy tak jest naprawdę i na co zwrócić uwagę przy próbach wdrażania Agile?
Przede wszystkim musimy zacząć od tego, że Agile Manifesto zwraca na wstępie uwagę na prosty fakt, a mianowicie Agile to tzw. „mindset”, czyli sposób myślenia i funkcjonowania członków zespołu. Wdrażając metodykę w zespole musimy zadbać o to by nasi współpracownicy wiedzieli z czym mają do czynienia. Nie możemy rozpocząć ewolucji od nagłej i nieprzemyślanej rewolucji. Warto przygotować zespół na zmiany przed ich wdrożeniem. Najprostszym sposobem są szkolenia z podstaw metodyki, gdzie dowiemy się przede wszystkim o poszczególnych rolach w zespole, ale też o sposobie organizacji projektu, planowaniu, przyrostach itp. Musimy pamiętać, że w naszych organizacjach prowadzenie projektu metodyką zwinną dotknie nie tylko sam zespół wytwórczy, ale również takie osoby (lub działy) jak:
- Sponsor projektu. To od tej osoby zależy budżet, który w przypadku Agile estymowany jest całkowicie odmiennie niż w „standardowym” podejściu oraz uzależniony jest nie tylko od składu osobowego zespołu, ale przede wszystkim od „prędkości” zespołu.
- Kierownik projektu. Wiadomo, osoba odpowiadająca za budżet, jakość, czas realizacji, ale też i za kontrakt.
Umowy Agile’owe powinny zawierać dodatkowe zapisy dedykowane dla projektów dostarczanych przyrostowo. Często taki kontrakt nie odzwierciedla tego co dzieje się w rzeczywistości podczas wykonywania projektu. Pamiętajmy, że zapisy w kontrakcie są naszym wejściem do fakturowania i sposobu rozliczania wydatków.
- Księgowość. Projekty Agile w przewadze są projektami tzw. „Time & Material”, rozliczanymi godzinowo. Nasze kochane Panie z tego działu muszą być świadome jak wystawiamy faktury, jak je wyliczamy, za jakie fazy (przyrosty) itp.
- Product Owner. Osoba najczęściej umiejscowiona po stronie Klienta. Doświadczenia pokazują, że ograniczona dostępność takiego zasobu powoduje utrudnienia w planowaniu rozwoju produktu, w definiowaniu kryteriów jakości, ale przede wszystkim w określeniu zakresu i dostarczeniu MVP. Nieświadomy zagrożeń Klient wystawia nasz projekt na ryzyko porażki.
- Dział wsparcia/serwisu. Planując rozwój produktu musimy również pomyśleć co się stanie, gdy zakończymy jego wytwarzanie. Zwykle nasz zespół zostaje rozwiązany, osoby przechodzą do innego projektu a wiedza razem z nimi. W projektach które trwają długo, część produktu może być przekazana do działu wsparcia w trakcie, natomiast wytwarzanie toczy się dalej równolegle.
Spotkamy się z opiniami, że Agile jest super, bo nie wymaga planowania, fazy projektowania czy też fazy zbierania wymagań. Szybko, tanio i przyjemnie, prawda? Nic bardziej mylnego. Źle zaplanowany Agile oraz niedoprecyzowane wymagania wydłużą nam czas wytwarzania, a to finalnie przełoży się na jakość i koszty. Od czego mamy w końcu tak często wykorzystywane sprinty zerowe?
Agile jest praco- i czasochłonny. Owszem zwłaszcza na początku, ale który projekt taki nie jest w początkowanych fazach? Bilansując koszty pracy jakie wkładamy na wstępie do korzyści jaką jest szybkie dostarczenie minimalnych funkcjonalności produktowych możemy zauważyć, że ROI projektu przyjdzie znacznie wcześniej niż w przypadku projektu waterfall. Agile na pewno wymaga większego zaangażowania zasobów zarówno po stronie dostawcy, ale też po stronie Klienta. Każdy PM marzy o zaangażowanym zespole, niezaprzeczalnie jest to korzyść, ale potrafi być również zagrożeniem, gdy mamy problemy z dostępnością kluczowych osób.
W Agile szybko reagujemy na zmianę. Owszem, ale nie oznacza to, że możemy w dowolnej chwili dorzucać nowe funkcjonalności do aktualnie trwającego sprintu. Każda zmiana zakresu musi być poddana szczegółowej analizie, przede wszystkim pod kątem pracy jaką należy włożyć by podana funkcjonalność mogła zostać wdrożona. Szybkie reagowanie na zmianę nie oznacza wprowadzanie chaosu i zamieszania, wymaga przemyśleń przede wszystkim przez członków zespołu wytwarzającego. Zarządzanie zakresem wymaga priorytetyzacji funkcjonalności. W brew zachcianek Klienta, nie wszystko musi być na wczoraj i nie wszystko jest najważniejsze, najważniejsze jest MVP i funkcje typu „must have” oraz jakość. Jedną z dewiz Agile jest „NIGDY nie odpuszczaj jakości”, aby tą dewizę wypełnić musimy planować w taki sposób by mieć czas na testy.
Narzędzia do zarządzania. Pracując przyrostowo musimy pamiętać o narzędziach do zarządzania zakresem (backlogiem), narzędziach do przydzielania zadań i monitorowania postępu. W przypadku małych projektów często wystarczy nam zwykła tablica z karteczkami tzw. kanban, ale gdy już mamy rozbudowany projekt oraz backlog na kilka tysięcy pozycji, musimy pomyśleć o zakupie odpowiedniego programu, który pomoże nam w organizacji całego projektu.
Agile jest modny. „Robimy tak, bo wszyscy tak teraz robią.” Wszyscy czyli kto? Konkurencja? Czy może firmy, które przygotowały się lepiej? A może takie w których metoda wytwarzania produktu jest całkowicie odmienna od naszej. Pamiętajmy, przygotujmy się, zróbmy analizę co nam da Agile, czy warto rewolucjonizować wszystko, czy może lepiej iteracyjnie wprowadzać zmiany w organizacji. Warto przeprowadzić analizę ryzyka potencjalnych zmian, ale też analizę dojrzałości projektowej naszej organizacji.
Czy Agile jest drogi? Nie, jest inny niż dotychczasowe podejście, ale nieumiejętne i nieświadome wdrażanie metodyki na silę lub poprzez bezmyślne podążanie za trendami i modą może nam przysporzyć nie lada kłopotów, a finalny efekt będzie odwrotny do zamierzonego.