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.

Czytaj dalej Wicedyrektor do spraw – rozwiewanie mitó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.

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

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.