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.

Oprócz tego wiedzieliśmy, że podobnego typu warsztat, ale bardziej dostosowane do potrzeb biznesowych, potrzebujemy dla grona wspólnego z biznesem. Zebraliśmy na nim top managerów po stronie biznesowej, to nie były osoby z Zarządu, ale szczebel niżej lub dwa szczeble niżej pod Zarządem. Kryterium doboru było takie, że szukaliśmy w miarę możliwości menedżerów najbardziej zaangażowanych w realizację projektów, które potem wdrażane są w IT. Struktura banku odbiega od typowej organizacji produktowej i nie ma jednego miejsca, w którym generowane są pomysły na rozwój system, więc wybór był trudny – tutaj bardzo nam pomogła wiedza o organizacji najdłuższych stażem managerów IT. Ja czy szef IT wtedy nie byliśmy jeszcze aż tak bardzo zorientowani, nie byliśmy dostatecznie długo w firmie. Dobraliśmy tą grupę (różne osoby z biznesu i kilku menedżerów z IT), zorganizowaliśmy warsztat ponownie z Tomkiem Włodarkiem. Przy realizacji tego warsztatu pojawiło się trochę kontrowersji i nie ma co kryć, temat mógł wypaść lepiej. Przede wszystkim takie grono managerskie wyższego szczebla biznesowego potrzebowało (w porównaniu do naszych założeń) znacznie więcej dyskusji o konkretnych rozwiązaniach, jakie są zawarte w podejściu zwinnym, a mniej skorzy byli do dyskusji o wartościach, jakie są związane z agilem czy Scrumem. Chcieliśmy przekazać im sporo rzeczy z poziomu wartości, ale zostały one odebrane jako filozofowanie. Dla nich to podejście zwinne wtedy było na tyle nowe, że potrzebowali więcej wyjaśnień, jeśli chodzi o warstwę praktyk. Warsztaty i tak i tak były inspirujące dla wielu, ale pozostał pewien niedosyt. Nie ma tego złego, co by na dobre nie wyszło – przynajmniej ten niedosyt był bazą do tego, żeby realizować kolejne rundy przekazywania wiedzy i z poszczególnymi osobami można było się dodatkowo spotkać, by jakieś brakujące elementy układanki przekazać bezpośrednio. Część z tych osób potem dotarła na szkolenie z podstaw Scruma, co fajnie dopełniło program (najpierw poziom menedżerski, potem szczegóły Scruma wraz z konkretnymi zespołami).

Samo to wydarzenie akurat jest dla mnie przestrogą, że taki szczebel wyższego managementu może potrzebować bardzo dopasowane do siebie szkolenia z agile i przyznam szczerze, że takiego szkolenia jeszcze nie widziałem. Szkolenie z podstaw Scruma lubi skupiać się na szczegółach mechaniki scrumowej, co dla poziomu menedżerskiego nie jest tak istotne. Z drugiej strony szkolenie o wartościach łatwo odebrać właśnie jako filozofowanie, jako coś takiego już odpływającego od pragmatyki biznesowej. Jest na pewno miejsce na rynku na szkolenie ze zwinnej organizacji, ale dokładnie z perspektywy konkretnej praktyki menedżerskiej. Sam chętnie bym takie szkolenie z jednej strony przeżył, a z drugiej strony poprowadził, gdyby tylko była taka okazja. Gdybym na dzisiaj miał złożyć taki program, zawarłbym podstawy manifestu, ale z naciskiem na 12 zasad w praktyce dla managera. Kolejny temat to wsparcie dla zespołu scrumowego, zwłaszcza perspektywa potrzeb Scrum Mastera i takie zrozumienie jego roli, by umieć mu efektywnie pomóc. W takim szkoleniu menedżerskim też miejsce na jakąś cząstkę Managementu 3.0, ale nie przesadzałbym z tym aspektem, bo widzę, że coraz mocniej kojarzy się on z zestawem sztuczek menedżerskich (mapy, boardy, itp.), a nie szerszej koncepcji tego, że zasady zarządzania się zmieniają. Ostatni element, który zawarłbym w takim szkoleniu, a który w Polsce na razie jest mało popularny, to koncepcja Beyond Budgeting, filozofii zarządzania całą organizacją zainicjowaną w świecie finansów i opartą na założeniach bardzo przypominających agile.

