Czy Scrum Master / Agile Coach musi się tłumaczyć z tego, co robi?

Tak, SM (a dotyczy to praktycznie w tym samym stopniu Agile Coacha) musi się tłumaczyć przed całym zespołem i firmą z tego co robi – w tym sensie, że musi wytłumaczyć pozostałym członkom zespołu swoją rolę, swoje zadania, swój dzień pracy. Zwłaszcza, jeśli zespół czy firma są nowi w temacie albo nieprzekonani – wtedy nieznajomość roli SMa prowadzi do uproszczenia „nic nie robi, jest niepotrzebny”. I nie ma co jako Scrum Master brać do siebie tego, że zespół będzie sceptyczny do naszej roli albo nisko oceniał pracę takiego SMa (zwłaszcza tą niewidoczną) – jak nie rozumieją to trzeba wytłumaczyć, a jak nie widzą efektów pracy, może trzeba unaocznić.

Czytaj dalej Czy Scrum Master / Agile Coach musi się tłumaczyć z tego, co robi?

Refleksje po Agilii17

Wczoraj skończyła się Agilia’17, w której wziąłem udział jako uczestnik. Na agile247.pl na dniach wypuszczę poukładaną relację z najlepszych prezentacji, a w tym wpisie parę refleksji osobistych. Podobnie jak z Zarządzania Zespołami IT, wrzucam te przemyślenia kompletnie bez priorytetyzowania, świadomy że wychodzi z tego miszmasz o skalowaniu, roli agile coacha, transformacjach i korzystania z konferencji jako takich.

Czytaj dalej Refleksje po Agilii17

3 rodzaje postaw na spotkaniu

Wyobraźcie sobie spotkanie społecznościowe, na które przychodzi duża ilość osób i w zamierzeniu ma dochodzić do dyskusji, wymiany doświadczeń, wzajemnego dzielenia się inspiracjami. Świetnie trafiła do mnie teoria, którą przyniósł mi Adam Kwiecień z pewnego wydarzenia – na czymś takim są 2 rodzaje ludzi: Ci którzy są skupieni na tym, żeby posłuchać i tacy którzy są skupieni na tym, żeby mówić. Gdy przegadywaliśmy sobie to, dookreśliliśmy jeszcze trzecią grupę: Ci, którzy mówią po to, by po wszystkim sprzedać Ci swoją usługę („… a tak w ogóle to jestem coachem, oto moja wizytówka”).  Spotkanie tego typu wyjdzie tylko wtedy, gdy znaczna przewaga obecnych zainteresowana jest przede wszystkim słuchaniem i będzie totalną klapą, jeśli pojawi się choć mała część tych drugich i trzecich, których słuchanie nie interesuje, za to czekają tylko na to, by dołożyć coś do dyskusji.

Czytaj dalej 3 rodzaje postaw na spotkaniu

Nie przejmuj się za zespół za bardzo

W ramach toczących się transformacji, przy pracy z poszczególnymi zespołami czy częściami firmy Agile Coach ma duże ryzyko wpadnięcia w bardzo łatwą pułapkę pomagania swoim podopiecznym, wyręczania ich z pewnych działań. Mówię ogólnie, ale sam też mam to zjawisko, widzę je u osób, z którymi współpracuję czy rozmawiam. Na przykład mam na myśli moment, w którym widzę, że zespół nie dogaduje się z jakimś wysoko postawionym interesariuszem. Zespół i efekty jego pracy ewidentnie cierpią, na osąd coacha jest to aktualnie największy problem, jaki blokuje zespół i wpływa na szereg kolejnych negatywnych zjawisk. Widząc taką sytuację mam dylemat – pomóc osobiście (porozmawiać z interesariuszem, zrobić jakiś warsztat albo szybkie ćwiczenie) czy znaleźć jakieś inne rozwiązanie, takie które przenosi odpowiedzialność za sytuację na zespół, SMa, PO, może czasem menedżera zespołu. Czytaj dalej Nie przejmuj się za zespół za bardzo

Dlaczego Scrum Master nie powinien być pośrednikiem

W czasie ostatniego spotkania na Zwinnej Łodzi, na której prezentowałem swoją opowieść o ścieżce kariery agilowej, dostałem bardzo dobre pytanie: „a tak w zasadzie, to co jest złego w tym, że Scrum Master bywa pośrednikiem między firmą a zespołem” . Chodziło o mój przykład życia, gdy odradzam z własnego doświadczenia by SM brał na siebie odpowiedzialność za na przykład raportowanie statusu projektu, koordynowanie prac pomiędzy zespołami czy przynoszenie do zespołu jakichś nowych wytycznych z organizacji i wdrażanie ich.

Pytanie jest o tyle dobre, że sięgało do istoty problemu, obaj z pytającym zgodziliśmy się, że samo stwierdzenie „Scrum Guide tak każe” nie jest dla nas wystarczające.

W temacie przychodzą mi do głowy trzy kwestie merytoryczne:

  1. Usuwanie pośredników – usuwanie głuchego telefonu którego istnienie jest często nieświadome, a każde kolejny szczebel przekazywania informacji bezwiednie zmienia niuanse komunikatu. Stąd SM powinien dążyć do tego, żeby różnego rodzaju komunikaty do i z zespołu przechodziło bezpośrednio między nadawcą a odbiorcą. Chcesz się dowiedzieć jaki jest status prac – przyjdź na review. Albo zajrzyj w backlog poprzednich sprintów. Chcesz żeby zespół coś dla Ciebie zrobił – przyjdź do nas na planning, pozwól się zaprosić na retro.
  2. Budowanie odpowiedzialności w zespole – taka inspiracja „Scrum Mastery” żeby być SMem, który rozwija cały zespół w odpowiedzialności za całość produktu, nawet jeśli oznacza to „kłopotanie” zespołu rzeczami innymi niż development. Moim zdaniem ślepą uliczką jest odciążanie zespołu od tych innych rzeczy (raporty, komunikacja, itd.) – w długim okresie czasu takie rzeczy należy optymalizować (nie powiem usuwać, bo to może być zbytnie uproszczenie), w krótkim nie chować, nie plastrować.
  3. Nie branie na siebie nie swojej odpowiedzialności – SM (zwłaszcza z korzeniami menedżerskimi albo PMowymi) może mieć ochotę wykazać się w zespole i przejąć tematy koordynacyjne. Niektóre z nich bardziej pasują do zestawu odpowiedzialności Product Ownera (praca z interesariuszami, odpowiedzialność za decyzje w produkcie), inne powinny być w całym zespole (dbałość o jakość, znalezienie sposobu na współpracę pomiędzy zespołami). SM zabierający na siebie te odpowiedzialności, zwłaszcza robiąc to niejawnie, osłabia role innych członków zespołu, jednocześnie zaburzając czystość swojej odpowiedzialności w Scrumie. To zaburzenie czystości swojej roli może być szczególnie spotęgowane, jeśli otoczenie zespołu (management, inne zespoły) zacznie traktować Scrum Mastera jako przedstawiciela zespołu w różnych sprawach, które do niego nie należą i wzmacniać nieoptymalny układ. W skrajnym przypadku prowadzić to może do zupełnie złego wykształcenia roli i odpowiedzialności Scrum Mastera w firmie.

I jak o tym piszę, to ostatnia refleksja – każdy z tych punktów jest nadal równie prawdziwy a może jeszcze prawdziwszy dla roli Agile Coacha…

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.