O zaletach wewnętrznych szkoleń

W tym wpisie opiszę bardziej szczegółowo pierwszy z tematów, czym się zajmuję jako wewnętrzny agile coach w mBanku, czyli szkolenia. W zasadzie szkolenia to bardziej narzędzie – bo tematem, którym się zajmuję jest rozwój kompetencji organizacji czy członków organizacji.

Potrzeba rozwoju kompetencji zwinnych była widoczna natychmiast, jak tylko dołączyłem do firmy. Stan zastany przeze mnie w mBanku to przychylność do agile, jakieś tam swoje własne formy pierwszych prób jego wykorzystania przez osoby z różnych części IT. Ale w praktyce widziałem wyraźny rozdźwięk między chęciami a umiejętnościami czy znajomością agile takiego, jakim go znam. I dlaczego to podkreślam “takiego jakim go znam”? Bo coś co odkryłem w ciągu pierwszych miesięcy mojego pobytu w mbanku to fakt, że część osób, w szczególności całkiem pokaźna część managerów, coś już wiedziała o agile. Między innymi wzięli udział w szkoleniu, z “ogólnospożywczego agile’a”, czyli takiego wprowadzenia czym agile jest i jakie istnieją metody i jakie są podstawowe definicje. Potrafię zrozumieć dlaczego tego typu szkolenia są organizowane, natomiast jestem ich wielkim przeciwnikiem. Można to sobie wyobrazić po konspekcie szkolenia, co widać też było po prostu po efektach: uczestnicy tego szkolenia kojarzyli podstawowe definicje, ale nie umieli ich zastosować poprawnie. W szczególności, że te szkolenia to było głównie przekazanie wyobrażenia o agile ze strony trenera. I to nieprzypadkowo dobrane słowa, ponieważ po sprawdzeniu tego, kto szkolił trudno powiedzieć, by to był praktyk. A w moim świecie brak dogłębnej praktyki przekreśla możliwość szkolenia z podejścia zwinnego czy konkretnie Scruma. Jeśli ktoś tego nigdy nie praktykował, to nawet jeśli jest bardzo dobry w technikach nauczania, nawet jeśli umie dość poprawnie skopiować warsztat, który przeprowadzony był przez jakiegoś innego trenera, to jego misternie zbudowany domek z kart zaczyna się sypać w momencie, w którym pojawiają się jakieś praktyczne pytania ze strony uczestników, prośby o jakieś konkretne case’y.

Co szkolenie pojawia mi się komentarz:

“teoria teorią, ale jak to byś zrobił w praktyce”

i tutaj trener-teoretyk powinien szczerze odpowiedzieć

“no w praktyce to nie wiem, bo nie przeczytałem tego w żadnej książce, którą czytałem i nie potrafię sobie tego wyobrazić, więc przyznam Ci rację, że tego na pewno się nie da zrobić”.

A praktyk, który widział wiele zespołów, przeżył to sam na swojej własnej skórze (i najlepiej jeśli “to” widział w więcej niż jednej firmie), jest w stanie przytoczyć kilka przykładów z życia na dowolne trudne pytanie. A tak naprawdę, to będzie się czuł na tyle swobodnie z możliwymi scenariuszami rozwoju dyskusji, żeby ten konkretny trudny case rozpracować z tym kto pyta,  więc rozbiją założenia pytającego na części pierwsze, nurkując głęboko w problem związany z teoretycznie prostszym pytaniem.

