Czym jest i czym nie jest AgileHR

Coś czym się chcę podzielić na gorąco, to radość po przeprowadzeniu warsztatu AgileHR. Zrealizowałem wraz z Adamem i Agą warsztat agile dla naszych mBankowych HRów. Z kronikarskiego obowiązku zaznaczam ten moment, gdy zmiana zwinna dotarła już poza IT, gdy rozmawiamy sobie poważnie o tym, jak w zwinny sposób może być zorganizowany HR. Na pewno mamy zaangażowanych kilka osób, które faktycznie kumają o co chodzi. Zobaczymy na ile uda się doprowadzić do zmian po stronie HRów i na ile uda się zrealizować pewne oddolne pomysły na zmiany i usprawnienia. Zapewne będzie to kwestia wielu kwartałów, a nie miesięcy, ale prawdopodobnie na bieżąco będę do tematu wracał.

Natomiast sama w sobie koncepcja Agile HR też zasługuje na taki szerszy komentarz, bo jak z wieloma popularnymi koncepcjami  łatwo o nieprawidłowe zrozumienie. Rozmawiając o tym, czy w ogóle jako agile coache realizujący transformację powinniśmy się angażować w agile w HRach, stwierdziliśmy, że nie zaszkodzi spróbować zorganizować ten warsztat i sprawdzić, czy “chwyci”. Ubocznym efektem przygotowania się na poziomie koncepcyjnym było dużo fajnych rozmyślań, czym tak naprawdę jest agile w organizacji, czym jest agile poza IT. Agile Manifesto w swoim początku bardzo mocno akcentuje rozwój oprogramowania i przez to osobom, które wychodzą z IT, może być trudno ten temat AgileHR objąć.

Wyliczając możliwe zrozumienia Agile w HR, pierwsze i oczywiste podejście to “wprowadźmy scruma do prac HRu”. Dosłownie tak jak to powiedziałem czyli stwórzmy zespoły scrumowe, obwołajmy scrum mastera, zróbmy product ownera i wio! – “robić scruma, spotykać się, robić retro …dlaczego jeszcze nie jesteście zwinne?” To jest jakieś takie nieprawdopodobne uproszczenie, w ogóle nie uwzględniające domeny, z którą się mierzy HR i też rozpatrujące go jako praca pewnej grupy osób, a nie rozpatrujące to czym HR jest w szerszym kontekście ogólno firmowym, zarządzania, pracy z managerami, pracy z ludźmi, kreowaniu kultury itd. Ten pierwszy przypadek (“poprostu scrum w HR”) wymieniam w oczywisty sposób jako nieadekwatny.

Kolejny poziom agile w HRach, taki który już na co dzień się u nas dzieje, to zarażenie agilem tych osób, które pracują z zespołami IT. Szereg systemów, które są rozwijane, utrzymywane, wdrażane w nasz ekosystem firmowy jest pod własnością konkretnych osób w HRach: system kadrowy, system ocen, intranet. Fajnie, gdy osoby wchodzące w rolę product ownera, czy rolę członka zespołu wdrożeniowego zaczynają łapać na czym polega moc agile’a. Ale to nadal dla mnie nie jest jeszcze agile w HR, to jest tylko po prostu zarażenie agilem osób, które pracują z zespołami IT i przypadkowo tak się składa, że tutaj to są osoby w HR, ale równie dobrze to mogłyby być osoby w Logistyce, Prawnym, Administracji czy Marketingu.

Kolejny poziom agile, jaki może dotykać HRów i też występujący u nas w firmie, to jest rozwiązywanie szeregu rzeczy, które wymagają pracy z HRami. Jakieś impedimenty, czy potrzebne usprawnienia w sposobie funkcjonowania zespołów często wymagają zmiany polityk HRowych, np. systemu ocen, systemu wynagradzania i premiowania. Wszystkie te rzeczy można i  trzeba zrobić ze wsparciem HRu. Tu również uważam, że fakt zmieniania zasad ogólnofirmowych na podstawie sugestii z zespołów zwinnych nadal nie czyni dla mnie agile’a w HRach.

Pierwszy punkt, w których dla mnie zaczyna się agile w HR to taka perspektywa  – “stosujmy trochę inne zasady HR dla zespołów zwinnych, niż w całej organizacji”. Nie silmy się na to, że w tak wielkiej organizacji uda się od razu zmienić absolutnie wszystko do najbardziej odległego miejsca w firmie. Uzwinnianie się punktów styku z zespołami scrumowymi to dla mnie taki nieunikniony sposób na rozprzestrzenianie się zwinności jako filozofii zarządzania czy mindsetu na całą firmę. Dzięki temu, że zespoły scrumowe potrzebują innego podejścia do pracownika, prawdopodobnie wytworzy się potrzeba na inny sposób organizacji HRów i realizacja tej potrzeby (nawet gdy jest bardzo punktowa) to już jest dla mnie pierwszy sygnał zwinnych HRów.

