Scrum Master w nowym zespole

Dołączenie do nowego zespołu może być stresujące nawet dla doświadczonego Scrum Mastera. Dzielimy się naszymi podpowiedziami na temat kroków, które warto uwzględnić, gdy zmieniamy zespół i rozpoczynamy pracę w roli Scrum Mastera, nawet już z niemałym bagażem doświadczenia. Myślimy, że w tej liście inspiracji każdy znajdzie coś do rozważenia dla siebie na przyszłość.

Praca w nowym zespole jest zwykle stresującym wydarzeniem. Dotyczy to zarówno osób, które dopiero zaczynają swoją pracę w roli Scrum Masterów, jak i doświadczonych w tym obszarze. Jak zatem zminimalizować ten stres i ułatwić sobie rozpoczęcie pracy w nowym zespole?

Podzielimy się z Tobą praktycznymi wskazówkami oraz konkretnymi krokami, jakie warto wykonać, wchodząc do nowego zespołu w roli Scrum Mastera.

Zazwyczaj taka sytuacja wydarzy się w 2 przypadkach:

• całkowita zmiana firmy,
• zmiana zespołu wewnątrz tej samej organizacji.

Są też oczywiście inne okoliczności dołączania Scrum Mastera do nowego zespołu, jak np. startowanie zupełnie nowego zespołu i Scrum Master pomaga rozpocząć grupie współpracę. W tym artykule odniesiemy się jednak tylko do przypadku, gdy doświadczony Scrum Master dołącza do już zbudowanego i wcześniej pracującego ze sobą zespołu.

Dlaczego ważne jest dobre rozpoczęcie współpracy w nowym zespole?

Zacznijmy od tego, dlaczego jest to naszym zdaniem istotny temat i warto go poruszyć. Przede wszystkim, z perspektywy Scrum Mastera, to czas tego tzw. pierwszego wrażenia. Po drugie, z perspektywy zespołu i organizacji, to szansa na wprowadzenie trochę świeżości do funkcjonowania grupy. Stąd też warto świadomie wykorzystać ten moment, czerpiąc z niego korzyści, jakie ze sobą niesie.

Jako Scrum Master, powinieneś zatem odpowiednio się przygotować, aby uniknąć stworzenia złego wrażenia od samego początku. Ponadto, zwłaszcza gdy w organizacji nie ma świadomości roli Scrum Mastera, jest to idealny moment, aby wyjaśnić, czym się zajmuje Scrum Master i dlaczego warto, aby współpracował z zespołem. 

Warto też mieć w pamięci, że zespół ma jakąś historię i doświadczenia, które niekoniecznie mogą być pozytywne, jeśli chodzi o współpracę ze Scrum Masterem. Brak czułości na ten aspekt może sprawić, że wchodząc do zespołu, który ma złe skojarzenia z rolą Scrum Mastera, jeszcze bardziej utrudnimy sobie nawiązanie dobrej relacji.

Możemy też mieć do czynienia z pewną niekompatybilnością na linii Scrum Master a Zespół Deweloperski. Taka sytuacja może zajść np. gdy dołączamy do dojrzałego już zespołu, który może mieć inne oczekiwania co do naszego wsparcia jako Scrum Master, niż nam się wydaje. Efektem tego może być poczucie dyskomfortu po obu stronach, zwłaszcza jeśli zespół nie powie o swoich oczekiwaniach na głos.

Powodów tej niekompatybilności może być rzecz jasna więcej. Oprócz dojrzałości czy doświadczenia zespołu powodem może być również specyficzna energia, czy kultura zespołu – jeden zespół lubi pożartować, inny jest bardziej poważny, jeden ma duży fokus na kwestie techniczne i detale, z kolei dla innego ważna jest miła atmosfera i komunikacja. Scrum Master na kwestie te może zareagować, dostosowując się do zespołu lub próbując go zmienić, bo ma inne przekonania co do organizacji zespołu. Stąd też te pierwsze dni mogą zaważyć o dalszej współpracy i nastawienia zespołu do Scrum mastera albo Scrum mastera do zespołu.

Ta niekompatybilność może wyjść np. podczas Retrospektywy Sprintu, kiedy to Scrum Master dobiera bardziej kreatywne i niestandardowe techniki, które zespół odbierze jako infantylne i niepoważne, bo woli zwyczajnie porozmawiać co wyszło, co nie wyszło, a nie bawić się w jakieś zabawy.

Ponieważ dołączanie do nowego zespołu wiąże się często z dużym stresem i niepewnością, co słyszymy w pytaniach, jakie dostajemy podczas rozmów ze Scrum Masterami, może być też tak, że ten stres wyrwie się nam spod kontroli, gdy np. zespół zareaguje inaczej, niż byśmy chcieli. Ten stres będzie się napiętrzać i wpływać na to, jak działamy i jak się komunikujemy. Stąd też tak ważne jest przygotowanie się na te nowe okoliczności zawodowe.

Jak dobrze przejść proces wchodzenia do nowego Zespołu Scrumowego?

Proces przygotowywania się do wkroczenia do nowego zespołu należy rozpocząć w swoim poprzednim zespole. Mianowicie, sugerujemy poświęcenie trochę czasu na porządną refleksję nad swoją pracą wykonaną do tej pory. Warto poprosić zespół o wsparcie w tej kwestiii przekazanie nam feedbacku, co im się podobało, a co nie i co warto poprawić. Oczywiście zdajemy sobie sprawę, że nie zawsze jest to możliwe, bo przykładowo rozstajemy się z zespołem w niezbyt dobrych realiach (zwolnienia, rozpad zespołu itp.). Wtedy zachęcamy do przeprowadzenia szczerej autorefleksji na zasadzie: jak widzę swoją współpracę z zespołem z dłuższej perspektywy czasu, jakim zespołem byłem/byłam i co chcę zmienić, co się udało, a co nie, jakie techniki chcę rozwijać, a które niekoniecznie. Taką autorefleksję ogólnie warto przeprowadzać częściej, nie tylko przy zmianie zespołu, bo to jest bardzo pomocne przy rozwoju siebie w roli Scrum Mastera. 

Na bazie naszego doświadczenia wiemy, że bardzo dużo wartości ma i jest pewnym fundamentem dalszej współpracy, zawiązanie kontraktu z zespołem. Polega to na porozmawianiu o tym, jak będziecie współpracować, czego możecie się spodziewać po sobie, jak wyobrażacie sobie Waszą współpracę, o sposobie przekazywania feedbacku i np. otwartości na eksperymenty. Jest to właśnie świetna okazja do ustalenia sobie takich absolutnie bazowych zasad, do których będziecie mogli się odwoływać w momencie, gdy sytuacja zacznie się wymykać spod kontroli. Może to mieć formę spisanej w kilku punktach umowy, która będzie dla każdego dostępna. Warto też ją odświeżać i sprawdzać, czy Wasze potrzeby i punkt spojrzenia się nie zmienił, a także zapoznawać z nią nowych członków zespołu i pytać, czy jest ona dla nich jasna i czy się z nią zgadzają. Warto też tam zawrzeć kwestię tego, jak zareagujemy, jeśli jedna ze stron przestanie wywiązywać się ze swoich zobowiązań. I co bardzo ważne, pamiętajcie, że ten kontrakt jest dwustronny, a jego tworzenie nie powinno przybierać licytacji lub listy życzeń od zespołu w kierunku Scrum Mastera.

Gdy kontrakt między Scrum masterem a zespołem już powstanie, zachęcamy do stworzenia lub sprawdzenia aktualności kontraktu całego zespołu, czyli członków zespołu między sobą i członków zespołu względem Product Ownera. Możemy tam zawrzeć takie punkty jak, np.  pomagamy sobie przy code review, nie ukrywamy wiedzy, współpracujemy, otwarcie sygnalizujemy kłopoty i wykazujemy chęć pomocy innym. Jeśli z kolei w funkcjonującym już kontrakcie widzicie jakieś toksyczne punkty, np. nierównomiernie rozkładające się zadania, to warto zaprosić do przegadania tego jeszcze raz, aby wyprostować kwestie, które mogą psuć atmosferę i osłabiać zaangażowanie niektórych członków zespołu.

