Zwinnie czy klasycznie? Kiedy warto przejść na Agile

Czym różni się Zwinne Zarządzanie Projektem (Agile) od klasycznego? Które podejście sprawdzi się lepiej i w jakiej sytuacji? Czy Scrum to jedyna metodyka zwinna? Na co uważać, jeśli zdecydujemy się na wdrożenie Agile? Kto zdecydowanie nie powinien przechodzić na zwinne zarządzanie projektem?

Klasyczny projekt zawsze miał kaskadowe etapy, najpierw początkowe fazy z precyzowaniem zakresu, potem szczegółowe planowanie a realizacja następowała po dogłębnym przemyśleniu wszystkiego co miało się wydarzyć do końca. Zwinne podejście do zarządzania projektami to kompletnie inna bajka.

Agile powstało w tej części IT, która zajmuje się tworzeniem oprogramowania. To istotna informacja, bo Agile jest najlepiej dopasowany do środowiska software development. To oznacza, że  adaptacje metodyk z tej rodziny w inne obszary zwiększają ryzyko niepowodzenia.

Scrum nie jest jedyna metodyką Agile. Oto kilka innych nazw rozwiązań będących w rodzinie Agile: Lean software development, Agile Unified Process (AUP), Feature Driven Development (FDD), Test-driven development (TDD), DSDM Atern.

Scrum jest najpopularniejszym przedstawicielem Agile. Sama nazwa Scrum zaczerpnięta jest z figury w grze Rugby gdzie cały zespół współpracuje razem. Zespół, samozarządzający się, niehierarchiczny - jest osią zwinności.

