Agile: Fake Agile w natarciu

Chaos to najczęstszy zarzut jaki słyszy się od krytyków Agile. Jak to możliwe, że coś, co z definicji ma pracę usprawnić i czynić każdy projekt przejrzystym, doprowadza do bałaganu? To zasługa tych, którzy nie wiedząc o zwinności dużo, ale chcą bardzo szybko ją wprowadzić, często motywowani chęcią marketingowego pogłosu.

Agile to Agile, po co drążyć temat

O tym jak wiele jest różnych teorii bycia zwinnym można się przekonać, wchodząc chociażby na YouTube, czy dowolną platformę do podcastów. Podcasty, szkolenia, poradniki i zwykłe komentarze „specjalistów” faktycznie wprowadzają chaos. Brak spójności w wypowiedziach sprawia, że firma, chcąc pracować zwinnie, zatrudnia certyfikowanego specjalistę (Agile Coacha, albo Agile Mastera), która/y ma poukładać wszystkie procesy.

Problem w tym, że układa je tak, jak nauczył się tego na szkoleniu lub przeczytał w podręczniku, a rzeczywistość jest bardziej złożona niż case’y w książkach. Mało kto sprawdza, czy taka osoba kiedykolwiek przeprowadziła projekt zwinnie od początku do końca, albo czy była w stanie wprowadzić do organizacji zwinność w szerszym kontekście. Problemem jest wówczas brak zrozumienia, że radykalizm i wymaganie spełnienia wszystkich punktów z podręcznika mają mało wspólnego ze zwinnością.

Coraz częstsze stają się również doniesienia o typowych oszustwach. Zasłaniając się byciem „Agile” zwyczajnie przeciąga się oddanie namacalnych produktów przez kolejne iteracje, tłumacząc, że tak działają metodyki zwinne. Oczywiście cała wcześniejsza otoczka wprawia w zachwyt, a w niekończących się ustaleniach zdaje się jedynie brakować koloru tuszu, jakim ma być wydrukowany protokół odbioru.

Fake Agile

Sprawa jest poważna i to nie tylko w Polsce. O Fake Agile mówi się na całym świecie coraz częściej i coraz ostrzej. Sjoerd Nijland – założyciel Serious Scrum – stworzył w zeszłym roku serię poczytnych fabularyzowanych artykułów o fikcyjnej firmie, która zatrudnia specjalistę, aby ten odpowiedział na pytanie: dlaczego mimo zmiany trybu pracy na Agile, zespół nie jest wydajny?

Poprzez rozmowy z pracownikami poszczególnych działów obnaża w tekstach fałszywą zwinność, która bardziej przypomina nieśmiertelny waterfall. Pani Prezes mówi o swoim zespole jako zdemotywowanym, niewystarczająco produktywnym i obiecującym zbyt wiele, dowodem na co jest czerwona od opóźnień mapa drogowa projektów.

„W projekcie prawdziwie Agilie’owym nie ma patologii polegającej na dostarczaniu ustalonego na długo przed rozpoczęciem projektu zakresu w modelu fixed time i fixed price.  Nie powinny się też pojawiać sformułowania typu „do 15 czerwca musicie to dowieźć”.  Decydujący w kwestii zakresu i terminu dostarczenia zawsze powinien być zespół, który najlepiej zna swoją prędkość i może zobowiązać się do dostarczenia wartości w określonej liczbie sprintów. A musi to zrobić wg priorytetów, które ustalają członkowie zespołu będący przedstawicielami Klienta. To wcale nie oznacza , że w projektach zwinnych, że nie ma deadline’u, słyszeliśmy to już kilka razy w tym roku.”

– mówi Jakub Skałbania, Chief Growth Officer w Netwise.

Przy współpracy z Netwise nigdy nie pojawiają się gwarancje bez pokrycia. Znamy możliwości i prędkość swoich zespołów, bo dobrze się znamy i zrobiliśmy razem wiele projektów. Czasami, gdy pojawia się priorytet, którego realizacja jest zaledwie małą składową dużego projektu, ale Klient potrzebuje go na już, możliwe jest szybkie dostarczenie tymczasowego rozwiązania. W takich przypadkach niezwykle ważne okazują się zwinność w działaniu i doświadczony product owner, który jest odpowiedzialny za danie Klientowi minimalnego wykonalnego produktu (MVP):

„Zawsze w takiej sytuacji jesteśmy z Klientami szczerzy i uświadamiamy, że owszem, możemy dostarczyć coś w danym sprincie tak, aby funkcja pojawiła się jak najszybciej, ale zaznaczamy, że dane rozwiązanie może wymagać przebudowania w późniejszym etapie (refaktoringu). Szybkie wdrożenie pozwala jednak Klientowi pracować na minimalnym produkcie, a zespołowi wprowadzać w życie feedback od Klienta. To też wcale nie oznacza, że Klient dostaje niedziałającą, albo ryzykownie wdrożoną funkcjonalność. Done is done i to jedna z naczelnych zasad dobrej zwinności.”

– tłumaczy Piotr Kerner, Solution Architect w Netwise.

Elastyczność trzeba zrozumieć

Niezależnie od regionu świata bolączki są te same. Niby szacuje się story pointy, ale i tak Klient chce wiedzieć ile to będzie roboczogodzin. Po co? Bo tak rozliczany jest budżet.

Gdy coś nie działa tak jak trzeba obwinia się inny dział, z którym zamiast współpracować, toczy się bój. A przecież o to właśnie chodzi w zwinności, aby odkrywać, że coś nie pracuje tak jak powinno i szybko to naprawiać. Gdy więc wdrożony proces nie przynosi zamierzonego efektu, warto usiąść z realnymi użytkownikami i zapytać „jak chcielibyście móc to robić”, a z członkami zespołu omówić co nie zadziałało i czego się nauczyliśmy. Rozdzielanie zespołów i tworzenie niezliczonej liczby grup roboczych jest zaprzeczeniem ducha Agile i nigdy nie przyniesie dobrego efektu. To właśnie zebranie razem osób odpowiedzialnych za architekturę, wymagania, testy oraz programistów daje gwarancję realizacji dobrego i kompletnego backlogu.

To co teraz?

Czy więc warto za wszelką cenę realizować punkty z podręcznika? Czy da się pracować zwinnie, ale jednocześnie nie zmuszać całego świata do swojej wizji? Da się. A przy okazji udaje się realizować duże projekty i poszerzać katalog zadowolonych Klientów, którzy chcą współpracować przez kolejne lata. Jak to robimy w Netwise? O tym w kolejnym artykule. A kto jeszcze nie czytał poprzedniego, znajdzie go pod linkiem.