Kolejnym krokiem na początku współpracy z nowym zespołem jest zejście na poziom konkretnych ról i dyskusja dotycząca potrzeb oraz oczekiwań w stosunku do roli Scrum Mastera, Product Ownera, jak i członków Zespołu Deweloperskiego. Pojawi się wiele wartościowych dyskusji na punkcie styku pomiędzy tymi rolami. Można też poruszyć kwestie takie jak: jak te potrzeby i oczekiwania były realizowane do tej pory, co chcielibyśmy, aby się zmieniło, a co nam odpowiada i chcemy, aby było to kontynuowane. Tego rodzaju ćwiczenie  pozwala nam wypowiedzieć się, co byśmy chcieli od konkretnych ról w Scrumie i jak sobie wyobrażamy naszą współpracę.

Mówiąc o wzajemnych oczekiwaniach względem ról Scrumowych wewnątrz Zespołu Scrumowego, chcemy Cię przestrzec przed spłyceniem tego do cytowania sobie wzajemnie Scrum Guide’a. Na własne oczy widzieliśmy Scrum Mastera, który rozdawał członkom zespołu wydruki ze Scrum Guide’a i nie tędy droga. Przewodnik po Scrumie służy jako baza i kierunkowskaz, jak najbardziej można się nim posiłkować, jednak nie słowo po słowie, a przekładając na własne realia i mówiąc bardziej zrozumiałym językiem. 

Warto się upewnić, że zespół rozumie, czym jest samoorganizujący się zespół, na czym polega zwinność itd. Jest to istotne, gdyż przykładowo dla jednego zespołu prawdziwa zwinność, to jest faktyczne skupienie na produkcie, częste eksperymenty i bardzo szybkie wypuszczanie przyrostów produktu, dla innego zespołu szczytem zwinności będzie podzielenie waterfallowego projektu na fazy i realizowanie go w iteracjach, kompletnie nie zbierając informacji zwrotnej, nie eksperymentując, tylko po prostu realizując projekt. Ponadto Scrum Master może trafić do zespołu, który będzie miał już ochotę lekko polemizować z frameworkiem scrumowym, bo będzie chciał korzystać z praktyk bardziej start-upowych, albo od dawna nie korzysta z czystego, podręcznikowego Scruma, tylko z miksu elementów Kanbana i Lean Startup.

Z tym, co teraz powiedzieliśmy, wiąże się także poznanie całego aspektu produktowego, czyli zrozumienie, jak blisko, bądź jak daleko zespół znajduje się od produktu i od użytkownika końcowego. Powinniśmy dowiedzieć się, jak zespół rozumie kontekst biznesowy i dlaczego rozwija ten konkretny produkt. Jest to ważne, bo możemy zrazić do siebie zespół, wchodząc mocno z pewnymi założeniami, które zupełnie nie pasują do ich mindsetu, a my musimy zrobić kilka kroków do tyłu i skupić się na zbliżeniu zespołu do produktu. Stąd nasza praktyczna rada, to poznanie wizji produktu i poznanie, gdzie zespół jest, jeżeli chodzi o taką produktową perspektywę. Może to się odbyć poprzez zwykłą luźną rozmowę z zespołem i zapytanie o to, jakim produktem się zajmujemy.

Ostatnią wskazówką, jaką chcemy się z Tobą podzielić, jest przeprowadzenie “Retrospektywy Zero”, jak ją roboczo nazwaliśmy. Mamy tu na myśli taką retrospektywę z jednej strony otwierającą naszą współpracę z zespołem, a z drugiej strony, może domknąć czas, który zespół dotychczas pracował bez nas. Dla Scrum Mastera może to być dobra okazja, żeby posłuchać o problemach zespołu, zobaczyć, które rzeczy zespół uważa, że działają dobrze, a które nie działają, usłyszeć też, jakie takie tematy uznane są za przegrane itd. Z drugiej strony może się okazać, że będzie to pierwsza porządna retrospektywa tego konkretnego zespołu. Może wcześniej nie mieli sposobności, żeby opowiedzieć o potrzebach, problemach i jak mogą to wszystko na nowo poukładać. Miejmy jednak z tyłu głowy, żeby nie rzucać się na poprawianie wszystkiego na raz, a tym bardziej na obiecywanie zbyt wiele, jeśli dopiero rozpoznajemy się w sytuacji. Wybierzmy jeden temat i faktycznie zacznijmy się nim zajmować, co pozytywnie wpłynie na budowanie zaufania w zespole i podejście do naszej osoby jako Scrum Mastera. Stąd też warto jako pierwszą rzecz wybrać coś, co wiemy, że możemy rozwiązać, co dodatkowo pomoże zwiększyć naszą wiarygodność i pokaże, że jesteśmy dobrzy w tym, co robimy. 

Przestrogi dla Scrum Mastera w nowym zespole

Przede wszystkim unikaj jakiś odgórnych założeń i przekonań, a zwłaszcza nie uznawaj za pewnik rozwiązań, które Ci się wcześniej sprawdziły. W nowej firmie, czy też w nowym zespole w ramach tej samej firmy, to co działało wcześniej, tutaj ma prawo nie zadziałać. Mamy nowe środowisko, nowy kontekst, nowe okoliczności. Bądź uważny i otwarty na nowe możliwości i krok po kroku przejdź z zespołem przez istniejący problem lub wyzwanie. Warto wykazywać postawę wspierającą zespół, asystującą w jego rozwoju, a nie podsuwającą gotowe rozwiązania, mającą przyspieszyć dojrzewanie zespołu.

Nie przesadź też z liczbą spotkań, jakie zaplanujesz od początku współpracy. Może się okazać, że zespół miał wcześniej słabo realizowany Scrum i zbyt duża liczba spotkań, może wywołać poczucie, że znów będzie trzeba siedzieć na nic niewnoszących spotkaniach. Dlatego zachęcamy Cię ponownie do uważności i stawiania małych kroków, obserwując, na co zespół chętnie przystaje i jakie zgłasza potrzeby. Powoli budujmy kredyt zaufania, a nawet poprośmy o niego i róbmy wszystko, aby go nie stracić.

Ostatnią radą jest pokora i unikanie postawy “wszechwiedzącego Scrum Mastera”. Uszanuj mądrość i doświadczenie zespołu, a także ich potrzeby i wcześniejsze przeżycia. Nie traktuj zespołu z góry, nie baw się w “kołcza”, bo zespół może nie zechcieć z Tobą współpracować i będziesz stracony już od samego początku.

Chętnie poznamy Twoje doświadczenia związane z dołączaniem do nowego zespołu. Podziel się z nimi w komentarzu.

Transkrypcja podcastu „Scrum Master w nowym zespole„

Kuba: W dzisiejszym odcinku poruszymy temat przypadku, w którym Scrum Master dołącza do innego zespołu. Jest  to sytuacja, w której jesteśmy już Scrum Masterem praktykującym w jakimś zespole, mamy za zadanie dołączyć do nowego zespołu. Wyróżnilibyśmy dwa życiowe przykłady. Jeden to: zmieniamy zupełnie firmę, przeszliśmy rekrutację i trafiamy do zupełnie nowej firmy. Drugi przypadek to zmiana zespołu, ale wewnątrz tej samej firmy – popracowaliśmy już wystarczająco długo lub jakiś inny zespół bardziej nas potrzebuje i trafiamy do zupełnie nowego zespołu. Nie poruszymy takich szczegółowych wątków, jak: praca Scrum Mastera z organizacją – to zasługuje na kompletnie nowy odcinek. No i nie poruszymy też tematu startowania zupełnie nowego zespołu, na zasadzie: Scrum Master, jako osoba, która pomaga zawiązać się zupełnie nowej grupie. Odcinek będzie doprecyzowany tylko i wyłącznie do tego tematu: „Jestem już doświadczonym Scrum Masterem i dołączam do jakiegoś zespołu, który pracuje… wcześniej może z innym Scrum Masterem, może bez Scrum Mastera, ale jakoś tam już pracuje”. W ramach tego odcinka zaczniemy od wątku przedyskutowania dlaczego w ogóle to jest ważny temat, co może pójść nie tak, dlaczego chcemy o tym rozmawiać. Potem przekażemy tobie nasze inspiracje, rzeczy, o których myślimy, że warto rozważyć jako kroki do wykonania czy działania do zrealizowania w ramach rozpoczynania pracy w nowym zespole. I zakończymy cały odcinek kilkoma przestrogami, takiej generalnej natury, jakimiś praktycznymi uwagami, które warto uwzględnić we wszystkich tych technikach i praktykach.

