Można znaleźć sporo informacji o mnie czy to na stronie Code Sprinters, czy w Scrum.org, czy też na LinkedIn, ale pozwalają one dowiedzieć się przede wszystkim, jakie mam doświadczenie, certyfikaty itd. Nie można tam natomiast znaleźć informacji o tym, jak właściwie prowadzę szkolenia. Postanowiłem więc o tym opowiedzieć. Mam nadzieję, że w ten sposób ułatwię potencjalnym uczestnikom moich szkoleń podjęcie decyzji: zapisać się, czy uciekać z krzykiem.

Podzieliłem tę opowieść na szereg sekcji, z których każda opisuje to, co wydało mi się istotne. Ten wybór jest oczywiście całkowicie subiektywny, a kolejność sekcji nie jest determinowana priorytetem czy ważnością, tylko dążeniem do logicznego uporządkowania (pogrupowania?) tego, o czym piszę.

1. Nie jestem ewangelistą

O ile mocno wierzę w sens tego, o czym mówię na szkoleniach, nie staram się przekonywać o wyższości Scruma czy Kanbana nad innymi podejściami i metodami. Każdy sam musi zdecydować, z czego będzie korzystał, a moim celem jest dostarczyć wiedzę, która tego wyboru pozwoli dokonać.

Zdarza mi się oceniać takie czy inne działanie, o którym dyskutujemy z uczestnikami na szkoleniach, jako mało sensowne lub wręcz szkodliwe (albo po prostu głupie). Przy czym ocena taka nigdy nie wynika z uznania, że coś nie powinno być robione, bo „nie jest to Scrum”. Chodzi zawsze o brak efektywności działania i jego skuteczności.

2. Jestem pragmatykiem

Mój brak ciągot do ewangelizowania wynika z traktowania wszystkiego, o czym opowiadam jako narzędzi. Narzędzia działają, jeśli użyte są do tego, do czego powstały i jeśli są użyte w sposób, w jaki powinny być używane. Tylko tyle i aż tyle.

Jestem być może przyziemnym pragmatykiem i – co gorsza – tym przyziemnym pragmatyzmem świadomie zarażam uczestników szkoleń. Chciałbym bowiem, by nie traktowali oni Scruma lub Kanbana jako filozofii życiowej, czy nieomal religii. Scrum i Kanban nie wymagają wiary w ich działanie, ale zrozumienia, w jaki sposób działają i zapewnienia warunków niezbędnych do tego, by mogły zadziałać.

3. Uważam, że celem każdej organizacji jest kreowanie korzyści

To wynika ze wspomnianego już pragmatyzmu. W definicjach różnych metod i podejść, a także w dyskusjach o nich, na wszystkie sposoby odmieniane jest słowo „wartość”, ale często staje się ono nic nie znaczącym, abstrakcyjnym terminem, w najlepszym razie przekuwanym na „wytworzyć jak najwięcej tego, co tu robimy”.

Kreowanie korzyści, o którym piszę, to coś więcej niż tylko kreowanie tej jakkolwiek definiowanej, mniej lub bardziej abstrakcyjnej wartości. To zdolność uzyskiwania wartości, która przynajmniej rekompensuje koszty jej wytworzenia, a najlepiej daje jeszcze coś ponadto.

Oczywiście nie musi się to przekładać na pieniądze, bo są korzyści niefinansowe (np. rozwiązanie jakiegoś problemu społecznego). Ale często i to przecież oznacza realnie uzyskanie pieniędzy na to, by móc prospołeczne działania kontynuować.

Dlaczego o tym wspominam? Bo często w dyskusjach o takim czy innym podejściu, metodzie lub praktyce pojawia się kwestia tego, co to znaczy, że one są „dobrze użyte”. I staram się zainspirować do takiego oto definiowania tej „dobroci”: używane są tak, jak zostały zdefiniowane, świadomie i (to ważne a często pomijane!) dają korzyści tym, którzy je stosują.

4. Opowiadam o swoich doświadczeniach

Byłem Scrum Masterem, Developerem, Product Ownerem (choć nigdy oficjalnie), managerem, leaderem Zespołów. Pracowałem w ciężkim Waterfallu, różnych metodach projektowych, mniej lub bardziej kulawym Agile (w tym w Scrumie), w Kanbanie…

