Organizacja ucząca się

W zeszłym miesiącu pisaliśmy o przepływie informacji – a tym razem bliżej przyjrzymy się tematowi przepływu wiedzy.

Jak zachęcamy innych do działania?

Właśnie – jak wykorzystać wiedzę naszych pracowników i jak zmotywować ich do dzielenia się nią z innymi lub do promowania firmy na zewnątrz? Nie wystarczy przecież tylko powołać samoorganizujące się zespoły i uznać, że z czasem nastąpi oczekiwana synergia wiedzy ich poszczególnych członków. Że wszyscy będą dzielić się swoimi doświadczeniami – zwycięstwami i porażkami. Że część wniosków z retrospektyw będzie komunikowana na forum całego działu, stanowiąc bazę dla dobrych praktyk i nauki.

Bez dwóch zdań – w tej branży każdy chce się uczyć, rozwijać, realizować coraz ciekawsze, ambitniejsze zadania. Ale… nie każdy chce uczyć. Nie każdy ma w sobie potrzebę i chęci dzielenia się z innymi swoją wiedzą, doświadczeniem. Pal licho przyczyny, które mogą być bardzo różne. Tak po prostu jest. Sztuką jest zachęcić takie osoby do działania. Nie za pomocą jednorazowej “marchewki”, ale tak, żeby robiły to chętnie, regularnie, z zaangażowaniem. Pasja w przekazywaniu wiedzy jest bowiem jednym z kluczowych czynników tego, aby robić to skutecznie. Pasja zaraża.

Dlatego od samego początku, jako Scrum Masterzy GetResponse, staraliśmy się dawać przykład, inspirować innych. Przygotowywanie wewnętrznych szkoleń, prezentacji, występowanie na wewnętrznych spotkaniach z wnioskami, dobrymi praktykami, wrzucanie na Slacku linków do ciekawych artykułów (także technicznych), motywowanie innych do działania. Od początku postawiliśmy na działanie przez przykład, żeby pokazać, że to ma sens. Chcieliśmy uwidocznić, jak wiele wnosi to do firmy i jak wiele samemu przy okazji można się nauczyć.

Nastawiliśmy się na długotrwały i niełatwy proces, ale z czasem pojawiły się owoce. Fakt, gdzieniegdzie bez naszego zaangażowania wracamy do punktu wyjścia. Nie ma gotowych recept, złotych wzorów działania. Potrzeba na to dużo czasu, wiary w końcowy sukces i samozaparcia, ale bez dwóch zdań – warto!

W naszych działaniach próbujemy różnorodonych rzeczy. Oto te, które okazały się najbardziej skuteczne:

• Slack

Dobrze przemyślana lista kanałów to klucz do sukcesu dobrej komunikacji na Slacku. I to również w zakresie przekazywania wiedzy, ot chociażby poprzez podrzucanie linków do ciekawych artykułów, do poczytania przy kawie. Warto promować i zachęcać ludzi do podrzucania ciekawych materiałów. Trzeba mieć jednak wyczucie i dobre niepisane zasady, tak żeby na przykład nie zarzucać ogólnego kanału IT artykułami dotyczącymi szczegółów konkretnej technologii, wykorzystywanej przez jeden zespół, albo szczegółową dyskusją o historii Scruma. Warto utworzyć ogólne kanały zbierające specjalistów z danej dziedziny. Ważne, żeby jednak te kanały pozostałe otwarte, a o ich istnieniu dobrze komunikować.

Przykładowo, jako Scrum Masterzy, stworzyliśmy kanał #agile i byliśmy bardzo pozytywnie zaskoczeni liczbą osób, która do niego dołączyła Ale jednocześnie często co ciekawsze artykuły wrzucamy na kanał dostępny dla całego działu IT.

• prezentacja zespołów IT

Czy szesnaście zespołów deweloperskich to dużo? Nie wiemy… Wiemy natomiast, że w zupełności wystarczająco, aby zespół X kompletnie stracił z pola widzenia zespół Y. Stąd postanowiliśmy zrobić wewnętrzny “przegląd wojska” i, na wspomnianych w poprzednich wpisach spotkaniach Developers – Wymiana Wiedzy, rozpocząć cykl prezentacji wszystkich naszych zespołów. Każdy z nich przygotował dwudziestominutową prezentację. Kto wchodzi w jego skład? czym się na co dzień zajmują, jakie narzędzia/mierniki wykorzystują? Jak pracują? Pomysł okazał się strzałem w dziesiątkę – przede wszystkim unaocznił wszystkim, jak bardzo szerokie spektrum działań prowadzimy i  jak dużo dzieje się w naszej firmie. Pomógł również rozpowszechnić dobre praktyki i ciekawe rozwiązania.

• Lessons Learned

Na początku była to głównie nasza rola: obserwowanie co się dzieje w zespołach, jakie ważne wydarzenia mają miejsce, co nowego przetestowaliśmy i  co się sprawdziło (lub nie powiodło) oraz zachęcanie innych do przekazywania tej wiedzy na forum. Z czasem uzyskaliśmy oczekiwany efekt i teraz już rzadko kiedy trzeba jeszcze kogoś zachęcać, wypychać. W większości zespołów udało się już zbudować poczucie tego, z jakimi informacjami – sukcesami bądź porażkami – warto wychodzić na forum. Efektem takich wystąpień jest stale rosnący zestaw dobrych praktyk – dla prac międzyzespołowych czy wdrożeń.