Jacek: Zaczniemy odcinek zastanowieniem się dlaczego ten temat jest istotny i jak przygotowywaliśmy się z Kubą do tego odcinka, to zgodziliśmy się, że jest to taki pierwszy ważny krok, który wykonuje Scrum Master w nowym zespole, no i jest to – z mojej perspektywy – szansa, żeby zrobić to takie pierwsze wrażenie – to jest jeden aspekt. Drugi aspekt jest taki, że dysponujemy tutaj tym fajnym atutem świeżości, czyli zaczynamy na nowo, pojawiamy się jako nowa osoba i możemy świadomie ten moment wykorzystać, żeby ten nasz pierwszy krok był faktycznie takim krokiem, jaki chcielibyśmy wykonać, a nie jakimś takim przypadkowym, nieopanowanym ruchem, który może nie do końca nas satysfakcjonować.

Kuba: Innymi słowy – żeby ten pierwszy krok to nie było pośliźnięcie się w progu i w zasadzie już na dzień dobry złe wrażenie i cała reszta już sama leci, bo nie przemyśleliśmy jak to zrobić, żeby ten nowy zespół ruszyć, jak się w nim pokazać.

Jacek: Inny aspekt ważności tego pierwszego kroku jest taki, że bardzo często spotykam się w firmach, które wspieram, z niejasną rolą Scrum Mastera. Ta rola nadal, tak jak patrzę na rynek, nie do końca jest dla wszystkich jasna. Więc taki świadomy ten pierwszy krok, też wytłumaczenie, pokazanie, pomoc w zrozumieniu w zespole, kim jest Scrum Master, czego możemy się spodziewać po tej roli – może nam oszczędzić wielu problemów, niejasności, niedomówień w przyszłości.

Kuba: Może być też tak, że – zwłaszcza, jeśli ta rola Scrum Mastera była do tej pory niejasna, niedogadana – to może się okazać, że wchodzimy do zespołu, w którym są już jakieś przekonania, jakieś zaszłości, jakieś złe stare skojarzenia – i te wszystkie rzeczy mogą nam bardzo wpłynąć na to, jak pracujemy. Możemy się – nie mając ich przemyślanych – bardzo mocno nadziać na to, że my jesteśmy pełni dobrych intencji, chcemy dobrze, mamy jakieś swoje przemyślenia, doświadczenia. Po czym wchodzimy do zespołu, który w zasadzie już na dzień dobry jest na przykład źle nastawiony, na dzień dobry źle rozumie, ma jakieś złe skojarzenia z tą czy inną techniką, praktyką – i to niekoniecznie dlatego, że ta technika jest nie taka, tylko np. poprzedni Scrum Master zrobił coś nieumiejętnie i „spalił” nam już jakąś ścieżkę, którą możemy wykorzystać. Brak czułości na ten aspekt – że zespół ma jakąś historię, że ma już jakieś stare doświadczenia, których możemy nie znać, nie rozumieć – jest jeszcze jednym sposobem na to, żeby się nadziać, żeby ten pierwszy krok był nieudany.

Jacek: Innym aspektem ważności tego momentu dołączania do zespołu jest taka wrażliwość na pewną niekompatybilność, która może się pojawić na linii: Scrum Master a Zespół Deweloperski. Przykładowo możemy doświadczyć sytuacji, w której zespół, do którego dołączamy, jest już dojrzałym zespołem. No, stąd oczekiwania tego zespołu co do naszego wsparcia jako Scrum Master mogą być inne. I w tym konkretnym przypadku traktowanie zespołu w taki sposób bardzo opiekuńczy, traktowanie tego zespołu jakby właśnie dopiero zaczynał, może spowodować, że członkowie zespołu nie będą się czuć z tym komfortowo, często może nawet nie wyrażą tego werbalnie, natomiast wyczuwalne będzie, że zdecydowanie coś w tym zespole dzieje się nie tak, jak byśmy chcieli.

Kuba: I tych niekompatybilności może być więcej. Jedna oś, o której powiedziałeś, to będzie doświadczenie lub jego brak, dojrzałość zespołu lub brak tej dojrzałości, ale to też może być jakaś energia, może być jakaś specyficzna kultura – jeden zespół lubi bardziej pożartować, drugi jest bardziej poważny, jeden zespół ma wysoką kulturę inżynierską i dużą wagę wkładają na takie rzeczy inżynierskie, inny zespół woli się po prostu fajnie ze sobą czuć – i na wiele z tych rzeczy Scrum Master może zareagować, może się dostosować, ale też łatwo sobie wyobrazić te skrajności, w których Scrum Master ma ochotę, żeby była duża zespołowość, a w zespole jest wielki kult dobrego kodu i dobrej architektury i po prostu będzie niedopasowanie. I to nie jest tak, że jedno albo drugie jest lepsze lub gorsze, ale te pierwsze dni mogą się okazać już skreślonymi – tak to powiem – jeśli źle nam tutaj zespół się ustawi albo Scrum Master się ustawi źle do zespołu.

Jacek: Jak o tym mówisz, to taki przykład, który przyszedł mi do głowy – niekompatybilności – może wyjść podczas Retrospektywy Sprintu, gdzie Scrum Master może dobrać techniki, takie, powiedzmy, bardziej kreatywne, takie bardzo, powiedzmy, niestandardowe, które mogą zostać odebrane przez zespół jako infantylne, takie nie na miejscu, niepoważne. Przykładowo, zespół woli w takim niemieckim stylu po prostu porozmawiać o tym, co wyszło, o tym, co nie wyszło i np. pomysł malowania sobie jakiegoś zwierzątka na twarzy farbkami, zgadywanie, jakim zwierzęciem jesteśmy, może akurat w tym zespole „nie siąść” tak, jak byśmy chcieli.

Kuba: Może być też tak, że wszystkie te rzeczy, o których mówimy, to to jest takie doświadczenie, jakie mam z rozmów z wieloma Scrum Masterami, którzy proszą o radę, gdy zmieniają zespół, no to słyszę w tych pytaniach po prostu budujący się stres, budującą się niepewność, jakieś podekscytowanie, ale też ochota zrobienia tego dobrze, być może taka ambicja, żeby kolejny zespół był jeszcze lepiej uruchomiony niż do tej pory, niż te poprzednie. No i to wszystko buduje stres – no i teraz ten stres zawsze jest, i to jest naturalne, natomiast jeślibyśmy dołączali do innego zespołu bez tego, o czym chcemy opowiedzieć w kolejnych częściach odcinka – bez jakiegoś przygotowania, bez pewnych praktyk, no to ten stres może czasem wyrwać nam się spod kontroli, jeśli się okaże, że zespół reaguje gorzej niż chcieliśmy albo nie reaguje na nasze jakieś podpowiedzi czy działania, no i ten stres się zaczyna budować, napiętrza nam się, czy ta kula śniegowa się błyskawicznie zwiększa, bo nie reagują tak, jak chcą, „może to coś ze mną?” – i ten stres zaczyna też wpływać na to, jak działamy, jak się komunikujemy, przestajemy panować nad głosem, nad mową ciała, no i bardzo krótko i bardzo szybko można się spalić.

Jacek: Podaliśmy kilka przykładów na to, dlaczego ten temat świadomego wkroczenia do innego zespołu niż ten, z którym pracowaliśmy dotychczas, jest ważny. Jakbyś miał, Kuba, podzielić się inspiracjami, poradami, jak – na bazie twoich doświadczeń – dobrze przeprowadzić taki moment wkraczania do nowego zespołu, to co by to było?

