Agile Community of Practice

Wdrażając Scruma, zaczynasz zapewne od IT i “biznesu”, ale prędzej czy później przyjdzie się Ci zmierzyć z wyjściem do całej organizacji i pokazaniem jakie wartości płyną z agile’owej transformacji. W tym artykule chciałbym podzielić się z Wami jednym z najprostszych sposobów zbudowania Agile Community of Practice, czyli cyklicznego, zamkniętego w ramach czasowych spotkania, adresowanego do wszystkich pracowników organizacji.

Żeby takie spotkania miały sens, każdy w firmie musi mieć choćby minimum wiedzy na temat agile – w innym przypadku ludzie nie będą rozumieli po co mają się spotkać i o czym traktować będzie te spotkanie. Taką wiedzę trzeba jednak zbudować. Na pierwszy rzut warto porozmawiać czym jest Agile Manifesto, dlaczego chcecie w organizacji postawić na wartości za nim idące i opowiedzieć jaka droga będzie Was wszystkich czekać podczas transformacji. Same spotkania na początku będą wymagały silnej moderacji i wyjścia z inicjatywą ze strony organizatora. Warto znaleźć chwytliwe odniesienia do Waszej organizacyjnej rzeczywistości.

Spotkania zdecydowanie powinny posiadać stałą strukturę, i odpowiednio wcześniej komunikowaną agendę, dzięki czemu każdy będzie wiedział jaki obszar będzie poruszany. Mogę powiedzieć, że najbardziej sprawdzony podział spotkania to:

część teoretyczna (10 min.),
część praktyczna (35 min.),
“przyjdź z problemem” (10 min.),
zbieranie informacji zwrotnej po spotkaniu (5 min.).

Całość dobrze jest zamknąć w około 60 minutach raz na dwa tygodnie. Ramy czasowe są bardzo ważne i pozwalają się skupić tylko na istotnych rzeczach.

Z pewnością nasuwa się pytanie, kto powinien uczestniczyć w takich nieobowiązkowych spotkaniach. Czy powinni się na nich pojawiać oprócz liniowych pracowników managerowie, a może nawet C-level? To dość trudny temat, bo jak ich przekonać, że to nie strata czasu i warto znaleźć miejsce w kalendarzu, aby w nich uczestniczyć? Ponadto, ich obecność z jednej strony może pokazać jak ważny, jak poważnie w firmie jest traktowany agile, z drugiej – szczególnie w bardziej schierarchizowanych organizacjach – może zakłócić otwartość wypowiedzi czy spowodować efekt uczestnictwa “bo wypada się pokazać”. Docelowo, na pewno warto dążyć do tego, aby osoby z przysłowiowej “góry”, nawet w ograniczonym składzie, były co najmniej okazjonalnymi uczestnikami takiego spotkania. A bez wątpienia, zanim taki cykl spotkań się rozpocznie, należy porozmawiać z wszystkimi menedżerami danych działów i wyjaśnić im cel, ideę tego spotkania i uzyskać ich przychylność. Ważne, aby wszyscy pracownicy firmy mieli “zielone światło” na uczestnictwo w spotkaniu.

Pierwsza część powinna być zazwyczaj w formie krótkiej prezentacji, nawiązania do jakiegoś artykułu czy też dyskusji. Nie powinna ona być zbyt długa, bo zależy nam na tym, aby wiedzę teoretyczną poprzeć jak najszybciej praktycznymi aspektami. Ta druga część wymaga zazwyczaj przygotowania (wydrukowania elementów planowanej gry, znalezienia “narzędzi”), rób to zawsze przed spotkaniem, aby nie tracić czasu w jego trakcie. Sala powinna być także przyszykowana odpowiednio wcześniej, tak aby wszystko przebiegało bez zakłóceń (przygotowanie stołów dla grup, zaaranżowanie dużej przestrzeni, etc.). Środowisko musi wspierać spotkanie i być przygotowane na jego potrzeby. Warto, aby część praktyczna była odzwierciedleniem wcześniej prezentowanej teorii, czyli jeśli np. rozmawiacie o estymowaniu zadań z użyciem story pointów to idealnym ćwiczeniem będzie np. pokazanie Planning Pokera w praktyce.

Na kilku pierwszych spotkaniach może zabraknąć części “Przyjdź z problemem”, czyli miejsca gdzie uczestnicy mogą przyjść i zadać pytania odnośnie problemów, niejasności, które napotykają w kulturze pracy agile. Bądźcie na to przygotowani i w zanadrzu miejcie studium przypadków z firmowych projektów. Ludzie mogą nie wiedzieć jeszcze z jakimi problemami mogą przyjść na to spotkanie – tak jak mówiłem – początki bywają trudne i wymagają dużej inicjatywy i zaangażowania prowadzących. Ale z czasem ciężar spotkania powinien być przeniesiony na uczestników, a organizujący powinni stać się moderatorami.