Dlaczego to ma znaczenie? Bo nie jestem teoretykiem i zanim zacząłem szkolić, faktycznie tego, o czym mówię na szkoleniach, sam używałem. Daje to mi pewną łatwość w dogadaniu się z uczestnikami o naprawdę różnych doświadczeniach (choć nie zagwarantuję, że z każdym się dogadam – aż tak dobrze nie ma).

5. Opowiadam anegdoty

To być może największa korzyść z tego mojego doświadczenia. Praktycznie na każdym szkoleniu opowiadam historię Zespołów, w których pracowałem albo z którymi się zetknąłem już jako trener czy konsultant. Czy jestem gadułą? Pewnie trochę tak, ale nauczyłem się nad tym panować i dawkować opowieści i dygresje tak, by było ich w sam raz.

Tu warto dodać, że takie opowieści pozwalają uzupełnić suchą teorię przykładami, które czynią pojęcie omawiane na szkoleniu łatwiejszym do zrozumienia. Nie jest to więc tylko źródło inspiracji, ale też dobre narzędzie do pogłębienia wiedzy.

6. Mówię o mojej pracy w dobrze działającym Scrumie i Kanbanie

Miałem to szczęście, że udało mi się trafić do firm, gdzie metody, których uczę, były poprawnie używane i dobrze działały. Dzięki temu bez opierania się wyłącznie na wierze mogę powiedzieć: to naprawdę działa i nie jest wyłącznie teorią. Mogę też po prostu opowiedzieć o tym, jak taki dobry Scrum czy dobry Kanban wygląda. Oraz to, jak można taki stan osiągnąć.

7. Nie obiecuję cudów

O ile chętnie opowiadam o tym, jak dobrze działa sensownie użyty Scrum, albo jak Kanban pomaga w podniesieniu skuteczności działania Zespołów, o tyle nigdy nie obiecuję, że wszędzie jest to możliwe. Tu wracamy do pragmatyzmu, o którym już wspominałem.

W wielu organizacjach konieczna jest długotrwała walka ze status quo, trzeba zmagać się z osobami niechętnymi zmianie lub wręcz ją zwalczającymi. Zanim pojawią się jakieś korzyści z użycia nowoczesnych metod, mijają często miesiące. Dlatego na szkoleniach zachęcam do cierpliwości i stawiania sobie realistycznych celów.

W praktyce nigdy nie próbuję przedstawiać tego, o czym uczę na szkoleniach jako sposobów na osiągnięcie nieuchronnego sukcesu.

8. Czasami ściągam na ziemię marzycieli

Zdarza mi się pozbawić uczestników złudzeń, że użycie tej czy innej praktyki albo metody w ich organizacji będzie łatwe, albo w ogóle możliwe. Wyjaśniam też „do bólu”, na czym polega odpowiedzialność Scrum Mastera, Product Ownera i Developera.

Zdarza się, że po szkoleniach uczestnicy dzielą się ze mną refleksją, że w ich organizacjach „wszystko jest nie tak”. Staram się wtedy podpowiedzieć, od czego zacząć, przestrzegając przy tym przed próbą zorganizowania rewolucji, która zmieni wszystko na raz. Takie rewolucje nigdy się nie udają.

Bywa też, że uczestnicy odkrywają na moich szkoleniach, że nie chcą być Scrum Masterem albo Product Ownerem, choć wcześniej mieli takie plany. I cieszy mnie to, bo odpowiedzialność należy na siebie brać świadomie, rozumiejąc trudności, z jakimi może łączyć się wywiązanie z nich. Jeśli ktoś uznaje, że temu nie podoła albo że nie ma do tego motywacji, faktycznie powinien zająć się czymś innym.

9. Przestrzegam przed zgniłymi kompromisami i fundamentalizmem

Nie zawsze da się jakąś metodę albo praktykę zastosować w sposób, w jaki została ona zdefiniowana, bo na drodze stoją różne czynniki, z którymi najpierw trzeba coś zrobić. W tej sytuacji niektórzy stają się zbyt tolerancyjni, a inni zbyt wymagający w stosunku do rzeczywistości, w obu przypadkach z opłakanymi skutkami.