Kuba: Paradoksalnie, rzecz od której bym zaczął, to coś, co trzeba zrobić w swoim poprzednim zespole. Czyli: wkraczając do nowego zespołu potrzebuję od osoby, która wkracza, porządnej refleksji nad całą swoją pracą wykonaną do tej pory. I to może mieć postać np. Retrospektywy takiej końcowej, na zasadzie rady od zespołu, co było fajne, co było niefajne, co można było poprawić – do Scrum Mastera. Nie zawsze jest nam to dane, bo np. rozstajemy się z zespołem w niezbyt dobrych realiach, jakieś zwolnienie, może zespół się rozsypał, może jest luka między tym czasem, gdy odchodzimy a tym miejscem nowym, do którego się zatrudniamy – nawet jeśli nie ma możliwości przegadania tego z zespołem, z Product Ownerem, to chociaż dokonałbym autorefleksji – na zasadzie: jak widzę z dłuższej perspektywy czasu, z większego oddalenia – jak widzę tą moją pracę wykonaną w tym zespole, jakim Scrum Masterem byłem (albo byłam) i jak chcę się zmienić – bo to często jest tak, że te działania w ramach danego zespołu już są podyktowane pewną jakąś rutyną, pewnym rozpoczęciem, pewnym stylem, którego się konsekwentnie trzymaliśmy i każda zmiana zespołu to jest świetna okazja do tego, żeby sobie czegoś spróbować – i to jest coś na zasadzie: „Może nie będę tak dominować, a może będę trochę mocniej dominować, a może będę używać więcej technik, a może więcej coachingu, a może będę mocniej moderować, a może teraz spróbuję lepiej się skumać z zespołem, bo później było głupio już to nadrobić” – szereg rzeczy, nie chcę nawet tutaj próbować podawać skończonej listy – ale szereg rzeczy, takich pytań do samego siebie, co robiłem/co robiłam fajnie, co mogę robić lepiej, jak chcę spróbować inaczej funkcjonować w tym zespole – i to jest jakby taka perspektywa dobre/złe rzeczy, ale też co chcę spróbować, czyli taki bardziej temat eksperymentowania. Na zasadzie: w starym zespole to już głupio byłoby coś wprowadzić, bo to tam już wszyscy poczuliśmy, że tego nie chcemy i zespół jakieś tam rzeczy blokował. No to w nowym zespole może jest okazja, żeby sobie odświeżyć te wszystkie fajne rzeczy, które zawsze chcę robić, tylko nie było za bardzo warunków. No i jest szereg tego typu przemyśleń. Podsumowując – refleksja na temat poprzedniego zespołu lub poprzednich zespołów, na takiej warstwie, jak ja pracuję jako Scrum Master, jakie techniki stosuję, z jakim nastawieniem pracuję, jakie postawy prezentuje.

Jacek: Wszystko to, co mówisz, to – widząc po sobie – widzę, że jest duża wartość, żeby takiej refleksji dokonywać częściej niż tylko w momencie kiedy – czy zmieniamy zespół, czy w naszych rolach, jako Agile Coachowie – kiedy rozpoczynamy współpracę z nowym klientem. Ale jeżeli ktoś takiej refleksji regularnej sobie nie przeprowadza na takiej warstwie, jak pracuję, co mówię, w jaki sposób mówię, czego się obawiam, co mi przychodzi lekko – no to faktycznie taki co najmniej ten moment, kiedy ta zmiana jest taka bardzo wyraźna, no to to powinna być ta chwila – jeżeli mamy dokonać tego tylko jeden raz, przy tym przejściu – no to niech to będzie ten moment. Z własnych doświadczeń widzę, że udane takie przejście – w sensie, takie głębokie, sensowne podsumowanie przeszłości, umówienie się z samym sobą, co zmienię w nowym zespole, w nowej rzeczywistości, a potem zobaczenie, że to wcale nie było aż takie trudne, jak się wydawało, zachęca do tego, żeby ten okres, co ile dokonujemy inspekcji siebie, skrócić i robić to zdecydowanie częściej.

Kuba: Nawet jeśli nie robimy tego częściej, no to ta zmiana zespołu to jest najlepsza okazja, żeby też po prostu coś zmienić, no bo tam najwięcej swobody mamy – trochę trudno się zmienia, a zwłaszcza radykalnie, zmienia się swój sposób postępowania w zespole, w którym już jesteśmy dłuższy czas. To może wymagać bardzo głębokiej rozmowy, być może jakiegoś kryzysu, być może jakiegoś mocnego rachunku sumienia, więc, no, warto to robić.

Jacek: Inną inspiracją, która – na bazie mojego doświadczenia – przynosi bardzo dużo wartości, jest takim pewnego rodzaju fundamentem dalszej współpracy, jest zawiązanie kontraktu z zespołem. Mam tutaj konkretnie na myśli kontrakt na linii: zespół a Scrum Master, czyli porozmawianie trochę o tym, jak będziemy współpracować, czego możecie się spodziewać po mojej osobie, czego ja mogę się spodziewać po waszej osobie. Porozmawiać trochę o potencjalnych zachowaniach, które mogą się pojawić – jakaś taka nasza chęć do eksperymentów, chęć do niezmieniania niczego, przestrzeń nadawania informacji zwrotnej – w ogóle to jest też moment, żeby zdiagnozować, czy w ogóle w zespole panuje kultura dzielenia się, informacji zwrotnej, jak zespół przyjmuje informację zwrotną – czyli ustalenie takich absolutnie bazowych zasad, do których będziemy mogli się odwoływać bądź wracać, w momencie, kiedy sytuacja będzie się nam wymykała spod kontroli. Warto mieć taki spis, taką umowę, takie parę jakichś konkretnych punktów, które będziemy mieć gdzieś tam w tle – tak, żeby można było w trudnych momentach pracy w zespole wracać do tego i upewniać się, czy coś się zmieniło w tej kwestii, czy może po prostu zapomnieliśmy, że na jakieś zasady współpracy się umówiliśmy.

Kuba: I ten kontrakt może brzmieć tak bardzo poważnie, może się kojarzyć z jakimś kontraktem grupowym, jakieś takie… bardzo wysublimowane rzeczy. Ja czasem używam takiego bardzo prostego porównania, że to może być kontrakt jak przy wynajmowaniu mieszkania albo jakimś kupnie/sprzedaży auta, na zasadzie: co dajemy, czego oczekujemy w zamian, na co się umawiamy, być może jakieś warunki dodatkowe, typu: jak to będziemy realizować, no i też ewentualnie myślę że ważną częścią kontraktu może być też to, jak zareagujemy, jeśli jedna ze stron się ze swoich zobowiązań nie wywiązuje. Czyli np. umawiamy się, że Scrum Master nas moderuje, Scrum Master jednak tego nie robi, to Scrum Master się umawia z zespołem, że w przypadku gdy będzie nie wypełniał swoich działań czy swoich zadań, to umawiamy się, że dostanie feedback – z powołaniem się na to, że „robisz inaczej, niż się umówiliśmy”. I to możemy naprawdę sprowadzić dosłownie do takiego „co daję i co biorę”. W aucie daję pieniądze, dostaję samochód w jakimś tam standardzie, a w tym kontrakcie daję swoją energię, daję techniki, jako Scrum Master, w zamian oczekuję, że będziecie ze mną współpracować, wspólnie umawiamy się, że będziemy sobie dawać feedback, wspólnie umawiamy się, że będziemy dokonywać od czasu do czasu eksperymentów i jesteśmy otwarci na to, że będziemy różne rzeczy próbować. Każdy zespół będzie miał swoje własne jakieś specyficzne potrzeby, co może się wiązać z tymi zaszłościami – może zespół może chcieć np. poprosić, że pewne techniki na retro dotyczące twarzy oraz farbek są nieoczekiwane i raczej byśmy ich nie chcieli, czyli również jakieś takie wyłączenia w kontrakcie – tego sobie wzajemnie nie robimy – i tak po dorosłemu, jak dorośli ludzie, poważne osoby, strony podpisujące kontakt, mówimy sobie: to robimy, tego nie robimy, tego unikamy.