Pierwszy ( z czterech punktów Manifestu Agile mówi, że ważniejsi są: Ludzie i ich wzajemne interakcje (współdziałanie) ponad procedury i narzędzia.

Kiedy ludzie po stronie klienta potrzebujący rozwiązania IT mają wytłumaczyć czego chcą, to okazuje się to w praktyce bardzo trudne. Prostsze jest to w budownictwie. Architekt po rozmowie z klientem pokazuje projekt budynku. Błędem okazuje się mnożenie procedur i narzędzi w tym trudnym dla IT obszarze. Rozwiązaniem Agile jest powrót do prostoty: ludzie i potrzebna im komunikacja. Jedna z zasad Agile brzmi: "Prostota - sztuka maksymalizowania pracy nie wykonanej jest konieczna". Podobnie zasada pracy w jednym pomieszczeniu całego zespołu dramatycznie usprawnia komunikację i powoduje, że wiele wcześniejszych procedur i narzędzi staje się zbędnych.

Realizacja postulatów Agile to rewolucja dla specjalistów siedzących dotąd osobno w swoich funkcjonalnych działach. Jeśli jest  to firma IT, to osobno siedzą tam programiści, osobno graficy, testerzy , analitycy i tak dalej. Zwinne podejście wymusza powstanie multidyscyplinarnych zespołów siedzących i pracujących ciągle razem w jednym pomieszczeniu.

Dzięki temu, że teraz różni specjaliści tworzący zespół siedzą w jednym pokoju, to co załatwiano wcześniej e-mailami czekając całymi dniami na odpowiedz, obecnie jest konsultowane natychmiast z kimś, kto siedzi obok. Zmniejsza się ilość dokumentacji, zwłaszcza jeśli spora część z niej tworzona jest tylko po to by później ewentualnie uchronić się od odpowiedzialności w przypadku sporu. Zamawiający i wykonawca umawiając się na Agile decydują się na współpracę i współzależność. Bliska i szybka komunikacja przejmuje większą część tego, co dawały wcześniej procedury, odchudzając jednocześnie dokumentację.

Agile skupia ludzi na dostarczaniu oczekiwanego przez klienta rezultatu. Dlatego redukuje się dokumentację do koniecznego minimum. Zmieniona coachingiem mentalność samozarządzających się zespołów nie potrzebuje aż tylu procedur. Programiści to inteligentni ludzie, nie lubiący pracować pod presją project managera z "marchewką i batem kijem". Dlatego w zwinnym zarządzaniu projektami nie ma project managera - jest samozarządzający się zespół oraz wspierający ich coach (w Scrum nazywa się go Scrum Masterem).

Działające oprogramowanie nad wyczerpującą dokumentację (Agile Manifesto p.2)

Ponieważ ludziom jest trudno stworzyć spójne wymagania dla rozległych i skomplikowanych systemów IT, lepiej  poświęcać czas na tworzenie kolejnych odsłon oprogramowania, które podlegają ocenie niż samej dokumentacji wymagań. Sprawdza się to przy tworzeniu oprogramowania. Co jednak robić w obszarach, gdzie stworzenie wymagań nie jest takie trudne? Trudność tworzenia wymagań jest jednym z kluczowych elementów wskazujących czy warto wdrożyć Agile czy jednak trzymać się tradycji.

Współpraca z klientem nad negocjację umów (Agile Manifesto p.3)

Tylko 10% Polaków deklaruje zaufanie do obcych ludzi, w Szwecji jest to 70%. Zwinne podejście zakłada zaufanie zleceniodawcy wobec zleceniobiorcy w odróżnieniu od gier negocjacyjnych, jakimi zazwyczaj są poprzedzone kontrakty klasyczne z określonym zakresem, ceną i terminem. W Agile zakres projektu pozostawia się niedoprecyzowany, budżet zależny jest od wielkości zespołu i ilości czasu. Można termin i budżet założyć na początku, bywa on jednak zmieniany. Słyszałem o przypadkach gdy klient zatrzymywał dalszy rozwój produktu ponieważ przyrostowy charakter pracy dał wcześniej wynik, który go zadowolił.

Zmiany zakresu mają jednak swoją granicę. W Scrum występują stałe przebiegi pracy (Sprinty), w których zakres jest zamrażany. Po zakończeniu Sprintu i pokazaniu rezultatów pracy ustalane są nowe priorytety z ciągle uzupełnianej listy określającej zakres. Sprinty trwają zawsze tyle samo dla jednego projektu - zwykle od tygodnia do czterech. Kolejne Sprinty nadają rytmikę pracy zespołowi.

Reagowanie na zmiany nad realizowaniem planu (Agile Manifesto p.4)

Świętością klasycznego PM jest precyzyjne określenie na samym początku co ma być zrobione. A każde odejście od pierwotnego zamysłu zakłóca projekt i jest traktowane jako coś złego. W Scrumie do określania zakresu używa się historyjek użytkowników (ang. User Stories). Na początku projektu Product Owner priorytetyzuje listę wymagań utworzoną z historyjek. Zespół określa ile z nich zrobi w kolejnym Sprincie. Lista jest ciągle uzupełniana i zmieniana, zmiany są traktowane jako normalna rzeczywistość. Przed chaosem zmian chroni zamrażanie listy wymagań dla danego Sprintu - przez ten okres nic się nie zmienia. Zmieniać mogą się plany na następny Sprint - aż zostaną zamrożone na jego początku.

Agile wykluczone

Są jednak obszary, w których na pewno, nigdy Agile nie wkroczy. Przykładowo zbudowanie nowej rafinerii wymaga najpierw dogłębnego zaprojektowania a dopiero później budowy (tzw. Front-End Project Management). Odpowiedź na pytanie "dlaczego?" jest prosta. Gdy przeprowadzamy szkolenie ze Scrum, ćwiczymy tę metodę zlecając zespołom zbudowanie czegoś ze zwykłych klocków. Jeśli ma nastąpić zmiana - szybko można klocki przebudować. Spróbujmy jednak przenieść prawdziwe jezioro lub olbrzymią instalację chemiczną a potem jeszcze raz ją przenieść w inne miejsce - bo klient zmienił zdanie. Nie znajdziemy klientów gotowych na ponoszenie tego typu kosztów nieprzewidywania przyszłości. To musi być zaplanowane od razu, dobrze już za pierwszym razem. Można za to próbować tworzyć w sposób zwinny dokumentację dla rafinerii. Jeśli porównamy tworzenie software do budowy rafinerii to zobaczymy, że software to odpowiednik inżynieryjnego projektowania. Budowa - to coś, co w IT wykonywane jest automatycznie i nazywa się kompilacją kodu. Dlatego w budownictwie trudno by Agile się przyjęło. Chyba, że jest to budownictwo z klocków.

Wdrażanie Agile

Nie jest tajemnicą, że wdrażanie Agile nastręcza problemów nawet w IT. Project Managerowie, którzy zainwestowali wiele w nauczenie się klasycznego PM protestują jako pierwsi. Nie wszystkim jest łatwo przyjąć zupełnie nową rolę - jeśli mają zostać "kimś w rodzaju" Scrum Mastera.

Inną kluczową osobą w Scrum jest Product Owner - reprezentant klienta będący blisko zespołu, gotowy by szybko odpowiadać na pojawiające się pytania "czego właściwie chce klient". To zdecydowanie przyspiesza pracę w zespole. Product Owner nie ingeruje w to jak zespół chce zrealizować cele, upewnia się tylko, że dobrze rozumiane jest to czego pragnie klient. Co zrobić jednak gdy nie ma chętnych do nowych ról?

Wdrożenie Agile zmienia dość sporo przyzwyczajeń, dlatego początkowo w Polsce odnotowano szereg nieudanych wdrożeń. Nie spodziewano się, że jest konieczna aż tak duża determinacja do tego aby przeprowadzić wszystkie zmiany. Zatrzymywano się w pół drogi. Wdrożenie pół-Agile okazywało się mniej efektywne niż pełna klasyka zarządzania projektem. Nie wystarczyło oddelegowanie ludzi na szkolenia. Potrzebne były zmiany organizacyjne, a przede wszystkim, ilość wiele godzin coachingu, by zmienić mentalność pracowników. Pierwsze udane wdrożenia Scrum w Polsce miały miejsce dopiero 5-6 lat temu.

Ze swojej strony doradzam, aby przy wdrażaniu zwinności najpierw popróbować wdrażać na pilotażowym, niezbyt dużym projekcie. Chociaż rozbudowywanie struktur Agile jest możliwe, to jednak najlepiej sprawdza się w kilkuosobowym zespole.

3 punktowy test czy warto w danym obszarze przejść na zwinne zarządzanie projektami. Wystarczy, że na wszystkie ŁĄCZNIE pytania odpowiedź będzie brzmiała TAK.

1. Czy wprowadzanie zmian w tworzonym systemie/produkcie jest tanie?

2. Czy zbieranie wymagań do tworzonego rozwiązania jest trudne?

3. Czy wymagany zespół projektowy może być niewielki (kilkuosobowy)?

Michał Hałas - Trener GRUPY ODITK

Polecane artykuły:

• Wymagania w projektach zwinnych - działasz Agile czy tylko o tym mówisz
• AGILE - zwinny sposób na projekt nie tylko dla IT