Taka absolutnie najbardziej wypasiona wersja AgileHR, to koncepcja spisana przez kilka osób jako manifest AgileHR. Jest to bardzo spójne i wyczerpujące przeniesienie zasad Agile na HR, funkcjonuje też opracowanie czym jest AgileHR napisany przez Fabiolę Eyholzer. To są wszystko bardzo fajne koncepcje i  mogą być bardzo bardzo inspirującą wytyczną czym AgileHR jest. Jednocześnie ta wizja już jest na tyle rozbudowana, że droga do jej wypełnienia dla wielu organizacji będzie bardzo duża – od hierarchii do sieci, od zasady traktowania wszystkiego w tajemnicy do zasady przejrzystości itd. Wszystkie punkty zawarte w tych materiałach są bardzo obiecujące i bardzo kibicuję organizacjom, które się na takie kroki decydują. Jednocześnie jak w ogóle z wdrażaniem agila, tak samo z tym wdrażaniem AgileHR zachęcam do myślenia perspektywą  przyrostową. Jak ognia unikajmy w takiej sytuacji wdrażania jednym wielkim strzałem, jednym wielkim wdrożeniem szesnaście punktów, krok po kroku zmienionych w organizacji, tylko dlatego, że jest  (będzie?) moda na AgileHR. Raczej zastanówmy się po co to chcemy zrobić, co jest tak naprawdę dla nas ważne, jaki jest stan obecny. Zastanówmy się też, jaki jest pierwszy krok, na jaki się chcemy zdecydować, by uzwinnić dany aspekt funkcjonowania organizacji.

W dodatkowym wpisie, nie wiem czy następnym, czy w jakimś późniejszym czasie, dołożę jeszcze moje osobiste przeżycia związane z tym warsztatem, bo jest tu też kilka przemyśleń na temat tego, czego ja sam o sobie się dowiedziałem dzięki takiej nietypowej inicjatywie.

PS. Dodatkowy komentarz dlaczego tak rozróżniam, że ten wpis jest “na gorąco”, “z kronikarskiego obowiązku”: Dochodząc do mBanku myślałem między innymi o tym, żeby opisywać te osobiste doświadczenia z przeprowadzania transformacji, taką historię pisaną z dnia na dzień. Z różnych względów tamten pomysł wtedy nie wypalił, stąd teraz te wpisy na blogu zazwyczaj są i będą z takiej perspektywy trochę historycznej “dwa lata temu robiłem to, a rok temu udało się to”. Tym wpisem pokuszę się o otwarcie wątku bieżącego, na samym początku drogi. Zupełnie nie wiem jeszcze do czego nurt AgileHR w mBanku doprowadzi i dopuszczam możliwość, że będzie to jeden z ostatnich wpisów w tym wątku 😉 Postaram się częściej pisać również o toczących się rzeczach nie wiedząc w momencie pisania do czego doprowadzi rozwój sytuacji.

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.

Dwa najbliższe wystąpienia publiczne

Częścią tej strony jest zakładka “Wystąpienia”, gdzie zebrałem kilka moich najważniejszych wystąpień i linków do nich, gdyby ktoś chciał się z nimi zapoznać. Oprócz tego wyliczam wydarzenia, na których mam potwierdzoną możliwość wystąpienia albo poprowadzenia warsztatu. W najbliższym czasie zrobię dwie rzeczy, do których zapowiedź jest przedmiotem tego wpisu.

 

Jedna jest już znana od jakiegoś czasu i wspominałem o niej na Linkedinie wklejając zapowiedź z YouTube’a. Jest to konferencja “Zarządzanie zespołami IT” Computerworldu, gdzie 30 stycznia opowiem o konkretnym aspekcie naszej transformacji w mBanku, czyli podejście do zmieniającej się roli menedżera. Zapraszam Was na tę konferencję, jeśli jest w obszarze Waszego zainteresowania jej tematyka, i jest wielce prawdopodobne, że w ramach bloga niebawem przytoczę najważniejsze myśli ze swojej prezentacji w oddzielnym artykule.

 

Drugie wystąpienie które szykuje mi się w niedługim czasie to skorzystanie z zaproszenia ze Zwinnej Łodzi, gdzie 13 lutego opowiem o mojej osobistej refleksji nt. Ścieżki rozwoju Agile Coacha. Jest to odświeżenie prezentacji którą robiłem już dwukrotnie w zeszłym roku. Wystąpiłem z nią po angielsku na Agilii w Czechach, trochę znienacka, gdy zwolnił się w ostatniej chwili slot na tej konferencji. Powtórzyłem to wystąpienie po niedługim czasie na 4developers. W ramach tej prezentacji mam zebrane szereg myśli o swoich kolejnych etapach rozwoju, gdzie opowiadam o tym, jak stałem się Scrum Masterem i co mi pomogło rozwinąć się w tej roli, potem co mi pomogło przejść z roli SM do roli coacha zespołów scrumowych i wreszcie oddzielnie przybliżam perspektywę, którą w ramach tej prezentacji nazywam Change Agentem – czyli osoby która zmienia całą organizację. Jeśli macie taką możliwość, zapraszam Was na Zwinną  Łódź i wejście ze mną w rozmowę o poszczególnych aspektach tego, co przygotowałem. Odświeżony materiał pewnie również przekażę w jakiejś skróconej wersji we wpisach na blogu.
Być może będą nagrania z tych prezentacji, wtedy oczywiście również zamieszczę je w postaci linka w zakładce Wystąpienia.

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.