Na szkoleniach podpowiadam, jak radzić sobie w tym balansowaniu między nadmierną kompromisowością a fundamentalizmem. I tak np. Scrum Masterom odradzam zarówno bycie „misiem przytulasiem od robienia, żeby było miło”, jak i zbyt radykalne uznawanie, że coś, co nie jest Scrumem idealnym, nie jest nim w ogóle.

I podobnie postępuję na szkoleniach: nie chcę narzucać mojej wizji tego, jak coś powinno być robione, ale też jasno wskazuję, które pomysły uczestników są sprzeczne z omawianymi podejściami lub metodami. Niekoniecznie każdemu się to podoba, bo nie stronię od ironii (a może i sarkazmu), przez co nawet kiedyś dorobiłem się etykietki „despotyczny trener” od jednej z uczestniczek szkolenia. Dlatego czujcie się ostrzeżeni!

10. Nie pluję jadem na klasyczne metody projektowe i własne podejścia organizacji

A bardziej poważnie: nie w każdej organizacji i nie do każdego rodzaju pracy można z sensem zastosować metody obecnie popularne (Scrum, Kanban itd.). Niekoniecznie też „źle robiony Scrum” (czyli nie-Scrum) musi być bezsensowny i nieskuteczny (choć zawsze rodzi ryzyko marnowania możliwości uzyskania więcej).

Dlatego uczulam moich kursantów na to, że muszą rozumieć, kiedy i do czego warto stosować to, o czym mówimy, a kiedy może być to kontrproduktywne lub wręcz szkodliwe. Stąd np. nie tkwię w okopach dawno zakończonej (i mało sensownej) „wojny z Waterfallem” i nie mówię managerom projektów, że są zbędni.

Natomiast nie ukrywam, że odsądzam od czci i wiary pomysły, by łączyć podejścia predyktywne (projektowe) z podejściem zwinnym (empiryczne) w ramach jednego procesu – bo to wymaga działania na bazie dwóch fundamentalnie rozbieżnych założeń. Dałoby się taki pomysł opisać następująco: „ponieważ funkcjonujemy w domenie niestabilnej złożoności, gdzie nie da się wiele przewidzieć z góry, zaplanujmy na początek, co, kiedy i jak zrobimy”. Prawda, że to absurd? Ale próby łączenia ognia z wodą trwają.

11. Nie mówię językiem IT ani tylko o IT

Jeśli ktoś zerknął na mój profil LinkedIn, bez trudu zauważył, że pracowałem w domenie IT, choć niekoniecznie tylko w branży wytwarzania oprogramowania. Niektórzy obawiają się, że będę bełkotał w sposób zrozumiały wyłącznie dla Developerów. Niesłusznie.

W czasie szkoleń nie sięgam wyłącznie do przykładów IT i unikam posługiwania się językiem z obszaru software developmentu przy omawianiu poszczególnych zagadnień. Chcę, by to, o czym rozmawiamy, zostało dobrze zrozumiane przez wszystkich.

Co więcej, przykładami spoza IT posługuję się nawet wtedy, kiedy na szkoleniu są sami Developerzy i osoby z tej branży. Im szersze będzie rozumienie omawianych kwestii przez uczestników, tym przecież lepiej – niezależnie od tego, w jakiej domenie pracują na co dzień.

12. Często rysuję na tablicy

Absolutnie nie jestem mistrzem „fliopowania” (ba, wręcz przeciwnie), ale bardzo dużo rysuję na szkoleniach i udostępniam moje bohomazy uczestnikom po zajęciach. Robię to zresztą na ich prośbę. Te moje koślawe wizualizacje doskonale nadają się bowiem do kilku rzeczy.

Po pierwsze, pozwalają lepiej zrozumieć to, o czym mówię – większość osób potrzebuje czegoś więcej, poza słuchaniem, by przyswoić omawiane pojęcia. Rysowanie pozwala mi też unikać posługiwania się slajdami (mało kto lubi się na nie gapić) oraz tworzyć na żywo wizualizację, krok po kroku, zamiast omawiać statyczny, już gotowy rysunek.

Po drugie, rysunki z tablicy stanowią „token”, który pozwala sobie po szkoleniu przypomnieć, o czym mówiliśmy, jeśli rzuci się okiem na grafikę (choćby tak marną).

