Rola lidera merytorycznego w Scrumie

Jeśli jesteś szefem zespołu lub szefem danej grupy specjalistów, to możesz skorzystać z naszych rad na temat Twojej roli w Scrumie. Jedna z naszych podpowiedzi, to organizowanie wymiany wiedzy.

Na czym polega rola szefa konkretnego zespołu w Scrumie i co należy do jego obowiązków? Poznaj wskazówki, jakie mamy dla liderów merytorycznych w Zespołach Scrumowych. 

Ostatnio poruszaliśmy temat roli managera w Scrumie, tu z kolei zgłębimy ten temat i skupimy się na konkretnym typie managerów – liderów merytorycznych. Są to managerowie konkretnej grupy specjalistów (np. testerów). Jak sama nazwa wskazuje, odpowiadają oni również merytorycznie za swój zespół i rozwój zawodowy jego członków.

Rola lidera merytorycznego w Scrumie – nasze porady i wskazówki

1. Zbuduj wizję swojego obszaru

Chodzi tu o wysokopoziomowe wyobrażenie tego, jak obszar który masz pod swoimi skrzydłami, będzie się rozwijał i do czego będziecie wspólnie dążyć. Ważne, by wykształcić perspektywę jak jako lider chcę, żeby mój obszar funkcjonował i jak będę realizował ten proces zmiany.

Pracując w centrum Agile w jednej z firm, sami doświadczyliśmy, jak bardzo jest to wartościowe ćwiczenie, ponieważ przypominało rozproszonemu na co dzień zespołowi, dokąd tak naprawdę idziemy, co jest dla nas ważne, kto jest naszym klientem, co mamy dostarczyć organizacji i co tak naprawdę chcemy osiągnąć.

2. Dbaj o miary swojej sfery

Mamy tu na myśli posiadanie konkretnych miar (jakościowych czy np. technologicznych), które wskazują, jak funkcjonuje obszar, za który odpowiadasz.

Przykładowo, jeżeli jesteś liderem zespołu testerów i odpowiadasz za ich kompetencje merytoryczne, to warto ustalić jakie miary pokażą Ci poziom tego, co na co dzień robicie. Miary te umożliwią też obserwację realizowanych zmian i ich ewentualne usprawnianie, jeśli nie przynoszą oczekiwanych rezultatów. Pokażą też długofalowe trendy.

Nie chodzi tu o miary, jakie ma Zespół Scrumowy i analizuje je na Retrospektywie. To mają być miary typu wydajność czy stabilność.

Pamiętaj też, aby budować zrozumienie w zespole, po co te miary funkcjonują, aby nie były świadomie lub nieświadomie zafałszowane, np. poprzez nierzetelne czyszczenie ticketów.

3. Kształtuj warunki i narzędzia pracy

Buduj systemowe wsparcie, np. nowoczesne narzędzia, odpowiednie środowiska i techniki pracy, które będą de facto realizować tę wizję, o której pisaliśmy w pierwszym punkcie. Propaguj te metody i narzędzia, nawet jeśli nie są powszechne w Twojej organizacji i o ile to możliwe przesuwaj granicę ich wykorzystywania.

Innymi słowy, wyposaż członków swojego zespołu w konkretne rozwiązania, które pozwolą im lepiej pracować.

Ten punkt będzie szczególnie istotny, jeśli dopiero co dołączyłeś do organizacji i zaczynasz dostrzegać, że narzędzia tutaj wykorzystywane są nieefektywne lub niekompatybilne z podejściem, który chcesz promować.

Przykładem może być tu często przez nas obserwowana zmiana systemu obsługi repozytorium kodu, czyli na przykład przejście z SVN-a na GIT-a.

Może być tak, że osobiście będziesz musiał wykonać kawałek pracy, bo np. nikt wcześniej tego nie robił, nikt w firmie nie ma odpowiednich kompetencji. Może być też tak, że będziesz musiał porozmawiać z różnymi osobami, np. Product Ownerami, aby wygospodarlowali czas na daną rzecz w Backlogu Produktu.

4. Współpracuj z innymi liderami obszarów

Taka współpraca może mieć szczególne znaczenie, kiedy chcesz dobrze doprecyzować wszelkiego rodzaju punkty styku konkretnych kompetencji, np. testerów z programistami, którzy stanowią oddzielne zespoły.

Jeśli zechcesz w procesie usprawniania pracy dołączyć do zespołu testera w ramach pilotażu i przetestowania działania w inny sposób, to warto spotkać się i przedyskutować wszelkie niuanse dotyczące tej zmiany. W dłuższej perspektywie przyjdzie też potrzeba refleksji nad tym, jak ten konkretny tester odnajduje się w zespole, jak się zmienia rola dewelopera, czy widać pozytywne rezultaty. Tu właśnie bardzo pomocne będzie włączenie liderów innych obszarów, np. lider merytoryczny osób odpowiadających za front-end lub za back-end.