Właśnie to drugie podejście stosuję na co dzień. Widzę dużą różnicę między momentem rozpoczęcia dwudniowego warsztatu, gdy łatwo wyłuskać osoby sceptyczne, a wręcz krytyczne albo negatywnie nastawione do koncepcji, po czym przez cały tok warsztatu prowadzimy swego rodzaju grę, proces docierania do tego co konkretnie dana osoba potrzebuje i jak sobie te kwestie związane ze zwinnością czy Scrumem wyobraża. Ważne jest to, by dotrzeć, jakie ktoś ma założenia, jak sobie wyobraża, że coś się da, a czegoś się nie da zrobić w podejście zwinnym i dość często dość prosto docieramy do tego, że sceptyczne czy negatywne nastawienie do agile wiąże się na przykład trudnością wyobrażenia sobie tematu skalowania, tematu architektury, tematu koordynacji pracy różnego rodzaju specjalistów. Szereg takich mitów, albo po prostu braków wiedzy na temat tego, że pewne kwestie są rozwiązywane, warto sobie na warsztacie rozpracować. Wejść w partnerską dyskusję na równych zasadach, z wsłuchaniem się w konkretne potrzeby konkretnej osoby.

Jedna ciekawa kwestia związana z organizowaniem prawidłowych szkoleń uprościła się “sama”. Szkolenia organizujemy wewnętrznie, to znaczy własnymi trenerami. Pierwszym trenerem byłem ja sam, potem gdy mój zespół zaczął rosnąć, to kolejne osoby z mojego zespołu zaczęły szkolić, a ostatnio już taką praktyką, którą regularnie stosujemy są szkolenia realizowane “w parze”: jeden trener to agile coach a drugi trener wywodzi się z grona Scrum Masterów. Temat uprościł się “sam” w tym sensie, że akurat budżet szkoleniowy nie jest zbyt pokaźny, nazywając to dyplomatycznie, a szkolenia scrumowe na rynku są drogie, więc nawet jeśli by wejść w jakąś stałą współpracę z zaufanym trenerem i wynegocjować u niego duży pakiet zamówień to i tak coach zatrudniony na etacie i realizujący dwa szkolenia w miesiącu spokojnie spłaca temat szkoleń zamawianych na rynku. Dodatkowo coach dostępny na miejscu jest gotowy podjąć temat znacznie wcześniej, czy znacznie szybciej niż przy umawianiu się z trenerem zewnętrznym. Większość dobrych trenerów w tej chwili na rynku potrafi mieć przynajmniej niektóre terminy zarezerwowane sporo w przód. Druga korzyść takich szkoleń wewnętrznych, nieoczywista na początku to coś, co mi Tomek Włodarek, z którym współpracujemy w mBanku, przekazał jako feedback po szkoleniu, które w moim wykonaniu obserwował. Wśród uwag pozytywnych zwrócił uwagę na to, że takie szkolenie wewnętrzne jest niesamowicie wzmacniane przez konkretne przypadki zespołów czy cały kontekst wewnątrzfirmowy. Trener wewnętrzny, zwłaszcza jeśli jest już dłuższy czas w organizacji i jest z nią też mocno związany przez praktykę zespołów scrumowych, w zasadzie jest w stanie odpowiadać na większość pytań, jakie się trafiają na szkoleniu, przykładami z firmy, co wzmacnia możliwość wyjaśniania i przekonywania. Na przykład opowieści o chociażby skalowaniu łatwo wzmocnić, jeśli się użyje przykładu “a w zespole X skalowanie wygląda tak”. Wtedy w zasadzie unikamy opowiadania o smutnych i wesołych historiach wydarzających się w zupełnie innych organizacjach (“bo przecież nasza organizacja jest specjalna”), tylko to jest historia o Twoich kolegach, o ludziach których kojarzysz z nazwiska i wiesz, że mają porównywalną sytuację do Twojej. Od któregoś momentu transformacji w zasadzie na dowolne kwestie jestem w stanie używać przykładów wewnątrzorganizacyjnych, co tak jak wspominam na pewno polepsza tą możliwość dotarcia z przekazem, rozwiania wątpliwości i błędnych założeń o niedasizmie.

Powyższe jeszcze nie wyczerpuje tematu rozwoju kompetencji w ramach toczącej się transformacji, ale opowiem resztę w drugiej części tego wpisu niebawem.

Wicedyrektor do spraw – rozwiewanie mitów

