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.
Na każdym spotkaniu omawiane są kolejne dokumenty i prezentacje, aktualizowany jest plan komunikacji oraz uzupełniany jest plan wdrożenia. I to wszystko w ramach kolejnego frameworku, który ma w nazwie i Agile, i Enterprise. I co gorsza, niektóre mają też w nazwie „bezpieczny”, albo „skalowalny”.
Czasami zdaje się, że ważniejszy od rezultatu projektu jest news, że dana organizacja pracuje zwinnie. Nawet, jeśli jakiś komercyjny framework jest dokładnie zaprzeczeniem zwinności.
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.
Czasem trzeba się zastanowić, czy możliwość chwalenia się byciem Agile jest naprawdę warta tego, żeby wprowadzać do organizacji chaos. Często lepiej, żeby firmy robiły projekty w preskryptywnych metodykach, albo starym waterfall’u niż udawały, że są zwinne. Zresztą część metodyk zwinnych, tak zwanych „korporacyjnych”, albo „skalowalnych”, i tak wprowadza tak dużo obostrzeń i procedur, że firmy te de facto działają w modelu waterfall, tylko ze znacznie rozbudowanym procesem akceptacji. Czy to jest Agile? Nie. Czy się sprzedaje? I to jak!
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.