Po trzecie, czasami zresztą uczestnicy odtwarzają fragment szkolenia (wraz z tworzeniem jakiejś wizualizacji) w swoich Zespołach, a łatwiej im to zrobić, gdy dysponują przykładem wytworzonym podczas zajęć przeze mnie.

13. Slajdów używam w ograniczonym stopniu

Szkolenia akredytowane np. przez Scrum.org mają gotowe slajdy, z których trener może korzystać. Ale nie musi. Dlaczego używam ich sporadycznie, tylko w tym zakresie, w jakim większy sens ma coś gotowego pokazać, niż samemu to rysować.

Natomiast wiele szkoleń własnych, które prowadzę, pozbawionych jest w ogóle slajdów. Nie znaczy to, że uczestnicy nie dostają ode mnie żadnych materiałów (o tym jeszcze napiszę później), ale po prostu nie posługuję się slajdami. Albo „flipuję” (nieudolnie, jak wyjaśniałem wcześniej), albo udostępniam materiały kawałek po kawałku – czy to w wersji elektronicznej (na szkoleniach online), czy jako fizyczne kartki (na szkoleniach stacjonarnych).

Oczywiście na koniec zestawy slajdów, jeśli istnieją dla jakiegoś szkolenia, zawsze udostępniam uczestnikom.

14. Mam swoje sposoby prowadzenia standardowych szkoleń

Warto wiedzieć, że szkolenia akredytowane np. Scrum.org są wszędzie takie same (jeśli chodzi o wiedzę, kluczowe materiały i schemat przebiegu szkolenia), ale nie są identyczne. Każdy trener robi je nieco inaczej.

Dlatego nie trzymam się kurczowo slajdów. Choć są naprawdę dobre, chcę korzystać również z własnych doświadczeń i tego, co wypracowałem z grupami wcześniejszymi.

Nie oznacza to, że pozwalam sobie na jakieś szalone eksperymenty. To bardzo mozolna ewolucja, polegająca na stopniowym zastępowaniu tego, co daje słabsze efekty tym, co pozwala uczestnikom wynieść ze szkolenia więcej.

15. Prowadzę szkolenia online z przekonania, a nie dlatego, że muszę

Gdy konieczne stało się prowadzenie szkoleń zdalnie, nie potraktowałem tego jako problem, tylko zbiór nowych możliwości. Bo całkiem serio uważam, że dla większości szkoleń formuła zdalna jest po prostu lepsza. Wyjątkiem są takie kursy, które skupione są na interakcji z ludźmi (np. nie bardzo wyobrażam sobie naprawdę dobre szkolenie z coachingu robione wyłącznie zdalnie).

Co dają szkolenia online, czego brak w szkoleniach stacjonarnych? Ot, choćby możliwość uczestniczenia z dowolnego miejsca. Można rozbić szkolenie na większą ilość dni, przez co żaden z nich nie jest nużący. Można smarować do woli po wirtualnej tablicy bez marnowania papieru i dać całą takie bohomazy każdemu z uczestników na koniec. Można robić wspólne notatki i udostępniać sporo materiałów elektronicznych.

Poza tym dziś wiele osób po prostu pracuje zdalnie, przynajmniej w jakimś wymiarze. Dlaczego szkolić miałyby się inaczej, niż pracują?

16. Udostępniam sporo materiałów dodatkowych

Poza standardowymi materiałami, jakie dają uczestnicy szkoleń wszyscy (oficjalne prezentacje, czasami książki, różne zbiory linków do zapoznania się z nimi itd.), daję uczestnikom moich szkoleń zdalnych kilka rzeczy mniej nieoczywistych.

Po pierwsze, do tworzonych wspólnie notatek dodaję całą masę komentarzy. Efektem jest spory e-book, który pozwala nie tylko odświeżyć sobie wiedzę w przyszłości, ale też ją poszerzyć. Bo z racji ograniczeń czasowych nie o wszystkim udaje się porozmawiać na szkoleniach. I nie da się z marszu odpowiedzieć na każde pytanie. Dlatego robię to właśnie w tych komentarzach.