Z drugiej strony, chodzi też o to, żeby uniknąć budowania silosu czy lokalnej optymalizacji. Jest to duża pokusa, która i u nas się pojawiała. Jeśli będziemy zoptymalizowani tylko na siebie, będziemy idealni, będziemy perfekcyjni i będziemy bardzo dużo wymagać od innych profesji, to może to powodować konflikty, np. pomiędzy analitykami a resztą zespołu. Tu właśnie współpraca z liderami innych obszarów może wyprostować ten problem, ustalając proces wspólnego dążenia do jednego celu.

5. Działaj z zespołem w porozumieniu z nim

Wiąże się to z pewną niedogodnością, jaka dotyka wielu liderów merytorycznych, którzy z jednej strony odpowiadają za rozwój merytoryczny danego obszaru i realizację pewnej wizji, a z drugiej strony mają dosyć utrudniony dostęp do Zespołu Scrumowego, który stara się być bardzo autonomiczny i ma swoje własne spotkania.

Ten trudniejszy dostęp do poszczególnych osób wynika z tego, że mniej jest tych punktów zaczepienia, które są obecne np. w klasycznych metodach zarządzania poprzez delegowanie zadań i ich odbieranie.

Sugerujemy Ci, żeby nie zakładać, że Scrum zabrania rozmawiania ze swoimi ludźmi, bo nie jest to prawdą. Mocno Cię zachęcamy do działania w porozumieniu z zespołem i wspólne znalezienie złotego środka między tym, aby być w kontakcie i realizować pewną wizję Waszego obszaru czy właśnie się rozwijać merytorycznie, a jednocześnie nie zaburzyć celu biznesowego funkcjonowania danego Zespołu Scrumowego.

Przytoczymy pewien przykład z historii zawodowej Jacka, który odpowiadał za kompetencje zwinne, w szczególności za kompetencje Scrum Masterów. Aby mieć okazję do poznania sposobów pracy konkretnych osób w ich naturalnym rytmie, z uprzedzeniem dawał on znać, że chciałby pojawić się na Daily. Zwykle też przedstawiał, jak to będzie wyglądać i że nie będzie przeszkadzał i zaburzał przebiegu spotkania. Dzięki zebranym obserwacjom mógł on później je przedyskutować z osobą, którą w danym czasie rozwijał.

Istotne jest tu też, aby zespół miał sposobność zakomunikowania, że w danym momencie nie ma na to przestrzeni i zaproponowania innego sposobu współdziałania.

6. Opiekuj się ścieżką rozwoju

W sumie najpierw należałoby zadać sobie pytanie, czy jakakolwiek ścieżka rozwoju istnieje i czy pracownicy o niej wiedzą i ją znają. Jeśli ścieżka istnieje, to z ilu szczebli się składa? Jakie są wymagania merytoryczne na poziomie konkretnych stopni? Czy to są wymagania tylko techniczne, czy także wymagania związane z kompetencjami miękkimi?

Ponieważ nie każda organizacja taką ścieżkę posiada, to w gestii lidera merytorycznego leży jej ustalenie i opisanie lub stworzenie od podstaw. Warto też skonsultować z innymi jej sens i zebrać feedback od stricte zainteresowanych jej istnieniem. Należy ją także przedstawić pracownikom i dbać o jej implementację.

To nie musi być typowo korporacyjny system, nawet subtelne ustrukturyzowanie tego obszaru wprowadzi zrozumienie oraz transparentne oczekiwania od ludzi na każdym z etapów ich rozwoju w organizacji. Ważne jest też, aby pracownicy wiedzieli, co jest cenione, co jest wymagane, aby móc awansować w ramach swojego stanowiska.

7. Organizuj wymiany wiedzy

Jako lider merytoryczny, zwłaszcza w większych organizacjach, możesz być inicjatorem czy facylitatorem sytuacji, w których osoby rozproszone po różnych zespołach rzadko ze sobą współpracującymi mogą wymienić się wiedzą i skorzystać z doświadczenia kolegów i koleżanek z pracy.

Takie transfery wiedzy najlepiej przeprowadzać cyklicznie i nie muszą mieć one formy typowych szkoleń, a po prostu wspólnego dzielenia się wnioskami lub przykładami problemów, na jakie natrafili i jak je rozwiązali. Często przecież jest tak, że jeden zespół nie ma zupełnie pojęcia, jakie fajne projekty realizuje inny zespół, który siedzi po drugiej stronie ściany.

Przy okazji mówienia o wymianie wiedzy, to przypominamy, że trwają zapisy na warsztaty Labirynty Scruma, które odbędą się 22 i 23 września tego roku. Są to warsztaty dla osób, które już pracują w Scrumie i chcą dowiedzieć się, jak radzić sobie z najpopularniejszymi problemami w Scrumie. Więcej informacji znajdziesz na stronie labiryntyscruma.pl/szkolenie.

8. Rozwijaj ludzi ze swojego zespołu

Ta funkcja może przybierać wiele różnych form, jednak generalne założenie jest takie, że jako lider merytoryczny masz wiedzę i doświadczenie, aby dzielić się nimi ze swoim zespołem, a także inspirować i wspierać w kształtowaniu indywidualnych ścieżek rozwoju.

Możesz to robić, organizując spotkania jeden na jeden lub szkolenia. Dobrą opcją będzie także udzielanie informacji zwrotnych i podsyłanie interesujących artykułów, podcastów lub książek.