No, ale jak zbierać takie informacje o czym chcą rozmawiać uczestnicy? Jest kilka sposobów, które też w sprytny sposób pozwolą także zareklamować spotkanie różnymi kanałami.
Po pierwsze, mailowa lista dyskusyjna/kanał na komunikatorze, po drugie analogowa, dedykowana spotkaniu tablica (np. korkowa) z zapasem post it’ów i czymś do pisania w łatwo dostępnym dla pracowników miejscu (np. kuchnia). Dzięki niej będzie można zachować trochę anonimowości, przez co dajemy możliwość poruszania problemów bez wskazywania na konkretne osoby/zespoły/obszary. Czasami jest to bardzo ważne bo ktoś może czuć się skrępowany, bo będzie mu się wydawało, że ma problem z oczywistymi rzeczami i nie będzie chciał ich poruszać na spotkaniu.

Przyjdź z problemem (“Bring your own problem”) to raczej temat na dojrzałe spotkania, gdzie będzie już spora świadomość czym jest Scrum i kultura Agile. Przez pryzmat organizatora takich spotkań, mogę powiedzieć, że dotykają one najróżniejszych części organizacji, od tego np. czy w helpdesku da się pracować z użyciem Kanbana, co zrobić gdy na retrospektywie wszyscy udają, że nie ma problemu albo co zrobić, gdy ktoś z managementu zaczyna wymuszać terminy. Odpowiada nie tylko organizator spotkania – trzeba aktywizować całe towarzystwo. Takie dyskusje zazwyczaj wystarczy tylko lekko moderować i ucinać ucieczki na poboczne tematy czy populistyczne rozwiązania, skupiające się na personalnej optyce, nie interesie całej firmy. Uczestnicy świetnie sobie radzą i zaczynają dzielić się swoimi historiami, jak sobie poradzili z danym tematem.

Ostatnia część – czyli informacja zwrotna, niezmiernie ważna dla organizatorów, ale przekładająca się bezpośrednio na to jak będą wyglądały spotkania w przyszłości.
Sugeruje rozdanie ankiet, bezpośrednio po spotkaniu i prośbę o ich uzupełnienie, zanim wszyscy opuszczą salę. Gdy się to nie uda i wszyscy się rozejdą raczej nie ma co liczyć na powrót ankiet. Każdy usiądzie do obowiązków i zapomni o istotnych szczegółach spotkania.

Świetnie sprawdza się do tego Perfection Game. Ankieta powinna być prosta i dać możliwość przekazania wartościowego feedbacku uczestnikom. Proponuje trzy krótkie pytania, czyli:

Jak oceniasz spotkanie w skali 0/10?
Co byś zmienił, aby dać 10?
Co było najbardziej wartościową częścią spotkania?
Z jakiego działu jesteś? (opcjonalne)

Pamiętaj, aby ankieta miała sens uczestnicy spotkania muszą widzieć, że ona działa, więc jeśli kilkanaście osób domaga się jakieś rzeczy, warto coś zmienić.

A sprawą, która jest z tym bezpośrednio związana jest transparentność tych ankiet. Warto wysłać podsumowanie w miejsca gdzie trwa komunikacja o spotkaniach. Np. średnią ocenę z ankiety, pogrupowane tematycznie rzeczy wskazane jako “do zmiany”. Warto też poinformować jaki następny obszar będzie zmieniany – nie zawsze da się od razu zmienić wszystko, ale też nie wszystkie rzeczy będziecie chcieli zmienić.

Często obserwując takie spotkania, bądź je organizując, miałem styczność z dostawaniem obniżonych not za to, że spotkanie trwa tylko godzinę – ale była to świadoma decyzja – po pierwsze nie chcieliśmy zabierać za dużo czasu, po drugie chcieliśmy zostawić pewien poziom nienasycenia, to przekładało się na frekwencję na spotkaniach. Dzięki tym spotkaniom powinieneś zyskać grono stałych uczestników, którzy staną się agentami zmiany i Twoimi sprzymierzeńcami w różnych działach firmy.

Reasumując – takie spotkania są bardzo fajnym miejscem na krzewienie kultury agile. Są nieformalne, prowadzone przez pracowników firmy, a więc nie będzie ryzyka, że ktoś się będzie krępował z zadawaniem pytań czy nie pojawi się obawa przed obnażeniem niechcianych sytuacji. Dodatkowo całość będzie podparta znaną wszystkim organizacyjną rzeczywistością w której każdy łatwo się odnajdzie. Dodatkowo agile będzie miał szans dotrzeć nie tylko do biznesu i IT, ale także do innych działów, gdzie może trafić na podatny grunt.

#agile #Scrum