Jestem pytany o swoje stanowisko, niektórym ono imponuje, brzmi szczególnie dobrze – ten wpis będzie trochę rozwiewał nadzieje społeczne 😉 Stanowisko jakim się posługiwałem do tej pory – czyli wicedyrektor ds. optymalizacji procesów IT – brzmi godnie, natomiast chciałem trochę opowiedzieć co to dokładnie jest i dlaczego tak a nie inaczej zostało skonstruowane.

To nie jest tak, że ten opis stanowiska ma jakąś wielką historię za sobą, ale pewne informacje są tu istotne. Gdy dołączałem do mBanku, trzeba było mnie jakoś zatrudnić, bo zdecydowaliśmy się (obie strony), że idę na etat. Wiadomo było, że moja funkcja musi – i docelowo będzie miała – jakieś formalne umiejscowienie, bardziej wyraźne, w postaci odrębnego zespołu, gdzieś zawieszonego w strukturze. Pierwszy pomysł był taki, że być może można by mnie podwiesić pod CIO, ale tutaj zasady korporacyjne nie pozwoliły na to, by pod CIO umieścić pojedynczą osobę… Szef całego IT mógł mieć pod sobą wyłącznie dyrektorów departamentów. A ja przychodząc do firmy byłem bardzo jednoosobowym zespołem 😉 więc nie wchodziło w grę umiejscowienie mnie tak wysoko. Mimo wszystko z paru względów warto było wyróżnić to co robiłem, no i trzeba też było stworzyć stanowisko (nazwać je jakoś i spisać zakres obowiązków).

Stanowisko wicedyrektora niektórzy spoza firmy wyobrażają sobie bardziej doniośle niż jest to w rzeczywistości struktury organizacyjnej mBanku – moja organizacja ma dość dużo osób na takim stanowisku, jest dość wypiętrzona i hierarchiczna.

Po wszystkim okazało się, że takie stanowisko miało bardzo dobry efekt w organizacji, coś czego nie doceniłbym wcześniej, przed dołączeniem do mBanku. Paradoksem z perspektywy osoby wprowadzającej agile jest to, że w takiej organizacji hierarchicznej osoba, która ma ochotę coś zmienić z poziomu specjalisty (szeregowego pracownika) może mieć bardzo duży problem. Bardzo duże znaczenie ma posiadanie stanowiska, dopiero ono, wraz z umocowaniem, zespołem i budżetem buduje całość twojego potencjału w organizacji. Nie wystarczy mieć rację na poziomie samego przekazu i entuzjazmu jaki niesiesz… Gdy pracowałem jeszcze w Allegro, wspominał mi o tym jeden z wyżej postawionych menedżerów, który chciał osiągnąć ważną zmianę biznesową wskroś całej firmy i miał wielkie problemy z uzyskaniem tego będąc w zasadzie osamotnionym. Teraz sam to obserwuję, że wielokrotnie moje działania faktycznie wzmacniane są przez moje miejsce w organizacji, które być może (w moich własnych oczach) jest trochę na wyrost i nie lubię nim epatować – na przykład nie mam tego wicedyrektora w ogóle w stopce mailowej i sam siebie nigdy nie tytułuję, gdy się przedstawiam. Ale w hierarchii organizacyjnej, w szczegółach kontaktu osoby, ten mój wicedyrektor gdzieś tam wisiał i zdarzały się przypadki, gdzie można to było instrumentalnie potraktować. To zasługuje na miano anegdoty, gdy jakiś zespół procesowy nie miał ochoty z jakichś swoich powodów realizować moich zamówień (np. jakiegoś zakupu materiałów które ja wiem że są potrzebne, mimo że dziwne – takie jak klocki LEGO 😉 ). W takiej sytuacji można było użyć ostatecznego argumentu „(wice)dyrektor tego potrzebuje!”.