O udostępnianiu moich bohomazów już wspominałem. Ale udostępniam też nagrania z sesji pytań i odpowiedzi, które odbywają się na koniec każdego dnia szkoleniowego. Oczywiście pod warunkiem, że uczestnicy zgodzą się na takie nagranie. To jest zdecydowanie coś, czego nie da się realnie zrobić w szkoleniu stacjonarnym.

17. Odpowiadam na wszystkie pytania

Wspomniałem o sesjach pytań i odpowiedzi, które odbywają się na koniec każdego dnia szkoleniowego. Rzecz jasna staram się odpowiedzieć na wszystkie pytania na bieżąco w trakcie szkolenia, ale często pojawiają się tematy wykraczające poza zakres materiału lub zbyt specyficzne, by zainteresować wszystkich. I na nie odpowiadam w ramach tych dodatkowych sesji albo pisemnie, w komentarzach zamieszczonych w notatkach.

18. Jestem dostępny również po zakończeniu szkoleń

Jeśli komuś sesji pytań i odpowiedzi mało, może do mnie napisać również po szkoleniu (mailem, albo poprzez czat, który udostępniam). Niekoniecznie reaguję natychmiast na przesyłane pytania, ale zawsze jakiejś odpowiedzi w końcu udzielę. Przy czym potem często te wymiany maili lub dyskusję na czacie przekuwam na wpisy na blogu (tak, to jedno z głównych źródeł mojej inspiracji).

19. Uczestnicy moich szkoleń polecają mnie znajomym

Od jakiegoś czasu zbieram informację na temat tego, dlaczego uczestnicy zapisują się na moje szkolenia. I choć byłem już nazwany „despotycznym trenerem” (chyba zafunduję sobie taką koszulkę), i zdarzają się osoby nieusatysfakcjonowane przebiegiem szkolenia, to jednak większość (i to zdecydowana) chwali je sobie (np. na moim profilu Scrum.org w sekcji „See What My Students Say”, albo w Code Sprinters na stronie z opiniami widać, co ludzie piszą po zakończeniu zajęć).

Dla mnie jednak najważniejsze są dwie rzeczy. Pierwsza, że wiele osób przychodzi do mnie na kolejne szkolenia. A druga, którą ujawniają zbierane dane, to fakt, że ponad połowa uczestników zapisała się, bo polecił im moje szkolenia ktoś, kto był u mnie na jakimś kursie. I to nie jest 51% tylko blisko 70%. Więc chyba nie jestem aż taki „despotyczny”, prawda?

20. Moi kursanci dobrze zdają egzaminy

Osobnym czynnikiem jest to, jak udaje się zdawać certyfikacyjne egzaminy uczestnikom moich szkoleń. Mam dostęp do takich statystyk i analizuję je na bieżąco po to, by zobaczyć, co mogę zrobić lepiej. Oczywiście nie jest tak, że wszyscy zdają za pierwszym razem, ale poziom zdawalności jest wysoki (ponad 80% przy pierwszym podejściu, w praktyce 100% za drugim podejściem).

Przy czym ja nigdy nie prowadzę szkoleń tak, by przygotować do egzaminu – bo to chybiony cel. Dążę do tego, by uczestnicy zrozumieli metodę, której zamierzają użyć, lub której już używają. Bo potrafili powiedzieć, czemu zasady w niej obowiązujące są takie, a nie inne, skąd wzięły się poszczególne elementy, co ma w niej sens, a co jest z tą metodą sprzeczne. Dzięki tej wiedzy i zrozumieniu, zdanie egzaminu nie jest wynikiem „wyuczenia się”, ale połączenia wiedzy ze zrozumieniem.

Oczywiście poza wiedzą dostarczam też zawsze podpowiedź, jak przygotować się dobrze do egzaminu i w jaki sposób poradzić sobie w jego trakcie.

Chcesz się zapisać do mnie na szkolenie?

Jeśli tak, listę aktualnie zaplanowanych terminów szkoleń publicznych, jakie prowadzę, znajdziesz zawsze tutaj. Rejestrując się na moje szkolenia z kodem 10MPRO, dostaniesz zawsze 10% zniżki od standardowej ceny.

(Kocia mordka na początku służy oczywiście przyciągnięciu uwagi, ale faktycznie mam koty i bardzo je lubię. A raczej, by być uczciwym, powinienem napisać, że to koty mają mnie).