Agile is the worst approach to research projects — except for all the others that have been tried*

W czerwcu, w ramach programu NERW PW, udało mi się uczestniczyć w dwóch szkoleniach kończących się certyfikatami AgilePM i AgilePgM. Te intensywne dwa tygodnie były dobrym pretekstem by uporządkować sobie zasady pracy w metodyce Agile (DSDM). Uczestnicząc w szkoleniach i czytając materiały zadawałem sobie pytanie — co z tej metodyki nadaje się do prowadzenia projektów badawczych B+R w obszarze Data Science w środowisku akademickim? Poniżej krótko podsumowuje moje opinie i doświadczenia. Oczywiście zapraszam do polemiki!

—

Po co ci te szkolenia?

To pytanie często słyszę, gdy opowiadam o kolejnym szkoleniu, na które się zapisałem. Zacznijmy więc od motywacji. Po co takie certyfikaty osobie pracującej na uczelni, zaangażowanej głównie w projekty NCN i NCBR? Zespół MI2 ostatnio urósł do dwudziestu osób, które uczestniczą w realizacji ponad 5 projektów badawczych. Na tym etapie szybko okazuje się, że komunikacja każdy z każdym i samoorganizacja napotyka duże trudności. Intuicyjne i zdroworozsądkowe podejście do projektów jest ok, ale okazuje się, że w dużej grupie intuicje są bardzo różne. Potrzebujemy uporządkowania procesów, szkieletu, który da trochę stabilności. Oczywiście można te procesy powymyślać samemu, ale po co, skoro powstały już liczne rozwiązania ułatwiające prowadzenie projektów? Wybrałem się na szkolenie w nadziei, że pomoże mi uporządkować podejście do prowadzenia portfolio projektów badawczych z obszaru Data Science. Byłem ciekaw czy w metodyce AgilePM i AgilePgM znajdę jakieś ciekawe pomysły jak usprawnić pracę naszego zespołu. I jak było?

—

AgilePM vs AgilePgM

Szkolenia były z zakresu AgilePM i AgilePgM. Czym się różnią te dwa tematy?

AgilePM jest związany z prowadzeniem projektów. Omawiane są rytuały i techniki pozwalające prowadzić jeden projekt od fazy oceny wykonalności do fazy oceny korzyści z realizacji projektu. Mnie akurat to szkolenie podobało się bardziej. Zarówno, jeżeli chodzi o praktyki takie jak MoSCoW (więcej poniżej), określenie co jest zmienną a co jest stałą w Agile (o tym też więcej poniżej), praktykami poprawienia transparentności i komunikacji.

AgilePgM jest związany z prowadzeniem zbioru projektów (który jest nazywany programem). Poszczególne projekty w programie mogą być agile lub nie, ale kluczowe w zarządzaniu programem jest koordynacja prac pomiędzy poszczególnymi projektami.

Największe nadzieje miałem związane z AgilePgM ponieważ obecnie w zespole MI2 mamy portfolio równolegle toczących się, powiązanych ze sobą projektów. Projekty korzystają często ze wspólnych zasobów i ich synchronizacja jest nie lada wyzwaniem. Więc najbardziej liczyłem na wiedzę związaną z tym szkoleniem. Ale, być może za sprawą prowadzącego, dużo więcej ciekawych informacji znalazłem w szkoleniu i materiałach z AgilePM. Poniżej skupię się głównie na nim.

—

Nie wszystko Agile co się zmienia

O technikach zwinnych słyszy się ostatnio bardzo dużo. Słowo to jest często powtarzane jako synonim bardzo elastycznego prowadzenia projektów, a jeszcze częściej jako przeciwieństwo tradycyjnego/kaskadowego podejścia do planowania i prowadzenia projektu. Obok typowego ,,hype’’ związanego z wszystkim co nowe, można znaleźć ciekawe przykłady czynników sukcesu tego podejścia. Mnie np. bardzo podobało się to omówienie.
Z własnego doświadczenia z pracy z młodymi zespołami, zdarzyło się słyszeć określenie ,,jestem agile’’ jako wymówka by nie robić planowania, by przesuwać terminy, jeszcze bardziej przesuwać terminy, zmieniać cele w trakcie realizacji projektów, nie robić dokumentacji itp.

A tutaj okazuje się, że metodyka Agile wcale nie pozwala na żadną z tych rzeczy! To tylko wymówki! W rzeczywistości:

