Bardziej niż agile – projekty eksploracyjne w praktyce

Kilka tysięcy lat temu wyłoniło się podejście kaskadowe do realizacji nowatorskich przedsięwzięć. Około pięćdziesiąt lat temu został założony PMI. PMBOK® Guide po raz pierwszy ujrzał światło dzienne prawie trzydzieści lat wstecz. Dwadzieścia lat temu pojawił się agile z kilkunastoma metodykami zwinnymi, z których bezapelacyjnie wygrał Scrum. W międzyczasie gospodarka zaczęła galopować jak kobyła klepnięta w zad, skracając cykle życia produktów, podnosząc apetyt na ryzyko i wymuszając realizację narastającej liczby projektów. Czy nadszedł czas na nowe podejście? Tego nie wiem, ale jestem przekonany, że biznes chciałby robić projekty szybciej, taniej i lepiej trafiać w gusta klientów.

---

Tę lukę stara się wypełnić podejście, które ma wiele imion: eksploracyjne, R&D, eksperymentalne, ekstremalne. Na potrzeby niniejszego tekstu wybiorę nazwę eksploracyjne (exploratory), ponieważ ten termin stosowany jest w zbiorze praktyk Disciplined Agile Delivery.

Co wyróżnia projekty eksploracyjne

Po pierwsze olbrzymia niepewność. Jeżeli projekt to wtaczanie głazu na szczyt góry, a kierownik projektu ma na imię Syzyf, to w podejściu kaskadowym Syzyf, przed rozpoczęciem swojej mitręgi, zaplanowałby z góry całą trasę, wszystkie kroki i w prezentacji ogłosił bliską realizację celu, jakim jest wtoczenie kamienia na szczyt. W podejściu zwinnym Syzyf nie planowałby całej trasy od początku, tylko widząc szczyt w chmurach, przez pierwszy tydzień pchałby kamień w mniej więcej zadanym kierunku. Po tygodniu zastanowiłby się, jak pokonać kolejny odcinek i ruszył, i tak co tydzień raportowałby, jak wiele mu jeszcze brakuje. W podejściu eksploracyjnym natomiast nasz Syzyf wybrałby najbliższą górę. Zacząłby pod nią wtaczać swój głaz, jednak jak tylko by się zorientował po pierwszych krokach, że w okolicy znajduje się lepszy szczyt, to natychmiast porzuciłby kamień i rozpoczął wspinaczkę od nowa. W przypadku dwóch pierwszych podejść celem jest znalezienie się na szczycie. W przypadku trzeciego celem jest zdobycie wiedzy o wchodzeniu na różne góry oraz ustalenie, która z nich jest najbardziej atrakcyjna.

Czasem praktyki eksploracyjne pojawiają się również w projektach kaskadowych lub zwinnych, w których założono nierealnie krótki czas realizacji. Przykładem takich są hackathony, gdzie w dwa dni, pracując non stop, zespół stara się dostarczyć prototyp rozwiązania. 

Co działa

Przeprowadziłem ponad pięćdziesiąt rozmów z praktykami, którzy chcieli się podzielić swoimi „patentami” na eksplorację projektową. Tyle wywiadów to kilkaset stron notatek, dziesiątki linków i odesłań do książek, mnóstwo roboczych koncepcji, trudnych do replikowania. Poniżej przybliżam niektóre z wniosków, które wyłoniły się z tych rozmów.

Motywacja wewnętrzna

Wszyscy niemal moi rozmówcy zapytani o to, co ich i ich zespoły nakręca do pracy, wskazywali czynniki, które zakwalifikowałem do motywacji wewnętrznej. Jedna osoba wskazała, że w projektach tzw. hardware’owych, w których wytwarzane są prototypy nowych urządzeń, zewnętrzni konsultanci są zmotywowani, bo się im płaci za pracę. Jedna kierowniczka projektu z uczelni państwowej powiedziała, że początkowo naukowcy zmotywowani byli tym, że dostali dodatkowe zlecenie, ale z czasem tak się „wkręcili” w projekt, że pracowali dużo więcej niż wymagałby tego kontrakt, a cieszył ich po prostu postęp badań i osiągane rezultaty.