Zachęcamy też do uwzględnienia takiej perspektywy bardziej coachingowej, czyli rozmowy z ludźmi o tym, jak się rozwijają. Jest to o tyle istotne, bo jako lider merytoryczny niekoniecznie musisz dokładnie wiedzieć, co kto dokładnie robi, a duża część rozwoju pracowników będzie wynikała właśnie z ich codziennej pracy, realizacji konkretnych zadań, które mają w ramach kolejnych Sprintów. Taka rozmowa otwiera przestrzeń na to, żeby pobudzić ciekawość. Dopytując czy dana osoba używała jakiejś nowej technologii, czy już wykorzystała w pracy, to, czego się nauczyła ostatnio na szkoleniu – będziesz wzmacniać w ludziach tę perspektywę rozwoju i przy okazji przypominać, że jak jest to ważne.

Z własnego doświadczenia wiemy, że dla wielu osób jest istotne, aby lider zespołu był też autorytetem, od którego mogą się uczyć, który będzie inspirował i pomagał być jeszcze lepszym specjalistą czy ekspertem w danej dziedzinie. To zresztą jest częsty argument za wyborem tej, czy innej organizacji. 

To już wszystkie wskazówki, jakie mamy dla liderów merytorycznych, które zebraliśmy przez lata, pracując z różnego rodzaju zespołami i na różnych stanowiskach. Czy dodalibyście do tego coś jeszcze?
Jednocześnie mamy do Ciebie prośbę. Przygotowujemy produkt dla osób początkujących w tematyce zwinności i będziemy wdzięczni za odpowiedź na kilka pytań dotyczących tego, jak Ty uczysz się zwinności lub co polecasz osobom, które zgłębiają ten temat? Ankietę znajdziesz pod adresem porzadnyagile.pl/produkt. Pomożesz całej zwinnej społeczności, gdyż będziemy mogli stworzyć naprawdę wartościowy produkt.

Dołącz do dyskusji o tym odcinku na naszych social mediach

Chcesz przeczytać transkrypcję naszej rozmowy w tym odcinku podcastu? Czytaj poniżej!

Kuba: Odcinek, który przed Tobą jest rozszerzeniem poprzedniego. W tym powiemy o konkretnym typie managerów, którzy odpowiadają również merytorycznie za swój zespół i rozwój profesjonalny swoich ludzi.

Jacek: Zanim przejdziemy do meritum, krótka definicja i przykłady tego, co mamy na myśli, rozdzielając treści tych dwóch odcinków. Czyli widzimy tutaj dwa typy poukładanie roli managera. Pierwszy sposób to jest manager jako szef zespołu. I tutaj manager odpowiada wtedy za cały Zespół Scrumowy. Bez względu na kompetencje, po prostu wszystkie te osoby mają jednego managera. I drugi typ, to jest szef danej grupy profesjonalistów wchodzących w skład różnych zespołów. Czyli to może być lider testerów, czy na przykład chapter lead back-end’owców.

Kuba: Poprzedni odcinek, który jeśli jeszcze go nie znasz, znajdziesz albo pod adresem porzadnyagile.pl/91, albo po prostu w appce, prawdopodobnie poniżej na liście odcinków, jest nadal zasadny dla obu podtypów managerów. To znaczy te treści z poprzedniego odcinka były uniwersalne zarówno dla managera Zespołu Scrumowego, jak i managera danego typu profesji, np. UX-owców czy back-end’owców. Natomiast dla managerów takiej danej grupy profesjonalistów, tutaj w tytule nazwaliśmy to liderem merytorycznym, żeby się nie sugerować żadnym konkretnym modelem, czy sposobem tego, jak to jest poukładane w firmie. Mamy kilka dodatkowych porad na temat ich roli czy ich sposobu funkcjonowania zarówno w firmie, jak i w interakcji z Zespołem Scrumowym, które będą zawartością tego odcinka.

Jacek: I przechodząc płynnie już do konkretnych porad. Co byś wymienił Kuba jako pierwszą poradę dla takiego lidera merytorycznego?

Kuba: Pierwsza porada brzmi, zbuduj wizję swojego obszaru. I to jest bardzo istotna perspektywa lidera merytorycznego, żeby zbudować wysoko poziomowe wyobrażenie tego, jak ten dany obszar, nad którym mam opiekę, którym się zajmuję, jak on będzie się rozwijał, jaki on ma być i też jak będzie realizowany. Znaczy, jak ta prawdopodobnie wizja jest na temat tego, że tu będzie jakaś zmiana, że dzisiaj pracujemy tak, a chcemy pracować trochę bardziej tak, albo kompletnie zrewolucjonizować tę sferę. Więc potrzebna jest wizja tego, gdzie chcemy być, jak chcemy, żeby to funkcjonowało, jak ja chcę jako lider tego obszaru, żeby ten mój obszar funkcjonował i jak będę ten obszar realizować. To zaznaczy, jakimi krokami chcę, żeby to się powolutku zmieniało. Prawdopodobnie to będzie mnogość kroków. Też kroki, które będą powolutku po sobie następowały. Więc tutaj jest cała długofalowa wizja oraz też plan na najbliższych, parę kroków, żeby tę wizję realizować.

