Czego nie zrobiłem w 2017 roku

Jak zwykle spóźniony podsumuję w punktach rok 2017:

Co się udało:

Czytaj dalej Czego nie zrobiłem w 2017 roku

Nadal piszę – krótka aktualizacja

Wypadłem z rytmu pisania, a jak już wypadłem, to pozwoliłem sobie na dłuższą nieobecność. Co się wydarzyło w międzyczasie (i o czym prędzej czy później napiszę również na blogu):

  • Świetna konferencja Agilia Prague – dedykowany dzień konferencyjny tylko dla świata finansów, bardzo mięsiste prezentacje Barclaysa i Royal Bank of Scotland i wielkie zdziwienie dla mnie, że są inne banki, które podążają drogą adaptacyjnej ewolucji.

Czytaj dalej Nadal piszę – krótka aktualizacja

Warsztaty z agile dla menedżerów

Niedawno pisałem o sposobie na szkolenie z podstaw Scruma, jaki stosuję w mBanku. Warto wspomnieć, że jest jeszcze temat innego typu działań, które były realizowane w ramach rozwoju kompetencji zwinnych w organizacji. Najważniejsze dwie rzeczy które zrealizowaliśmy to warsztat dla managerów wyższego szczebla IT i warsztat dla biznesu. Była to odpowiedź na problem tego, że znajomość agile była niedoskonała. Warsztaty zorganizowaliśmy zaraz na samym początku transformacji, ze zrozumienia Scruma i agile, zwłaszcza z perspektywy managerskiej. Poprosiliśmy o to, by taki warsztat poprowadził Tomek Włodarek.

Na pierwszym z warsztatów (tych dla ścisłego grona kierownictwa IT) mieliśmy okazję do tego, żeby w gronie samych managerów IT przestudiować temat tego czym jest Scrum, jak wygląda zwinna organizacja, jakie kwestie są niezbędne do tego, żeby naszą firmę uzwinnić. Była to też świetna okazja do tego, żeby rozwiać szereg nieporozumień, jakie narosły wokół zwinności z racji dotychczasowych nieskoordynowanych działań szkoleniowych.

Czytaj dalej Warsztaty z agile dla menedżerów

Mów do mnie jak do labradora

Wczoraj miałem ciekawą rozmowę na temat szykującego się wydarzenia związanego z AgileHR. I o samym wydarzeniu już nic więcej nie powiem 🙂

W rozmowie uczestniczyła pewna mądra osoba, która przepięknie rozprawiła się z rozbudowanymi planami na wydarzenie, w ramach których organizator chciał uczestników zapoznać z koncepcjami złożoności, adaptujących się organizacji itd. Poradziła, aby skupić się na prostych sprawach, bardzo podstawowych, żebyśmy przypomnieli sobie czego potrzebowaliśmy, gdy byliśmy na początku swojej drogi agilowej (ja 8 lat temu potrzebowałem wiedzieć jak zrobić dobrze te storypointy…).

Złożyło mi się to z przeżyciem z warsztatów z agile dla HR które organizowałem w mBanku. Miałem (wraz z zespołem) podobny pomysł – koniecznie muszę przekazać Cynefin, on tak ładnie rozwiązuje wszystkie problemy tego, jak należy postępować. Uczestnicy(-czki) warsztatu wolały porozmawiać o tym, co konkretnie trzeba robić żeby być agile, jak to w praktyce wpływa na osoby, zespoły i całą firmę. Bez tych wszystkich skomplikowanych wymyślnych pojęć, teorii, nazwisk, cytatów.

W ostatnim tygodniu miałem też świetną interakcję z przedstawicielami zespołu, który właśnie puka do drzwi wyższych stanów zaawansowania swojej współpracy i rozmowa szła gładko, metafory, rady i pytania miękko siadały aż do momentu, gdy użyłem pojęcia „Scrum Studio” i uzyskałem komentarz „Wy coache zawsze macie swoje nazwy na różne rzeczy”.

Cały czas się uczę. I jeśli gdzieś jest jeden z moich obszarów do rozwoju, to właśnie w tym – mimo całej tej wiedzy o Cynefinie, zaawansowanych agile’ach, Nexusach, Flowach, Kanbanach – jak to zrobić, by dotrzeć do odbiorcy na jego poziomie, nie odstraszyć go trudnymi pojęciami. Jak dobrać prostą metaforę, jak ubrać jakieś zaawansowane koncepcje w proste ćwiczenie. Jak zachować cierpliwość do tego, że na pewne sprawy jest jeszcze za wcześnie na tym etapie rozwoju na którym jest mój rozmówca.

PS. Tytuł wpisu wzięty z polskiego tłumaczenia pewnej kwestii z filmu „Chciwość”. Czyli po angielsku „Margin Call”, gdzie w oryginale mowa o golden retrieverze 😉

Jak robię warsztat z podstaw Scruma

W ramach pracy nad kompetencjami mBanku przygotowałem autorski program szkolenia z podstaw Scruma i w ramach tego artykułu chcę się podzielić filozofią, jaka mi przyświecała przy jego tworzeniu. Gdy niedawno przygotowywaliśmy się razem do współprowadzenia “Podstaw Scruma” jedna ze Scrum Masterek zadała mi pytanie: “na podstawie czego ten program powstał”. Dla mnie to pytanie dotyka dość ważnej kwestii, czyli tego jaka jest konstrukcja szkieletu warsztatu, a może z jakiego innego szkolenia to szkolenie jest kopią ;).

Czytaj dalej Jak robię warsztat z podstaw Scruma

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.