Projekty wysoko innowacyjne wymagają głębokiej, eksperckiej wiedzy. Tacy eksperci, aby stać się prawdziwymi fachowcami, muszą kochać swoją pracę. Nowy projekt to nowa piaskownica i nowe zabawki do psucia za cudze pieniądze, a to uzależnia.

Badania naukowe również potwierdzają, że wewnętrzna motywacja ma wpływ na poczucie osobistej skuteczności, a to z kolei wpływa na innowacyjność. Ludzie zmotywowani wewnętrznie czerpią większą satysfakcję z zadań innowacyjnych niż rutynowych, co może być dodatkowo wzmocnione przez zaangażowanego lidera.

Przywództwo mieszane

Podejście kaskadowe promuje dyrektywny typ przywództwa. Planowanie jeszcze może być partycypacyjne, ale późniejsza koordynacja i kontrola polegają na wydawaniu poleceń i sprawdzaniu ich wykonania zgodnie z planem. Oczywiście lider projektu kaskadowego może reprezentować styl zarządzania o niskiej inwazyjności, lecz nadal jego sercem jest “command & control”.

W podejściu zwinnym promuje się lidera oddającego decyzyjność zespołowi, tzw. servant leadership lub lidera wspierającego. Taki lider ma zachęcać ludzi do efektywnej pracy i skupiania się na właściwych zadaniach, ale ich nie rozlicza. Brzegowym założeniem jest, że zespół jest zmotywowany, ma kompetencje co do tego, jak osiągnąć cel oraz zaznajomiono go z wizją końca projektu.

W projektach eksploracyjnych okazuje się, że działa jeszcze inny styl przywództwa – nazwałem go mieszanym. Ale od początku, Scrum się świetnie sprawdza, gdy zespół ma zadany kierunek i wie dokąd podąża. Jeszcze lepiej, gdy dysponuje pełną wiedzą o tym, jak przebyć zadaną marszrutę. Wówczas wystarczy nie przeszkadzać, a zespół sam się zorganizuje. 

Natomiast w projektach eksploracyjnych regularnie pojawia się konieczność zmiany kierunku i to im gwałtowniejszej, tym lepiej, bo projekt nie będzie marnował czasu. Przykładowo, gdy okazuje się, że dotychczasowy pomysł na biznes startupu się nie sprzedaje, to nieefektywne jest organizowanie głosowania, co o tym sądzi cały zespół. Z reguły founder narzuca nową wizję, wyhamowuje zespół, a następnie ostro skręca na nowy kurs.

Zatem w takich projektach servant leader działa, gdy trzeba maksymalizować tempo płynięcia do zadanego celu, ale gdy trzeba zmienić cel, to pojawia się autokrata i chwyta za rumpel. A potem znowu powraca lider wspierający i zachęca zespół do samodoskonalenia.

Słabością takiego podejścia jest ta chwilowa utrata sprawczości przez zespół. Zespół może zniechęcić się, gdy zaangażował się w rejs do Indii, a lider po pół roku żeglugi uznaje, że fajniejsze będzie odkrycie Ameryki.

Kultura eksperymentowania

Jednym z najpoważniejszych hamulców innowacji jest brak poczucia bezpieczeństwa pracowników. Pokazuje to szereg badań. Gdy człowiek obawia się o swoją reputację, nie zgłosi niepopularnego pomysłu. Nie zada także pytania, tylko sam się będzie męczył z trudnym problemem. Nie poinformuje, że widzi zagrożenie, bo po co się narażać. Efekt? Tylko bezpieczne idee, przytakiwanie i milczenie.