Jacek: Sam pamiętam, że jak pracowaliśmy razem w centrum Agile w jednej z firm, to mieliśmy zbudowaną taką wizję i było to bardzo wartościowe ćwiczenie, ponieważ przypominało rozproszonemu na co dzień zespołowi, dokąd tak naprawdę jedziemy, co jest dla nas ważne, kto jest naszym klientem i co tak naprawdę chcemy dostarczyć organizacji i co chcemy osiągnąć?

Jacek: Kolejna porada to dbaj o miary swojej sfery. To, co mamy tutaj na myśli, to fakt posiadania konkretnych miar, które wskazują nam, jak funkcjonuje nasz obszar, za który odpowiadamy. Przykładowo, jeżeli jesteśmy liderem odpowiedzialnym za kompetencje testerskie, no to warto zastanowić się, jakie miary pokazują nam kondycję tego, co na co dzień robimy. No i oczywiście warto na te miary spoglądać, patrzeć i obserwować, czy zmiany, które realizujemy razem z ludźmi, za których odpowiadamy, czy przynoszą rezultaty, których się spodziewamy, czy też może nie. I wtedy oczywiście warto zastanowić się nad tym, co usprawnić.

Kuba: I oczywiście mówimy w takim generalnym trybie, więc trochę trudniej o bardzo konkretne przykłady, ale w szczególności mamy na myśli tutaj miary, które są dla danego obszaru, dla danego naszego zagadnienia, którymi się opiekujemy, na przykład właśnie obszar testów, obszar front-endu, obszar User Experience, a niekoniecznie perspektywa miar konkretnego pojedynczego zespołu. Zespół na przykład Scrumowy sam odpowiada za te swoje miary, analizuje je na Retrospektywie. Natomiast wyobrażam sobie, że rolą takiego lidera merytorycznego jest też opieka nad takimi tematami wskrośnymi. Na przykład stabilność, na przykład wydajność, na przykład perspektywa procesowa też. Jak szybko wydajemy, jak sprawnie realizujemy jakieś konkretne kroki czy etapy, czy procesy. Więc tutaj te wszystkie aspekty miar są potrzebne do tego, żeby dobrze ten swój obszar mieć pod opieką. Wiedzieć, w jakiej jest kondycji, jakie też ma długofalowe trendy. A druga myśl o miarach to też to, że taka bardzo mocna przestroga również z osobistego doświadczenia, że takie miary potrafią być nam przydatne jako liderowi, ale niekoniecznie być zrozumiane przez ludzi, którzy w pewnym sensie kontrybuują do tych miar. Zwłaszcza jeśli bazujemy na miarach, które są zbudowane o na przykład deklaracje. To jest najtrudniejszy przypadek. Albo zbudowane o czynności, które ludzie wykonują, na przykład aktualizowanie jakichś statusów, w miarę rzetelne odświeżanie jakichś informacji. Tutaj budujmy oprócz tego, że opiekujemy się miarami, budujmy też świadomość, po co te miary w ogóle są. Propagujmy tę informację do ludzi z naszego zespołu, żeby na przykład nie oprzeć swoich miar o dane, które są świadomie albo nieświadomie zafałszowane, ponieważ ludzie w ogóle nie wiedzą, że ma znaczenie ustawienie na przykład statusu do testów, albo znaczenie ma wyczyszczenie jakichś ticketów do odpowiedniego jakiegoś etapu czy do odpowiedniej daty, czy do odpowiedniego momentu. My sobie na tym budujemy miary, a ktoś pod spodem robi to bardzo nierzetelnie, bo na przykład nie zdaje sobie sprawy, że to jest ważne albo niestety, ale ma interes w tym, żeby trochę inaczej pokazać rzeczywistość niż taka, jaką ona jest.

Kuba: Trzecia porada, jaką mamy dla lidera merytorycznego, to kształtuj warunki i narzędzia pracy. Mamy tu na myśli budowanie pewnych systemów, budowanie pewnych gotowych rozwiązań czy jakiegoś takiego szerszego procesu na to, żeby de facto realizować tę wizję, o której mówiliśmy w pierwszej posadzie. Czyli propagowanie, wprowadzanie, rozszerzanie, stosowania bardzo konkretnych narzędzi, bardzo konkretnych technik, realizacje bardzo konkretnych procesów, które powodują, że ta praca jest wykonywana. Z jednej strony patrząc na minimalnym poziomie, którego oczekujemy od wszystkich, albo patrząc od tej strony pozytywnej, że cały czas jest realizowana, ciągle coraz lepiej przez wykorzystywanie technik, które na razie nie są być może zbyt popularne w naszej organizacji, czy w naszych zespołach, czy poprzez też przesuwanie tej granicy, co jest nową normą. Ale od tej strony bardzo konkretnie mamy na myśli narzędziowej organizacyjnej. Po prostu wyposażenie członków zespołu w konkretne rozwiązania, które pozwalają im lepiej pracować.

