Wewnętrzna wymiana wiedzy

Dzielenie się wiedzą to temat, z którym musi zmierzyć się każda rosnąca organizacja. Z dostępnych narzędzi, które mogą wspomóc ten proces, korzystamy ze Slacka i Confluence’a. Dodatkowo organizujemy w tym celu spotkania, jak np. Brown Bag, ogólnofirmowe “Spotkanie IT” oraz te w węższych gronach, według specjalizacji, np. php-owe, frontendowe lub testerskie. Dzięki nim mamy możliwość zapoznania się ze wszelkimi wprowadzanymi w organizacji zmianami, nowymi procedurami, standardami itp., itd., krótko mówiąc: jak mówi konstytucja sejmowa z 1505 r. – nihil novi.  

Zapewne wygląda to podobnie w większości organizacji.

Przyglądając się tematowi bliżej, zauważyliśmy, że potrzebujemy też bardziej szczegółowo zająć się “podwórkami” wewnątrz zespołów deweloperskich.

Niestety, czasem może wydarzyć się, że w ramach jednego zespołu trzeba zająć się utrzymaniem kilkunastu integracji (pluginy i mikroserwisy oraz aplikacje wewnątrz naszego systemu). Efektem tego jest pojawianie się tzw. ekspertów, biegłych w jednym obszarze, zawłaszczających zadania dotyczące tego obszaru i niemających wystarczającej wiedzy do poruszania się płynnie w pozostałych. Ma to swoje plusy i minusy. Plusem niewątpliwie jest możliwość szybkiej realizacji zadań przez eksperta w danym obszarze. Więcej jest niestety minusów, np.:

• Zadania dzielone są według klucza, eksperci biorą swoje.
• Żaden ekspert nie rozwija się w innym obszarze.
• Zanika pomału zespołowość.
• Fikcyjne zastępstwo w przypadku nieobecności.

Jako zespół Scrum Masterów – strażników porządku – postanowiliśmy zapanować nad tym lekko niekontrolowanym chaosem i zasugerowaliśmy, aby zespoły spróbowały mniej formalnie i na mniejszą skalę zastosować praktyki płynące z ogólnofirmowego plenum.

W związku z powyższym, jeden z nich zaczął praktykować tytułową “wewnętrzną wymianę wiedzy”. Jako dzień, w którym takie spotkania się odbywają, wybrano piątek. Tematy do omówienia są dobierane na bieżąco (w kontekście zbliżających się zadań w przyszłym sprincie). Do każdego przypisana jest osoba prowadząca oraz data, kiedy będzie on omawiany. Członkowie zespołu proponują zagadnienia, którymi chcą się podzielić, jak również mogą zgłaszać potrzebę poszerzenia wiedzy w danych obszarach. W tym drugim przypadku osoba, która najlepiej czuje się w temacie, przygotowuje się do omówienia go. Staramy się, aby spotkania miały charakter prezentacji efektów pracy – czy to nowo wytworzonej funkcjonalności, czy też nowo napisanego kodu. Taka formuła spotkania sprawia, że dużo więcej zostaje w głowie, a wymierną korzyścią z tego płynącą jest większa przewidywalność zespołu podczas planowania kolejnych sprintów.

Spotkania te wzmacniają również poczucie zespołowości, pozwalają na identyfikację i eliminację obszarów w małym stopniu rozpoznanych przez resztę. Kompetencje każdego z członków zespołu rosną i mimo dużej różnorodności tematów, jakimi się zajmują, bez większych przeszkód potrafią się nimi wymieniać.

Inspekcja i adaptacja! Jako to napisano w manuskrypcie.