Czym się zajmuje wewnętrzny agile coach?

Od czasu do czasu dostaję takie pytanie – czym się zajmuję jako Agile Coach w mBanku? Ostatnie tego typu pytanie zdopingowało mnie, żeby wreszcie wystartować tego bloga, więc traktuję tę kwestię poważnie.

W dużym skrócie – zajmuję się wprowadzaniem agile’a. W szczegółach zajmuję się kilkoma aspektami:

  • Z jednej strony jest to rozwój kompetencji związanych z agile całej firmy, ale przede wszystkim IT i zespołów blisko współpracujących z IT. I to jest temat organizowania szkoleń i warsztatów, dostarczanie zastrzyku konkretnej wiedzy i konkretnej praktyki do firmy.
  • Drugim aspektem jest wsparcie zespołów przy wykorzystaniu agile. W kontekście wprowadzania agile’a to jest przede wszystkim wsparcie zespołów scrumowych, które powstają, ale to też jest wsparcie zespołów, które od jakiegoś czasu pracują i potrzebują pomocy w ten czy inny sposób.
  • Dalej jest temat wsparcia dla menedżerów, zwłaszcza przy zmienianiu organizacji, struktury, startowania jakichś nowych większych przedsięwzięć, projektów wewnętrznych i projektów biznesowych – to wszystko może wymagać i faktycznie wymaga wsparcia ze strony osoby, która jest doświadczona w temacie zwinności.
  • Jest też temat procesowy – procesy w większych organizacjach mają wielkie znaczenie. I tutaj osoba doświadczona w agile’u ma zadania związane z kształtowaniem nowych procesów i formułowaniem nowej strategii, formułowaniem wymagań co do wszelkich formalnych dokumentów, które będą miały wpływ na to, w jaki sposób pracują zespoły projektowe

Powyższe z grubsza zbiera wszystkie rzeczy, którymi się zajmuję czy zajmuje się mój zespół. I właśnie zespół to jest kolejny punkt tego, co robię w mBanku, bo wszystkie te rzeczy, które wymieniłem, w ramach dużej organizacji nie są do zrobienia przez jedną osobę. Rozwiązaniem na ten temat jest utworzenie zespołu Agile Coachów wewnętrznych, którego jestem liderem i to też wchodzi w zakres tego, co robię na co dzień – czyli prowadzenie i kierowanie moim zespołem, wsparcie dla zespołu, wykonywanie pracy typowo menedżerskiej (procedury HRowe itp.), również współkreowanie priorytetów tego zespołu.

Najbardziej nie namacalnym, ale też istotnym zadaniem w mojej roli jest wsparcie dla wyższego menedżmentu, w szczególności mam na myśli szefa całego IT. Praca bezpośrednio z zespołami daje ciekawą perspektywę na to, jak sprawy się w firmie mają i od czasu do czasu jest okazja by porozmawiać z wyższymi menedżerami, przekazać im feedback jak ich praca przekłada się na faktyczne zmiany w zespołach, może też następować inspirowanie do dalszych kroków. To działa też w drugą stronę, jest okazja, by wsłuchać się w prawdziwe potrzeby, bieżące przemyślenia i priorytety, co przekłada się na próbę odpowiedzenia na to w postaci kładzenia akcentów w kreowanej przeze mnie i przez mój zespół zmianie, na jakieś konkretne kwestie, które są aktualnie najbardziej potrzebne.
Na bardzo ogólnym poziomie to wszystko, w serii kolejnych wpisów zanurkuję szczegółowo w poszczególne kwestie, rozbudowując je o przykłady i doświadczenia.

Jeszcze jeden blog? Mało Ci?

  • – Będę pisał bloga osobistego.
  • – Jeszcze jednego? Przecież masz agile247!
  • – Nieee, ten będzie osobisty. O agile, ale w pierwszej osobie, tak od serca, krótko i szybko

Cytat z wczorajszej rozmowy z Krystianem w zasadzie wypełnia całość tego, po co jest ten blog. Chcę podzielić się trochę swoimi przemyśleniami w szybkiej formie – bez dbałości o SEO, formatowanie, obrazki, stylistykę. A także bez dbałości o super dopieszczenie merytoryczne – chcę podzielić się tym, co myślę na temat agile, również tym, gdzie mam tylko przeczucia i się mogę mylić. Chętnie porozmawiam z Tobą o tym w komentarzach.

Wpisy będą mocno różnorodne – krótkie przemyślenia z jakiegoś bieżącego doświadczenia z mojej pracy, inspiracja z rozmowy czy konferencji a wreszcie pisemna odpowiedź na często zadawane pytania.

OK, to startujemy.