Synchronizacja prac
Najczęściej powracającym rytuałem zespołów eksploracyjnych było różnie realizowanie synchronizowanie wysiłków. Spotkania jednak w przeciwieństwie do tego, co proponuje Scrum pod nazwą Daily Standup Meeting, niekoniecznie następują codziennie. W niektórych zespołach są co dwa tygodnie, w innych co tydzień, a czasem faktycznie raz dziennie. Spotkałem również zespoły, w których nie było stałej regularności spotkań.
Ta synchronizacja może odbywać się w postaci po prostu spotkań, na których zespół rozmawia o bieżących pracach. Jednak może to też być spotkanie asynchroniczne za pośrednictwem narzędzia do dyskusji takiego, jak Slack, czy Discord. Szczególnie, gdy, jak w przypadku hackathonów, występuje duża presja czasowa. Szkoda wówczas minut na spotykanie się i gadanie. Każdy członek zespołu, kiedy akurat ma chwilę wpisuje swój stan prac do wspólnego narzędzia i odczytuje zgłoszenia pozostałych członków.
Artykuł jest fragmentem książki Bardziej niż Agile będącej w trakcie druku: https://onepress.pl/ksiazki/bardziej-niz-agile-marcin-zmigrodzki,baragi.htm#format/d
Niekiedy spotkanie synchronizacyjne jest koordynowane przez lidera projektu, którym może być profesor kierujący komórką badawczą, założyciel startupu, dyrektor innowacji w korporacji, główny inżynier, czy wreszcie kierownik projektu. Ta osoba przechodzi wówczas przez zadania każdego człowieka i upewnia się, że projekt zmierza we właściwym kierunku i zespół nie ma do czynienia z punktem zwrotnym.
Czasem w spotkaniu synchronizacyjnym bierze również udział klient wewnętrzny lub zewnętrzny. Chodzi o to, aby miał świadomość jak niepewne jest rozwiązanie i jakie nowe ścieżki działania otwierają się po każdym eksperymencie. To znacząco buduje zaufanie między stronami.
Jeżeli zespół jest większy i podzielony na sekcje merytoryczne. To zdarza się, że w jeden dzień organizowane są wewnętrzne spotkania w ramach każdej sekcji, a potem jedno zbiorcze dla całego projektu. Może na nim być obecny cały zespół lub tylko przedstawiciele sekcji.
Podnoszenie problemów na forum
“Jak mam chwilę wolną, to dzwonię do kolegi z projektu i pytam, co tam dzisiaj zrobiłeś, pokaż to. Albo piszę do kolegów – Hej, potrzebuję pomocy przy takiej funkcji”. I zaczynamy dyskusję na ten temat.” – stwierdził Adam Wojciechowski z Poznan Supercomputing and Networking Center. I ten cytat moim zdaniem dobrze oddaje naturę dzielenia się wiedzą. Nie ma wielkich narzędzi, ceremoniałów, czasem pojawiają się formalne retrospektywy. Natomiast najważniejsze są postawy członków zespołu nastawione na ciekawość, co robią pozostali, otwartość dzielenia się swoimi pracami i pewność uzyskania pomocy od kolegów.
Rola mentora
Niekiedy spotykanym pomysłem jest rola mentora. Jeden z członków zespołu lub jego lider, dysponujący odpowiednio rozległą wiedzą, może regularnie przyglądać się problemom, z jakimi zmagają się ludzie. W trakcie hackathonów to wygląda tak, że mentorzy wędrują między zespołami i aktywnie, podkreślam aktywnie, podpytują, co zespoły robią i na czym się zablokowały.
W projektach realizowanych w organizacjach mentor również może co jakiś czas odłożyć swoje zadania i przyjrzeć się, co robią inni. To oznacza, że człowiek w tej roli z jednej strony jest wykonawcą zadań, ale z drugiej strony musi mieć czas na zainteresowanie się zadaniami pozostałych.
Pasywne podejście mentorów do wsparcia zwykle nie działa. Jeżeli człowiek zakopał się w jakimś problemie, to zwykle nie ma świadomości, że ktoś może mu pomóc. W takiej sytuacji mentor musi “szturchnąć” go w ramię i zapytać, nad czym się tak biedzi. Widziałem ten syndrom na Hackyeah, gdzie dopiero aktywne zaczepianie zespołu powodowało, że otwierały się i wysypywały swoje pytania.
Mentor jest odpowiedzią na sytuację, gdy zespół stoi przed problemem a jego kompetencje są na poziomie nieświadomej ignorancji. Gdy człowiek nie wie, że nie wie, to także nie wie, że powinien zapytać.
Odbiory
W projektach eksploracyjnych wypuszczenia funkcjonalności do klienta następuje nieregularnie. Jednak typową praktyką, która ma zapewnić większa kontrolowalność projektu jest umawianie się na konkretne daty odbiorów. Jeżeli projekt jest robiony dla zewnętrznego klienta, to często w kontrakcie wpisuje się daty kalendarze, w którym zostanie przeprowadzony oficjalny przegląd i odbiór tego, co można dostarczyć. Jeżeli projekt jest wewnętrzny, to również zespół umawia się na okresowe odbiory.
Ciekawe jest to, że częstotliwość odbiorów nie musi być wcale stała. Bartosz Krzywański pracujący w sektorze lotniczym, przyznał, że w ich firmie częstotliwość odbiorów zależy od poziomu dojrzałości technologicznej rozwiązania. Gdy jest na poziomie TRL2 to może odbywać się co dwa miesiące, ale gdy wchodzi na poziom TRL4 to nawet raz na sześć miesięcy. Interpretuję to tak – im bardziej sprawdzone i dojrzałe rozwiązanie, tym rzadsze przeglądy. Im bardziej niepewne, tym większe ryzyko napotkania punktu zwrotnego i konieczność częstszych przeglądów.
Spotkania odbiorowe są również dobrą okazją do skontrolowania budżetu. Gdy przykładowo korporacja, potrzebuje przejrzeć, czy projekty nadal ma zapewnione finansowanie, może raz na kwartał zaplanować odbiory, w ramach których dokona przeglądu rozwiązania, wygenerowanej wiedzy, szans na sukces oraz właśnie zużycia budżetu.
Na poziomie odbiorów perspektywa eksploracyjna zderza się z kaskadową. Może to prowadzić do konfliktów niestety.
Rytuały integracyjne
O tym, że duch zespołu jest ważny pisałem już wcześniej. Warto jednak zorientować się, w jaki sposób go budować. W wielu rozmowach praktycy zespołów eksploracyjnych wspominali o gastronomii i sporcie. Jedni gotowali pierogi dla wszystkich, inni organizowali dzień z ciastami pieczonymi w domu, jeszcze inni kupowali pizze i piwo. Kilku uczestników hackathonów spontanicznie wspomniało, że jednym z powodów uczestnictwa w tych konkursach jest darmowe jedzenie. Edison stawiał obiad swoim pracownikom, którzy zostali z nim w laboratorium, jednak przyjętą porą obiadu była północ. Drugi czynnik to sport w postaci wspólnych meczy w koszykówkę lub siatkówkę, albo wyjścia na squasha, albo zawody w piłkarzyki.
Generalnie chodzi o to, aby zespół zrobił coś wspólnie, co wymaga kooperacji i interakcji społecznych, powoduje uczucie przyjemności, a nie jest pracą.