Organizacje, które stawiają na innowacyjność prowokują ludzi do ujawniania swojej ignorancji i zadawania pytań. Pokazują, że proszenie o pomoc spotyka się z sympatyczną reakcją i… pomocą. Praktyką, która wielokrotnie powracała w rozmowach, było regularne spotykanie się w zespole i albo wyciąganie problemów na stół, albo omawianie, co dzieje się gdzie indziej.

Nieregularne sprinty lub ich brak

Scrum zakłada prowadzenie regularnych sprintów. Zespół uzgadnia długość etapu, a później się tego trzyma. Nie zaleca się zmiany ich długości między innymi dlatego, że na stałym rytmie opiera się raportowanie projektu scrumowego.

W projekcie eksploracyjnym rzadko napotykałem regularne sprinty. Zdarzały się projekty, w których jedna iteracja trwała półtorej godziny, a druga dwa tygodnie. W tak niepewnym środowisku nie miało sensu zakładać stałego rytmu dostaw.

A kiedy sprint trzeba zakończyć? Po pierwsze wtedy, gdy zdobędziemy nową wiedzę. Skoro eksperyment szybciej dostarczył negatywne rezultaty, to po co czekać z zakończeniem sprintu do umówionej daty? Od razu go kończymy i wyznaczamy nowy eksperyment. Jeżeli eksperyment trwa i wolniej zbieramy dane, to po prostu trzeba poczekać. Kończenie sprintu przed czasem nie ma sensu, bo nie dostarczy nowej wiedzy.

Drugie kryterium zakończenia sprintu to bloker lub – jak określił jeden z rozmówców – zwrotnica. Czasem w projekcie pojawia się konflikt, na przykład część A nie pasuje do B, albo klienci nie akceptują ceny, która gwarantowałaby rentowność. Wówczas trzeba zakończyć sprint i podjąć decyzję, w jaki sposób wyeliminować ten konflikt. Wszystko po to, aby jak najszybciej dostarczyć wiedzę i ewentualnie działające urządzenie, system bądź biznes. 

W badaniach naukowych pojawił się ostatnio nurt dzielący zarządzanie projektami na te sterowane czasem i te sterowane zdarzeniami. W projektach sterowanych czasem koncentracja jest przede wszystkim na zrealizowaniu celów, zadań w określonych odcinkach czasu. W podejściu kaskadowym są to etapy wynikające z harmonogramu, w podejściu zwinnym to regularne zdarzenia kończące sprinty lub wydania wersji produktu. Badania pokazują, że menedżerowie lubią to podejście, bo daje im poczucie kontroli. 

Jednak jak się okazuje, gdyby spytać naukowców i inżynierów, to nie jest to dla nich naturalny tryb pracy w projektach eksploracyjnych. W ich przypadku postęp projektu jest mierzony zdarzeniami, w których zespół uczy się lub eliminuje niepewność (ang. learning events). Takie zdarzenia mogą pojawiać się bardzo szybko po sobie, a może się okazać, że trzeba na nie czekać wyjątkowo długo. Jednak nie ma progresu, gdy nie zdobywa się nowej wiedzy w projekcie eksploracyjnym. Niestety taka filozofia pracy nie oferuje poczucia bezpieczeństwa tym, którzy odpowiadają za pieniądze.

Aktualnie temat napięć między menedżerami a innowatorami jest coraz intensywniej badany. Pierwsze rezultaty pokazują, że zbyt duże skupienie się na perspektywie czasowej powoduje, że wypuszczane są kulawe produkty i rozwiązania, i ignorowana jest nowa obiecująca wiedza.

Czas – czas – czas

Czas jest bezwzględnie największy priorytetem w projektach eksploracyjnych. O ile w projektach kaskadowych mówi się o macierzy kompromisów, która definiuje strategię realizacji projektu, to tutaj sprawa jest prosta – ma być szybko. Szybko chcemy wiedzieć, czy biznes się opłaci, szybko chcemy zdobyć wiedzę naukową, szybko chcemy sprawdzić, czy technologia da radę.

