Blog

Otrzymałem jakiś czas temu zaproszenie do udziału w rekrutacji na stanowisko Product Ownera w jednej z zagranicznych firm, która ma oddział na terenie Polski. Ciekawie napisana oferta, sporo nawiązań do Agile, może mógłbym nawet komuś polecić kontakt z nadawcą wiadomości, gdyby nie jedno zdanie upchnięte gdzieś w środkowym akapicie, pozornie bez znaczenia.

„Nie jest to rola analityczna, gdyż wszelkie wymagania zostały już określone.”

Raz a dobrze

W świecie idealnym mądrzy ludzie o długich siwych brodach siadają na naradzie, gdzie mocą swych światłych umysłów i kosztem wielu dni wytężonej pracy spisują wszystkie wymagania, które należy zrealizować, aby wytworzyć wartościowy produkt. Wymagania te są starannie przemyślane, dobrze zdefiniowane i nie wymagają poszukiwania odpowiedzi na żadne pytania, nie jest konieczna analiza, wiadomo co trzeba zrobić i w jakiej kolejności…

(Tu łagodna muzyczka rozbrzmiewająca w tle urywa się i rozlega się nieprzyjemny zgrzyt, po którym zapada ponura cisza)

W obrazku jak powyżej zgadzają się tylko długie brody, o ile zaangażowani w proces ludzie nie będą mieli czasu lub ochoty się ogolić. Wszystkie pozostałe mrzonki wynikają z braku akceptacji lub zrozumienia tego, że tworzenie oprogramowania oznacza konieczność zmagania się z nieprzewidywalnością, złożonością i zmiennością zarówno produktu, jak i środowiska, w którym on powstaje.

Czy da się napisać kompletny backlog produktu?

Nie, albowiem wtedy już nie będzie to backlog, tylko specyfikacja tego produktu. Lub raczej lista życzeń, które być może w jakimś stopniu uda się spełnić, o ile będzie nas stać na podjęcie próby ich realizacji. Cechą wymagań jest bowiem ich zmienność; wiele z nich staje się nieaktualne w momencie, gdy jeszcze wstukujemy je do Jiry lub innego Rally. Inne okażą się niekompletne, jeszcze inne niepotrzebne, a niektórych po prostu będzie brakować.

Istotą podejścia zwinnego jest to, że nie próbujemy wszystkiego przewidzieć, ale wytyczamy cel, do którego dążymy poprzez serię eksperymentów. Rozwijamy produkt w krótkich iteracjach, dokonując kolejnych zmian jego cech lub funkcjonalności. Ten przyrostowy model rozwoju nakazuje nam w stałych, krótkich interwałach dokonać oceny, czy to, co zbudowaliśmy do tej pory, faktycznie pozwala nam osiągnąć cel, do którego zmierzamy.

A zdarza się nierzadko, że ten cel jest ruchomy, bo pojawiają się nowe możliwości, znikają natomiast te, na których wykorzystanie liczyliśmy wcześniej. W modelu inkrementalnym i iteracyjnym radzenie sobie z tym jest dużo prostsze, bo… (tutaj brzmią werble)… nie mamy napisanego raz a dobrze kompletnego „backlogu”. Zamiast tego mamy listę wymagań, która podlega ciągłym zmianom tak, by kolejność na tej liście odzwierciedlała to co już wiemy, to co teraz chcemy zrobić, to dokąd dzisiaj zmierzamy.

Niekończąca się analiza

W zdaniu zawartym w ofercie pracy, które zacytowałem na wstępie, jest informacja, że poszukiwany Product Owner nie będzie pełnił roli analitycznej. Z jednej strony gotów jestem przyklasnąć, bo Product Owner nie jest analitykiem; istotą tej roli jest decydowanie o tym, co warto w produkcie zrealizować, z czym można się wstrzymać, a co jest w ogóle niepotrzebne. Tyle, że podjęcie takiej decyzji wymaga umiejętności analitycznych, a zatem czy kandydat chce, czy nie, rola ta będzie „analityczna”.

