We wpisie o tym co robię jako agile coach wewnątrz organizacji wspomniałem o tym, że wspieram zespoły. Teraz chciałbym jeszcze bardziej szczegółowo opisać co to dokładnie znaczy. Trzymając się nadal bardziej ogólnej perspektywy – wsparcie zespołów polega głównie na tym, żeby pomagać zespołom startującym z wykorzystaniem danej metody, którą ten zespół wykorzystuje (startowaliśmy zazwyczaj od Scruma, ale w paru zespołach stosowany był też Kanban).
Agile Coach upewniał się, że zespół jest przeszkolony (a jak nie – organizowaliśmy warsztat albo dołączaliśmy brakujące osoby do najbliższego terminu szkolenia z podstaw). Zespół wspierany był szeroko – nie tylko wsparcie na poziomie developerów, ale najczęściej w ramach rozmowy o potrzebach włączani do działań byli też menedżerowie zespołu, czy menedżerowie powyżej Product Ownera. Pierwsze próby wsparcia zespołów z banku pokazały, że menedżer odgrywa bardzo istotną rolę w transformacji – może mocno wesprzeć, postawić dobre oczekiwania, wyjaśnić kontekst zmieniania podejścia do pracy. Ale może też torpedować wysiłki Agile Coacha, Scrum Mastera i zmieniającego się zespołu, jeśli w żadnym stopniu nie zmieni swoich postaw i wymagań (np. co do wyceniania zadań, osobistego rozliczania poszczególnych członków zespołów za wykonaną pracę, podważanie sensu transformacji). Potrzebna zmiana takich postaw powoduje, że część czasu Agile Coach spędza również pracując z menedżerem – pracując razem nad słabościami, dzieląc się obserwacjami i planując wspólnie skoordynowane działania zmieniające zespół i jego otoczenie. Zignorowanie menedżera i pomijanie pracy z nim w szczególnych przypadkach prowadziło do działań, które wyglądały na ratowanie swojej pozycji, próby wykazania się w sposób który już kompletnie nie był potrzebny (np. próby koordynowania pracy w zespole albo wpływanie na jego rozwiązania jako coś lepszego od samoorganizacji). Dostrzeżenie takich odruchów może też uruchomić szereg dalszych rozmów – bo być może menedżer zespołu zachowuje się tak a nie inaczej, ponieważ przełożony przełożonego wykonuje jakieś działania niezgodne z tym, dokąd zmierzamy jako zwinna organizacja. Agile Coach od czasu do czasu wstępował też z jakimś konkretnym tematem do osób na wyższym szczeblu, delikatnie sygnalizując potrzebne zmiany postępowania albo wskazując potrzebę wsparcia przez wyższy management przy szczególnie skomplikowanych blokerach efektywności.
Z samym zespołem na początku Agile Coach pracuje głównie w trybie mentora i nauczyciela. Przekazuje podstawy metod, dzieli się propozycjami i wskazówkami bazującymi na jego doświadczeniu na temat tego, jak spróbować zacząć pracować – i w porozumieniu z zespołem rozpocząć pracę na pierwszymi potrzebnymi usprawnieniami. Idealnie taki sposób działania to rola Scrum Mastera, ale w zespole, w którym wszyscy są początkujący, z SMem włącznie, Agile Coach uzupełnia takie braki kompetencji. A można powiedzieć, że w tych pierwszych krokach jest de facto Scrum Masterem – tylko działającym z pełną świadomością tego, że będzie funkcjonował wyłącznie kilka sprintów, w czasie których wybrana przez zespół osoba musi przejąć te odpowiedzialności i pociągnąć zespół dalej już bez tak silnego wsparcia. Ważne, by na tym etapie Agile Coach nie zgubił priorytetu na potrzeby zespołu – nawet w pierwszym sprincie, gdy zespół jeszcze nie będzie wiedzieć jak poprawnie realizować Daily, będzie już umiał powiedzieć co jest dla niego priorytetem w sposobie funkcjonowania, jakie metody chcą spróbować a jakich nie kupują. Agile Coach musi umieć zignorować część wiedzy jaką ma (gdy pracował z zaawansowanymi zespołami, dużo się naczytał i naoglądał) i odkrywać ten świat zwinności od najbardziej podstawowych poziomów, asystować w rozwoju zespołowi a nie próbować go na siłę („na sterydach”) przeprowadzić zbyt wcześnie w zbyt zaawansowane poziomy.
Gdy zespół zacznie się czuć swobodniej w poziomach podstawowych (pewnie zajmie im to parę sprintów) Agile Coach może zacząć włączać mocniejszą postawę coachingową. Zazwyczaj AC wewnętrzny z konkretnym zespołem pracuje maksymalnie tylko kilka miesięcy i w drugiej części takiego okresu musi uruchomić w zespole świadomość (śmiałość do) tego, że takimi praktykami jak głęboka Retrospektywa Sprintu, z dobrym wsłuchaniem się w swoje potrzeby, można rozwiązywać wszystkie problemy i w trybie ciągłym usprawniać pracę zespołu – bez żadnych konkretnych podpowiedzi od doświadczonego Agile Coacha.
Swoją drogą – jeśli potrzebujesz poprawić to, jak realizowane są popularne „retro” w twoim zespole i osiągnąć to wyżej nazwałem „głęboką Retrospektywą”, to polecam Twojej uwadze webinar Porządna Retrospektywa Sprintu mojego współautorstwa, który jest już w sprzedaży.
Zespoły, które zaznajomią się z podstawami i będą je stosować, są w stanie na ich bazie zacząć budować swoje własne podejście, samemu odkrywać metody i narzędzia a może nawet tworzyć jakieś własne. Rolą Agile Coacha może być zwrócić zespołowi na to uwagę, a jeśli sami zasmakują korzyści z tego, w zasadzie zewnętrzne wsparcie może przestać być im potrzebne poza wyjątkowymi sytuacjami. Na takich etapach największym wyzwaniem w roli Agile Coacha jest wytrwać w obserwowaniu pierwszych prób samodzielnego kreowania sposobu działania, nawet jeśli ma się jakiś konkretny pomysł, który w dodatku na bazie doświadczenia można założyć, że się sprawdzi. AC, który ciągle będzie trwał w trybie konsultanta/nauczyciela i nie przełączy się w obserwację i prowokowanie do myślenia samodzielnego, może przegapić okazję i uzależnić zespół od siebie. Coach odejdzie od takiego zespołu do jakiegoś nowego, a konstrukcja dotychczasowa może się łatwo i spektakularnie rozsypać – zespół nie był przygotowywany na samodzielne funkcjonowania, bez wsparcia mentora.
Agile Coach oprócz wskazywania konkretnych narzędzi i uczenia ich stosowania samodzielnie może też wspierać zespoły w rozwiązywaniu impedimentów. Podobnie jak w poprzednim akapicie, idealnie by było, żeby Coach nie zmieniał firmy osobiście (osobiście chodził za jakimś problemem, pilotował i nakręcał zmianę z własnej inicjatywy) tylko raczej pokazywał jak zmianę skutecznie w firmie przeprowadzić. Agile Coach może pomóc przemyśleć przygotowanie się do rozwiązania jakiegoś dużego problemu (np. pomóc zebrać dane, przemyśleć strategię, zbudować koalicję kilku zespołów, które mają identyczny problem). Może też wykorzystać posiadane znajomości w organizacji, by razem z zespołami dotrzeć do osób, które mają wpływ na rozwiązanie problemu. Ważne by zespołów nie wyręczać, nawet jeśli miałoby się poczucie większego sprawstwa i szybsze efekty. Powtórzę się – tu i teraz może i rozwiążemy temat, ale tracimy okazję do zbudowania umiejętności samodzielnego rozwiązywania problemów przez zespoły w przyszłości. Można zrobić to razem, można pobudzać inicjatywę, pokazywać, że zmiany są potrzebne i możliwe, ale niech Agile Coach nie stanie się najbardziej przejmującym się człowiekiem w firmie – bardziej niż Ci, których dany problem faktycznie boli (albo powinien boleć).
Agile Coach pracując z danym zespołem wewnątrz organizacji w ramach kilku miesięcy wsparcia przejdzie z trybu nauczyciela/mentora, przez współpracownika aż do poziomu coacha wspierającego zespół w samodzielnej pracy i doskonaleniu swoich metod. Dobrze na początku współpracy zakontraktować z zespołem takie podejście, uświadomić wszystkim, że rola AC jest przejściowa i będzie ewoluować. Zespoły z którymi współpracowałem ceniły sobie przejrzystość w stosowanych przeze mnie trybach (co oferowałem, by nie wzbudzać zdziwienia, gdy nagle przestawałem dawać podpowiedzi tylko zaczynałem zadawać pytania). Agile Coach, który już opuścił dany zespół najczęściej pozostaje skumplowany z całą drużyną i od czasu do czasu może być poproszony o wsparcie jednostkowe (jakieś trudne retro, rozpoczęcie dużej nowej inicjatywy, realizacja czegoś, czego zespół jeszcze w ogóle nie robił). W takich sytuacjach dużą satysfakcję daje możliwość obserwowania dojrzałego już zespołu, który świetnie radzi sobie z tym, co w pierwszych sprintach było prawie niemożliwe do zrealizowania.
PS. Ten wpis planowałem jako rozszerzenie bardzo starego wpisu przygotowanego jeszcze w czasach, gdy byłem w mBanku. Odświeżyłem go, bo akurat tak się składa, że (mój już były) zespół Agile Coachów szuka nowej osoby do Warszawy. Jeśli interesuje Cię praca m.in. w takim trybie jaki opisałem wyżej, zaaplikuj i daj sobie szanse poznać Agę, Marzenę, Adama i Bartka.
PS2. O roli Agile Coacha rozmawiamy też z Jackiem w piętnastym odcinku podcastu „Porządny Agile” http://porzadnyagile.pl/015-kto-to-jest-agile-coach/?utm_source=ks_ac
dziękuję za ten wpis, bo realnie wyjaśnia również różnicę między SM a AC.