Jacek: Ten punkt może być szczególnie istotny dla osób, które dołączyły do organizacji i odkrywają, że narzędzia, którymi organizacja dysponuje, są niekompatybilne z podejściem, który dana osoba chciałaby promować, albo po prostu są nieefektywne. I może to spowodować chęć uruchomienia procesu zmiany. Przykładowa taka zmiana, którą obserwuję w różnych firmach. To jest zmiana systemu obsługi repozytorium kodu, czyli na przykład przejście z SVN-a na GIT-a. Czy na przykład odkrycie, że w sumie fajnie by było, gdybyśmy mieli jednak jakiś serwer, który pomaga nam w ciągłej integracji po to, żebyśmy mogli dostawać na bieżąco feedback, na takim absolutnie poziomie czysto deweloperskim. I widzę tutaj rolę lidera, jako osoby, która być może czasem będzie musiała sobie tę ścieżkę do tych narzędzi wydeptać. No ale ostatecznie co do zasady powinno to podnieść jakość pracy, czy efektywność. Generalnie powinno przynieść porządne rezultaty.

Kuba: I tak dopowiem jedną rzecz, bo powiedziałaś wydeptać. Ja też tak trochę ogólnie i to mówiłem. Mamy tu na myśli z Jackiem zarówno te sytuacje, gdzie trzeba osobiście wykonać kawałek pracy. I może to być niezbędne, bo być może w całej organizacji niemal nikt inny nigdy tego nie robił, nie ma nikt kompetencji. No ale to też może być jakieś kształtowanie czy znalezienie czasów u różnych zespołów, porozmawianie z Product Ownerami, żeby to gdzieś znalazło się w Backlogach Produktów. Czy też inspirowanie zespołu, jeśli zespół na przykład ma jakąś przestrzeń na własne działania, żeby być może tam właśnie na przykład poprawić temat Continous Integration i w ramach tych działań raczej inspirować członków zespołu, a nie samemu to zrobić? Więc tutaj pewnie będzie mnogość sytuacji, zarówno od tej skrajności, gdzie ja zrobię sporo sam, aż po tą skrajność, gdzie w zasadzie raczej tylko przekazuję wizję i sygnalizuje, że warto byłoby coś zrobić, a ludzie się organizują, sami też wykonują te działania.

Jacek: Kolejna porada dla lidera merytorycznego, to współpracuj z innymi liderami obszarów. Taka współpraca może mieć szczególne znaczenie, kiedy chcemy dobrze doprecyzować wszelkiego rodzaju punkty styku konkretnych kompetencji. Takim przykładowym punktem styku może być współpraca testerów z programistami. Wyobraźmy sobie model, w którym zespoły deweloperskie nie posiadają kompetencji eksperckich. Testerzy to jest zupełnie oddzielne zespół. No i decydujemy się w jakimś tam procesie zmian, czy usprawniania sposobu pracy, dołączyć testera do zespołu pilotażowego i po prostu popróbować pracy w trochę inny sposób. To może wymagać spotkania się, podyskutowania, a pewnie w dłuższej perspektywie pewnej też obserwacji i refleksji, jak ten konkretny tester odnajduje się w zespole. Czy ta praca wygląda tak, jak wyglądała? Co powinniśmy zmienić? Jak się zmienia rola dewelopera? Jak się zmienia rola testera? Wszystkie te takie drobne niuanse, których celem jest zapewnienie efektywnej pracy, najprawdopodobniej będzie trzeba dogadać. I tutaj koniecznie warto do tej rozmowy włączyć liderów innych obszarów. Czyli na przykład to może być lider merytoryczny osób odpowiadających za front-end, czy lider merytoryczny ludzi odpowiadających za back-end.

Kuba: I trochę może tym razem ja negatywnie to ujmę. Chodzi też o to, żeby uniknąć budowania silosu, albo uniknąć lokalnej optymalizacji. Niestety, jest na to pokusa, a sam też jej kiedyś ulegałem, jako taki lider merytoryczny, że zrobimy sobie dobrze albo zrealizujemy wizję naszego obszaru, perfekcyjną, idealną, zgodną ze sztuką. Ludzie tak w Stanach uczą na konferencjach, jak my to realizujemy u nas w firmie. Tylko jeśli robimy to w oderwaniu od sąsiednich profesji, a zazwyczaj mówimy tutaj o zespołowej grze. Większość tych produktów jednak jest rozwijana zespołowo, z perspektywą różnych profesji. Jeśli my będziemy zoptymalizowani na siebie, będziemy idealni, będziemy perfekcyjni i będziemy bardzo dużo wymagać od innych profesji, to może się okazać, że niestety, ale zapraszamy do Zespołów Scrumowych. Jakiś taki ukryty konflikt, gdzie testerzy nie lubią się z programistami, albo analitycy nie chcą współpracować z resztą zespołu w taki sposób, jaki byłby potrzebny, jaki jest potrzebny po prostu biznesowo. Więc tutaj ta współpraca z innymi liderami obszarów może oznaczać też odrobinę dogadania się, może nawet kompromisów, a może przede wszystkim właśnie poszukania wspólnego celu i wspólnej realizacji tego. Każdy w swojej części, jako pewnego rodzaju przeciwieństwo takiego ciągnięcia kocyka w swoją stronę. Byle więcej na mnie, byle więcej do moich ludzi, żeby było lepiej dla mnie, żebym mógł się wykazać. Co może być bardzo toksyczne na dłuższą metę. Może też bardzo mocno, szybko się zemścić. No bo po prostu w ten sposób bardzo systemowo zaburzamy zespołowość konkretnych Zespołów Scrumowych, ale też psujemy tę perspektywę holistycznego usprawniania się całej organizacji, dążenia wspólnie do jednego celu.

