Q&A cz.2

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.

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.

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.

FAQ:  Q&A cz.2

Jak zbudować wiedzę produktową u nowego Product Ownera?

Zadbaj o okres przejściowy i przekazanie obowiązków od poprzedniego PO. Zbierz różne perspektywy osób, które znajdują się w organizacji, znają produkt, znają też historię drogi tego produktu do stanu obecnego. Może to okazać się nieocenione, choć zajmie dużo czasu.

Jak podejść do relatywnego szacowania w zespołach ze zjawiskiem silosów technologicznych i niską zastępowalnością?

Można zaprosić cały Zespół do próby szacowania. Ważne będą rozmowy po tym, jak już wszyscy zadeklarują swoje estymaty. Będą one różne, ale w dalszej rozmowie zajdzie transfer wiedzy i tajników danego kawałka produktu. Jeśli zespół ma otwartość na taką inwestycję czasową, będzie to krok w stronę zatarcia silosów kompetencyjnych.

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

Wbrew pozorom to nie agile wymyślił Agile Coach’a. Uważamy, że AC to realizacja bardzo starej koncepcji mistrza czy mentora. Czyli doświadczonej osoby, która przekazuje pewną wiedzę i uczula na wybrane aspekty osoby, które dopiero wchodzą w dany obszar wiedzy i umiejętności. Agile Coach to osoba z bardzo dużym doświadczeniem, która pomaga zwinnym zespołom.

Dlaczego firmy zatrudniają Scrum Masterów, aby zarządzali zespołami, a nie pomogli organizacji?

Obserwujemy, że często Scrum Master jest domyślnie lokowany w zespole, co czasami wynika z niewiedzy osoby zatrudniającej. W zależności od organizacji może to przybrać różne kierunki. Uważamy, że warto, by Scrum Master zbudował swoją wiarygodność poprzez pomoc Zespołowi i na tej bazie zaczął wpływać na zmiany w całej organizacji.

Czy Scrum Master nie powinien być rolą tymczasową?

Tak, Scrum Master powinien być rolą tymczasową. Działaj tak, żeby mogło Cię za chwilę w zespole nie być. Ucz członków Zespołu samodzielności, brania na siebie odpowiedzialności. Dobieraj  techniki działania i przejdź z Zespołem drogę zmiany, żeby proces nie był uzależniony od Twojej obecności.

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”

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.

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 j