Jacek: Jak o tym mówisz to to, co – z mojej perspektywy – jest istotne, coś, co jest oczywiste, ale chciałbym to powiedzieć głośno – że ten kontrakt jest dwustronny. Dlaczego o tym mówię? Często spotykam się z sytuacją, w której w momencie inicjowania takiego kontraktu zespół staje się tą stroną, która zaczyna licytować się wręcz, czego będą oczekiwać od Scrum Mastera, bardzo szybko ten Scrum Master staje się taką sekretarką zespołu, „będziesz rezerwował nam salki”, będziesz jakieś takie wszystkie rzeczy logistyczno-operacyjne rozwiązywał.

Kuba: Przynosił post-ity, dbał o to, żeby były zawsze dwa kolory markera.

Jacek: Czy na przykład wietrzył sale, czyli takie absolutnie rzeczy, które, no, umówmy się, nie są istotą pracy Scrum Mastera, natomiast bardzo często nie ma tych oczekiwań budowanych ze strony Scrum Mastera w stronę zespołu, a tutaj istnieje, moim zdaniem, dosyć duża przestrzeń na umówienie się, chociażby, na jakieś zasady kultury, czyli na przykład jak jedna osoba mówi, to druga osoba słucha, w sensie: zapewnienie sobie, Scrum Masterowi, że pewna taka przestrzeń będzie występować, tak więc akcent tylko na to, żeby ten kontrakt między Scrum Masterem a zespołem to nie była tylko taka lista życzeń od zespołu, ale żeby Scrum Master też mógł wyrazić swoje oczekiwania od zespołu.

Kuba: Czyli taki kontrakt równych stron, w których obie strony coś dają i obie strony coś biorą, a nie ma nierównowagi sił. I tak jak mówiłeś o zasadach pracy czy jakiejś takiej kulturze współpracy czy kulturze komunikacji, no to to jest już kolejna inspiracją, którą też można zrobić, jak już przejdziemy przez ten etap, że zbudowaliśmy kontrakt – ja versus zespół, to warto, moim zdaniem, niezależnie od tego, do jakiego zespołu dochodzimy, upewnić się, że istnieje, albo wręcz zmoderować na nowo powstanie kontraktu całego zespołu – na zasadzie: członków zespołu między sobą, członków zespołu względem Product Ownera, żebyśmy wszystkie takie podobnego typu umowy mieli też wewnątrz zespołu – pomagamy sobie przy code review, nie ukrywamy wiedzy, współpracujemy, otwarcie sygnalizujemy kłopoty, chętnie współpracujemy, gdy ktoś kłopot ma, a ja mogę mu pomóc – czyli szereg tego typu rzeczy, na które zespół może się umówić. I jak dołączamy do istniejącego zespołu, to na pewno jakiś kontrakt jest, tylko może być bardzo duże zagrożenie, że on nigdy nie był sformalizowany, spisany, głośno nazwany. Najgorzej, jeśli wtedy też częścią tego kontraktu będzie np. starzy gnoją młodych albo tester sam musi testować i my mu nie pomagamy, czyli takie, bym powiedział, bardzo toksyczne punkty kontraktu – bardzo nierównomiernie rozkładające jakieś zadania albo energie, emocje w zespole. My jako Scrum Master, moim zdaniem, powinniśmy porozmawiać o tym, jakie warunki współpracy w zespole funkcjonują i jeśli tylko są ślady tego, że zespół nie ma tego na wylot, na czysto, pięknie przegadane, to po prostu zaprosić zespół do tego, że: „Hej, mam taki pomysł, możemy spróbujmy sobie to spisać, zrobimy to na flipcharcie, wypiszemy, to będzie taka nasza reguła, ja chcę to poznać, bo tego nie znam, bo jestem nowy w zespole i wchodzę”. A przy okazji uważam, że takim fajnym skutkiem ubocznym takiego ćwiczenia będzie to, żeby sobie czarno na białym cały zespół powiedział, na co się umawiamy, a co jest nie okej, do czego się później w razie czego będzie można odwołać w przyszłości.

Jacek: Takim pogłębionym pomysłem na to, na co jeszcze się możemy umówić – taką właśnie mam refleksję, że cały czas jesteśmy w tym obszarze, że nie zaczęliśmy jeszcze pracy, tylko cały czas jeszcze ustalamy, jak to będzie wyglądać, co uważam za bardzo – z perspektywy czasu – za bardzo wartościową inwestycję, to kolejną taką płaszczyzną umówienia się w ramach zespołu, jak będziemy pracować, jest zejście już na poziom konkretnie ról, które występują w Scrumie. Czyli podyskutowanie sobie, w ramach Zespołu Scrumowego, jakie są nasze potrzeby i oczekiwania w stosunku do roli Scrum Mastera, jakie są nasze oczekiwania, potrzeby w stosunku do roli Product Ownera, ale także porozmawianie o tym, jakie są oczekiwania i potrzeby członków zespołu Scrumowego, Scrum Mastera i Product Ownera, względem Zespołu Deweloperskiego. I sam takie ćwiczenie przeprowadzałem kilkukrotnie, gdzie zastanawialiśmy się, w ramach Zespołu Scrumowego, jakie są nasze potrzeby. Te potrzeby po wygenerowaniu ich przez członków zespołu przypinaliśmy w odpowiednie obszary – czy to jest Scrum Master, czy to jest Product Owner, czy to jest Zespół Deweloperski, dużo wartościowej dyskusji było na punkcie styku pomiędzy tymi rolami – a następnie na osi rozkładaliśmy sobie, jak bardzo czujemy, że te potrzeby na dzisiaj są realizowane bądź nie. I to było bardzo fajnie widoczne, że np. dotychczas Scrum Master, w sensie: potrzeba zespołu, żeby wydarzenia Scrumowe były moderowane, plasuje się, powiedzmy, na zasadzie, że jest okej, że to jest realizowane, ale przykładowo informacja taka na temat kontekstu biznesowego ze strony Product Ownera lądowała gdzieś tam na początku osi. Tak więc… Tego rodzaju ćwiczenie z jednej strony pozwala nam wypowiedzieć się, co byśmy chcieli od konkretnych ról w Scrumie, jak sobie wyobrażamy tą współpracę, a z drugiej strony to jest taki fajny moment, kiedy możemy dostać informację zwrotną, jak na dzisiaj te potrzeby zespół Scrumowy uważa, że są w tym zespole realizowane.

Kuba: Jeśli mówimy o wzajemnych oczekiwaniach względem ról Scrumowych wewnątrz zespołu Scrumowego, to może być spora pułapka spłycenia tego tylko i wyłączenie do pewnego cytowania sobie wzajemnie Scrum Guide’a. Zwłaszcza doświadczony i wryty porządnie, porządnie wycertyfikowany Scrum Master może stwierdzić: „Kurczę, przecież co tu wymyślać, ja im po prostu wyliczę, co to ma być”. Widziałem już na własne oczy gościa, który rozdawał ludziom wydruki ze Scrum Guide’a albo cytował na wyrywki dokładnie, słowo po słowie, lepiej ode mnie, co tam w tym Scrum Guidzie jest. Fajnie. Natomiast to, co widzę, że w zespołach jest potrzebne, to powiedzenie tego ludzkim językiem, czyli, owszem, „Scrum Master zachęca zespół,  czy tam uczy zespół, wykorzystywania empiryzmu, samoorganizacji” itd. Fajnie byłoby, żeby w ramach sformułowania wzajemnych oczekiwań, wprost powiedzieć, co to znaczy. Co to znaczy, co będę robić. Bo to może być tak, że Scrum Master np., jak to jest czasem w żartach o Scrum Masterach, aktywnie robi „nic”, czyli np. czeka aż zespół się wywali i wtedy dopiero „coachuje” sytuację, że, no, słuchajcie, to nauczmy się coś z tego przypadku. I fajnie byłoby, żeby to było z góry zadeklarowane i fajnie byłoby, żeby zespół zaakceptował taki przypadek. Zespół, niejeden, w tym przypadku, w tym dokładnie miejscu, powie: „Słuchaj, ja bym chciał, żebyś nami nie manipulował”. Albo, jak ty wiesz, że idziemy na minę, to nam to powiedz, a nie udawaj mądrego post factum i: „A nie mówiłem?”/”A nie mówiłam?”. Więc jest szereg rzeczy, które można ustalić, jako wzajemne oczekiwania i wzajemne takie realizowanie tych oczekiwań, ale ja bym apelował o to, żeby to sformułować poprzez przykłady, poprzez ludzki język, a przez odwrotność – unikanie raczej takich żywych cytatów, tych takich sformułowań, które fajnie brzmią, zamykają w paru słowach dokładne zrozumienie tego, co mamy na myśli, tylko że my to mamy na myśli, a zespół może tego kompletnie nie rozumieć.