Domyślam się wszakże, że w ofercie chodzi o podkreślenie, że ów Product Owner nie byłby analitykiem biznesowym lub systemowym. To też dobrze, bo nie do końca rozumiem potrzebę utrzymania takich „ról analitycznych”. Dokonywanie analiz to przede wszystkim kompetencja (niejedyna) developera oraz Product Ownera, im bardziej rozpowszechniona wśród tych osób, tym lepiej. Natomiast skoro „backlog” już jest kompletny i gotowy do realizacji, to… cóż, analitycy (nie daj Bóg, by zwać ich developerami), już skończyli swą pracę. I jej rezultatem jest rzeczony kompletny „backlog”. Więc poszukiwany Product Owner nie będzie nic analizował. Prawda, że to logiczne? Dla mnie absolutnie nie.

Warto rozumieć metody, których używamy

Korzystanie z metod zwinnych w sposób, który doprowadza do powstania kompletnego „backlogu” produktu, najzwyczajniej nie opłaca się. Taki „Agile” jest wciąż starym, kosmatym Waterfallem, opakowanym w nową nomenklaturę. Tak, jest tam Product Owner, ale właściwie wszystkie kluczowe decyzje już zapadły. Pewnie jest tam i Scrum Master, który „zarządza procesem” a w praktyce ludźmi i ich pracą, przy czym z racji korzystania z metod Agile nie może już nazywać się po prostu Project Managerem.

Piszę o tym, bo fasadowy Agile zupełnie nie ma sensu. Organizacja poniesie wszystkie koszty związane z wdrożeniem metod zwinnych, ponieważ zadba, by pojawiły się ceremoniały konsumujące czas developerów. W zamian nie uzyska nic wartościowego. Efektem będzie kumulacja wszystkich problemów związanych z metodami tradycyjnymi (długie czasy oczekiwania na produkt, unikanie zmian w projektach, utrzymywanie silosów kompetencyjnych, długi proces decyzyjny etc.) i wszystkich kosztów związanych z mechaniką pracy zwinnej.

Piszę powyżej o ceremoniałach, bo przecież w prawdziwym Agile służą one empirycznemu poszukiwaniu najlepszych rozwiązań technicznych, ale przede wszystkim biznesowych (tu powinienem postawić wiele wykrzykników). A po co eksperymentować, skoro mamy już kompletną listę wymagań i możemy po prostu zaplanować ich realizację? W tym podejściu nie ma za grosz potrzeby stosowania empiryzmu, więc po co tracić czas na zdarzenia, które ów empiryzm mają zapewnić? Jeśli naprawdę wierzymy, że da się spisać wszystkie wymagania, Agile jest nam zbędny.

Panuje przekonanie, że metody Agile pozwalają szybciej dostarczać rozwiązania potrzeb biznesowych. I to prawda, ale nie dlatego, że dzięki nim pracuje się więcej lub szybciej. Dzieje się tak dlatego, że metody zwinne pozwalają odkrywać najlepsze rozwiązania, skupiać się na robieniu rzeczy potrzebnych, usprawnianiu procesów, narzędzi, komunikacji i organizacji. Pozwalają też szybko reagować na zmianę potrzeb, bo nie zakładają, że najpierw trzeba zbudować kompletny „backlog”. Posługują się backlogiem (bez cudzysłowu), który cały czas żyje i zmienia się, by odzwierciedlać bieżące potrzeby.

Zrozumieć czym jest zwinność

Metody zwinne dają przewagę nad konkurencją firmom potrafiącym z nich korzystać świadomie. Organizacje, które tego się nauczą, mogą osiągnąć zwinność biznesową i błyskawicznie odpowiadać na potrzeby rynku, zmiany w prawie, pojawienie się nowych technologii etc.

Warto zrozumieć, jak to działa, i dlaczego działa, nim edyktem zarządu „wdroży się Agile” w organizacji. To pozwoli uniknąć takich transformacji do Agile, które kończą się poszukiwaniem kandydatów do roli „Product Ownera”, który otrzyma do ręki gotowy „backlog” i ma go jedynie zrealizować. Code Sprinters specjalizuje się w kształceniu osób, które zajmują się transformacją tradycyjnych organizacji do Agile, doradzamy też wielu z nich jak to zrobić, by nie ponieść kosztów bez uzyskania niczego w zamian. Skontaktuj się z nami, bo dowiedzieć się więcej.