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 zbierają się 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 rozwiązywanie złożonych problemów (na przykład za pomocą 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 wprowadzimy je do Jiry lub innego narzędzia elektronicznego. Inne okażą się niekompletne, niewłaściwe lub 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, co teraz chcemy zrobić, do czego dziś dążymy.

Niekończąca się analiza

Stwierdzenie z oferty pracy, które zacytowałem na wstępie, zawiera informację, że poszukiwany Product Owner nie będzie miał roli analitycznej. Z jednej strony gotów jestem przyklasnąć, bo Product Owner nie jest analitykiem; istotą jego odpowiedzialności 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, jego rola będzie „analityczna”.

Domyślam się, że w ofercie chodzi o podkreślenie, że poszukiwany Product Owner nie ma być szeregowym analitykiem biznesowym lub systemowym tylko kimś, kto zarządzi wdrożeniem efektów analiz w życie. I to rodzi moje wątpliwości. Nie będę ukrywał, że nie rozumiem sensu istnienia „dedykowanych ról analitycznych” w Zespołach, bo dla mnie dokonywanie analiz to nie rola, ale czynność. Do jej wykonania niezbędne są specyficzne kompetencje, które posiadać powinni tak Developerzy, jak i Product Owner. Im bardziej umiejętność dokonywania analiz jest rozpowszechniona w Zespole, tym lepiej. Nie jest bowiem tak, że analiz dokonywać mogą tylko ściśle wyznaczone osoby ani że Product Owner jest jakimś „managerem analityków”, podobnie jak nie jest „superanalitykiem”.

Wracając do omawianej oferty pracy: skoro „wszelkie wymagania zostały już określone”, analitycy zapewne zakończyli swoją pracę, a jej efektem jest „kompletny Backlog”. Product Owner nie będzie więc nic analizował (stąd stwierdzenie o tym, że jego rola nie jest „analityczna”), tylko skupi się na realizacji zdefiniowanych wymagań z Developerami, wśród których zapewne nie będzie żadnego analityka (bo są niepotrzebni, skoro analizy zostały już ukończone). Prawda, że to logiczne? Nie, dla mnie absolutnie nie. To bzdura.

Warto rozumieć metody, których używamy

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 podejścia Agile nie może już nazywać się po prostu managerem projektu.

Piszę o tym, bo fasadowy Agile zupełnie nie ma sensu. Korzystanie z metod zwinnych w sposób, który doprowadza do powstania „kompletnego Backlogu Produktu”, najzwyczajniej się nie opłaca. Organizacja poniesie wszystkie koszty związane z użyciem metod zwinnych: zadba, by pojawiły się ceremoniały konsumujące czas Developerów, by wytwarzano artefakty, których do niczego realnie się nie używa i tak dalej. 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. Nie pojawi się natomiast podstawowa korzyść, wynikająca z pracy zwinnej, jaką jest lepsze radzenie sobie z niestabilną złożonością (czyli spadek ryzyka inwestycyjnego).

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 oczekuje się od nas, że po prostu je zrealizujemy? 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, po co sięgamy po Agile? A jeśli rzeczywiście takie podejście okaże się skuteczne, czyli jeśli nie zmagamy się z niestabilną złożonością, 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ą firmom przewagę nad konkurencją, o ile potrafią one z nich korzystać świadomie. Ta przewaga wynika przede wszystkim z umiejętności szybkiego reagowania na zmienność rynku i potrzeb interesariuszy (klientów, użytkowników itd.), ale też ze zdolności do wybierania tego, co faktycznie warto robić – a więc ograniczenia marnotrawstwa czasu, umiejętności ludzkich i zasobów na to, co zbędne. 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óremu wepchnie się do ręki „gotowy Backlog” z poleceniem, by go zrealizował.