Jacek: Albo rozumieć błędnie.

Kuba: Bardzo inaczej. I wtedy kiwną głową: „Tak, tak, rób nam samoorganizację”, tylko ich poprzedni Scrum Master samoorganizację rozumiał jako rozdawanie zadań samemu. I wtedy, niestety, zespół może się okazać, że – nie zrozumiał tego, na co się zgodził.

Jacek: Tak, myślę, że ta dbałość o to, co te konkretne wyrazy znaczą, ma tutaj duże znaczenie. Taką powiązaną inspiracją z tym, o czym właśnie rozmawiamy, jest upewnienie się przez Scrum Mastera, jak zespół rozumie „zwinność”. W czasach, w których żyjemy – bo nie ma firmy, która by nie deklarowała, że pracuje zwinnie – oczywiście diabeł tkwi w szczegółach, no i może się okazać, że ta zwinność, w zależności od firmy bądź od zespołu, z którym przychodzi nam pracować, może być rozumiana na zupełnie innym poziomie. Przykładowo: dla jednego zespołu prawdziwa zwinność to jest faktyczne skupienie na produkcie, częste eksperymenty i bardzo szybkie wypuszczanie produktu (w sensie przyrostów produktu) na rynek, dla innego zespołu szczytem zwinności będzie podzielenie waterfallowego projektu na fazy i realizowanie go w iteracjach, kompletnie nie zbierając informacji zwrotnej, nie eksperymentując, tylko po prostu realizując projekt. Wracając do tego, co przed chwilą powiedziałeś, no, czy pracujemy zwinnie – tak, pracujemy zwinnie, wszyscy zgodnie powiedzą, natomiast już za chwil kilka na pierwszych wydarzeniach Scrumowych, czy patrząc na sposób pracy zespołu, okaże się, że ta zwinność może być postrzegana w zupełnie inny sposób, łącznie z przypadkiem, w którym Scrum Master, który rozpoczyna swoją przygodę może trafić do zespołu, który będzie miał już ochotę lekko polemizować z frameworkiem scrumowym, bo będą już tak dojrzali, że będzie ich ciągnęło bardziej w stronę jakiegoś, nie wiem, lean’a takich jakichś praktyk bardziej start-upowych, niż korzystać tak bardzo książkowo z frameworka scrumowego. 

Kuba: Lub przez odwrotność – i to też czasem spotykam – taka już spalona ziemia, że, „no, już nie musisz mi tłumaczyć, czym jest Scrum, ja doskonale wiem, co to jest, to są nudne spotkania, dużo jakiegoś bullshitu”, nic nie zmienia się, firma się nie zmienia, zespół się nie zmienia, produkt nie ma żadnej wartości, Product Owner nie decyduje – czyli szereg jakichś takich złych skojarzeń ze Scrumem, no i lepiej byłoby to szybko sobie ustalić, bo może się okazać, że przez dyplomatycznie ujmowaną jakąś grzeczność względem tego nowego Scrum Mastera jeszcze się powstrzymujemy, no ale chyba chciałbym pierwszego dnia już wiedzieć, że mam taki kłopot, że tak naprawdę w zespole już jest hejt, że już jest silne zniechęcenie, no i to silne zniechęcenie to jest tak w ogóle świetny temat na dalszą dyskusję – trochę o tym jeszcze wspomnimy w kolejnej radzie, ale na tym etapie, na którym jesteśmy tutaj, czyli upewnienie się, jak zespół rozumie zwinność, no to sprawdziłbym to, porozmawiał o tym, poprosił, żeby oni zdefiniowali, podali przykłady, podali swoje przeżycia, co to jest dla nich, co to jest dla nich, jako dla zespołu, jakie mają doświadczenia jako zespół, który już wykonał jakieś działania i, no, był czujny na to, że wszystkie te miejsca, w których jest różnica między tym jak my to rozumiemy, jak rozumie to zespół, no to jest temat do rozmowy – bo może być przypadek: „oni nie mają racji, ja mam rację”, ale może być też przypadek, że oni już są bardzo dojrzali i mają ochotę na takie, no, rozszerzenie sobie frameworków, tak naprawdę tworzenie już jakichś podejść takich bardzo zaawansowanych i możemy zrobić sobie krzywdę, jak wchodzimy na pełnym rozpędzie modelowego „Scrum Guide’owego Scruma”, zgodnie z książką, a zespół już trzy lata tam był i teraz już ma ochotę na zaaplikowanie trochę Kanbana, może trochę Lean Startup, może jakiś DevOpsowe praktyki, które powodują, że ten Scrum już będzie bardzo inny niż taki czysty, podręcznikowy.

Jacek: Tak. Powiązanym tematem – jednak akcentującym mocno taką stronę biznesowo-produktową w tym pierwszym kroku – może być poznanie całego tego aspektu produktowego. Dotychczas dużo mówiliśmy o zespole, trochę wspomnieliśmy o Product Ownerze, natomiast takim znacznym tematem do eksploracji jest zrozumienie, jak blisko, bądź jak daleko zespół znajduje się od produktu, od użytkownika końcowego. Jak bardzo rozumie kontekst biznesowy, jak bardzo rozumie to, dlaczego ten konkretny produkt rozwijamy – czyli takie, jak głęboko zespół jest osadzony w produktowości – bo z jednej strony to osadzenie może być bardzo głębokie, a z drugiej – zespół może być sprowadzony do roli takiej podwykonawczej, gdzie kompletnie bez kontekstu biznesowego, kompletnie bez zrozumienia dlaczego, po co pewne rzeczy robimy, po prostu implementują jakąś funkcję produktu, natomiast absolutnie nie mają tego zaplecza, żeby wytłumaczyć: „Robimy to dlatego, że jest taki problem i taka potrzeba i zmieniamy to w tym miejscu, bo to, to i tamto”. To również może być taka pułapka, że my wejdziemy z pewnymi założeniami, natomiast okaże się, że jak zrozumiemy, gdzie zespół się znajduje, jeśli chodzi o tą, nazwijmy to, „produktowość”, to będziemy musieli zrobić trzy kroki do tyłu i cały ten nasz plan okaże się do zmiany, bo większość wysiłku będziemy np. potrzebowali wsadzić w to, żeby przybliżyć zespół do produktu, co może nie być tak proste – w zależności od organizacji.

Kuba: I w praktyce ta rada, czyli takie poznanie wizji produktu i poznanie, gdzie zespół jest, jeżeli chodzi o taką produktową perspektywę, w praktyce może oznaczać prośbę Scrum Mastera, który wchodzi do zespołu, o to, żeby zespół opowiedział tej osobie, jakim produktem się zajmujemy. I kładę akcent na zespół, a nie na Product Ownera, bo Product Owner prawdopodobnie w produkcie jest obryty i będzie umiał o tym dużo opowiedzieć, a to może być bardzo fajna sesja w tych zespołach, które od produktu są dalej, że tak zupełnie mimochodem, tak z czystej ciekawości osobistej, pytając o produkt, przy okazji uruchomimy rozmowę w całym zespole, że znamy lub nie znamy ten produkt, a ktoś tam w ogóle myślał, że jednak czymś trochę innym się zajmujemy. Może to brzmieć absurdalnie, ale byłem świadkiem takich sytuacji. Także ja bardzo luźno pytam – jako osoba zupełnie z zewnątrz: „Hej, czym się zajmujecie? Opowiedzcie mi trochę, żebym lepiej to zrozumiał” i nagle się okazuje, że ciekawa dla wszystkich rozmowa odbywa się właśnie: „taki a taki problem rozwiązujemy biznesowy, nasi użytkownicy są tacy, tacy i tacy, tak ich klasyfikujemy, tak ich odróżniamy, takimi danymi dysponujemy, tych naszych klientów jest tylu, są w takim stopniu zadowoleni” – szereg szczegółowych, drobnych pytań, które mogą albo wyczuć, że wszyscy to fajnie rozumiemy – i to jest takie „uwspólnienie” – i zespół jak to rozumie, to powinno być bardzo proste spotkanie, bo rozmawiamy o rzeczach dosyć oczywistych, a ten zespół, który będzie miał kłopot, tak naprawdę właśnie zaprosiliśmy do uświadomienia sobie, że mamy luki, że mamy jakieś niedoskonałości w tym, jak postrzegamy produkt. No i co z tym zrobimy – no, może to są luki na zasadzie „pięć minut wypowiedzi Ownera i mamy to”, a może to jest jedna z rzeczy do zrobienia szybko, już od pierwszych tygodni funkcjonowania Scrum Mastera w zespole, nadrobić temat wizji, może ją w ogóle zbudować, jak jej nie ma, albo chociaż przepracować razem z tym, kto ją ma i może ją do tego zespołu przynieść – i szereg innych tego typu rzeczy. Na pewno – tak w praktyce – zacząłbym od niewinnego pytania, na zasadzie: „Słuchajcie, jestem ciekawy/ciekawa, powiedzcie mi, czym jest produkt”. I drążyć, ciekawić się, zgłębiać i się może okazać, że cały zespół będzie miał zupełnie przypadkiem fajny efekt uboczny w postaci uświadomienia sobie lub zrozumienia czym ten produkt nasz jest.

Jacek: Ostatnia taka inspiracja, którą chcieliśmy się z tobą podzielić, to jest zachęta do przeprowadzenia, nazwaliśmy to, „Retrospektywy Zero”, czyli takiej retrospektywy otwierającej z jednej strony naszą współpracę z zespołem, a z drugiej strony może to być taka retrospektywa, która domknie ten czas, który zespół dotychczas pracował. I teraz z jednej strony może to być dla nas, jako dla Scrum Mastera, bardzo fajna okazja, żeby posłuchać o problemach zespołu, zobaczyć, które rzeczy zespół uważa, że działają dobrze, zobaczyć, które rzeczy nie działają, usłyszeć też, które rzeczy są już tak postawione, jako takie tematy przegrane, że już pracowaliśmy, sto razy rozmawialiśmy o tym, żeby środowiska testowe działały i to nie działa, zobaczysz, tobie też będzie ciężko itd., więc absolutnie głęboka informacja, świetny kontekst dla Scrum Mastera. Natomiast z drugiej strony może się okazać – i sam byłem świadkiem takiej sytuacji – że będzie to pierwsza porządna retrospektywa tego konkretnego zespołu i z planowanych 45 minut może się okazać, że dyskusja będzie trwała dwie godziny, ale zdrowy rozsądek będzie podpowiadał, że szkoda to przerywać, bo np. to jest pierwsza okazja od dwóch lat dla tych wszystkich osób, żeby się wypowiedzieć, żeby opowiedzieć o potrzebach, żeby trochę skanalizować stres – po to, żeby na bazie tego wszystkiego wystartować od zera i z pomocą nas, jako tych nowych osób, zacząć te wszystkie problemy, o których rozmawialiśmy, na tyle, na ile możemy, układać. 

Kuba: I bardzo duża pokusa w takiej retrospektywie, którą zrobiłbym świadomie przed pierwszym Sprintem, w którym funkcjonuję jako Scrum Master, czyli nie mam jeszcze takich bezpośrednich osobistych przeżyć i ten zespół nie jest jeszcze pod wpływem mojego działania, tylko tak naprawdę zaglądamy w przeszłość, co do tej pory się działo – i pokusą, której bym próbował nie wypełnić, to jest ochota załatwienia wszystkiego od razu. Na zasadzie, tak jak mówisz przykłady, no to: „Środowiska nie działają”, „Owner nie ma Backlogu”, „Menadżer nie wspiera”, „Jakiś inny zespół jest kłopotliwy”, „Release’y są kłopotliwe”, „Tu coś nie działa”, „Dług techniczny”, „Nie mamy tyle automatyzacji, ile byśmy chcieli”. I nagle się okazuje, że rysuje się obraz po prostu dramatu. Dałbym się zespołowi wygadać, może poprosiłbym ich, żeby sobie też jakoś zarysowali, jakie są konsekwencje tych rzeczy, które z tych rzeczy są groźniejsze, a które mniej groźne. Ale naprawdę wziąłbym sobie do serca – na początek weźmy jedną rzecz i ją poprawiajmy, bo może się okazać, że fajnie, że doprowadzimy do takiej retrospektywy i zespołowi się uleje, bo wtedy mamy fajne rozeznanie w sytuacji, tylko nie zobowiązujmy się za wcześnie do za dużej ilości rzeczy, bo to nadal oznacza tylko i wyłącznie to, że dopiero wchodzimy, rozpoznawajmy tą sytuację, budujmy sobie wyobrażenie, co można zrobić i rozpracowujmy te kłopoty krok po kroku, krok po kroku, jeden po drugim, być może nawet małymi takimi kroczkami też nie raz, a porządnie a wszystko – tylko jakoś tak polepszajmy sytuację chociaż o trochę, bo tutaj można dostać naprawdę porządnego wysypu tematów, fajnie go uzyskać, zachęcam, żeby to zrobić, unieśmy fakt, że rozeznaliśmy się w problemach i na razie jeszcze nie rozwiążemy wszystkich, ale będziemy się za nie brać.

Jacek: Idealnie, jeśli faktycznie się za nie weźmiemy i szybko będziemy w stanie zespołowi pokazać – tak na zasadzie budowania zaufania, że: „Rozmawialiśmy ostatnio o tym problemie, porozmawiałem z tym, z tym, z tamtym, z menedżerem, z kimś tam, no i dobra, jesteśmy już trochę bliżej, mamy pewne ustalone akcje, te rzeczy się dzieją”. To też może pomóc zespołowi, w szczególności takiemu zespołowi, który już wielokrotnie się odbijał od ściany, próbował – żeby uwierzyć ponownie, „Okej, dobrze, z tym gościem/z tą dziewczyną/z tym Scrum Masterem czujemy, że to może być nowy start i to może być absolutnie nowy wiatr w żagle dla zespołu”.

Kuba: Na samym starcie mówiliśmy o stresie początkującego Scrum Mastera w danym zespole i dołożyłbym gwiazdkę do tego, co powiedziałeś. Szybkie wyniki są potrzebne, ale powiedziałbym: „Wybierajmy sobie bitwy, w których walczymy, i zacznijmy od tych, w których wiemy, że możemy wygrać”. Czyli: dobierajmy sobie te pierwsze działania również pod tym kątem, czy wydaje mi się prawdopodobne rozwiązanie tego problemu, bo fajnie jest patrzeć tą perspektywą wiarygodności moich działań i na początku, przychodząc do zespołu, mam wiarygodność, bo jestem doświadczony lub doświadczona, bo przychodzę jako już osoba, która miała jakieś zespoły poprzednio. Jeśli to jest jakaś rekrutacja, no to przechodzę rekrutację, co też jest takim dowodem, że to jest najlepsza osoba spośród kandydatów, jakich mieliśmy, więc jakąś tam wiarygodność na wstępie mamy. Ale to jest tylko i wyłącznie wstęp do tego, żeby się wykazać w praktyce, no i fajnie byłoby się wykazać, więc dwie rzeczy skrajne, których bym nie polecał, to – jedna skrajność to jest: „Biorę na siebie bitwy, które są przegrane i tak naprawdę po dwóch tygodniach już mi wszystko oklapło, bo nie mam rezultatów, zespół widzi, że nie mam rezultatów i już jestem w dołku”. I w drugą stronę też czasem widzę Scrum Masterów, którzy mają zbyt dużo postawy oczekiwania czy obserwacji rozpoznania i upływa miesiąc, a ta osoba nadal robi notatki i się słowem nie odezwała, nadal nie wpłynęła, nadal nie ruszyła. Bardzo trudny do uzyskania jest tutaj balans, ale szukałbym tej okazji do tego: „Zróbmy pierwsze rezultaty i bądźmy czujni na rzeczywistość wokół nas. Te rezultaty może mogą być drobne, ale niech będą jakieś konkretne, niech zespół je widzi”.