Masz dylemat zatrudnić więcej ludzi, czy poczekać? To wyobraź sobie utracony przychód z opóźnienia wydania nowego produktu. Policz, ile więcej będzie cię kosztowało powolne brnięcie w alejkę, z której będziesz i tak musiał zawrócić.

Dobrą metaforą jest wyobrażenie sobie przyszłości jako bardzo rozbudowanego drzewa decyzyjnego. Zaczynamy na poziomie ziemi i wspinamy się po kolejnych gałęziach. Niestety ponad 90% gałęzi kończy się ślepą uliczką. I wtedy trzeba się wycofać. Rolą projektu eksploracyjnego jest zidentyfikowanie, które gałęzie prowadzą nas na czubek tej sekwoi. 

Im szybciej potrafimy wycofać się ze ślepych zaułków drzewa wiedzy, tym szybciej wspinamy się na górę. Właśnie dlatego czas jest najważniejszym kryterium.

Drugim jest presja konkurencji. Chcemy dostarczyć innowacje przed konkurencją, aby zdobyć rynek. 

Najpierw mikroskala

W jednym z omawianym projektów konstruowano superkomputer. Kluczową regułą było to, aby w każdym kluczowym etapie planowano mikrorozwiązanie. Trzeba zrobić coś dużego, ryzykownego? W takim razie najpierw trzeba zrobić to samo w mikroskali. To pozornie dodaje pracy, jednak długofalowo zwraca się wielokrotnie. Duża część błędów i problemów technicznych może być szybko rozwiązana na mikroprototypie zanim pojawi się w finalnym rozwiązaniu.

Idąc dalej, można uznać, że jeśli nie da się stworzyć mikroskalowego rozwiązania, to samo w sobie jest to ryzykiem. Jeden z inwestorów przyjął zasadę, że odrzuca pomysły na biznes, jeżeli nie da się na nich przeprowadzić eksperymentu w skali mikro niezależnie od ich wstępnej atrakcyjności.

Czego brakuje

Na koniec warto jeszcze zwrócić uwagę, czego brakuje, co mnie zaskoczyło. Wydawałoby się, że taka pozornie prosta rzecz jak gromadzenie lessons learned i dzielenie się nimi między projektami powinna być powszechna. Nie jest.

Nawet w projektach eksploracyjnych rzadko zbiera się i dokumentuje nauczki poprojektowe. Temat zarządzania wiedzą dwadzieścia lat temu był gorący, były konferencje, targi, sporo dostawców narzędzi, teraz powraca co jakiś czas, ale już w formie pojedynczych przypadków lub anegdot. Generalnie, jak w domu starców, wszyscy by chcieli, ale nikt nie daje rady.

Dzielenie się doświadczeniami przeważnie funkcjonuje na poziomie wymiany niesformalizowanej wiedzy: rozmowy w kuchni lub na „fajce”, cotygodniowe retrospektywy, grupy zainteresowań, wspólnoty praktyków, przeglądy projektów, np. Obeya. 

Natomiast organizacje chciałyby, aby spisywać nauczki, bo dzięki temu można je później dystrybuować bez ograniczeń. Organizacje jednak nie radzą sobie z motywacją do dokumentowania nauczek i motywacją do korzystania z nich. Pojedyncze jaskółki dobrej zmiany ćwierkały o stosowaniu systemów do interaktywnej edycji, jak Notion, Nuclino, czy Labarchives. Inni dokumentują doświadczenia w arkuszu kalkulacyjnym lub Muralu. Jednak nie jest to ciągle wszechobecna praktyka nawet w projektach eksploracyjnych.

Lessons learned mają na ogół trzy formy. Po pierwsze mogą to być luźne notatki na różne tematy: terminowości dostawcy, link do artykułu, wnioski po wdrożeniu. Te notatki niekiedy mają zadaną strukturę, np.: cel, hipoteza, eksperyment, wnioski i bywają otagowane, co ułatwia wyszukiwanie. 

Druga forma to tabela zbierająca wiele wniosków z podobnych działań, na przykład eksperymentów. Poniżej zamieszczam przykład tabeli (Tab. 1.), którą wypełniał mój kolega w ramach prowadzonego eksperymentu na pewnym pomyśle biznesowym.

Trzecia forma to nieustrukturalizowany zapis dyskusji, na przykład w formie mindmapy lub karteczek rozrzuconych w Muralu albo Miro. Trudniejsza do przeszukiwania, ale wymaga mniej wysiłku przy dokumentowaniu.

Inny przykładem olbrzymiej luki, która wciąż pozostaje nie zapełniona jest motywacja. Jak to wcześniej podkreślałem, ciężko wymyśla się nowe rzeczy bez wewnętrznego zaangażowania. Jednak żadna z napotkanych firm nie stworzyła mechanizmu, który by w powtarzalny sposób potrafił zbudować motywację wewnętrzną u uczestników projektów. Są pewne praktyki, które pomagają, ale nie gwarantują sukcesu. Czymś, co w miarę powtarzalnie działa, jest rekrutować ludzi z taką motywacją, a później tego nie zepsuć. 

Zatem niektóre firmy skupiają się na rekrutacji dla motywacji. Ciekawym procesem, który wydaje się przynosić dobre rezultaty jest „negatywna rekrutacja”. Termin jest mój, ale pomysł podpatrzyłem w dwóch firmach technologicznych i jednej doradczej. Idea polega na zniechęcaniu kandydatów, stawiając im wysoką poprzeczkę kompetencyjną. Taki kandydat jest odrzucany, ale na tym nie kończy się proces. Trzy miesiące później rusza nowa fala rekrutacji i nasz kandydat na nowo może startować. Jeżeli spróbuje jeszcze raz, to znowu jest poddawany weryfikacji i ponownie może odpaść. W ten sposób eliminuje się tych, którzy nie mają dość samozaparcia. Wyobrażacie sobie jak bardzo musi być nakręcony człowiek, który przez rok został trzy razy odprawiony z wymarzonej firmy? Jak żul pod monopolowym w niedzielę. Gdy za czwartym razem w końcu dostanie upragnioną robotę, jest duża szansa, że będzie zmotywowany czymś więcej niż pieniędzmi, znaną marką i pierogowymi wtorkami. Taka strategia ma swoje ograniczenia. Jest kosztowna i długotrwała, bowiem pozyskanie jednego człowieka zajmuje wiele miesięcy i kilka podejść. W związku z tym nabór trzeba planować z wyprzedzeniem.

W mikroskali ja sam i niektórzy moi rozmówcy wskazywali, że czasem stosowali praktyki negatywnej rekrutacji, starając się zniechęcić kandydatów do pracy. W efekcie pozostawali ci, którym nie przeszkadzały trudności, bo nakręcało ich coś innego.

Podsumowanie

W sumie ten artykuł mógłbym zatytułować Coś innego. Podejście eksploracyjne przejawia się dzisiaj w luźnych praktykach, często nieświadomie powielanych w różnych organizacjach. Wyzwanie jest wspólne – zrobić coś szalenie ryzykownego i warunki brzegowe, jak motywacja wewnętrzna, szybkie uczenie się, odwaga w eksperymentowaniu, częsta zmiana kierunku marszu są zbliżone. W takim środowisku jest potencjał na zbudowanie nowej metodyki, a przynajmniej zbioru dobrych praktyk.

Mógłbym też zatytułować go Niechaj Kairos was zaskoczy. Starożytni Grecy mieli boga, który odpowiadał za zaskakujące i wyjątkowo fortunne lub przełomowe zdarzenia. Nazywał się Kairos. Kairos powinien być dzisiaj patronem innowatorów. Na podstawie tych wywiadów powstaje książka pod roboczym tytułem Bardziej niż agile, której premierę zaplanowałem na 2023 rok.