Drugi człon mojego stanowiska też zasługuje na rozwianie niektórych mitów. „Optymalizacja procesów IT” to odpowiedź na wymogi organizacyjne, które każą nazywać każde stanowisko takim właśnie członem opisowym (do spraw obsługi klienta, do spraw rozwoju systemów IT itd.). Ten człon w moim przypadku najbardziej oczywisty to jest „do spraw agile” i takie coś w tej chwili mam już oficjalnie w dokumentach, ale w momencie gdy dołączałem do organizacji takie ujęcie sprawy byłoby przede wszystkim niezrozumiałe. Czym jest (tak naprawdę) agile wtedy wiedziało może raptem kilkanaście osób. Druga kwestia to też była taka forma taktyki: idąc tropem porad Sun Tzu jeśli chcemy coś zmienić w organizacji radykalnie, to może na początku nie ma potrzeby tym radykalizmem epatować. Zwłaszcza, że z Krzyśkiem (czyli szefem IT mBanku) ustaliliśmy, że w zasadzie to nie ma potrzeby się spieszyć ze zmianą agilową, transformacja będzie przebiegała świadomie powoli. Zmiana organizacyjna, jaka była do wykonania, była bardzo duża i w szczególności nie zdecydowaliśmy się na jakieś rozwiązania intensywne, rewolucyjne zmiany. Stąd tym bardziej nie ma co straszyć ludzi jakimiś stanowiskami do spraw agile i hiszpańską inkwizycją. Zamaskować troszkę to, czym się będę zajmował, żeby za wcześnie zbyt mylnych wniosków niektórzy nie wyciągali. Czy to wyszło czy nie wyszło, to jest temat na oddzielną dyskusję 😉 bo siłą rzeczą rozpoczynając pracę w firmie musiałem się jakoś przedstawić.

Wniosek ogólny – nie interpretujcie mojej funkcji przesadnie, bardziej się liczy to co robię i jaką mam rolę w organizacji. Na potrzeby świata zewnętrznego lepiej byłoby to opisać jako bycie liderem zespołu agile coachów

Jak pisałem ogłoszenie rekrutacyjne na agile coacha?

Jeszcze jeden epizod z mojej roli menedżerskiej to prowadzenie rekrutacji. Po tym jak dołączyłem do mBanku, wyobrażałem sobie, że do mojego zespołu zaproszę kilka znanych mi wcześniej osób. Niestety żadna z nich nie zdecydowała się ostatecznie na ten krok, więc spotkałem jeszcze jeden z przypadków wyjścia poza strefę komfortu w ramach pracy w mBanku – zbudowanie zespołu Agile Coachów z zupełnie nieznanych mi osób.

Łamiąc zasadę chronologii w opisywaniu wydarzeń, opowiem jak udało się dołączyć do ekipy ostatnią z osób.

Do zaplanowanej wielkości zespołu brakowało mi 1 osoby w Warszawie, do zaplanowanej różnorodności brakowało mi 1 dziewczyny (przy czym wiedziałem, że przy kruchości podaży na rynku pracy agilistów może sie nie udać – kryterium płciowe było nice-to-have). I jak już przy różnorodności jestem – wyrazistym się stało, że zespół w dotychczasowym wyszedł dość ekspercki, ujmując to dyplomatycznie. Potrzebowałem do zespołu osoby mniej zaawansowanej. A ponieważ zespół zajmuje się odpowiedzialnymi rzeczami, ta mniej zaawansowana osoba musi mieć duży potencjał rozwojowy, tak by mogła w niedługim czasie po dołączeniu podjąć tematy trudne (wspieranie trudnych zespołów projektowych, praca z wyższym kierownictwem), nawet jeśli nie ma w nich doświadczenia z poprzednich miejsc pracy.

Łatwo powiedzieć, trudniej zrobić – jak znaleźć kogoś, kto ma duży potencjał, ale chwilowo jeszcze się nie łapie na jakieś wysublimowane kryteria typu wiele lat doświadczeń w transformowaniu firm i coachowaniu zespołów? Sięgnąłem po dwie znane mi metody – persony i kontakty.