Wracając do konkretnej historii mBankowej, warsztat z biznesem, mimo, że było kilka rzeczy, które można było zrobić lepiej, odniósł najważniejszy efekt – celem warsztatów było zbudowanie świadomości, że pewne zmiany w organizacji są potrzebne, że wsparcie biznesowe jest niezbędne i tu akurat bez problemów udało się na koniec warsztatów uzyskać zaangażowanie i deklarację do tego, że pierwsze próby Scrumowe będą wsparte.

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ą ;).

Program jakiego używam w mBanku jest mocno autorski w tym sensie, że założyłem zasadę pustej kartki, więc to nie są slajdy przetłumaczone, skopiowane, przeniesione, czy nawet inspirowane przez jakieś konkretne szkolenie. A byłem na wielu, na samych szkoleniach z podstaw Scruma byłem na szkoleniu Certified Scrum Master w 2009 roku u Angeli Druckman, pół roku później u Dana Rawsthorne’a. W 2011 roku w czasie transformacji zwinnej w Allegro wziąłem udział w Professional Scrum Product Owner u Tomka Włodarka, a w kolejnym roku uczestniczyłem w szkoleniu Professional Scrum Foundations Tomka jako pomocnik w moderowaniu ćwiczeń i gość, który mógł z boku trochę pokomentować, gdy pojawiały się jakieś pytania o transformację Allegro. Scrumowo najmocniejszym przeżyciem było szkolenie Certified Scrum Master u Jeffa Sutherlanda, który sam Jeff nazywał raczej zaawansowanym Scrumem, niż podstawami Scruma. Nie wymieniam tego, żeby się chwalić, ale żeby pokazać, że szkoleń o Scrumie widziałem parę jako uczestnik i każde dało mi okazję z jednej strony zobaczyć warsztat trenerski, a z drugiej każde kolejne było okazją do przemyślenia, odświeżenia, wypolerowania sobie wiedzy o Scrumie jako takim.

Ale moje szkolenie nie jest kopią, ani jakimś miksem żadnego z tych kursów. Filozofia tego warsztatu wraca do pewnego krótkiego szkolenia w Allegro, gdzie zaeksperymentowałem z koncepcją opowiedzenia Scruma przez pryzmat problemów, jakie Scrum rozwiązuje – w metodzie zaszyte są pewne praktyki, które rozwiązują typowe problemy podejścia tradycyjnego. Na warsztacie miałem nietypowy zespół, który chciał się dowiedzieć czym jest Scrum i zamiast im tłumaczyć jak zwykle, zacząłem od wypytania z jakimi problemami stykają się przy realizacji projektów. Tak się jakoś dziwnie samo złożyło, że wszystkie problemy przez nich wymienione stały się szkieletem zdefiniowania Scruma. Dosłownie to się działo na whiteboardzie, na którym dopisywałem kolejne elementy frameworka jako odpowiedź na ich problemy z codziennego życia projektowego. Oni wymieniali m.in. problemy komunikacyjne, problemy z priorytetami, problemy ze sformułowaniem wymagań, a ja im pokazałem po kolei Product Backlog i Przyrost, Planowanie Sprintu, a z drugiej strony ewentualne odkrycie na Review, że się nie dogadaliśmy itd. No i koncepcja bardzo zażarła, w tym sensie, że zarówno ja jak i uczestnicy byliśmy zadowoleni z jasnego wytłumaczenia i łatwości z jaką przebiegł ten warsztat.

Gdy dołączyłem do mBanku postanowiłem zaeksperymentować z tą formułą jako kompletnym sposobem na szkielet warsztatu. Całkowicie zrezygnowałem z podejścia “klasycznego”, że tak to nazwę Scrum “po kolei”: zacznijmy od ról, no to role: pierwsza, druga, trzecia rola; no to teraz zdarzenia: pierwsze, drugie, trzecie, czwarte zdarzenie; no to teraz artefakty: pierwszy, drugi, trzeci artefakt; teraz jakiś temat zaawansowany, dyplom, ankieta, koniec! W takim podejściu moim zdaniem strasznie ciężko jest zdefiniować poszczególne elementy Scruma bez definiowania “nieznane przez nieznane”. Scrum Master to jest ten, kto pracuje z Product Ownerem, a kto to jest Product Owner? Coś, co ja zastosowałem, to takie rozsupłanie Scruma nie rola po roli, zdarzenie po zdarzeniu, tylko problem po problemie, jaki mamy w projektach. Stąd zaczynam od sformułowania tematów zarządzania produktem, potem wprowadzam temat pracy zespołowej, potem jest temat ciągłego usprawniania, potem jest temat realizacji projektów no i na końcu jest miejsce na tematy zaawansowane np. skalowanie, ale to już często bardzo wynika z konkretnej potrzeby szkolonego zespołu.

Szkoleń po dołączeniu do mBanku robiłem bardzo dużo, pewnie doliczył bym się kilkudziesięciu szkoleń poprowadzonych, co pozwoliło w krótkim czasie pokombinować z różnymi ćwiczeniami, z różnymi formułami instrukcji i dopracowywać slajdy, zwrócić uwagę na rozłożenie akcentów, rozłożenie kolejności przekazywanej wiedzy. Pozwoliło to też reagować na to co wyglądało, że zostało przekazane niejasno albo pojawiało się w feedbackach jako słabszy fragment. Najmocniejszym feedbackiem było zjawisko zbierania swoich własnych owoców poszkoleniowych. Gdy najpierw szkoliłem, a potem osobiście coachowałem (po prostu byłem jedynym coachem w całej organizacji), bardzo łatwo mogłem dostrzec to, jak niedoskonałości moich pierwszych szkoleń później było widać w zespole. Na przykład temat retrospektywy, żeby ukonkretnić opowieść. Dla mnie samego retrospektywa była dosyć oczywista, stąd jak przyszedł czas na ten temat na szkoleniu, no to w zasadzie w skrócie opowiedziałem, że trzeba to robić i dzięki temu się ciągle usprawniamy. Porównywalnie o wiele więcej czasu i uwagi skupiałem na tematy backlogów, Ownera, roli Scrum Mastera, prognozowanie realizacji projektu. Potem docieram do pierwszego zespołu, który przeszkoliłem, który dzięki mojemu szkoleniu spróbował wykorzystać Scruma i spotykam ścianę. Nie wiedzą jak zrobić retrospektywę, więc najprostsza reakcja, jak nie wiemy, jak coś zrobić to tego nie robimy. Gdy szkoliłem kolejny zespół, już wzmocniłem w swoim programie temat propozycji konkretnych technik retrospektyw, podpowiedź starfish diagram i timeline, tak żeby umieli zastosować to na początku swojej pracy, na początku swojej drogi ze Scrumem. Kolejna kwestia, która najwyraźniej nie wybrzmiewała na moich szkoleniach to retrospektywa jako element obowiązkowy w każdym sprincie. Pierwsze zespoły miały ochotę robić retrospektywę wtedy gdy trzeba, a nie co sprint. Zwłaszcza startującemu zespołowi naprawdę nie uwierzę, że nie potrzebuje robić retrospektywy co sprint, ale w kolejnych warsztatach zwracałem uwagę na jakieś wzmocnienie tematu jak bardzo retrospektywa jest potrzebna co sprint.

Oczywiście nadużyciem byłoby stwierdzenie, że dzięki wypolerowanym warsztatom ludzie przeze mnie przeszkoleni idealnie od pierwszego sprintu będą realizować Scruma, ale wiem, że warsztat ma dobry szkielet, który uzupełniam ciągłymi usprawnieniami, dzięki temu, że mogę też zbierać feedback z prawdziwego zastosowania w praktyce tego, co uczę.

 

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.