• planowanie w Agile jest bardzo ważne! Przy czym planuje się tylko to co jest niezbędne i tylko wtedy, gdy jest to potrzebne. Nie planuje się zbyt szczegółowo całego projektu, zaczyna się od ogólnego zarysu. Jednak, gdy przychodzi czas na daną aktywność to planuje się ją bardzo dokładnie i z naciskiem na to jak wygenerować nową wartość dodaną w każdej iteracji.
• Terminy to w agile rzecz święta i nienegocjowalna! To zresztą jedna z cech tej metodyki, która mi się najbardziej podoba w kontekście projektów B+R. Możesz ograniczyć funkcjonalność, możesz ciąć cechy, ale nie możesz przekroczyć terminu ani kosztu! Terminy to rzecz święta. W świecie akademickim, gdzie projekty są często rozliczane w konkretnych ramach czasowych (np. masz grant na 3 lata — masz go zrobić w 3 lata, bo będziesz rozliczany w 3. roku a nie później. Chcesz wysłać artykuł na konferencją XYZ? musisz mieć artykuł do określonego deadline. Możesz negocjować zakres artykułu, ale nie terminy)
• Dokumentacja… cóż, powiedzmy, że metodyka nie naciska na nią za bardzo przyjmując bardzo zdroworozsądkowe podejście: dokumentacje przygotuj tylko jeżeli wiesz kto ją przeczyta i po co będzie ją czytał oraz co będzie chciał się z niej dowiedzieć. Dokumentacja dla samej dokumentacji nie ma sensu.

Poniżej opisuję trzy rzeczy, które w Agile Przyjrzyjmy się tym punktom bliżej.

—

Terminy to rzecz święta!

Drugim pryncypium Agile/DSDM jest “Dostarczaj na czas”. To postawa, która bardzo pasuje do projektów, w których uczestniczę. Jeżeli mamy grant na 4 lata, który się kończy 30 września 2024 to wszystkie prace, faktury, rachunki, wyniki muszą się wydarzyć do tego czasu.

Oczywiście nie trzeba czytać książek o Agile by stwierdzić, że terminowość jest cenna. Ale tutaj chodzi o coś więcej. Jeżeli w trakcie realizacji projektu, okaże się, że trzeba szukać kompromisów, to ani czas, ani zasoby nie są negocjowalne. Negocjujmy zakres funkcjonalności.

Świetnie to podsumowuje poniższy rysunek (pochodzi z blogu quanta). W tradycyjnym podejściu stałą w projekcie są funkcjonalności. Projekt toczy się by je zrealizować. Jeżeli okaże się, że do ich realizacji potrzeba więcej czasu lub zasobów to szuka się ich po to by zrealizować zaplanowane funkcjonalności. Ale w podejściu Agile stałe są terminy i zasoby, ich nie negocjujemy. Gdy trzeba z czegoś rezygnować to rezygnuje się z funkcjonalności, oczywiście tych które są mniej istotne. Skąd wiadomo, które są mniej istotne? O tym kolejny punkt.

Z tej perspektywy granty badawcze są bardzo Agile. W grantach NCN lub NCBR kosztów praktycznie nie da się negocjować po uzyskaniu finansowania. Terminy czasem można negocjować, choć przy stałym budżecie to nie jest dobry pomysł.

—

Priorytetyzacja MoSCoW

Obsesja na punkcie terminów ma oczywistą konsekwencje — w określonym terminie nie wszystko uda się zrobić. A skoro tak to trzeba wiedzieć (najlepiej od początku) co musi być zrobione, a co można odpuścić.

Narzędziem do określania priorytetów, które bardzo mi się spodobało z uwagi na swoją prostotę, jest MoSCoW. Każda planowana funkcjonalność trafia do jednego z czterech koszyczków.

• Must have — funkcjonalności w tej grupie muszą być zrealizowane, bez ich realizacji sensowność projektu jest zagrożona. W przypadku projektów badawczych to są najbardziej fundamentalne hipotezy do weryfikacji.
• Should have — te funkcje nie są krytyczne, ale dobrze byłoby je zrealizować. Nawet jeżeli nie wszystkie to choć większość.
• Could have — dodatkowe funkcjonalności, które można mieć, bo przynoszą wartość, ale nie załapały się na kategorię Should have.
• Won’t have this time — funkcjonalności, które może brzmią fajnie, ale nie zmieszczą się w tym projekcie. Może kolejnym razem?

W sieci znaleźć można bardzo szczegółowe opisy tego podejścia, np. tutaj, tutaj i tutaj. Zaletą z priorytetyzacji jest to, że gdy osoba lub zespół dostaje dwa lub więcej zadań do wykonania, to nie skupia się na tym, które wygląda atrakcyjniej, ale na tym, które ma wyższy priorytet.

—

Kontrola przez transparentność

Ostatnim pryncypium Agile/DSDM jest “Demonstruj kontrolę”. I nie chodzi o menadżera, który pokazuje kto rządzi, ale o dbanie o to by cele i postępy prac były zrozumiałe i widoczne dla całego zespołu. Zrozumiałe cele pozwalają na skupienie się na potrzebnych zadaniach, a widoczne postępy podnoszą morale zespołu. Kontrola oznacza, że realizowane są właściwe zadania we właściwym tempie.

Zespołu IT mają masę narzędzi do wizualizacji postępów prac, od Trello, Basecamp, po Jira i podobne narzędzia. W przypadku MI2, póki co najlepiej sprawdza się GitHub projects. W podobny sposób można śledzić postępu prac nad bibliotekami oprogramowania jak i prace nad artykułami badawczymi.

—

Czy faktycznie jest tak słodko?

Powyżej przedstawiłem cechy metodyki Agile PM, które mi się najbardziej podobają. Ale są też trudności, które powodują, że projekty może być trudno zrealizować zgodnie z filozofią Agile. Bez względu na to czy mimo wszystko zdecydujemy się na tę metodykę, czy wyciągniemy z niej kilka praktycznych rozwiązań, warto mieć na uwadze potencjalne problemy.

Aby je omówić muszę dodać, że projekty B+R prowadzone na uczelni angażują zazwyczaj studentów/doktorantów i pracowników naukowo-dydaktycznych. Jedni i drudzy zazwyczaj nie są zaangażowani w projekt w 100% a jedynie w części etatu, czasem niewielkiej części. Studenci mają na głowie studia, doktoranci mają i studia, i projekt doktorski, publikowanie itp., pracownicy często uczestniczą w kilku projektach jednocześnie lub w dydaktyce. Uczelnie są też miejscem, w którym odbywa się kształcenie, więc dosyć naturalne jest, że wielu uczestników projektu dopiero uczy się nowych technologii.

Z powodu niepełnej dostępności trudno jest utrzymać tempo projektów Agile, które zakłada bardzo częstą aktualizacją informacji o postępach projektu, mających miejsce praktycznie codziennie podczas ,,codziennych zbiórek’’. Ale jak robić codzienne zbiórki, jeżeli każdy w zespole pracuje na fragment etatu? Synchronizacja fragmentów etatów jest wyzwaniem, którego podręcznik nie omawia.

Agile też jest podejściem obsesyjnie skupionym na komunikacji w zespole. Zakłada to zarówno duże zaangażowanie w komunikacje jak i znaczne umiejętności komunikacyjne w zespole. To jednak kolejne ryzyko. Nawet jeżeli każdy w zespole potrafi się jakoś komunikować, to sprawna komunikacja zazwyczaj wymaga sporo pracy, dojrzałości, zaangażowania i doświadczenia. Jeżeli każdy w zespole jest w 100% skupiony na projekcie to jest łatwiej, ale jeżeli jednocześnie pracuje się nad kilkoma projektami to już komunikacja pomiędzy nimi potrafi być nie lada wyzwaniem.

W naszym zespole bardzo dużo dała możliwość powrotu do biura. Cotygodniowe spotkania, comiesięczne spotkania, semestralne dłuższe wyjazdy integracyjne, bez tego byłoby bardzo trudno. Oczywiście slack, github, meet, teams, overleaf i podobne narzędzia wspierają komunikacje, ale znacznie efektywniej i przyjemniej jest porozmawiać twarzą w twarz.

—

Stosować czy nie stosować?

Nie ma co oczekiwać, że można wziąć generyczną metodykę prowadzenia projektów prosto z półki i magicznie rozwiąże ona problemy w prowadzeniu projektów B+R. Ale przyznam, że wiele elementów z filozofii i pryncypiów Agile świetnie pasuje do projektów B+R.

*) to parafraza słów Winstona Churchilla “democracy is the worst form of government — except for all the others that have been tried.” Więc może jednak ten Agile nie jest taki zły.

Literatura:

• Traditional project management vs Agile https://www.quanta.co.uk/blog/2015/09/traditional-project-management-vs-agile
• 8 pryncypiów AgilePM https://inprogress.pl/blog/8-pryncypiow-agilepm/
• O co chodzi z tym Agile? https://lepszymanager.pl/agile-o-co-chodzi/
• How I led 6 R&D groups through an agile transition https://techbeacon.com/app-dev-testing/how-i-led-6-rd-groups-through-agile-transition