Kuba: Piąta porada, jaką mamy, to działaj z zespołem w porozumieniu z nim. Mamy tu na myśli tę zagwozdkę, czy to zmartwienie wielu liderów merytorycznych, którzy jednocześnie odpowiadają za ten obszar, za proces, za realizację pewnej wizji. Odpowiadają też za rozwój merytoryczny, o czym jeszcze będziemy w tym odcinku wspominać. No, a jednocześnie mają dosyć utrudniony dostęp do Zespołu Scrumowego. Zespół Scrumowy ma swoje spotkania, ma swoje wydarzenia scrumowe. Raczej stara się też być bardzo autonomiczny. Więc taki lider merytoryczny w Zespole Scrumowym ma trochę trudniejszy dostęp do poszczególnych osób. Te osoby mają swoje Cele Sprintu, te osoby mają swoje Daily. Współpracują blisko w ramach swojego zespołu. I trochę jest mniej tych punktów zaczepienia, które być może w innych metodach, zwłaszcza tych takich klasycznych metodach zarządzania, mogły być realizowane poprzez jakieś cykle, czy rytmy takiego klasycznego zarządzania, z delegowaniem zadań i ich odbieraniem. Coś, co sugerujemy w tej paradzie, to to, żeby w szczególności nie zakładać, że od teraz to ja już nie mogę rozmawiać ze swoimi ludźmi, bo Scrum mi zabrania, co jest bzdurą. Scrum tego nie zabrania. Natomiast coś, do czego zachęcamy, to działanie w porozumieniu z zespołem. Czyli znalezienie tego złotego środka między tym, co jest moją potrzebą i tak naprawdę jest też potrzebą poszczególnych osób, żeby być w kontakcie, żeby realizować wspólnie pewną wizję naszego obszaru czy właśnie się rozwijać merytorycznie, ale żeby jednak swoimi działaniami nie zaburzyć tego, co jest ważne, co jest celem biznesowym funkcjonowania danego Zespołu Scrumowego.

Jacek: I dam przykład do tego, co Kuba mówi. W przeszłości odpowiadałem za kompetencje zwinne, w szczególności za kompetencje Scrum Masterów. I takie właśnie okazje do zobaczenia, jak konkretne osoby pracują, wykorzystywałem właśnie na zasadzie pytając, informując, że chciałbym się pojawić na przykład na Daily, żeby zobaczyć, jak funkcjonuje Scrum Master w takim swoim naturalnym środowisku. Więc zwykle to się wiązało z tym, że z wyprzedzeniem zespół dostawał taką informację. Gdy pojawiały się jakieś pytania, to na te pytania odpowiadałem. Zwykle też przedstawiałem, jak to będzie wyglądać. Czyli właściwie w ogóle mnie nie będzie. Będę gdzieś tam z boku, z tyłu. Czy po prostu się podłącze do spotkania. Natomiast jeżeli ktoś by chciał o coś zapytać przy okazji, gdzieś tam zupełnie na sam koniec, to też nie ma problemu. Natomiast co do zasady wszystkie te obserwacje, które mogłem zabrać, mogłem później wykorzystać do przedyskutowania ich z osobą, którą miałem okazję w tym konkretnym kontekście obserwować.

Kuba: Jacek, powiedziałeś przykład ze spotkaniami, ale wyobrażam sobie, że niektórzy liderzy merytoryczni też mogą mieć ochotę na przykład na współdziałanie z daną osobą w środku Sprintu, na zasadzie takiej codziennej pracy. Czyli na przykład praca w parze, programista i lider, czy może udział w jakichś takich merytorycznych dyskusjach w środku Sprintu, gdy jest na przykład rozpatrywana jakaś architektura albo rozwiązywany jakiś trudny problem. Natomiast tu clue sprawy jest w tym, że jest bardzo duża otwartość co do intencji tego, z jaką wchodzę do tego zespołu i też przestrzeń na to, żeby być może, zespół mógł w jakiś sposób dać sygnał. Taka, a nie inna interakcja, niekoniecznie jest w tej chwili nam potrzebna, albo możesz nam pomóc, ale w trochę inny sposób.

