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 odniesień 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 dalsza 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ę stworzyć kompletny Backlog Produktu?

Nie, albowiem wtedy już nie będzie to Backlog, tylko specyfikacja 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 tylko 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 wymaga, by w stałych i 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

Cytat z oferty pracy, który przytoczył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ś „kierownikiem 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 zapewnienie 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

Tak stosowany „Agile” jest w istocie 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 deklarowania, że to Agile, nie może już nazywać się po prostu kierownikiem 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 (pojawią się zdarzenia, ale będą to puste ceremonie konsumujące czas Developerów; wytwarzane będą artefakty, których do niczego realnie się nie użyje i tak dalej), ale 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 ceremoniach, ale pamiętajmy, że w prawdziwym Agile zdarzenia (nie ceremonie!) służą empirycznemu poszukiwaniu najlepszych rozwiązań technicznych i 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”, a potem bezmyślnie go realizować. 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 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 skutecznie 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ł.