Jacek: Ta czujność, o której mówiliśmy, mi się wydaje, że to jest trudne – i tutaj tak, jak o tym opowiadałeś, zastanawiałem się, co bym doradził i nie mam tutaj jakiegoś sensownego rozwiązania, ale takie nasze wszelkie doświadczenia z przeszłości mogą nas prowadzić na błędną ścieżkę. Przykładowo: moje doświadczenia z jednej z firm były takie, że w przypadku pojawienia się problemów ze środowiskami testowymi, dosłownie kilka rozmów z menedżerami plus z dyrektorem działu doprowadziło do tego, że w przeciągu dosłownie dni te problem środowiska został zaadresowany: ktoś się za nie zabrał, powstał zespół, no i było widać, że ten temat jest wyraźnie widoczny i będziemy go rozwiązywać i on został rozwiązany w bardzo krótkim czasie. Wchodząc z takim doświadczeniem do innej firmy znów zobaczyłem problem ze środowiskami testowymi i mógłbym wybrać tą bitwę, tak jak mówisz, że: „Okej to to jest to, to załatwię przecież te środowiska to jest prosta rzecz”, natomiast w tej konkretnej firmie czekaliśmy grube kilka miesięcy, żeby te środowiska pojawiły się literalnie, że każdy zespół ma swoje środowisko, tak więc chyba to, co bym zrobił, to możliwe, że to jest ten moment, żeby się posiłkować zespołem i zrobić takie już trochę rozpoznanie też poza zespołem, jakby, co jest możliwe, a co nie jest możliwe. Moje doświadczenie jest takie, że zwykle ludzie bardzo szybko i otwarcie mówią o tym, że: „Środowiska testowe, słuchaj, walczymy już z tym pół roku. To nie będzie proste”.  Tak więc to, myślę, że warto zaznaczyć, że to nie jest proste. Po prostu.

Kuba: I bardzo płynnie przeszliśmy do tego, co chcieliśmy w ostatniej części tego odcinka przekazać, czyli pewne przestrogi – jak do tych wszystkich pierwszych inspiracji wymienionych wcześniej podejść na takim, no, poziomie ogólności. Jedna rzecz, no to właśnie to, co powiedziałeś, ja to sparafrazuję, żeby unikać jakichś przekonań, założeń, nie forsować rozwiązań, które nam się sprawdziły w poprzednim zespole lub zespołach. Bo, zwłaszcza jeśli zmienimy firmę, ale nawet jeśli w ramach tej samej firmy zmieniamy zespół, ten zespół to jest po prostu nowy zespół, to jest inny zespół i wszystko to, co nam działało, ma prawo nie zadziałać w tym specyficznym, nowym kontekście, więc tutaj przechodźmy na spokojnie tę drogę, bądźmy cały czas, jakby, ćwiczmy się w tej otwartości, że jest wiele opcji, są różne metody rozwiązania, nie próbujmy przeskoczyć ewolucji – ten zespół też musi przejść na spokojnie pewne kroki – być może parę razy się sparzyć, być może przejść kilka nieudanych prób wykorzystania jakichś innych technik niż te, które my wierzymy, że na pewno zadziałają. I nawet jeśli na koniec faktycznie zadziałają, to unieśmy w sobie to, że my raczej asystujemy zespołowi w tym, że on się rozwija, a nie podpowiadamy gotowe rozwiązania, jak wskoczyć na poziom zaawansowanego, wieloletnio pracującego ze sobą zespołu. To po prostu… tego się nie da przyspieszyć.

Jacek: Tak. Drugą poradą jest porada dotycząca uważności, jeśli chodzi o ilość spotkań i intensywność tych wszystkich rzeczy, o których przed chwilą powiedzieliśmy. Może się okazać, że – w szczególności zespół doświadczony wcześniej kiepsko realizowanym Scrumem, zobaczy, że nowy Scrum Master znów rozpoczyna od spotkań i ze względu na niski kredyt zaufania na początku, może być takie wrażenie w zespole: „Znowu siedzimy, znowu rozmawiamy itd.”, więc warto z tej długiej listy, którą przedstawiliśmy, wybrać sobie jedną, dwie rzeczy, żeby wystartować i na bazie tych pierwszych efektów w ogóle zobaczyć, gdzie jesteśmy i na bazie tych odczytów dopiero planować kolejne kroki – być może będzie tak, że nasza ambicja pod tytułem: „Zrobisz te siedem kroków, o których wspomnieliśmy”, w tej konkretnej organizacji, z tym konkretnym zespołem będzie nierealna – i to jest też okej, żeby wyhamować, żeby zrobić pauzę, żeby też dostosować się do rytmu pracy zespołu, co oczywiście nie oznacza, żeby z tych aktywności zrezygnować, ale być może będzie trzeba je trochę dłużej rozłożyć w czasie, albo gdzieś tak przeplatać między wierszami, przy okazji niż organizować dedykowane spotkanie, że będziemy rozmawiać np. o produkcie.

Kuba: Wspomniałeś „kredyt zaufania” – to jest coś, o co można też zespół otwarcie po prostu poprosić, na zasadzie: „Słuchajcie, dajcie mi szansę, spróbujmy, zaufajcie mi, dawajcie mi feedback, jeśli nie spełniam waszych oczekiwań, ale też pozwólcie mi spróbować jakichś działań, nawet jeśli na pierwsze wyczucie czujecie, że one tam nie wychodzą”. Jeśli dostaniemy minimalny kredyt zaufania, to później jest nasza brocha w tym, nasza zdolność do pracy jako Scrum Master w tym, żeby to zaufanie podtrzymywać kolejnymi drobnymi sukcesami. Poprośmy o ten kredyt zaufania i pamiętajmy, że go dostaliśmy i że on może się nam wyczerpać.

Jacek: I ostatnia rada, którą chcielibyśmy się z tobą podzielić, dotyczy tego, żeby uszanować zarówno mądrość, jak i doświadczenie zespołu. Zwykle jest tak, że zespoły, do których dołączamy już istnieją, mają swoje doświadczenia, mają swoje przeżycia i też takie wchodzenie na zasadzie: „Jestem Scrum Masterem, więc jestem bardzo mądry i teraz wam pokażę, ja mam te sprawdzone techniki z poprzednich zespołów”, no, może się skończyć, że dosyć mocno rozbijemy się, jeśli chodzi o takie podejście, tak więc raczej tutaj rekomendowałbym podejście takie na zasadzie: „Robię jakiś krok, robię stop, patrzę, co się dzieje, słucham, jestem pokorny, nie zakładam, że wszystko, co już doświadczyłem, zadziała mi w tym konkretnym zespole”. Mam doświadczenia z obserwowania pracy zespołów, gdzie Scrum Master dołączał i, przykładowo, traktował zespół bardzo mocno z góry, tak bardzo mocno „kołczingowo”, na zasadzie: „Dzieciaki, co wy wiecie, ja wam tutaj powiem, jestem już mądry”. Bardzo szybko może się okazać, że zespół naturalnie takiego Scrum Mastera wydali, w takim znaczeniu, że nie będzie chciał z nim pracować, no bo po prostu to będzie kompletny brak szacunku dla wszystkich wcześniejszych dokonań zespołu – tak po prostu po ludzku.

Kuba: Dobrze. Mam poczucie, że na ten moment treści tego odcinka wystarczy. Tak jak sygnalizowaliśmy, jest kilka wątków, które zasługują na osobny odcinek i to na pewno jest temat pracy z organizacją i to jest temat budowania zupełnie nowego zespołu. To – nie zadeklarujemy, w którym odcinku, ale będzie niedługo. W tym odcinku podzieliliśmy się z tobą tematem dołączenia do nowego zespołu czy pierwsze kroki w innym zespole, jako Scrum Master. Porozmawialiśmy o tym, dlaczego ten temat jest ważny, podzieliliśmy się siedmioma inspiracjami, co warto rozważyć – weź z nich tyle, ile czujesz, że jest ci potrzebne i na koniec opowiedzieliśmy o takich ogólnych przestrogach, takich bardziej ogólnego poziomu uwagach, jak do tej sprawy się zabrać.

---