Jacek: Przedostatnia porada, którą mamy, brzmi opiekuj się ścieżką rozwoju. Właściwie główne pytanie, które trzeba byłoby sobie zadać, to, czy w ogóle istnieje taka ścieżka? Czyli, czy konkretna osoba, deweloper, wie tak naprawdę, o jakiej ścieżce rozwoju mówimy w tej konkretnej organizacji. Z ilu szczebli się składa taka ścieżka? Jakie są wymagania merytoryczne na poziomie konkretnych stopni? Czy to są wymagania tylko techniczne? Czy to są wymagania także miękkie? Tak więc warto, żeby taka ścieżka w ogóle istniała. Natomiast nie każda organizacja taką ścieżkę posiada. Tak więc rolą lidera merytorycznego może być, albo upewnienie się, że taka ścieżka w ogóle jest opisana. Upewnienie się, że jeśli tak jest, to, że ona faktycznie ma sens. Posłuchać może też feedbacku od osób, które na tej ścieżce na jakichś konkretnych poziomach się znajdują. A jeżeli takiej ścieżki nie ma, no to zainicjować stworzenie takiej ścieżki. Niekoniecznie to trzeba robić własnymi rękoma. Część pracy związanej z wytworzeniem takiej ścieżki można oczywiście zdelegować, natomiast na koniec dnia jednak oczekiwałbym, że taką pieczę i zapewnienia, że to w sensownej formie pojawi się w organizacji, zostanie sensownie przedstawione, po prostu jest odpowiedzialnością lidera merytorycznego, konkretnej ścieżki.

Kuba: I takie ścieżki dla niektórych mogą być kontrowersją, zwłaszcza jeśli przeżyli realizację tych ścieżek w taki bardzo korporacyjny sposób, czy w korporacyjnych systemach. Natomiast niezależnie od tego, czy wierzymy w takie podejście bardzo ustrukturyzowane, czy nie. Dla mnie argumentem za tym, żeby jakiś rodzaj ścieżki rozwoju istniał, nawet bardzo subtelny, bardzo tylko zarysowane, to jest bardzo konkretna klarowność i taka transparencja na temat tego, czego oczekuje się od ludzi na każdym z etapów ich rozwoju. Pd juniora czy jakiegoś stażysty. Ale też to jest szczególnie ważne dla osób, które chcą się rozwijać merytorycznie. Chcą dalej dostawać jakieś bodźce do rozwoju, jeśli chodzi o kolejne trudne projekty, wyzwania. Być może rozszerzanie swoich kompetencji technologicznych. No i to może być bardzo ważna sugestia czy bardzo ważny sygnał, co jest cenione, ale też co jest wymagane, żeby być może właśnie awansować, bym powiedział, w ramach swojego stanowiska, czy w ramach bycia coraz lepszym ekspertem. Ale również częścią ścieżki rozwoju mogą być kompetencje takie bardziej międzyludzkie, miękkie. Czyli na przykład od kolejnych etapów oczekujemy bycia mentorem dla młodszych kolegów, lepszym liderem takim merytorycznym w swoim zespole. Więc tutaj tych elementów, ścieżki rozwoju może być wiele więcej.

Kuba: I przedostatni punkt porady, bo poprzednio się Jacek trochę pomylił, ale już nie będziemy do tego wracać, to organizuj wymiany wiedzy. Zwłaszcza w większych organizacjach taka rola lidera merytorycznego może być rolą takiego katalizatora, inicjatora, facylitatora sytuacji, w której osoby rozproszone po różnych zespołach, być może kilkunastu, a nawet kilkudziesięciu zespołach, w zależności od wielkości firmy, osoby, które mało ze sobą współpracują, albo tylko okazjonalnie, coś tam z grubsza wiedzą, że coś się dzieje, mogą bardzo fajnie wymienić się wiedzą, zbudować to wspólne zrozumienie, skorzystać z doświadczeń kolegów i koleżanek, które mają w firmie. I w jakichś takich najlepiej cyklach, albo jasno zrozumiałych ramach dokonywać tego transferu wiedzy, czy dokonywać transferów, może bardziej wniosków z tego, co ludzie uczą się w różnych zespołach, co fajnego robią w ramach organizacji. To jest szczególne nieszczęście bardzo dużych organizacji, w których dużo fajnych rzeczy się dzieje. No i może się okazać, że niestety, ale dosłownie za ścianą pokoju fizycznego albo za ścianą pokoju wirtualnego, już kompletnie nie wiemy, że jakieś fajne doświadczenia płyną, że jakaś wiedza się zbudowała. Jest do tego okazja. Fajnie, jeśli taki lider merytorycznie zapewni jakiś sposób na to, żeby wymieniać się tą wiedzą.

Jacek: A skoro mówimy o wymianie wiedzy, to przypominam, że trwają zapisy na warsztaty Labirynty Scruma. 22 i 23 września tego roku. Warsztaty dla osób, które już pracują w Scrumie i chcą dowiedzieć się, jak radzić sobie z najpopularniejszymi problemami w Scrumie. Uczestnicy w ankietach podsumowujących wskazują wymianę wiedzy jako jedną z największych wartości tych warsztatów. Więc jeżeli szukasz takiej formy informacji, to zapraszam. Więcej informacji na stronie labiryntyscruma.pl/szkolenie.