Zacznę od persony – znamy je jako jedną z metod marketingowych, product developmentowych czy Lean UX. Osobiście najmocniej temat person przećwiczyłem w czasie przygotowania się do pierwszego publicznego wystąpienia na ACE! w Krakowie w 2012. Magda Giec pomogła mi i Jackowi dookreślić do kogo tak naprawdę chcemy mówić, czyje potrzeby zaspokoić. Tamte wspomnienie zostało ze mną już do tej pory i przed każdym porządnie przygotowanym wystąpieniem robię sobie persony – a w kontekście tego artykułu zrobiłem personę idealnego kandydata, do którego skieruję bezpośrednio treść swojego ogłoszenia.

Poznajcie Edytę, 29 lat, która przepracowała kilka lat przy projektach w roli testerki, w tym ostatni rok jako Scrum Masterka. Edyta jest nieszczęśliwa, bo poczuła, że kręci ją temat agile i zmieniania swojego otoczenia, ale też odkryła, że jest nieszczęśliwie zblokowana kruchością Scruma w obecnej firmie (nic już więcej nie osiągnie przez kilka najbliższych lat, jej obecny szef jest zadowolony z obecnego status quo scrumowatości). Mimo swojego zniechęcenia obecną firmą (a może właśnie dzięki niemu) Edyta mocno skupia się na samorozwoju, rozwija swoje umiejętności miękkie i uczestniczy aktywnie w społeczności.

Pod kątem takiej persony skonstruowałem swoje własne ogłoszenie rekrutacyjne (moje inne ogłoszenia to też temat na niejeden artykuł 😉 ):

Scrum Master

  • Kim jesteś?
    • Masz pewne doświadczenie z agile, najlepiej w roli Scrum Mastera
    • Przeżyłaś / przeżyłeś co najmniej kilka projektów IT (w dowolnej roli) i wiesz, z jakimi problemami możesz się w nich spotkać
    • Dużo czytasz o agile i Scrumie, wiesz, że musisz się jeszcze dużo uczyć
    • Masz w sobie dużo energii, lubisz pracować z ludźmi, umiesz słuchać
  • Kim chcesz być?
    • Masz ochotę rozwinąć się w roli Scrum Mastera, być unikalną / unikalnym
    • Czujesz, że możesz też iść dalej w rozwoju, potrafisz wyobrazić siebie w roli trenera / coacha za kilka lat
    • Potrzebujesz zmiany, by odblokować swój potencjał, który w obecnym miejscu pracy osiągnął sufit możliwości
  • Dlaczego warto do nas dołączyć?
    • Tworzymy rzadko spotykany na polskim rynku zespół agile coachów, którzy w pocie czoła zmienia swoją firmę rozwijając przy okazji swoje umiejętności
    • Będziesz mieć szansę współpracować z grupą praktyków z doświadczeniami z wielu firm i najlepszymi polskimi trenerami/konsultantami scrumowymi
    • Potrzebujemy Twojej perspektywy w zespole – osoby ambitnej i z doświadczeniami, ale nadal z dużą ilością rozwoju przed sobą.
  • Co czeka na Ciebie u nas?
    • Pełnienie roli Scrum Mastera
    • Współpraca z zespołem Scrum Masterów
    • Wsparcie dla początkujących Scrum Masterów
    • Rozwój w stronę Agile Coacha

Nie czujcie się źle, że przeoczyliście to ogłoszenie w sieci – nie pojawiło się ono nigdzie, bo w międzyczasie zmieniła się trochę koncepcja… Kandydatów do tej rekrutacji poszukaliśmy bezpośrednio, zapraszając wybraną grupę osób – korzystając z Linkedina i osobistych rekomendacji trenerów. Spośród tej grupy było kilka mocnych kandydatur, z których udało się znaleźć zaskakująco dopasowaną osobę do wypisanej wyżej persony.

Aga, miło mi mieć Cię w zespole 🙂

PS. Po co ten artykuł? Jeśli robicie rekrutację, zastanówcie się czy Wasze ogłoszenie musi być takie jak wszystkie. Ile jest Was samych i Waszego zespołu w tym jak opisujecie stanowisko, oczekiwania itd.