• Agile Lessons Learned

Podobnie jak w przypadku przedstawionego w poprzednim wpisie GR TV, dość długo zastanawialiśmy się nad formą tego typu przekazu. W końcu stanęło na wysyłany w pierwszy piątek miesiąca tekst na Slacku, który jest równolegle publikowany na naszym WIKI.

Pierwotnie, miał mieć on formę omówienia bieżących wniosków, doświadczeń i podsumowywać to, czego się w zeszłym miesiącu nauczyliśmy. Finalnie, wyewoluował do mini-podręcznika Agile. W telegraficznym skrócie poruszamy jeden wybrany aspekt: zasady dobrego daily czy Przeglądu Sprintu, czym są Story Pointy i dlaczego je stosujemy, jak pisać wymagania techniczne itp. Na koniec jest też miejsce na sekcję F.A.Q. (Czy wszystkie elementy Backlogu muszą mieć formę User Story? Czy wymagania może pisać tylko Product Owner? itd.). Formuła ta została bardzo dobrze przyjęta. A w efekcie na WIKI uzyskaliśmy już całkiem pokaźną, ciekawą bazę wiedzy na temat agile’owych praktyk w naszej organizacji.

• Brown Bag + Agile Brown Bag

Co prawda nie umawiamy się na nie w trakcie posiłków i nie przynosimy jedzenia w papierowych torebkach, ale dbamy o nieformalny charakter tych spotkań i ciekawe tematy.

Spotykamy się co dwa tygodnie, aby poszerzać swoją wiedzę i horyzonty, niekoniecznie bazując na codziennie używanych technologiach. Ba, czasem wręcz od nich nieco odbiegamy, szczególnie na co trzecim spotkaniu, które jest zawsze zarezerwowane na jakiś temat “okołoagile’owy”. Skupiamy się wówczas na tematach bardziej procesowych czy nawiązujących do pracy programisty od zupełnie innej strony.

Kiedyś głównie oglądaliśmy najciekawsze prezentacje z wiodących światowych konferencji technicznych. Jednak ta formuła z czasem wyczerpała, co pokazała spadająca liczba uczestników spotkań. Ponad rok temu postanowiliśmy więc postawić na prezentacje przygotowywane przez nas samych., Mieliśmy w związku z tym spore obawy – czy znajdą się chętni? Dlatego kilka pierwszych edycji zapełniliśmy własnymi występami. Ale potem rzeczywistość przerosła nasze oczekiwania – wyobraźcie sobie, że chętnych jest tylu, że terminy wystąpień trzeba rezerwować z dużym wyprzedzeniem. Podobnie z uczestnikami, z każdym miesiącem musimy rezerwować coraz większe sale. Jesteśmy z tego szczególnie dumni.

• wewnętrzne szkolenia

Dbamy także o to, aby nasi specjaliści raz na jakiś czas przygotowywali szkolenia wewnętrzne – zarówno na temat technologii/narzędzi, z jakimi pracujemy na co dzień, jak i bardziej ogólnych, mogących pomóc w rozwoju, jak na przykład kryptografia. Aktywnie wspieramy też działania ogólnofirmowe. Mamy w organizacji cykl GR Academy, w ramach którego działamy między innymi z publikowanym już cyklem szkoleń Lego4Scrum@GR.

• kółka zainteresowań

Są one mniej formalne niż cykliczne spotkania specjalizacji technologicznych, otwarte dla każdego oraz bardziej nastawione na rzeczy nowe, “lśniące” lub omówienie tego, z czym aktualnie się zmagamy. Coś na zasadzie popularnych “community of practice”. Organizujem spotkania DevJS i Kółko Miłośników Agile. To drugie przybrało formę dyskusji. Agenda znana i promowana jest dużo wcześniej, między innymi na wspomnianych wcześniej GR TV i kanale #agile. A na samym spotkaniu omawiamy bieżące, zauważalne trendy, jak na przykład Socjokracja 3.0 lub Beyond Budgeting.

• biblioteka

Biblioteczki techniczne stały się w chwili obecnej pewnym standardem w rozbudowanych działach wytwarzania oprogramowania. Jak sprawić jednak, żeby książki nie porastały na półkach kurzem? Można bowiem odnieść wrażenie, że w kwestiach merytorycznych coraz rzadziej sięga się właśnie po tę formę wiedzy…

Jedną z popularniejszych metod, u nas swego czasu testowaną i chwaloną przez kilka zespołów, były tzw. “Kółka Czytelnicze”. Wybierana była konkretna książka, wszyscy mieli określony czas na jej przeczytanie, a później spotykaliśmy się, żeby podyskutować o różnych jej aspektach.

Innym, obecnie stosowanym przez nas rozwiązaniem, jest dedykowana strona na firmowym WIKI, gdzie rekomendujemy najciekawsze pozycje do przeczytania. Dominują tematy procesowo-agile’owe, ale liczymy, że z czasem strona ta wypełni się i pozycjami technicznymi.