Jacek: I tym razem ostatni punkt. I chyba się zgodzimy, że faktycznie to jest ostatni. Rozwijaj ludzi ze swojego zespołu. I to jest taki punkt, który może przybrać wiele różnych form. Natomiast jakby taka generalna koncepcja jest taka, że skoro jesteśmy liderami merytorycznymi, to oznacza, że jakąś merytorykę mamy. Najczęściej liderzy, których spotykam w takich rolach, mają za sobą doświadczenie. Przechodzili po jakiejś tam ścieżce rozwoju. Czy w tej konkretnej firmie, czy w poprzednich organizacjach, w których pracowali? Stąd też mogą tą wiedzą, którą mają się dzielić. I tutaj możliwości przelewania tej wiedzy, że tak powiem, na inne osoby, czy rozwijanie innych osób jest sporo, bo mamy i spotkania jeden na jeden. To może przybrać też formę podpowiadania na tym etapie rozwoju, na którym konkretna osoba się znajduje, może się przydać jakieś konkretne szkolenie. To może być też dzielenie się informacją zwrotną, czy takie zwykłe po prostu inspirowanie. Na zasadzie spójrz sobie na ten artykuł. Może zobacz sobie na tę książkę, a może podpatrzyć, jak osoba z zespołu X podchodzi do tematu Y.

Kuba: I do puli, którą Jacek wymienił. Dodałbym też po prostu taką perspektywę bardziej coachingową, czyli rozmowa z ludźmi o tym, jak się rozwijają. Duża część tego ich rozwoju będzie wynikała z ich codziennej pracy, realizacji tych konkretnych, kolejnych zadań, które mają w ramach kolejnych Sprintów. Tutaj ten styl coachingowy ma o tyle szczególne znaczenie, że zwłaszcza jeśli patrzymy tą perspektywą Zespołu Scrumowego, to być może jako lider merytoryczny, aż tak bardzo dokładnie nie wiem, co poszczególne osoby robią. Więc to tym bardziej mi otwiera przestrzeń na to, żeby bardziej może się zaciekawić i to autentycznie zaciekawić. Czy użyłeś jakiejś nowej technologii? Czy wykorzystałeś tą umiejętności, którą poznałeś w ostatnio na szkoleniu? Czyli gdzieś tak też wzmacniać w ludziach tą perspektywę rozwoju i tak przypominać, że jest to ważne i być może umówić się na jakiś rytm wzmocnień tych wszystkich innych działań, które Jacek powymieniał wcześniej. I ten lider merytoryczny, zwłaszcza jeśli jest też po prostu autorytetem dla danej osoby ze swojego zespołu, no to jest duża szansa, że będzie ważnym uczestnikiem takiej rozmowy i ważną osobą inspirującą do tego, żeby być lepszym w tym, co się robi. I wiem to sam po sobie jako pracownik. Wiem też to jako były manager, że to ma bardzo duże znaczenie, że wiele osób wybiera perspektywę danej konkretnej organizacji czy danego konkretnego zespołu również przez pryzmat tego, czy będę mógł się rozwijać, czy mam od kogo się uczyć. No i będę mieć od kogo się uczyć, jeśli będę miał kolegów i koleżanki w tej profesji, którzy są też dobrzy, albo na odpowiednim poziomie. I to wszystko sumuje te poprzednie punkty. Realizowana jest ta profesja zgodnie z jakąś wizją, stosujemy nowoczesne narzędzia. Składową tego wszystkiego będzie też po prostu bardzo dobry lider, który pomaga mi się rozwinąć, pomaga mi przesunąć tę granicę tego, co jest możliwe, co umiem, co z czym się czuję komfortowo, gdzieś wyżej, gdzieś w nowe rejony.

Kuba: Podsumowując cały odcinek. Co możesz robić jako lider merytoryczny w Scrumie? Zbuduj wizję swojego obszaru. Dbaj o miary danej sfery. Kształtuj warunki i narzędzia pracy. Współpracuj z innymi liderami obszarów.

Jacek: Działaj z zespołem w porozumieniu z nim. Opiekuj się ścieżką rozwoju. Organizuj wymiany wiedzy i rozwijaj ludzi ze swojego zespołu.

Kuba: Kontynuujemy nasz wątek przygotowywania produktu dla osób początkujących w tematyce zwinności. Ostatnio prosiliśmy o kontakt osoby początkujące w temacie zwinności, a tym razem chcemy poprosić wszystkich słuchaczy o udział w ankiecie.

Kuba: Odpowiedz proszę na parę pytań pod adresem porzadnyagile.pl/produkt i daj nam znać jak Ty uczysz się tematyki zwinności. Jakie źródła polecasz swoim znajomym, którzy chcą się Agile’a nauczyć. Odpowiedzi, które uzyskamy pozwolą nam lepiej zrozumieć perspektywę, której my sami możemy już nie mieć. Możesz też w ten sposób pomóc nam zrobić wartościowy produkt dla całej społeczności. Trzymajcie za nas kciuki, bo będziemy o tym, co szykujemy wspominać coraz częściej. Przypominam ankieta do wypełnienia na stronie porzadnyagile.pl/produkt.

Kuba: A notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo z naszej rozmowy znajdziesz na stronie porzadnyagile.pl/92

Jacek: I to by było na tyle. Dzięki Kuba.

Kuba: Dzięki Jacek i do usłyszenia wkrótce.

Daj nam znać co sądzisz o tym odcinku


Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Newsletter „Porządny Agile”

.

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial