Q&A cz.2

Porządny Agile

Skąd się wzięła rola Agile Coach’a? Czy Scrum Master nie powinien być rolą tymczasową? To kilka pytań, na które odpowiedzi usłyszysz w tej rozmowie. Poruszyliśmy też temat budowania wiedzy produktowej u nowego Product Ownera, zwolnień w pracy zwinnej i relatywnego szacowania. O wszystkie zapytali nasi Słuchacze – tym materiałem dokończyliśmy pulę pytań, które do nas dotarły, gdy o nie poprosiliśmy.

Porządny Agile · Q&A cz.2

Podobnie jak poprzednio wpis będzie miał formułę „pytanie-odpowiedź”. Przy niektórych, bardziej obszernych pytaniach, przyjęliśmy pewne założenia, o których wspomnimy. Ponieważ na pytania odpowiadamy dosyć spontanicznie, to może się zdarzyć, że nasze wypowiedzi będą trochę ze sobą sprzeczne lub nawiążemy do wątków pobocznych.

Spis treści

• Nowy Product Owner w Zespole Scrumowym. Jak budować wiedzę produktową?
• Jak weryfikować czy kandydat nadaje się do pracy zwinnej?
• Jak estymować z wykorzystaniem relatywnego szacowania w mocno wyspecjalizowanych zespołach?
• Skąd się wzięła rola Agile Coach’a?
• Dlaczego firmy zatrudniają Scrum Masterów do zarządzania zespołami zamiast do pomocy organizacji?
• Czy Scrum Master nie powinien być rolą tymczasową, aby budować odpowiedzialność w zespole?
• Transkrypcja podcastu „Q&A cz. 2”

Nowy Product Owner w Zespole Scrumowym. Jak budować wiedzę produktową?

W pytaniu widzimy założenie, że nowy Product Owner w zespole może mieć braki w wiedzy produktowej. Prawdopodobnie osoba ta ma predyspozycje do pełnienia swojej funkcji, brak jej po prostu doświadczenia z tym konkretnym produktem i zespołem.

W ramach budowania wiedzy produktowej rekomendujemy wykonanie poniższych kroków:

1. Zrozumienie produktu, wizji i strategii:

• Zapoznanie się z istniejącą dokumentacją, taką jak wizja produktu, strategia produktowa, roadmap itp.
• Jeśli dokumenty te nie są dostępne, to zidentyfikowanie osób, które pomogą zbudować te artefakty.
• Wypracowanie razem z zespołem wspólnego rozumienia produktu, jego celów i wartości dla użytkowników. Uspójnienie wiedzy dotyczącej kierunku, w którym produkt ma się rozwijać i w jaki sposób będziecie realizować cele biznesowe, które przed tym produktem są postawione.

2. Okres przejściowy:

• Zorganizowanie okresu przejściowego z dotychczasowym Product Ownerem lub Product Ownerką. Wykorzystanie tego czasu na wtajemniczenie w kontekst produktu, jego historię, wyzwania i sukcesy.
• Zaproszenie do procesu przekazywania wiedzy też innych osób pracujących z produktem, ale i Product Ownerów czy Product Ownerki z zespołów blisko współpracujących.
• Aktywne uczestniczenie w dyskusjach i zadawanie pytań, zamiast ograniczania się tylko do czytania dokumentacji.

3. Budowanie relacji i poznawanie różnych perspektyw:

• Zbudowanie mapy Interesariuszy i osób, które długo pracują w organizacji, aby poznać różne perspektywy, ale i więcej dowiedzieć się o historii produktu czy potrzebach odbiorców.
• Wykorzystanie spotkań z tymi osobami do budowania relacji i pozycji, aby wejść w realia tego produktu.

4. Odłożenie w czasie budowania Backlogu:

• Powstrzymanie się przed układaniem Backlogu.
• Skupienie się najpierw na poznawaniu produktu i jego otoczenia.

Jak weryfikować czy kandydat nadaje się do pracy zwinnej?

Pozwoliliśmy sobie trochę sparafrazować i skrócić otrzymane pytanie. W pełni brzmi tak: „Czy zdarzyło Wam się doprowadzić do zwolnienia kogoś, kto nie nadaje się do pracy zwinnej? Czy waszym zdaniem takie sytuacje nie powinny się zdarzać częściej, niż się zdarzają? Mam poczucie, że zwinność jest czymś premium, do czego naprawdę dużo osób nie pasuje. Nie chcę w tym pytaniu oceniać negatywnie tych ludzi, natomiast zwinność moim zdaniem jest wspierana przez pewne cechy osobowości, a przez inne jest mocno utrudniona. Jak weryfikowalibyście na etapie rekrutacji nadawanie się kandydata do pracy zwinnej?”

Możemy przyjąć, że mówimy tu o pewnej formie selekcji osób, które mają pracować zwinnie. Jak weryfikować takie osoby, jak upewniać się, że osoby, które mamy w procesie rekrutacji, sprawdzą się w pracy w środowisku zwinnym.

Kubie zdarzały się sytuacje związane z agile, w których osoby nie pasowały do pracy zwinnej. Najczęściej problem dotyczył nie tyle samej zwinności, ile umiejętności pracy zespołowej. Współdziałanie jest fundamentem zwinności, a nie każdy czuje się z tym komfortowo. Całkiem możliwe, że nie jest to kwestia osobowości, a zwykłych przyzwyczajeń. Ktoś to długo pracował całkowicie samodzielnie, mógł zatracić umiejętność czy nawet chęć współpracy.

Ważne jest, aby dawać szansę na dostosowanie się. Zwłaszcza w zespołach, które dopiero startują w danej organizacji albo składają się z ludzi, którzy do tej pory tak nie pracowali. Warto zadbać też o podstawy związane z zasadami jakościowej komunikacji, z dawaniem sobie feedbacku, ustaleniem zasad współpracy.

Jeśli natomiast osoba upiera się przy swojej postawie i nie wykazuje ochoty na współpracę, to jest jasny sygnał, że będzie źle funkcjonować w zespole zwinnym. Przy okazji zespół też będzie źle funkcjonował przez tę osobę.

W kwestii weryfikacji osób na etapie rekrutacji to mamy tu spore doświadczenie, także w rekrutacjach całych zespołów od zera. Kuba miał nawet rolę dedykowaną do sprawdzenia, czy konkretne osoby nadają się do pracy zwinnej (były to osoby bez wcześniejszego doświadczenia w tym obszarze).

Podczas tej części rekrutacji, w której chcemy sprawdzić czy osoba nadaje się do agile, nie sprawdzamy znajomości Manifestu Agile czy Scrum Guide’a. Te informacje są łatwo dostępne i nie dają wiedzy o doświadczeniu w pracy zespołowej.

Warto zadać pytania o doświadczenia pracy grupowej oraz poprosić o przykłady bycia częścią zespołu. Istotna jest też otwartość na nowe wyzwania i gotowość do nauki. Poznaj postawę tej osoby oraz dowiedz się, jaką ma wizję na siebie w nowej roli.

Godzinna rozmowa i obserwacja jak zadawane są pytania i, czy jest ten błysk w oku, gdy osoba opowiada, jak rozwiązała jakiś problem bardzo wiele powiedzą. Już to mocno oddzieli osoby tylko z wiedzą teoretyczną i dobrych w opowiadaniu historii, od tych z prawdziwym doświadczeniem.

Jak estymować z wykorzystaniem relatywnego szacowania w mocno wyspecjalizowanych zespołach?

W oryginale pytanie brzmi następująco: „Relatywne szacowanie w zespołach ze zjawiskiem silosów technologicznych i niską zastępowalnością. Jak to planować?”. Naszym zdaniem jednak jest trochę wieloznaczne i sparafrazowaliśmy je tak, jak je rozumiemy.

Zgodnie z tym, jak rozumiemy pytanie, chodzi tu o wybór podejścia do estymowania z wykorzystaniem szacowania względnego w zespołach, w których poszczególne osoby są bardzo wyspecjalizowane w swoim kawałku jakiegoś zagadnienia i nie znają się na innych kawałkach. Każdy zna się tylko na kawałeczku i nie zna się kompletnie na reszcie pracy, która jest w tym zespole do wykonania.

W tym zagadnieniu mamy trochę odmienne zdanie. Jacek uważa, że tak naprawdę to szacowanie relatywne ma sens tylko wtedy, gdy cały zespół bierze w nim udział i są w nim osoby posiadające kompetencje typu T (wszechstronna wiedza). Takie osoby rozumieją nie tylko swoją specjalizację, ale również pracę innych członków zespołu. Zdaniem Jacka, kluczem do szacowania relatywnego jest holistyczne spojrzenie na produkt, a nie skupianie się na wąskiej specjalizacji.

Kuba z kolei uważa, że szacowanie relatywne w zespole o dużej specjalizacji jest możliwe, ale wymaga więcej czasu i zaangażowania. Ważniejsze od samych wartości szacunków są rozmowy, które toczą się po ich zadeklarowaniu. Nawet jeśli ktoś da duży znak zapytania przy podanej liczbie, to nie po to, aby zamknąć temat, tylko żeby wspólnie usiąść do szacowania.

Rozmowy te pozwalają na transfer wiedzy i wzajemne zrozumienie silosów technologicznych w zespole.

Oboje zgadzamy się natomiast z tym, że szacowanie relatywne jest niejako zaproszeniem do rozmowy, a nie tylko techniką uzyskiwania samych szacunków.

Jeśli chodzi o drugą część pytania, czyli „jak planować?”, to nie mamy pewności, czy dobrze je rozumiemy. Założyliśmy, że chodzi o to, że istnieje świadomość silosów technologicznych i niskiej zastępowalności, dlatego trzeba się zastanowić jak ułożyć szacowanie relatywne. Trudnością będzie tu duże ryzyko biznesowe w przez niską zastępowalność, natomiast silosy nie współgrają z koncepcją bliskiej współpracy. Stąd należałoby wiedzieć, w jaki sposób członkowie zespołu będą się dzielić nią między sobą i jak rozwiązany zostanie problem niskiej zastępowalności. I to trzeba właśnie zaplanować.

Z drugiej strony w takim zespole nie powinno się zaczynać od szacowania. Tu jest miejsce na pracę grupową, aby członkowie zespołu mogli poznać różne aspekty produktu, a także siebie nawzajem. Jest to stosunkowo powolny proces, ale w dłuższej perspektywie powoduje transfer wiedzy i wyrównuje jej poziom w zespole.

Skąd się wzięła rola Agile Coach’a?

Rola Agile Coach’a powstała w odpowiedzi na potrzebę posiadania osoby, która pomagałaby początkującym zespołom, Scrum Masterom, Product Ownerom i managementowi w implementacji zwinnych metod w organizacji.

Początkowo funkcja ta nie była standaryzowana. W zależności od firmy nazywano ją różnie, np. trenerem Scruma, mentorem Extreme Programmingu, czy po prostu Centrum Agile jak to było w Allegro, gdy Kuba pełnił tam tę funkcję. To było około 2011 roku i wtedy pojęcie Agile Coach nie było tak rozpropagowane.

Z czasem rola ta stała się coraz bardziej popularna i zdefiniowana. Obecnie Agile Coach jest postrzegany jako mentor, starszy i bardziej doświadczony członek zespołu, który pomaga młodym praktykom metod zwinnych.

Jest w tym też ukryta koncepcja pewnego mistrzostwa, a Agile Coach występuje w roli właśnie mistrza, mentora, osoby, która przekazuje pewną wiedzę, uczula na pewne aspekty i być może wciąga w kolejne poziomy wtajemniczenia.

Z naszych obserwacji wynika, że w dużych organizacjach tych mistrzów na pokładzie potrzebnych jest wielu, w innych organizacjach takimi mistrzami są tacy konsultanci, jak my. Przychodzimy na pewien czas, pomagamy na przykład wystartować albo wyjść z jakiegoś problemu i zostawiamy samodzielny zespół.

Więcej o roli Agile Coach możesz posłuchać w rozmowie nr 15 „Kto to jest Agile Coach?”.

Dlaczego firmy zatrudniają Scrum Masterów do zarządzania zespołami zamiast do pomocy organizacji?

W oryginale przesłane pytanie brzmi: „Dlaczego firmy zatrudniają Scrum Masterów, aby zarządzali zespołami, a nie pomogli organizacji? Potem się dziwią, jak Scrum Master mówi, że na przykład story pointy to nie metryka wartości lub Scrum Master pyta o Cel Produktu interesariuszy.”

Zgadzamy się z tezą, że Scrum Masterzy i Scrum Masterki są często zatrudniani do zarządzania zespołami, a nie do pomagania organizacji.

Główną przyczyną zatrudniania Scrum Masterów do zarządzania zespołami, jest naszym zdaniem brak wiedzy o Scrumie. Często jest tak, że osoby decydujące o wdrożeniu Scruma w firmie, nie do końca rozumieją jego założenia i rolę Scrum Mastera. W efekcie Scrum Master jest postrzegany jako osoba, która ma „zająć się zespołem” i zapewnić jego efektywność.

Z drugiej strony czy to nie jest pewna naturalna progresja w organizacjach, gdzie właśnie ta wiedza o Scrumie jest mała? Najpierw Scrum Master lub Scrum Masterka pomaga swojemu zespołowi, a gdy zdobędzie większą wiedzą o firmie i zbuduje wiarygodność oraz pozycję, zajmie się stopniowym zmienianiem organizacji. Wówczas łatwiej też uzyskać niezbędne wsparcie ze strony managementu przy wprowadzaniu zmian.

Obserwowaliśmy wielokrotnie trend skupiania się na rozwiązywaniu problemów organizacyjnych, jednocześnie nie zajmując się zespołem. Sprawiało to trochę wrażenie odskoczni od problemów zespołowych, z którymi sobie nie radzono.

Wracając do wspomnianego w pytaniu zarządzania zespołem to mamy tu dwie kwestie:

• Zarządzanie w rozumieniu Scrum Guide’a: Scrum Master jako lider zespołu, który pomaga w wykorzystaniu Scruma i zapewnia ciągłe doskonalenie zespołu.
• Scrum Master jako ukryty kierownik projektu: osoba, która bez realnej pracy jako Scrum Master, skupia się na zarządzaniu i pilnowaniu zespołu.

Druga interpretacja jest zdecydowanie negatywna i powinna być traktowana jako sygnał ostrzegawczy podczas rekrutacji. Dlatego nie warto skupiać się na jako takim zrozumieniu Scruma i ogólnych hasłach, które mogą znaczyć wiele. Skupić się należy natomiast na tym, jakie są oczekiwania, jakie czynności będą do wykonania każdego dnia.

Czy Scrum Master nie powinien być rolą tymczasową, aby budować odpowiedzialność w zespole?

Ponownie skróciliśmy pytanie dla ułatwienia czytania. Pełne pytanie to: „Czy Scrum Master nie powinien być rolą tymczasową? Czy nie byłoby łatwiej wspierać zespołu w samej organizacji, gdyby ludzie wiedzieli, że Scrum Master jest tylko na jakiś czas, na przykład na rok? Mam wrażenie, że często zespoły przyzwyczajają się, że Scrum Master bierze odpowiedzialność na siebie i w związku z tym odruch brania odpowiedzialności samemu wytwarza się słabiej”.

Podchodząc do pytania trochę kontrowersyjnie, to faktycznie Scrum Master powinien być rolą tymczasową. Oczywiście długofalowo w organizacji powinni być profesjonalni Scrum Masterzy. Jednak warto zadbać o perspektywę, w której członkowie zespołu zmieniają na chwilę swoją funkcję i uczą się samodzielności.

Mentorzy Jacka w czasie, gdy zaczynał swoją przygodę ze Scrumem, też uważali, że powinien on po pewnym czasie zniknąć. Nawet jeśli będzie to rola na stałe to dobrze przyjąć podejście, że teraz pracuję z zespołem, ale w taki sposób, że gdy zniknę to zespół sobie poradzi.

Ciekawi nas czy Twoja organizacja jest gotowa do tego, aby dać nowy zespół konkretnemu Scrum Masterowi lub Scrum Masterce, zabierając dotychczasowy? Czy w organizacji w zespołach jest tak rozwinięta sytuacja, że można je przekazywać innym osobom lub zostawić do samodzielnego działania.

Pytanie kierujemy też do Ciebie, czy jesteś gotowy lub gotowa na to, żeby opuścić swój dotychczasowy zespół? Jeśli odpowiedź brzmi nie, to zachęcamy do przygotowania się do tego, aby być przygotowanym na taką sytuacją.

Ponieważ dziś odpowiedzieliśmy na 6 pytań, a w poprzednim odcinku na 8, a otrzymaliśmy ich dużo więcej, wymienimy w sekcji „Dodatkowe materiały” 5 odcinków naszego podcastu, w których znajdziesz odpowiedzi na pytania, których nie poruszyliśmy.

Jeśli masz więcej pytań związanych konkretnie z Twoją organizacją, to zapraszamy do konsultacji. Naszym klientom pomagamy właśnie w ten sposób, często w ramach konsultacji online. Więc jeśli masz jakieś zagadnienia, które jest realnie problemem albo jakąś rozterką twoją zawodową w dowolnej funkcji, czy to scrummasterskiej, produktowej, czy managerskiej, zapraszamy do rozmowy. Więcej informacji na temat tego, jak to przebiega, wszystkie pytania oraz stawki znajdziesz na porzadnyagile.pl/konsultacje.

Dodatkowe materiały

• Zacznij kończyć, przestań zaczynać
• Scrum Master w nowym zespole
• Pułapki odpowiedzialności PO
• Jak wspierać managerów w procesie zmiany?
• Zależności zewnętrzne w zespole

Transkrypcja podcastu „Q&A cz. 2”

Jacek: Dzisiejszy odcinek będzie kontynuacją poprzedniego odcinka i skupimy się na odpowiadaniu na pytania, które zebraliśmy od naszych Słuchaczy i Słuchaczek. Będzie to drugi i ostatni odcinek z tej serii, przynajmniej na teraz. Natomiast nie wykluczamy, że to podobnej serii typu Q&A wrócimy w przyszłości.

Kuba: Powtórzę, że ten odcinek rządzi się trochę innymi prawami niż zwykły odcinek. Przytoczymy wprost pytania, które dostaliśmy. Czasami je sparafrazujemy i powiemy głośno jakieś założenia, jeśli to będzie adekwatne dla danego pytania. I co ważne, też odpowiadamy na te pytania spontanicznie, więc może być tak, że nasze wypowiedzi będą albo trochę ze sobą sprzeczne, albo też trochę na żywo konstruowane, ale tak czujemy po tym poprzednim nagraniu, że ta formuła miała w sobie fajny dreszczyk emocji również dla nas, gdy byliśmy trochę bardziej zaskoczeni własnymi odpowiedziami. Więc nie przedłużając, przejdźmy wprost do sześciu pytań, bo na tyle dzisiaj odpowiemy.

Jacek: Pierwsze pytanie, które wybraliśmy na dzisiaj brzmi. Nowy Product Owner w Zespole Scrumowym. Jak budować wiedzę produktową?

Kuba: Rozumiemy, że jest to pytanie z założeniem, że ten Product Owner w tym zespole jednak przychodzi z jakimiś lukami, a może kompletnym brakiem wiedzy produktowej i że tak naprawdę obejmuje pewne stanowisko, do którego prawdopodobnie ta osoba ma predyspozycje, ale niekoniecznie ma doświadczenie i wiedzę taką dziedzinową, domenową czy produktową w tym konkretnym zespole produktowym.

Jacek: Tak, jak ja patrzę na to pytanie, to w pierwszej kolejności myślę sobie o tym aspekcie takim typowo produktowym. Zacząłbym generalnie od zastanowienia się, czy zdobycia wiedzy na temat tego, jaka w ogóle jest wizja produktu, jakim produktem mam się opiekować oraz jaka jest strategia produktowa. Zakładając oczywiście, że te elementy są dostępne. Jeżeli nie są, to zacząłbym od identyfikacji osób, które mogą mi pomóc w zbudowaniu tych artefaktów, a następnie w porozumieniu w idealnym świecie, w porozumieniu z zespołem, z którym będę pracował, żeby ten produkt wytworzyć, rozpocząłbym pracę nad tym, żeby zbudować wspólne zrozumienie. Czym tak naprawdę jest nasz produkt, w którą stronę idziemy, w jaki sposób w ogóle chcemy zrealizować cele biznesowe, które przed tym produktem są postawione.

Kuba: Ja w pytaniu słyszę też takie zagadnienie okresu przejściowego. Temat zastąpienia starego Product Ownera czy Product Ownerki jakąś nową osobą w sumie dosyć często następuje z różnych przyczyn. Również tych pozytywnych typu awans czy objęcia jakiegoś nowego produktu, który potrzebuje dotychczasowej doświadczonej osoby w jakimś innym miejscu. No i jednocześnie wtedy może dobrze byłoby zadbać przy takim okresie właśnie zmiany o pewien okres przejściowy i przekazanie obowiązków. Wydaje mi się, że najbardziej właściwą osobą do zbudowania wiedzy produktowej jest dotychczasowa osoba w tej odpowiedzialności produkt ownerskiej. Pewnie z pomocą, w zależności od tego oczywiście jaki to jest zespół, z pomocą Scrum Mastera, analityka biznesowego, jeśli taka osoba istnieje, pewnie też jakiegoś lidera technicznego lub architekta, jeśli takie funkcje występują. No i być może również innych Product Ownerów, którzy sąsiadują z tym naszym produktem, zwłaszcza jeśli mówimy o kontekście jakiejś dużej organizacji, która być może ma pewną pulę Produkt Ownerów ze sobą współpracujących też z racji uzależnienia swojego produktu. Ale wracając do zasadniczej myśli mojej, zorganizujmy, zorganizuj okres przejściowy. Zadbaj o to, żeby nie zniknął dotychczasowy Product Owner i żeby ta osoba nowa wytypowana była na tak zwaną zakładkę z tą poprzednią, żeby przekazać pewne myśli. Między innymi rzeczy, które Ty wymieniłeś, ale żeby tu nie było takie coś, takie zjawisko czytania artefaktów poprzedniego Product Ownera, tylko być może jakiegoś takiego wtajemniczenia poprzedniego Product Ownera.

Jacek: No myślę, że to na co warto zwrócić uwagę to to, żeby dobrze przemyśleć, do kogo powinniśmy się udać. Myślę, że zebranie różnych perspektyw osób, które znajdują się w organizacji, znają produkt, znają też historię drogi tego produktu do stanu obecnego, mogą okazać się nieocenione. No bo mogą być nie do wyczytania czy to z artefaktów, które wymieniłem, czy z jakiegoś dobrego produktu, czy nawet z jakiejś tam historii tego, jak ten produkt się rozwijał. Tak więc myślę, że ten największy potencjał czy miejsce, które myślę sobie, że może być najbardziej wartościowe, to właśnie są ludzie, którzy długo pracują w organizacji, no i są w stanie dać nam kontekst, którego myślę, że tak naprawdę w żadnym innym miejscu nie będziemy w stanie wyczytać.

Kuba: I to może mieć znaczenie, nawet jeśli obejmuje się tę rolę produktową z wewnątrz organizacji i być może ze stanowisk bliskich temu produktowi. Na przykład osoba, która do tej pory odpowiadała za jakiś proces, staje się Product Ownerem narzędzia, który ten proces obsługuje. Nadal ma sens zrobić sobie jakiś rodzaj mapy interesariuszy, wytypować kluczowe osoby albo wszystkie, jeśli jest to realne w skali danego produktu i po prostu z jednej strony, żeby zbudować wiedzę produktową, ale również z drugiej strony, żeby zbudować sobie jakieś pozycje takie polityczne czy dyplomatyczne relacje, żeby wejść w te realia danego produktu. I mówię to również właśnie nawet jeśli się jest w pozycji osoby, która już w organizacji istnieje, może być tak, że dopiero optyka bycia właścicielem produktu powoduje, że jednak widzimy sprawę trochę szerzej i nawet bym powiedział, musimy widzieć szerzej, nawet jeśli do tej pory już jakąś perspektywę na sprawę mieliśmy. Więc to będzie pewnie taka rundka wizyt gospodarskich po zarządzających wysokiego stopnia, po jakichś ekspertach, czy przedstawicielach klienta, czy użytkownika. Być może również właśnie jakichś sąsiadów produktów, na które wpływamy albo produktów, które od nas zależą. Więc może być tak, że jest cała długa lista osób, które trzeba odwiedzić, przegadać z nimi, zrozumieć, poznać się. To oznacza też, że być może nie można od razu wskoczyć natychmiast w układanie Backlogu, bo to może być tak, że kalendarz będzie długo zajęty jakimś takim zapoznaniem się.

Kuba: Dobra, to przejdziemy do pytania drugiego. Drugie pytanie jest już trochę bardziej rozbudowane, przeczytam je wiernie, tak jak Słuchacz czy Słuchaczka zadała je nam. Czy zdarzyło Wam się doprowadzić do zwolnienia kogoś, kto nie nadaje się do pracy zwinnej? Czy waszym zdaniem takie sytuacje nie powinny się zdarzać częściej, niż się zdarzają? Mam poczucie, że zwinność jest czymś premium, do czego naprawdę dużo osób nie pasuje. Nie chcę w tym pytaniu oceniać negatywnie tych ludzi, natomiast zwinność moim zdaniem jest wspierana przez pewne cechy osobowości, a przez inne jest mocno utrudniona. Jak weryfikowalibyście na etapie rekrutacji nadawanie się kandydata do pracy zwinnej?

Jacek: Czyli pytanie, parafrazując, dotyczy jakiejś formy selekcji osób, które mają pracować zwinnie. Nie ma tutaj wskazania, czy są to osoby takie bardziej związane z procesem, z produktem, czy z wytwarzaniem. Natomiast ta końcówka wprost kieruje nas na pytanie dotyczące tego, jak weryfikować, jak filtrować, czy jak upewniać się, że osoby, które mamy na rekrutacji, no, że faktycznie mają to coś, co będzie ich predysponować do pracy w środowisku zwinnym.

Kuba: No i pytanie jest bardzo ważne i jednocześnie dosyć delikatne, więc ja tutaj też spróbuję, nawet osoba pytająca też to delikatnie tutaj zaznaczyła. Ja też spróbuję delikatnie odpowiadać, myślę, że Jacek równie będzie łagodny. No ale zdarzyło się tak. Były sytuacje, w których byłem jakimś rodzajem uczestnika albo członkiem tego zespołu, albo osobą bardzo blisko, może zarządzającą takim zespołem i zdarzyło się, że były osoby, które do pracy zwinnej w jakiś sposób nie pasowały. Ja myślę, że przede wszystkim i jakby ja sam w tę stronę pójdę, przede wszystkim nie pasowały do pracy zespołowej jako takiej. No ważnym fundamentem zwinności jest to współdziałanie wszystkich członków zespołu. I nie każdy się czuje komfortowo w pracy zespołowej i myślę, że to nie jest kwestia jakiegoś tam aspektu osobowości, ale często też po prostu przyzwyczajeń. Wiele osób, długo pracując jako taka indywidualna jednostka, może bardzo zatracić możliwość czy umiejętność współpracy, a od któregoś momentu może już tego nie za bardzo chcieć. Więc faktycznie spotykam czasami w pracy, kiedyś chyba częściej spotykałem takie osoby, które po prostu były na tyle mocno przyzwyczajone do pracy indywidualnej, że bardzo źle się z nimi pracowało zespołowo. No i tak. Dużą nadzieję pokładam w dopasowaniu się, dostosowaniu się. Sam też mocno rekomenduję, żeby w zespołach zadbać, zwłaszcza takich, które dopiero startują w danej organizacji albo składają się z ludzi, którzy do tej pory tak nie pracowali, żeby zadbać też o takie absolutne podstawy związane z zasadami jakościowej komunikacji, z dawaniem sobie feedbacku, ustaleniem zasad współpracy, bo nawet jeśli się wydaje, że to są trywialne rzeczy, to się później dosyć szybko okazuje, że jednak trzeba je ustalić. Ale może być też tak, że ktoś nie chce albo ma za duży dystans do pokonania. Wtedy oczywiście, no ja sam mocno rekomenduję, to będę się powtarzał, ale mocno rekomenduję dawanie szansy. Oczywiście może jest szansa też wykorzystać taką osobę w jakimś innym zadaniu, może tam nie ma potrzeby pracy zespołowej albo nie tak dużej. No ale jeśli ktoś na przykład bardzo jasno postawi się w takiej sytuacji, że nie ma najmniejszej ochoty współdziałać z kimkolwiek, no to ta osoba będzie źle funkcjonować w zespole zwinnym i zespół będzie źle przez nią funkcjonował.

Jacek: No zdecydowanie praca zwinna opiera się na pewnych fundamentach, jednym z nich jest współdziałanie. No i generalnie, jeśli faktycznie ktoś nie ma absolutnie ochoty współdziałać w ramach zespołu, no to zarówno tej osobie będzie się ciężko funkcjonować, jak również wszystkim tym, którzy z tą osobą powinni w ramach działania w zespole współpracować. Natomiast pytanie jest, tak trochę wskazuje, że zwinność powinna być weryfikowana na zasadzie, czy potrafimy się odnaleźć w tym środowisku, ale moim zdaniem to uogólniając dotyczy tak naprawdę każdej innej kompetencji. No bo poziom naszego profesjonalizmu, poziom wywiązywania się z obowiązków, tak jak się komunikujemy, wszystkie te aspekty tak naprawdę mogą mieć wpływ. I ja nie patrzę nawet na to, że to jest jakaś taka umiejętność premium, no bo uważam, że na dzisiaj tak naprawdę umiejętność pracy w zespołach, umiejętność szybkiego reagowania jest czymś absolutnie podstawowym. Na zasadzie mało albo coraz mniej jest takich firm, w których zwinność to jest coś zupełnie nowego, świeżego i tak naprawdę takie firmy, moim zdaniem coraz mniej będziemy o nich słyszeć, no bo nie wyobrażam sobie, jak można pozostać konkurencyjnym, pracując bardziej w zgodzie z paradygmatem, że można sobie całą rzeczywistość zaplanować i tylko spokojnie przeprowadzić, wyegzekwować plan, który doprowadzi nas do jakiegoś tam sukcesu.

Kuba: No to tu się chyba zgadzamy. Ja może dopowiem parę słów na temat tego weryfikowania na etapie rekrutacji, bo miałem faktycznie taki fajny epizod, że kilka zespołów zwinnych mogłem skonstruować, czy uczestniczyłem w rekrutacji całych zespołów zupełnie od zera. No i nawet dokładnie byłem dedykowany w gronie osób, które decydowały o tym, byłem dedykowany do tego, żeby sprawdzić, czy się nadają do pracy zwinnej, a to były osoby, które w tej pracy zwinnej najczęściej w ogóle nie miały do tej pory udziału. Ale no oczywiście nie zadawałem im pytania o Manifest albo Scrum Guide, bo to oczywiście nie ma najmniejszego sensu i to jest czysto deklaratywne. Niektóre osoby nawet coś tam już kojarzyły albo wiedząc, że jak mają trafić do takiego zespołu, trochę się przygotowały, co było może takim fajnym plusikiem, ale tak naprawdę nie tego szukałem. Ja zadawałem pytanie o doświadczenie w pracy czy doświadczenie tak naprawdę bycia częścią zespołu. Bardzo fajne historie słuchałem. Myślę, że nie zdradzę za dużo, chociaż Ci, co usłyszą to wiedzą, że mówię właśnie o nich, ale historia o byciu częścią załogi żaglówki, byciu częścią drużyny harcerskiej, byciu częścią drużyny siatkówki, jakiejś hobbystycznie grającej, ale takiej mocno dobrze zgranej, czy na przykład fajna historia o wyprawie w Alpy i szykowanie się na wyprawę w Himalaje, gdzie też prawdziwe, mocne współdziałanie, też jakby dzielenie wartości, takie poczucie też bycia równym względem pozostałych. Te wszystkie wymienione przeze mnie zespoły, czy tak naprawdę nawet może coś mocniejszego, ale takie ekipy, one najczęściej mają też współdzielone przywództwo, a tak naprawdę chęć wspólnie osiągania pewnego celu. No i osoby, które poznały, tak uważam, osoby, które poznały tego typu sytuacje, dosyć ładnie umieją się też odnaleźć w takim zespole zwinnym. Nawet jeśli realnie w takim projekcie firmowym, czy takim profesjonalnym nigdy w takim zespole nie funkcjonowały, bo na przykład firma do tej pory tak nie działała. Więc ja szczerze mówiąc szukam zmapowania takich doświadczeń i one mogą być naprawdę bardzo różne. Wymieniłem takie najbardziej lajtowe przykłady, bo było ich tam trochę więcej, ja sam też mam takie historie mocnych drużyn ze swojego własnego życia, to mogą być naprawdę szalone rzeczy, ale to też pokazuje wtedy, co to znaczy być naprawdę częścią drużyny.

Jacek: Z mojej perspektywy, a oprę się tutaj na rekrutacji, w szczególności Product Ownerów i Scrum Masterów, do zespołu, którym zarządzałem. To generalnie to, co dla mnie było istotne, to pewnego rodzaju wszechstronność i otwartość na to, żeby uczyć się nowych rzeczy. Ja sobie to kiedyś zdefiniowałem jako taki błysk w oku, którego szukałem, gdy ktoś opowiadał o tym, co robił, jakie były przeszkody, jak sobie z nimi poradził czy poradziła. No i jaką ma wizję na to, jak się odnajdzie w tej nowej roli. Więc parafrazując, ja zwracałem uwagę bardziej na pewną postawę, niż na to, czy ktoś jest mi w stanie wyrecytować Scrum Guide’a, bo akurat nauczyć się Scrum Guide’a jest super prosto, a taka godzinna rozmowa jednak dosyć dobrze pokazuje, jakie ktoś ma podejście. Nawet takie detale jak zadawanie pytań, opowiedz o jakiejś sytuacji z przeszłości, jak sobie poradziłeś, kontrapytanie, co byś się zrobił czy zrobiła, one moim zdaniem bardzo mocno rozdzielają osoby, które są świetne w opowiadaniu, ale nigdy tego nie zrobiły w praktyce, od osób, które faktycznie były w realiach projektowych, to wcale nie muszą być realia zwinne. No i tak naprawdę mają szramy, o których są w stanie powiedzieć. Bo moim zdaniem te doświadczenia, czy będziemy pracować zwinnie, czy nie zwinnie, one i tak się przełożą na to, w jaki sposób te osoby będą kontrybuować do zespołu.

Jacek: No dobrze, to idziemy do kolejnego pytania. Kolejne pytanie brzmi w oryginale. Relatywne szacowanie w zespołach ze zjawiskiem silosów technologicznych i niską zastępowalnością. Jak to planować?

Kuba: Trochę sparafrazujemy to pytanie, bo ono jest w sumie dosyć wieloznaczne i nie do końca jasne, jakby je czytać dosłownie. Jak rozumiemy, jest to kwestia specyfiki podejścia do estymowania z wykorzystaniem szacowania właśnie względnego w zespołach, w których pojedyncze osoby są bardzo wyspecjalizowane w jakimś kawałku swojego zagadnienia i nie znają się na innych kawałkach, no i to jest jakby spójne u wszystkich. Czyli każdy zna się tylko na kawałeczku i nie zna się kompletnie na reszcie pracy, która jest w tym zespole do wykonania. No i jak rozumiemy, tu jest prośba o komentarz z naszej strony, żebyśmy podpowiedzieli, jak w takich zespołach szacować relatywnie.

Jacek: Dla mnie szacowania relatywne ma sens tylko wtedy, jeśli faktycznie cały zespół bierze udział w szacowaniu. Co oznacza, że fajnie byśmy mieli osoby z kompetencjami typu T. Czyli oprócz tego, że mam swoją bazową kompetencję, no to mimo wszystko, przykładowo, jeżeli jestem programistą, no to rozumiem, co do mnie mówi front-endowiec, rozumiem, co do mnie mówi QA, rozumiem, co do mnie mówi UX, rozumiem, co do mnie mówi osoba z biznesu. I czasem nawet taka niewielka wiedza, ale jednak nazwijmy to na wystarczającym poziomie, pozwala na bazie doświadczenia, na bazie współpracy wcześniejszej, na bazie tego, co już wyprodukowaliśmy, mieć pewne konkretne zdanie, jakiś tam punkt odniesienia. To jest jakby jedna rzecz. Dodatkowo w sytuacjach skrajnych zwykle te metody szacowania relatywnego oddają nam jakąś taką furtkę, że jeśli ja naprawdę nie wiem, jak coś oszacować, no to mam na to jakąś tam odpowiednią kartę czy jakiś tam odpowiedni komunikat mogę wystosować. Więc z mojej perspektywy jedyna ścieżka sensowna, która moim zdaniem ma sens, to jest ścieżka, w której wchodzimy na drogę, która prowadzi do tego, że musimy się dobrze zrozumieć i potrafić spojrzeć na produkt holistycznie, a nie tylko super wąsko ze swojej własnej dziedziny.

Kuba: Dobra, to tu będziemy mieli zdania odrębne. Bo ja myślę, że ta sytuacja opisana nie wyklucza tak w ogóle szacowania relatywnego, tylko uczyni je takim dosyć trudnym procesem. Ale szczerze mówiąc, wydaje mi się, że żeby osiągnąć to, o czym Ty mówisz, to właśnie można zespół zaprosić do próby szacowania, ale chyba ważniejsze nie będzie to, jakie wartości padają, tylko jakie rozmowy następują po tym, jak już wszyscy zadeklarują swoje wartości. Nawet jeśli jedną z tych zadeklarowanych wartości będzie jakiś tam znak zapytania, np. wymieniony przez Ciebie jako możliwy przykład, karty kompletnie nie wiem. Ale nie daję tej karty znak zapytania, kompletnie nie wiem, żebyście się odczepili, żebyśmy poszli dalej i przyjęli tę wartość, którą powiedział ten ktoś, kto się zna. Tylko żebyśmy zaczęli rozmawiać, dlaczego ja nie wiem, mimo że w zasadzie background taki merytoryczny mam, albo pracujemy nad tym samym projektem, czy podobnym produktem. Więc myślę, że jest sens, jeśli jest chęć wspólnego szacowania. Ważne, żebyśmy wtedy sobie wzięli poprawkę na to wszyscy, jako cały zespół, że to szacowanie będzie trochę dużej trwało, bo tak naprawdę ten, kto wie, ten wewnętrzny silos technologiczny w zespole będzie musiał pewnie w krótkiej wypowiedzi wyjaśnić wszystkim, dlaczego uważa, że to jest małe, duże średnie, dlaczego to jest większe niż tamto. Mimo że po powierzchni wydaje się, że są podobne kryteria akceptacji, podobne story, podobnie brzmi tak po powierzchni dane coś, a jednak z jakiegoś powodu jest zupełnie innych rozmiarów niż tamto inne. Więc nie zgadzam się, że w ogóle nie powinno się w tę stronę pójść, albo że najpierw trzeba mieć T, żeby potem móc szacować relatywnie, ale wtedy byłbym nastawiony bardziej na to, że to szacowanie relatywne to tak naprawdę jest pewnego rodzaju technika zaproszenia do rozmowy, a nie technika uzyskiwania szacunków samych w sobie. Bo te szacunki wtedy prawdopodobnie się szybko uzyska wyłącznie dzięki indywidualnym wycenom pojedynczych ekspertów i szkoda czasu, ale to nie o szacunki wtedy chodzi, tylko o to właśnie transferowanie wiedzy i takie wzajemne rozpoczynanie, przekazywania sobie pewnych tajników tych naszych wewnętrznych silosów.

Jacek: Zdarza mi się komentować proces estymowania relatywnego jako proces budowania wspólnego zrozumienia, gdzie tak naprawdę estymata staje się pewnym takim produktem ubocznym. Więc z Twojego komentarza Kuba podoba mi się ten aspekt takiego zaproszenia do rozmowy. No i to jest chyba ten warunek konieczny. Czyli ja mogę nie wiedzieć, ja mogę powiedzieć, nie znam się, ale musi być to otwarte, żebym wysłuchał, posłuchał. Bo to stworzy nam jakiś tam background, na bazie którego możemy zacząć rozmawiać, jak te klocki połączone różnych specjalizacji, ile wysiłku wymagają, żeby je połączyć, żeby to po prostu zaczęło działać. Jest jeszcze część pytania tutaj, jak to planować. Zastanawiam się, tak nie do końca wiem, co tu ten autor bądź autorka miała na myśli. Jak ja przeczytałem tę część pytania, to mi do głowy przyszło coś takiego, że silosy technologiczne i niska zastępowalność, to są tematy, do których trzeba byłoby podejść na zasadzie OK, mamy to zdiagnozowane i teraz to nie jest tylko kwestia, jak sobie ustawimy szacowanie relatywne, tylko tak naprawdę trzeba by było się zastanowić, co z tym tematem pracować. No bo niska zastępowalność brzmi jak dosyć duże ryzyko biznesowe. Z kolei silosy technologiczne mogą stać trochę w poprzek koncepcji, że chcemy blisko ze sobą współdziałać. Więc z kolei to planowanie, jak ja sobie o nim tak myślę, z mojej perspektywy mogłoby dotyczyć tego, w jaki sposób będziemy tą wiedzą się dzielić w zespole, w jaki sposób wyjdziemy z tej niskiej zastępowalności, co niestety oczywiście wymaga czasu. No i spotykam zespoły, które mówią tak, wiemy, mamy ten konkretny problem, ale robimy teraz projekt X i nie mamy na to czasu. Może następnym razem. To zrobimy, a może następnym razem i często niestety brakuje na to czasu, a to jest moim zdaniem tutaj zasadniczy problem, o którym powinniśmy porozmawiać.

Kuba: Jest to pewnego rodzaju wieloznaczność tego pytania. Nie wchodźmy już chyba w to głębiej za bardzo. Mój komentarz prawdopodobnie to nie od szacowania bym w takim zespole w takim razie zaczynał, bo tu może być zarówno wspólne poznawanie tych kawałków produktu przez osoby, które się znają i które się nie znają. Czyli jakiś rodzaj pracy w parach albo wręcz pracy w grupach i bardzo świadome inwestowanie w to. Spotykam też zespoły, które właśnie wchodzą do takiego problemu na zasadzie, niech problemem, czy danym zagadnieniem zajmie się ten ktoś, kto się na nim najmniej zna. Prosi o pomoc tych, którzy się znają. To jest krótkoterminowo bardzo powolny proces, ale w pewnym średnim i dłuższym okresie powoduje pewien transfer wiedzy i też takie wyrównywanie pewnych zasad działania. Ale myślę, że domknijmy to w tym miejscu i przejdźmy dalej.

Jacek: A, zanim przejdziemy dalej, to tylko krótka przypominajka, że jeżeli chcesz pogłębić wiedzę bardziej, niż robimy to w podcaście, to nasze płatne produkty premium znajdziesz na stronie naszego sklepu porzadnyagile.pl/sklep

Kuba: Pytanie czwarte jest króciutkie, ale myślę, że też będzie wieloznaczne. Skąd się wzięła rola Agile Coach’a?

Jacek: Agile Coach jest napisany przez K, co mi uruchomiło proces myślenia, czy to jest tak sarkastyczne, czy po prostu ktoś tak napisał z rozpędu. Tak, ale jak rozumiem, chodzi o pewien rys historyczny, jak do tego doszło, że mamy taką rolę, takie stanowisko w świecie pracy zespołowej, pracy zwinnej.

Kuba: To jest o tyle fajne pytanie, że sami przeszliśmy tę historię w czasach, które jeszcze nie były aż takie ustandaryzowane. Bo pamiętam ten czas, gdy jeszcze w czasach Allegro, które było pierwszą moją firmą, w której działałem zwinnie, dostałem zadanie przejęcia odpowiedzialności za taką funkcję, jaką pełni Agile Coach w dzisiejszym rozumieniu. No i pamiętam, że my wtedy za bardzo nie wiedzieliśmy, jak to nazwać, tzn. przez pewien czas ten zespół funkcjonował z bardzo tymczasową jakąś nazwą, zupełnie nic nieznaczącą i długo, długo było główkowanie, jak to w zasadzie nazwać i co to znaczy i czym się to coś zajmie. Ostatecznie nazwaliśmy to Centrum Agile i nie nazywaliśmy wtedy naszej funkcji, bo długo było zastanawianie się, co to jest. Mówię tu o okolicy 2011 roku, wtedy jeszcze te pojęcia Agile Coach nie było takie rozpropagowane, rozpopularyzowane. Książki Coaching Agile Teams dopiero powstawały albo dopiero nabierały popularności. I też te metody nie były takie ustandaryzowane, więc dosyć popularna funkcja była trenera, najczęściej Scruma. Były znane funkcje takich mentorów np. Extreme Programmingu, ale Agile Coach jeszcze wcale wtedy nie był normą jako nazwa pewnej funkcji. Ale myślę, że historycznie właśnie po to ta funkcja powstała, jak też sam to przeżyłem. Czyli pojawiła się potrzeba w organizacji, żeby był ktoś, kto tak trochę bardziej pomiędzy pomaga początkującym zespołom, początkującym Scrum Masterom, początkującym Product Ownerom, ale również managementowi w tym, żeby ten agile się w organizacji w ogóle zaczął. Później coraz bardziej rozwijał i być może też przełamywał kolejne bariery. No i myślę, że jest taka naturalna potrzeba, zwłaszcza w większych organizacjach, by był ktoś, kto jest taki trochę może właśnie starszy, trochę bardziej doświadczony, trochę bardziej do dyspozycji też, z trochę większą ilością czasu na rzeczy, takie z zaskoczenia, żeby podjąć pewne działania. Myślę, że troszkę zamieszał koncept Agile Coacha w modelu Spotify, który tutaj dodatkowo jeszcze propagowany w bardzo tak schematyczny sposób w niektórych organizacjach przez duże konsultingi, jeszcze dodatkowo namieszał, kim jest dokładnie Agile Coach i czym się zajmuje, ale może nie będę całości pytania zjadał.

Kuba: I w pewnym sensie tu jest też taka koncepcja takiego mistrzostwa. Ja lubię tę myśl o tym, że te takie zwinne zawody, zwłaszcza poważnie praktykowane to jednak są zawody z takim posmakiem mistrza, rzemieślnika, uczącego swoich uczniów, jak to robić dobrze. Sam byłem najpierw takim uczniem, teraz pewnie dla paru osób jestem takim mistrzem. No i ten Agile Coach to też jest taki właśnie mentor, miły starszy pan albo miła starsza pani, która młodych uczy, jak to robić dobrze, czego unikać, być może ma swoje własne metody, też szkoleniowe pokazujące jakieś takie specyficzne, czy kładące specyficzne akcenty na pewne zagadnienia, więc pewnie są też szkoły agile’a, czy szkoły agile coachingu? Ale nawet jeśli trochę ironizuję, a trochę ironizuję, to jednak ta koncepcja Agile Coacha jako takiego właśnie mistrza, mentora, osoby, która przekazuje pewną wiedzę, uczula na pewne aspekty. Być może ciąga w kolejne poziomy wtajemniczenia, no to jest koncepcja, która jest moim zdaniem tutaj tak profesjonalnie adekwatna i uniwersalna. To nie agile wymyślił Agile Coacha, to być może Agile Coach jest jakąś specyficzną wersją po prostu podejścia mistrz i uczeń. I w dużej organizacji tych mistrzów już na pokładzie jest potrzebnych wielu, w innych organizacjach takimi mistrzami są tacy konsultanci, jak my też nie dla niejednej firmy jesteśmy, gdzie przychodzimy na pewien czas, pomagamy na przykład wystartować albo wygrzebać się z jakiegoś kłopotu i idziemy dalej, a oni sobie już dzięki temu, co zaczęli z nami, mogą radzić sobie już zupełnie sami. Jeśli tematy Agile Coach’a interesuje Cię głębiej, to polecamy nasz odcinek 15, gdzie właśnie wspominamy, kim jest Agile Coach. Można go znaleźć pod adresem porzorzadnyagile.pl/15

Jacek: Kolejne pytanie. Dlaczego firmy zatrudniają Scrum Masterów, aby zarządzali zespołami, a nie pomogli organizacji? Potem się dziwią, jak Scrum Master mówi, że na przykład story pointy to nie metryka wartości lub Scrum Master pyta o Cel Produktu interesariuszy.

Kuba: Myślę, że skupię się przede wszystkim na tym początku, czyli te dwa konkretne przykłady to są jakieś szczegółowe kawałki historii. Natomiast osoba, która nam dała to pytanie pyta, dlaczego Scrum Masterzy są kierunkowani na zarządzanie zespołem. Myślę, że tutaj możemy troszkę też pobawić się trochę koncepcją, co to dokładnie znaczy, a nie pomocy organizacji jako takiej.

Jacek: Ja myślę tak, że pierwsza taka myśl, jak sobie czytam i myślę w ogóle o tym zjawisku, bo zgodziłbym się z taką obserwacją, że domyślnie Scrum Master jest lokowany w zespole. Może gdzieś tam w okolicach Product Ownera, ale myślę, że rzadziej. Natomiast ten aspekt organizacyjny, no to faktycznie czasem występuje, a czasem w ogóle nie występuje. I z czego to wynika? Moim zdaniem wynika to po prostu z niewiedzy osób, które decydują się na to, żeby w ogóle zwinność wykorzystać w organizacji. Wydaje mi się, że mogą trochę nie wiedzieć do końca, z czym to się je. Na zasadzie dobry Scrum Master przyjdzie i zacznie wiercić dziurę w brzuchu, jeśli chodzi o różne aspekty pracy organizacji. I tak naprawdę myślę, że większość zarządzających nie wie, że spory pożytek mogliby uzyskać dla firmy, jeżeli Scrum Master faktycznie będzie miał partnerów bądź partnerki po stronie organizacyjnej, po stronie managementu, żeby organizację zmieniać. Natomiast pytanie, czy w ogóle jest takie myślenie w głowach, że wprowadzając Scruma tak naprawdę wchodzimy na ścieżkę, która będzie oznaczała zmianę. No bo jeżeli nie jesteśmy gotowi na zmiany, to moim zdaniem nie ma co pakować się tu konkretnie w Scruma, no bo pytanie dotyczy Scrum Mastera.

Kuba: Też podzielam zdanie, że wiele organizacji właśnie tak się decyduje. Trochę lokuje się Scrum Mastera w pozycji zajmij się zespołem. To nie musi wcale być nic złego, ani nawet zamykać drogi, bo tutaj jak się z tobą zgadzam, tak może nadbuduje coś dalej. To, że organizacja, czy jakiś manager zatrudniający Scrum Mastera nie wie do końca, kim jest ta osoba, to jeszcze nie znaczy, że to jest z gruntu zły pomysł. Między innymi dlatego nie jestem wielkim fanem wyśmiewania się ze źle brzmiących ogłoszeń o pracę, bo autentycznie ta osoba szuka kogoś, kto się na Scrumie zna i może nie umieć jeszcze dobrze sformułować, czego potrzebuje. Ale jeśli chce spróbować zmiany, chce spróbować tego podejścia, to może jest tak, że jest pewnego rodzaju naturalna progresja. Najpierw pomogę swojemu zespołowi, osiągnę z tym zespołem jakiś poziom ulepszenia, oczywiście mający swoje limity, a dopiero później z wiarygodnością, którą mam wejdę wyżej. Zacznę zmieniać trochę organizację, być może małymi krokami, zacznę tam, gdzie jest łatwo, zacznę tam, gdzie jest większa przychylność, ale też zacznę rozszerzać i promieniować tą zmianą, którą mam. Więc to pytanie ma pewną tezę, że Scrum Master ma pomagać organizacji, no nie jestem do końca pewien, czy Scrum Master jest od tego, żeby pomagać organizacji, oczywiście przerysowuję teraz, ale powiedziałbym – Pomóż najpierw zespołowi. Z tego niech wyjdą wnioski, co trzeba zmienić w organizacji. Tych wniosków prawdopodobnie będzie kilkadziesiąt, nie wierzę, że będzie krótka lista. No i zacznij realizować tę listę, poszukaj sojuszników i zacznij od małej zmiany pierwszej na liście, albo tej, która jest realnie do uzyskania. Więc trochę jest takie pewne przeciwieństwo w tym pytaniu zawarte, z którym się trochę nie zgadzam.

Jacek: To tak, bo dwa ciekawe wątki się tutaj odkrywają. To może zacznę od tego ostatniego, o którym powiedziałeś. Zgodzę się, że obserwowałem wielokrotnie taki trend czy taką chęć rzucania się na rozwiązywanie problemów organizacyjnych, jednocześnie nie zajmując się zespołem. Co czasem wydawało mi się, że jest to taka odskocznia, na zasadzie w zespole nie idzie mi zbyt dobrze, tak za bardzo tego Scrum Mastera, czyli mnie nie kupują, no to sobie wskoczę na poziom organizacyjny, no i tam sobie coś porobię. To jest jeden aspekt. I tu faktycznie się zgodzę, zresztą sam miałem ze Scrum Masterami, których sam kiedyś rekrutowałem taką umowę, że najpierw musi być porządek z klientem, to akurat realia software house’owe. Następnie porządek w zespole i dopiero jak to jest zaopiekowane, to możemy sobie wychodzić na poziom organizacyjny. Natomiast mówię, że manager nie musi do końca wiedzieć. No to tak, moja ta empatyczna część mnie mówi, tak, jak najbardziej. I w takim pozytywnym scenariuszu to przychodzi ten Scrum Master i nagle się okazuje, że problemy w zespole to są problemy, które trzeba rozwiązać systemowo na poziomie organizacji i management z otwartymi rękoma pomaga, wspiera. No ale jest też ta ciemna strona tej historii, czyli Scrum Master wabiony fajnie brzmiącym ogłoszeniem o pracę, a na koniec się okazuje, że ma rozliczać zespół, pilnować zespół, właśnie zarządzać zespołem, no bo tutaj też dokładnie to słowo zostało użyte. Tak więc w zależności od organizacji to może przybrać różne kierunki, no i nie wszystkie z mojej perspektywy są korzystne.

Kuba: Tak i dobrze to wyłapałeś, bo to zarządzanie może mieć kilka smaków, jeśli to jest takie zarządzanie w rozumieniu Scrum Guide’owym, bycie liderem zespołu, pomoc w wykorzystaniu Scruma i zapewnienie tych wszystkich elementów takiego doskonalenia się zespołu, no to jak najbardziej tak. Natomiast jeśli to jest Scrum Master jako ukryty kierownik projektu i to w tym negatywnym znaczeniu, bez realnej pracy jako Scrum Master, no to będzie pewnie czerwona flaga i sygnał, że jednak trzeba poszukać się ponownie. Może jest tak, że to właśnie wymieniłeś kilka takich aspektów, na co zwracać uwagę, bo myślę, że tutaj w tle jest też w ogóle cała koncepcja rekrutacji. Pewnie niejedna osoba, która nas słucha, jest myślami przy rekrutacji albo wprost znajduje się w pewnym procesie, no to nie szukajmy zrozumienia Scruma jako takiego, ale szukajmy tego, czego się konkretnie oczekuje, jakie działania ta osoba ma wykonywać, na którą toczy się rekrutacja. Bo to też może być pewien sygnał z kim można rozmawiać i o czym i jakie czynności będzie się wykonywać tak na co dzień, tak naprawdę, tak w praktyce, zwłaszcza gdy uda nam się przebić te takie okrągłe słówka, czy to z żargonu scrumowego, czy z takiego Business English, pełnego górnolotnych pojęć, które tak naprawdę mogą znaczyć wszystko i nic.

Jacek: Self organizing hyperproductive.

Kuba: AI-powered.

Jacek: Dobrze, ostatnie pytanie dzisiejszego odcinka.

Kuba: Pytanie brzmi, czy Scrum Master nie powinien być rolą tymczasową? Czy nie byłoby łatwiej wspierać zespołu w samej organizacji, gdyby ludzie wiedzieli, że Scrum Master jest tylko na jakiś czas, na przykład na rok? Mam wrażenie, że często zespoły przyzwyczajają się, że Scrum Master bierze odpowiedzialność na siebie i w związku z tym odruch brania odpowiedzialności samemu wytwarza się słabiej.

Jacek: Czyli pytanie dotyczy trochę sensu istnienia roli Scrum Mastera, no i tutaj jakby wprost mamy pytanie, czy to nie powinna być rola tymczasowa i w szczególności ta druga część tego pytania jest interesująca, czyli to ryzyko, że jeżeli mamy Scrum Mastera i wiemy, że on zawsze będzie, to może się pojawić takie poczucie w zespole, że ten obszar, nad którym zwykle pracuje Scrum Master to jest jego, czy jej obszar. No więc my jako developerzy czy Product Owner, jeśli patrzymy na cały Zespół Scrumowy, tak naprawdę w pewnym sensie umywamy ręce, no bo mamy od tego SM-a. Fajne pytanie.

Kuba: Fajne pytanie. Spróbuje być trochę kontrowersyjny wyjątkowo. Uważam, że Scrum Master powinien być rolą tymczasową. I ten horyzont czasowy podany w przykładzie roku, to jest nawet moim zdaniem dosyć długo jak na tymczasowość. I gdzie tu kontrowersja? No bo oczywiście wiele firm zatrudnia bardzo dużo etatowych, zawodowych, profesjonalnych, wykształconych Scrum Masterów i ja nie mówię, że taka rola nie powinna istnieć. Ale jest tu pewne połączenie, śmiałem się z Jackiem szykując to pytanie, jest połączenie do pierwszego odcinka, gdzie mimo wszystko uważam, że Scrum Master to też może być rola dzielona, wyłoniona z zespołu, przekazywana raz na jakiś czas w zespole. I taki tymczasowy, może mniej profesjonalny Scrum Master może uniknąć tych problemów. Długofalowo w całej organizacji powinni być profesjonalni Scrum Masterzy, ale fajnie byłoby myśleć tą perspektywą, jeśli jesteś Scrum Masterem, to działaj tak, żeby mogło Cię za chwilę w tym zespole nie być i to bardzo mocno zmienia Twoją funkcję na Daily, na Retro. Uczenie zespołu samodzielności, uczenie zespołu brania na siebie pewnych rzeczy, dobór pewnych technik i przejścia z zespołem pewnej drogi, żeby zespół nie był od Ciebie uzależniony.

Jacek: Nie będzie kontrowersji, bo generalnie jakby mój mentor, moi mentorzy w czasach, kiedy zaczynałem mówili o Scrum Masterze, że on tak naprawdę powinien zniknąć. To jest w pewnym sensie idealny stan, do którego dążymy, ale co do zasady się zgadzam. W szczególności, że obserwuję sytuacje, w których Scrum Master staje się taką osobą, która na swoich barkach po prostu ma proces i trochę mam wrażenie, że zespoły, w sensie developarzy, się trochę od tego odcinają i wydaje mi się, że długofalowo to w ogóle nie jest droga, którą powinniśmy podążać. Ja sam osobiście, kiedy myślę o sobie jako konsultancie, który pracuje z organizacjami, to bardzo często komunikuję to wprost. Słuchajcie, ja nie chcę być plasterkiem na Wasze problemy, że będę ten plaster naklejał i dezynfekował ranę i potem znowu naklejał plaster. Ma być tak, że ja Was nauczę tego, jak tę ranę zagoić i jak ja odejdę, to tam ma być wszystko zdrowe, wszystko ma być poukładane. Tak samo patrzyłbym na Scrum Mastera. Nawet jeżeli to będzie rola na stałe, to moim zdaniem właśnie taki mindset w stylu tak muszę pracować z zespołem, z organizacją, że jak w pewnym momencie zniknę, to tak naprawdę nie powinno być aż tak źle. Teraz czy po prostu ta rola zostanie nienazwana i rozmasowana po zespole, czy tak jak wspomniałeś, będzie to rola rotacyjna, gdzie ja kiedyś w ogóle nie akceptowałem takiego podejścia, z czasem uważam, że jednak może to mieć sens i wręcz widziałem przypadki zespołów, które wspierałem. I tak naprawdę ta odpowiedzialność, nawet nienazwana jako Scrum Master, po prostu zaczynała żyć w zespole, ma sens. Więc myślenie, że wchodzę do zespołu i będę tu miał już na zawsze pracę, moim zdaniem jest błędem logicznym z perspektywy roli Scrum Mastera, czy odpowiedzialności.

Kuba: Myślę, że warto sobie to też tak ustawić, takie myślenie. W dużej organizacji prawdopodobnie ci zawodowi Scrum Masterzy ciągle będą potrzebni, ale takie wyzwanie dla każdego, kto nas słucha, kto jest w takiej funkcji zawodowego Scrum Mastera, czy organizacja jest gotowa do tego, żeby dać Ci nowy zespół, zabierając Ci dotychczasowy. Nie mam na myśli tego, że dostajesz drugi, trzeci, siedemnasty zespół na głowę, tylko że w Twoim zespole jest wystarczająco dobrze rozwinięta sytuacja, że albo można to przekazać jakiejś nowej osobie, albo w ogóle pozostawić ten zespół już dobrze rozkręcony. Czy jesteś już w takiej sytuacji? I daję to wyzwanie, bo to jest takie myślenie bardzo pobudzające do pewnej listy takich, no może luk, mówiąc biznesowo, gdzie jeszcze mój zespół nie jest gotowy. W jakich zagadnieniach jest jeszcze praca do wykonania. Wykonaj tę pracę. Bo w wielu organizacjach nie następuje tak duża fluktuacja, to jest złe słowo, ale może przesuwanie Scrum Masterów jak powinno być. Bo ja wielokrotnie rozmawiam z managerami, że właśnie no kurczę, dałbym nowego Scrum Mastera, albo dałbym najlepszego Scrum Mastera, jakiego mam, no ale przykładowy Maciek ma dwa kluczowe zespoły i dopiero co je rozkręca. Przykładowa Marysia dopiero ledwie wyszła z jakiegoś kryzysu, więc choć firma tego potrzebuje, to nie jest w stanie pewnych ruchów zrobić. I to jest oczywiście wymyślony przykład, ale bazuje na bardzo realnych historiach. Fajnie byłoby być gotowym jako Scrum Master do tego, żeby móc w krótkim, skończonym czasie przekazać swoją odpowiedzialność ze swojego dotychczasowego zespołu, żeby podjąć zespół, który dopiero się buduje, przejąć zespół, który jest w kryzysie, przejąć zespół po jakimś Scrum Masterze, który z jakiegoś powodu nie robił dobrze swojej roli w tym zespole. No i pytanie, czy jesteś gotowy, gotowa na to, żeby opuścić swój dotychczasowy zespół? Jak nie, zacznij robić, żeby być gotowym, a nie czekać na ten moment, gdy to się faktycznie wydarzy metodą jakąś taką siłową, albo po prostu zostaniesz na głowę jeszcze jeden zespół i to jeszcze zespół z kłopotami.

Jacek: Natomiast myślę, że to, żeby nie było tak kolorowo, myślę, że to, że Scrum Masterzy mogą w wielu organizacjach być rolą taką trwałą, wynika z pozytywnej zmiany, którą mogą zrobić w zespole. Tak jak powiedziałeś tego słowa, rozkręcać zespół. Bo z jednej strony możemy rozkręcać zespół, patrząc z perspektywy rozwoju produktu, wykorzystania podejścia zwinnego, żeby budować przewagę, a czasem obserwuję, że Scrum Master już robi zmianę na plus, tylko przez to, że zakontraktuje zespół, zaczyna budować zespołowość. Zrobi takie rzeczy, które, ja bym powiedział, chyba powinny już być zaadresowane w firmie i w zespole i nie powinno być tak, że dopiero wchodzi Scrum Master i zaczynamy budować zespoły. W sensie tak bym sobie to wyobrażał, natomiast moim zdaniem, rzeczywistość w firmach jest taka, że często ten Scrum Master musi założyć o wiele więcej czapek, niż by to wynikało tylko, tak patrząc z definicji roli ze Scrum Guide’a.

Kuba. Dobra, to będziemy kończyć. Odpowiedzieliśmy na 6 pytań. W poprzednim odcinku odpowiedzieliśmy na pytań 8, ale to nie wszystkie pytania, jakie zostały nam zadane. Wymienimy 5 odcinków, w których naszym zdaniem na pytania, na które nie odpowiedzieliśmy, których nie wymieniliśmy, odcinków, w których odpowiedzi już się znajdują. Wszystkie te odcinki wspomnimy, podamy ich też numer. Prosty mechanizm, który stosujemy, to każdy numer odcinka można wpisać po porzazdnyagile.pl łamane na, i wtedy zostaniesz przekierowany, przekierowana dokładnie do tego odcinka.

Jacek: Pierwszy materiał, który rekomendujemy, Zacznij kończyć, skończ, zaczynać. Odcinek 83.

Kuba: Pojawiło się też pytanie o wejście do nowego zespołu. Był o tym materiał z Scrum Master w nowym zespole. Odcinek 12.

Jacek: Pytania dotyczące pułapek odpowiedzialności, Product Ownera pokryliśmy w odcinku 56.

Kuba: Ktoś zadał nam też bardzo słuszne pytanie o wsparcie managera nad przekazaniem kontroli, odpowiedzialności. Poruszyliśmy ten temat w odcinku Pomoc managerom w pracy nad zmianą swojej postawy, 45.

Jacek: Natomiast temat zarządzania zależnościami zewnętrznymi, zakładając, że nie możemy zmienić aktualnej konfiguracji zespołu w konfiguracji strukturalnej, pokryliśmy w odcinku 104.

Kuba: Seria tych pytań była o tyle fajna, że na takie lub podobne pytania odpowiadamy też naszym klientom w ramach konsultacji online. Więc jeśli masz jakieś zagadnienia, które jest realnie problemem albo jakąś rozterką twoją zawodową w dowolnej funkcji, czy to scrummasterskiej, produktowej, czy managerskiej, zapraszamy do skorzystania z opcji porozmawiania z nami w formule konsultacji online. Więcej informacji na temat tego, jak to przebiega, wszystkie pytania oraz stawki znajdziesz na porzadnyagile.pl/konsultacje.

Jacek: Natomiast notatki do tego odcinka, artykuł, transkrypcję, zapis wideo znajdziesz na stronie porzadnyagile.pl/120.

Kuba: I to by było wszystko na dzisiaj. Dzięki, Jacek.

Jacek: Dzięki, Kuba.

Kuba: I do usłyszenia wkrótce.

The post Q&A cz.2 first appeared on Porządny Agile.