Porządny Agile

Praca nad wieloma produktami jednocześnie w jednym zespole może być wyzwaniem. Jak sobie z tym poradzić? Jednym ze sposobów jest skoncentrowanie całej organizacji na priorytetach i ograniczenie liczby otwartych tematów. Pozostałe praktyczne wskazówki, które pomogą Twojemu zespołowi lepiej organizować pracę i zwiększać wydajność, znajdziesz w tym nagraniu.

Spis treści

• Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematów
• Zmniejsz liczbę tematów przekazywanych do zespołów jednocześnie 
• Zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produkt
• Realizuj inicjatywy produktowe w sposób sekwencyjny
• Wyodrębniaj esencję z tego, co jest do zrobienia
• Twórz dynamiczne podzespoły, skupione na wybranych obszarach
• Rozwijaj bardziej uniwersalny profil kompetencyjny członka zespołu
• Transkrypcja podcastu „Jak radzić sobie z wieloma produktami w jednym zespole?„

Zaczynając od pierwszej rekomendacji, skup całą organizację na priorytetach i zredukuj listę otwartych tematów. To fundamentalne zagadnienie, dlatego rekomendujemy rozpoczęcie od najwyższego szczebla. Działania na niższych poziomach, takich jak zespoły, mogą nie być tak skuteczne, jeśli nie rozwiążemy problemu u źródła. Tym źródłem jest strategia organizacji i jasna wizja tego, co ma być realizowane oraz dlaczego wybraliśmy konkretne inicjatywy. Redukcja liczby otwartych tematów na najwyższym poziomie to najbardziej systemowy i sensowny krok, jeśli chcesz ograniczyć liczbę inicjatyw w zespołach.

Mamy przykład z naszego doświadczenia zawodowego, kiedy mieliśmy przyjemność uczestniczyć w warsztatach strategicznych, gdzie wraz z całym zarządem analizowaliśmy strategię naszego produktu i porównywaliśmy ją z kluczowymi konkurentami, wobec których chcieliśmy się pozycjonować. Wsparci przez doświadczonych mentorów, zrozumieliśmy, że zarządzanie strategiczne polega na podejmowaniu kluczowych decyzji dotyczących tego, co będzie naszą przewagą konkurencyjną, z pełną świadomością rzeczy, które będą słabsze z naszej strony. 

Dzięki tym warsztatom i świadomej, wspólnej decyzji o tym, na czym się skupiamy i co będzie cenione przez rynek oraz klientów, stworzyliśmy solidny fundament. Na jego podstawie mogliśmy wyznaczyć konkretne inicjatywy produktowe i określić, na czym poszczególne zespoły powinny się skupić.

W tej samej organizacji, zanim doszło do tej strategicznej rozmowy, przez kilka lat realizowano dość przypadkowe projekty. Przynosiły one wartość biznesową, generowały zyski i były sensowne z rynkowego punktu widzenia, ale pochodziły z bardzo różnych kategorii. W efekcie generowały dużą różnorodność wątków podejmowanych przez zespoły.

Ustalenie strategicznych priorytetów i wybór kluczowego aspektu, na którym skupia się cała organizacja, pozwoliły łatwo wyznaczyć priorytety dla poszczególnych zespołów.

Jeśli nie udało się osiągnąć zgody, o której wspominaliśmy w powyższej historii, i wciąż istnieje szeroka lista tematów oraz inicjatyw do realizacji przez zespoły, proponujemy ograniczenie liczby tematów przekazywanych jednocześnie. Chodzi o świadomość na poziomie najwyższego kierownictwa, że przekazywanie wielu tematów naraz niekoniecznie poprawi efektywność pracy, a w szczególności nie sprawi, że tematy zostaną dostarczone wcześniej.

Sensownym punktem wyjścia może być umowa, że jeden zespół otrzymuje jeden konkretny cel na raz. Ten cel nie musi oznaczać pojedynczego elementu w produkcie; może obejmować wiele zadań do zrealizowania w ramach konkretnego produktu. Jednak wciąż poruszamy się w wyselekcjonowanym, konkretnym obszarze.

Narzędziowo najczęściej przekłada się to na roadmapę skupioną na celach, gdzie cele są realizowane sekwencyjnie. Nawet jeśli organizacja nie ma w pełni przemyślanej strategii lub nie jest ona wystarczająco wyrazista, warto, aby zarządzający produktem, kluczowi sponsorzy czy menedżerowie większych obszarów skupili uwagę zespołu na jednym celu w danym momencie. Gdy ten cel zostanie zrealizowany w satysfakcjonujący sposób, można przejść do kolejnego.

Nawet jeśli cele są ze sobą luźno powiązane, ważne jest, aby zespół mógł pracować nad nimi w bardziej skoncentrowany sposób. W praktyce oznacza to stworzenie roadmapy skupionej na celach, co podkreślamy jako coś innego niż roadmapa z planowanymi funkcjami czy cechami produktu lub planem realizacji prac. Roadmapy często kojarzą się z datami, ale w tym przypadku wyobrażam sobie roadmapę przypominającą drzewko rozwoju technologii w Cywilizacji, gdzie najpierw skupiamy się na rozwoju metalurgii, a potem zmieniamy sposób zbierania owoców. Tę analogię można przenieść na Twój produkt.

Trzecia porada dotycząca radzenia sobie z wieloma produktami to zreorganizowanie zakresu odpowiedzialności zespołów, aby każdy obejmował jeden konkretny produkt. Zakładamy tutaj, że mnogość jednocześnie realizowanych zadań wynika z nieoptymalnie ustalonych granic odpowiedzialności zespołu. Może warto ponownie przedyskutować, czy zespół nie obejmuje zbyt dużego obszaru lub nie jest przypisany do niego w niefortunny sposób, co skutkuje koniecznością jednoczesnej realizacji kilku tematów. W efekcie w tym konkretnym zespole pojawia się więcej niż jeden priorytet, który dodatkowo jest pilny, przez co nasze dwie poprzednie porady nie mogą zostać zastosowane. Jak to może wyglądać w praktyce?

Pomagaliśmy pewnej organizacji w usprawnieniu funkcjonowania zespołów, aby osiągnąć lepsze wyniki biznesowe. Zespoły te były zorganizowane wokół technologii, co powodowało, że nawet drobna, czysto biznesowa zmiana wymagała zaangażowania wielu zespołów, zanim użytkownicy mogli z niej skorzystać.

Management postanowił więc zreorganizować zespoły tak, aby nie były one skupione na konkretnej technologii, lecz na określonych obszarach biznesowych. Powstała konkretna tabela w Excelu, która proponowała, jakie to mogłyby być obszary biznesowe.

Równocześnie zespoły przygotowały listę tematów technologicznych, nad którymi pracują. Na tej podstawie rozpoczęła się wieloetapowa, trwająca kilka tygodni dyskusja na temat najlepszego sposobu przeorganizowania się. Celem było, aby zespoły mogły maksymalnie skoncentrować się na konkretnym produkcie, wykorzystując jednocześnie posiadaną wiedzę technologiczną i minimalizując zmiany w składzie zespołów.

Oczywiście nie było to w pełni możliwe, więc wprowadzona zmiana uwzględniała, że niektóre osoby musiały zmienić zespół. Pojawiły się też nowe odpowiedzialności technologiczne w zespołach, a niektóre dotychczasowe obowiązki zostały przekazane innym zespołom.

Z naszego doświadczenia udziału w kilku takich sytuacjach wynika, że nie ma gotowej odpowiedzi na to, jak podzielić zespoły. Nawet podział według kryteriów biznesowych to dość ogólne stwierdzenie. Doświadczenie podpowiada nam, że organizacje wypracowują odpowiedni dobór produktów iteracyjnie, najczęściej w trakcie dłuższych dyskusji, uwzględniając wiele czynników. Co ważne, prawdopodobnie za pierwszym razem nie uda się osiągnąć idealnego i trwałego efektu. Dlatego warto z góry założyć, że sposób podziału będzie doskonalony w przyszłości, a może organizacja przejdzie na tryb ciągłego, elastycznego reorganizowania zespołów, ponieważ produkt się zmienia, zmienia się cykl życia lub chcemy dostosować się do nowych rynków czy trendów.

Zbliżamy się tutaj do bardziej realistycznego podejścia, może nawet nieco pesymistycznego. Załóżmy, że poprzednich zaleceń nie udało się wdrożyć lub nie przyniosły one pełnych oczekiwanych efektów. W takiej sytuacji nawet jeśli na poziomie strategii, zadań przekazywanych zespołom czy odpowiedniej struktury organizacyjnej panuje pewne zamieszanie, wciąż można wiele zrobić na poziomie osoby decydującej o priorytetach w zespole.

W niektórych zespołach taką osobą jest Product Owner, w innych Product Manager. Niezależnie od nazwy, jest to decydent, który może postanowić, że mimo mnogości zleceń, inicjatyw, pomysłów czy różnych celów, będą one realizowane w danym zespole w sposób sekwencyjny, czyli po kolei. Najpierw jedna rzecz — ta najważniejsza lub najpilniejsza — a dopiero potem kolejne. Dzięki temu ograniczamy wielozadaniowość, minimalizujemy przełączanie kontekstu i być może przyspieszamy realizację tego, co jest naprawdę istotne.

Ten przykład doskonale pokazuje, jak ważne jest, aby osoba na ww. wspomnianym stanowisku wykazała się odwagą, praktycznością oraz asertywnością w mówieniu „nie”. Konieczne będzie zatrzymanie pewnych inicjatyw, wyraźne wskazanie, co musi poczekać i co zostanie zrealizowane w dalszej kolejności, aby stworzyć przestrzeń na realizację tego, co w danym momencie jest najważniejsze.

Trudno jednoznacznie określić, co jest w danej chwili najważniejsze —  może to być najbardziej obiecująca inicjatywa, pilne spłacenie długu technologicznego (na przykład z powodu utraty wsparcia dla używanej technologii) lub dostosowanie się do konkretnych, nieprzesuwalnych terminów. Na przykład musimy wprowadzić zmiany w produkcie ze względu na nadchodzące zmiany prawne i upewnić się, że nasz produkt spełnia nowe wymagania.

To podejście nie jest intuicyjne; wciąż pokutuje przekonanie, że jeśli robimy wiele rzeczy naraz, ukończymy je szybciej. Nie wiemy, skąd to się bierze. Literatura i praktyka są tu bezlitosne. Mantra „zacznij kończyć, przestań zaczynać” jest naszym zdaniem czymś, na czym warto się oprzeć.

Jedną z przyczyn, dla których zespoły mają trudności z realizacją wielu inicjatyw produktowych jednocześnie, może być fakt, że te inicjatywy są zbyt duże i trwają długo. Pod naporem priorytetów lub spraw, które nie mogą już czekać, pojawia się wielozadaniowość, która zaczyna być uciążliwa.

Zdolność do dzielenia zadań jest umiejętnością, której trzeba się nauczyć. Zespoły, które to potrafią, oraz osoby zarządzające priorytetami, umiejące określić, co w danym projekcie jest kluczowe, a co mniej istotne, są w stanie szybko dostarczać mniejsze fragmenty inicjatywy. Dzięki temu mogą podjąć decyzję, co zrobić z pozostałą częścią: czy ją wstrzymać i przystąpić do kolejnej inicjatywy, czy może całkowicie z niej zrezygnować, jeśli tak wskaże feedback z rynku. Czasem okazuje się, że po dostarczeniu pewnej części, reszta nie jest już tak bardzo potrzebna.

Klasycznym przykładem, który niezmiennie obserwujemy, jest przepisywanie systemu, zmiana platformy czy technologii, gdzie mamy już gotowy produkt z pewnymi funkcjami, z którego można korzystać, ale mimo to przepisujemy go od zera. Bardzo często takie przepisywanie odbywa się moduł po module, dosłownie jeden do jednego. Przechodzimy kolejno przez produkt i dopiero gdy wszystko zostanie przepisane, możemy powiedzieć: „OK, to jest zrobione.”

Zdecydowanie rekomendujemy krytyczne podejście do takiego przepisywania. Warto zastanowić się, co tak naprawdę jest esencją tego produktu i co jest najczęściej używane. Należy zaczerpnąć informacji zwrotnej od faktycznych użytkowników systemu i dopiero wtedy podjąć decyzję, co warto dostarczyć na wczesnym etapie. Przy okazji pojawi się refleksja, że nie wszystko dosłownie jeden do jednego, co znajduje się w obecnym produkcie, jest nam potrzebne w nowej wersji.Jeśli potrzebujesz wsparcia w dekompozycji produktu, zachęcamy do obejrzenia naszego webinaru, gdzie przedstawiamy 9 sposobów na podział produktu i omawiamy na przykładach, jak wdrożyć je w zespole produktowym. Materiał znajdziesz pod adresem porzadnyagile.pl/deko.

Akceptujemy fakt, że tematów jest wiele, więc warto podejść do tego zwinnie i elastycznie. Możemy mądrze podzielić zespół, tak aby wybrane osoby, dysponujące konkretnymi kompetencjami, skupiły się na określonych obszarach. Zamiast sytuacji, w której wszyscy są zaangażowani we wszystko, co bywa przytłaczające, warto określić priorytety i przydzielić podzespoły lub grupy w ramach zespołu do konkretnych zadań. Dzięki temu członkowie zespołu będą pracować w bardziej komfortowych warunkach, skupiając się na wybranych, konkretnych obszarach.

Oczywiście to podejście zakłada, że zespół jest nieco większy, że jest kogo dzielić, że można na przykład podzielić go na pół, a zespół nadal zachowa zdolność dostarczania rozwiązań. Sami byliśmy świadkami kilku odmian realizacji tej praktyki i w skrócie najczęściej wygląda to tak: podczas planowania iteracji czy Sprintu albo planowania dłuższego okresu — na przykład kwartału czy czasu realizacji największej inicjatywy trwającej kilka tygodni — zespół w ramach samoorganizacji ustala, kto jest potrzebny do zrealizowania danego przedsięwzięcia. Ludzie tymczasowo przydzielają się do tej inicjatywy i na czas jej realizacji działają jako podgrupa w ramach zespołu, aż nie potrzebują wrócić do swojego pierwotnego zespołu, czy to po pomoc, czy dlatego, że zakończyli dane przedsięwzięcie w satysfakcjonujący sposób.

Mamy tu więc do czynienia z pewnego rodzaju podziałem. Ten podział jest tymczasowy, więc nie ma potrzeby dokonywania większych reorganizacji. Jest on również bardzo elastyczny; są zespoły, które częściowo go stosują, a częściowo nie. To oznaka dojrzałości zespołu, który potrafi się dostosować i być może przełamać zasadę, że absolutnie wszyscy robią wszystko równocześnie  — wspólne wielkie Daily, wspólne wielkie planowania, wspólne wielkie warsztaty — co może przynosić niewielką wartość dodaną, a generować duże koszty. Jest to oczywiście kwestia dojrzałości zespołu, umiejętność, którą trzeba z zespołem wypracować, ale jest to jeden z ostatnich w naszym przypadku sposobów na poradzenie sobie z wieloma produktami realizowanymi jednocześnie.

Zdarza się, że obecne kompetencje w zespole sugerują zrównoleglenie inicjatyw, ponieważ w jednej z nich brakuje pracy dla niektórych specjalistów. Prowadzi to do sytuacji, w której Product Owner, Product Manager lub inna osoba decydująca o zadaniach zespołu jest zmuszona uruchamiać kolejne wątki, aby zapewnić pracę wszystkim członkom. Czyli po prostu, żeby każda osoba miała zajęcie.

Przykładem ilustrującym tę sytuację jest historia z pewnego zespołu IT, z którym był owocny okres współpracy. Podczas planowania kolejnego etapu prac jedna z programistek zauważyła: „Ciągle robię API”. Wszyscy myśleli, że po prostu zgłasza się po kolejne zadanie, ale po chwili dodała: „Chciałabym robić coś innego”. Ten moment okazał się przełomowy dla zespołu. Zamiast przydzielać te same zadania tym samym osobom, postanowiono zamienić się rolami i podjąć inne wyzwania niż zazwyczaj.

W efekcie doszło do wartościowego miksu kompetencji i transferu wiedzy na różnych częściach systemu. Nowe osoby zaczęły pracować nad obszarami, które wcześniej były rozwijane przez jedną lub dwie osoby, co pozwoliło na refaktoryzację i świeże spojrzenie na projekt. Zespół stał się bardziej uniwersalny, co odciążyło Product Ownera od konieczności generowania pracy dla wysoko wyspecjalizowanych specjalistów. Teraz mógł skupić się na celach produktu, wiedząc, że zespół samodzielnie poukłada swoją pracę.

Oczywiście w krótkim okresie takie podejście może wiązać się z tym, że osoby mniej doświadczone w danym obszarze będą pracować trochę wolniej. Jednak w średnim okresie sytuacja zaczyna się wyrównywać, a w długim zespół zyskuje zdolność do podejmowania różnorodnych zadań. Dzięki temu może szybko realizować to, co jest w danym momencie najważniejsze dla produktu.

Jeśli nawet te ostatnie punkty, które sugerowaliśmy — będące już pewnym kompromisem lub wykorzystaniem dostępnych nam możliwości — nie wydają się realistyczne w twoim kontekście, obawiamy się, że możesz mieć inny, znacznie większy problem niż tylko radzenie sobie z wieloma inicjatywami produktowymi jednocześnie. Co mamy na myśli, pisząc takie enigmatyczne stwierdzenia?

W naszym materiale zawarliśmy wiele porad. Pierwsze z nich są strategiczne, systemowe i ogólnoorganizacyjne. Kolejne dotyczą podejmowania decyzji. Ostatnie skupiają się na tym, jak radzić sobie poprzez zorganizowanie się. Jeśli nie jesteś w stanie zapewnić, że zespół się organizuje, lub istnieją blokady uniemożliwiające to, obawiamy się, że zespół może nie mieć możliwości decydowania o swoim procesie pracy. Może też być tak, że osoby pełniące role liderskie w zespole nie są słuchane. Może się okazać, że brak usprawnień w tym aspekcie jest jedynie symptomem tego, jak niesamodzielne i nadmiernie kontrolowane managersko są zespoły czy zasoby, które bezpośrednio w tym zespole nie pracują. To tylko hipoteza, być może nietrafna, ale postanowiliśmy zostawić to pytanie i refleksję na koniec.

Ten artykuł to jedynie fragment tego, co oferujemy w naszych programach rozwojowych dla osób zarządzających produktami w zwinnych zespołach. Wspieramy rozwój kluczowych kompetencji: budowanie strategii, tworzenie Roadmap, dzielenie pracy na mniejsze zadania oraz efektywne planowanie pracy w zespole. Nasze podejście łączy praktyczne warsztaty, mentoring i superwizję realnych inicjatyw, aby maksymalnie wspierać uczestników w codziennej pracy. Jeśli potrzebujesz takiego wsparcia, skontaktuj się z nami przez stronę porzadnyagile.pl/kontakt.

Kuba: Ostatnio z Jackiem mieliśmy okazję wziąć udział w dyskusji z pewnym Product Ownerem. Chciał się poradzić w temacie radzenia sobie z wieloma produktami rozwijanymi w jego zespole równocześnie. Wynikiem tej rozmowy była lista porad, którą postanowiliśmy zamienić na treść tego odcinka.

Jacek: Tematem odcinka jest „Jak radzić sobie z wieloma produktami w jednym zespole”. Będziemy starali się w tym odcinku być bardzo wyraziści i bardzo konkretnie rekomendować pewne kroki. Natomiast już nawet krok w stronę tych rekomendacji może dla Twojego kontekstu okazać się usprawnieniem.

Kuba: Jeśli pracujesz w projektach z typowym podejściem związanym z zarządzaniem projektami i inicjatywami projektowymi, możemy polecić inny materiał, więc ten, który właśnie się rozpoczyna. Nagraliśmy kiedyś odcinek „Mamy zbyt wiele projektów, co robić”. Do znalezienia pod adresem porzadnyagile.pl/67. Ten odcinek jest podobny do tego, co właśnie zaraz przedstawimy. Ale jednak w tamtym bardziej skupiamy się na perspektywie projektów i portfeli projektów. A ten konkretny odcinek, który właśnie się zaczyna, będzie skupiony wokół wątku rozwoju produktu.

Jacek: Ok. Czyli przechodząc do sedna odcinka. Jak radzić sobie z wieloma produktami? Pierwsza porada brzmi. Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematów. Temat jest dosyć fundamentalny i jak słyszysz, rekomendujemy, żeby zacząć od samej góry. Wszystkie inne działania, które możesz realizować gdzieś niżej na poziomie zespołów, mogą nie być już tak skuteczne, jeżeli nie zaczniemy rozwiązywać problemu u źródła. A źródłem jest strategia organizacji, pewna wizja na to, co będzie realizowane i dlaczego właśnie konkretnie takie, a nie inne inicjatywy. Redukcja otwartych tematów na poziomie od samej góry jest naszym zdaniem takim najbardziej systemowym i sensownym punktem zaczepienia, jeśli chcesz ograniczyć liczbę inicjatyw w zespołach.

Kuba: I mam tutaj przykład z osobistego doświadczenia w miarę na początku swojej kariery zawodowej. Miałem bardzo dużą przyjemność wziąć udział w takich warsztatach strategicznych, gdzie całą organizacją, a w zasadzie to managementem całej organizacji zastanowiliśmy się nad tym, jaka jest strategia naszego produktu, jak wypada nasza strategia na tle najważniejszych konkurentów, względem których chcieliśmy się pozycjonować. No i mieliśmy w tym materiale też bardzo ważnych mentorów, którzy nam bardzo pomogli z jednym założeniem. Zarządzanie strategiczne wiąże się z podejmowaniem kluczowych decyzji na temat tego, co będzie naszą przewagą, co chcemy, żeby było naszą przewagą, ale też z pełną świadomością pewnych rzeczy, które będą słabsze z naszej strony. Czyli odwracając, będą przewagą konkurencji na naszym tle. No i tutaj zrealizowane warsztaty strategiczne i świadoma wspólna decyzja na temat tego, na czym się skupiamy, co będzie przewagą konkurencyjną, co jest naszym założeniem, co do tego, co będzie też cenione przez rynek, przez klientów, było pewnym fundamentem, z którego później dopiero wyciągaliśmy wątki typu konkretne inicjatywy produktowe, konkretne rzeczy, nad którymi kolejne zespoły produktowe mogły się skupić. W tej samej organizacji bez tej rozmowy o strategii wcześniej, przez parę lat, realizowane były rzeczy dość losowe, które przynosiły wartość biznesową, które zarabiały na siebie, które nawet były rozsądne rynkowo, ale one były naprawdę z bardzo różnych kategorii i w efekcie też generowały bardzo dużą różnorodność wątków podejmowanych przez wybrane zespoły. Dzięki ustaleniu strategicznych priorytetów, dzięki wybraniu tego kluczowego aspektu, na którym się cała organizacja skupia, z tego łatwo było później wywieźć też priorytety dla pojedynczych zespołów. 

Jacek: I takiego podejścia byśmy życzyli każdej organizacji. Natomiast jeżeli nie jesteś w stanie czegoś takiego zrealizować, no to mamy listę kolejnych rekomendacji. Druga rekomendacja. Zmniejsz liczbę tematów przekazywanych do zespołów jednocześnie. Czyli wyobraźmy sobie, że nie ma takiej zgody, o której Kuba opowiedział w tej swojej historii, no i nadal jest dosyć szeroka lista tematów, inicjatyw, które mają być realizowane przez zespoły. To, co proponujemy w takim przypadku, to jest ograniczenie liczby tematów, które jednocześnie są przekazywane do zespołów, czyli taka świadomość na poziomie top managmentu, że przekazywanie wielu tematów naraz niekoniecznie poprawi efektywność pracy, a w szczególności nie sprawi, że te tematy będą dostarczone wcześniej. Propozycja, od której można zacząć, być może takim bardzo sensownym punktem startu, jest umówienie się, że jeden zespół otrzymuje jakiś jeden konkretny cel na raz. Ten cel nie musi oznaczać, że to jest jakiś jeden feature w produkcie, to może być sporo rzeczy, które jest do zrealizowania w ramach jakiegoś konkretnego produktu. Natomiast nadal poruszamy się w tym przypadku w jakimś konkretnym, wyselekcjonowanym obszarze.

Kuba: I narzędziowo to się najczęściej zamienia w pewną Road map skupioną na celach, przy czym te cele są realizowane w jakiś sposób szeregowy. Nawet jeśli niestety organizacja nie do końca ma przemyślaną strategię, albo ta strategia nie jest tak wyrazista, jak byśmy sobie tego życzyli, no to może chociaż niech zarządzający produktem, też osoby kluczowe, jacyś sponsorzy, jacyś też zarządzający większymi obszarami, niech chociaż skupią uwagę danego zespołu, czy skupią uwagę danego produktu na jednym celu w danym momencie, by zabrać się za kolejny cel, gdy tamten zostanie zrealizowany w satysfakcjonujący sposób. No i być może te cele ze sobą będą powiązane bardzo luźno, no ale chociaż na dany moment niech będą procesowane i polepszane przez zespół w jakiś taki bardziej skupiony sposób. W praktyce to oznacza Road mapę skupioną na celach, to bardzo mocno podkreślę i powtórzę, jako coś innego niż Road mapę, w której mamy planowane funkcje w produkcie, planowane cechy tego produktu, czy też coś innego niż jakiś taki plan realizacji, prac, bo Road mapy często się kojarzą raczej właśnie z datami. Wyobrażam sobie, że to jest Road mapa, która bardziej przypomina drzewko rozwoju technologii w Cywilizacji, gdzie najpierw skupimy się na rozwoju metalurgii, a potem zmienimy sposób, w jaki zbierane są owoce, no i to oczywiście da się taką tę analogię przenieść na wybrany twój produkt.

Kuba: Trzecia porada, jak radzić sobie z wieloma produktami, to zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produkt. Założenie w tej poradzie jest takie, że być może wielość rzeczy, które jest realizowana jednocześnie, wynika z tego, że zespół ma nieoptymalnie ustawione granice tego, czym się zajmuje. Być może tu trzeba przedyskutować ponownie temat, czy czasami zespół nie obejmuje za dużego obszaru, albo obejmuje ten obszar w jakiś taki nieszczęśliwy sposób, że organizacja musi jednocześnie realizować kilka rzeczy i w tym konkretnym zespole się to ujawnia jako więcej niż jeden priorytet i to w dodatku priorytet, który nie może czekać. Czyli te dwie nasze poprzednie porady nie są możliwe do zastosowania. Jak to może w praktyce wyglądać, Jacek?

Jacek: Tu z kolei ja podzielę się historią. Pomagałem pewnej organizacji w usprawnieniu tego, jak funkcjonują zespoły, no celem osiągania lepszych efektów biznesowych. Zespoły te były skupione wokół technologii, co powodowało, że nawet drobna zmiana taka czysto biznesowa powodowała, że wiele zespołów było angażowanych w to, żeby to doprowadzić do stanu, kiedy użytkownicy mogą z jakiejś tam konkretnej zmiany w produkcie korzystać. To, na czym skupił się management, to była reorganizacja zespołów, tak, aby nie były one skupione na konkretnej technologii, tylko raczej, żeby były skupione na konkretnych obszarach biznesowych. Powstała tam bardzo konkretna tabelka, która w Excelu proponowała, jakie to mogłyby być obszary biznesowe. Jednocześnie zespoły przygotowały listę tematów technologicznych, którymi się zajmują, no i na tej podstawie uruchomiła się taka wielocyklowa, wielotygodniowa dyskusja na temat tego, w jaki sposób najlepiej się przeorganizować, żeby z jednej strony zespoły maksymalnie skupiały się na konkretnym produkcie, z drugiej strony, żeby wykorzystać już tę wiedzę technologiczną, którą mają, jednocześnie nie robiąc zbyt dużych zmian, jeśli chodzi o skład zespołu. Oczywiście nie było to do końca możliwe, więc zmiana uwzględniała to, że pewne osoby będą musiały zmienić zespół, jak również pojawiły się pewne nowe odpowiedzialności technologiczne w zespołach, a pewne odpowiedzialności z kolei były przekazywane do innych teamów. 

Kuba: I z naszego doświadczenia udziału w kilku tego typu sytuacjach, no nie mamy gotowej odpowiedzi, jak się podzielić. Nawet ten podział biznesowy to i tak jest dosyć wysokopoziomowe stwierdzenie, ale coś, co nam podpowiada doświadczenie, to to, że organizacje ten dobór odpowiednich produktów wypracowują iteracyjnie. Najprawdopodobniej w dłuższych dyskusjach, uznając wiele czynników. No i co też ważne, prawdopodobnie za pierwszym razem nie uda się idealnie uzyskać takiego efektu stałego, więc tu z góry sobie załóżmy też to, że być może ten sposób podziału będzie doskonalony w przyszłości, a może w ogóle przejdzie organizacja na taki tryb ciągłego, lekkiego reorganizowania zespołów, bo zmienia się produkt, zmienia się jakiś cykl życia, czy może chcemy dopasować się do nowych rynków czy nowych trendów.

Kuba: Czwarta rada w tym odcinku to, realizuj inicjatywy produktowe w sposób sekwencyjny. Schodzimy tak coraz bardziej z realizmem w stronę może nawet pesymizmu. Czyli załóżmy, że te wybrane wcześniej rzeczy albo nie dało się zrealizować, albo nie dały jeszcze kompletu efektów, o których chodzi, więc może jest tak, że nawet jeśli jest swego rodzaju zamieszanie z poziomu strategii, z poziomu zadań zlecanych do zespołów, czy z poziomu odpowiednio poukładanej struktury, to nadal dużo da się zrobić na poziomie osoby, która decyduje o tym, co jest priorytetem w danym zespole. W niektórych zespołach ta osoba się nazwie Product Ownerem, w innych Product Managerem. W każdym razie jest jakiś decydent, który może zdecydować o tym, że niezależnie od tego, jaka jest mnogość zleceń, inicjatyw, pomysłów, czy nawet różnych celów, mogą one być w tym konkretnym jednym zespole realizowane w sposób sekwencyjny, czyli po kolei. Najpierw jedna rzecz, z jakiegoś powodu najważniejsza, może najpilniejsza, dopiero potem kolejna rzeczy, żeby ograniczyć wielozadaniowość, żeby ograniczyć przyłączanie kontekstu, być może też przyspieszyć realizację tego, co jest najważniejsze.

Jacek: I ten przykład pięknie pokazuje, jak ważne jest, żeby osoba, która znajduje się na stanowisku, o którym Kuba wspomniał, potrafiła wykazać się odwagą, potrafiła wykazać się praktywnością, ale też asertywnością w odmawianiu. Bo tak naprawdę będzie trzeba pewne inicjatywy zastopować, powiedzieć wyraźnie, co musi poczekać i co będzie tak naprawdę zrealizowane w dalszej kolejności, żeby stworzyć miejsce i przestrzeń na to, żeby zrealizować to, co w danym momencie jest najważniejsze. Trudno powiedzieć, co jest najważniejsze w danym momencie, bo to może być najbardziej obiecująca inicjatywa. Z drugiej strony to może być pilne spłacenie jakiegoś długu technologicznego, na przykład z tego powodu, że jakaś tam technologia, na której bazujemy traci wsparcie, a może to być też powiązane z jakąś konkretną, sztywną datą. Czyli na przykład musimy pewne rzeczy zmodyfikować w naszym produkcie ze względu na to, że od jakiegoś momentu w czasie na przykład zmieni się prawo no i tak naprawdę będziemy musieli być zgodni, jeśli chodzi o to, czy ten nasz produkt spełnia te wymagania prawne, czy niekoniecznie. Nie jest to intuicyjne podejście, mam wrażenie, że nadal pokutuje takie myślenie, że jak wiele rzeczy naraz robimy, to one będą szybciej. Nie wiem z czego to wynika. Literatura tutaj i praktyka jest bezlitosna. Mantra, zacznij kończyć, przestań zaczynać, z mojej perspektywy tutaj jest czymś, na czym warto się oprzeć.

Kuba: Ok, to przechodząc do następnej rekomendacji. Wyodrębniaj esencję z tego, co jest do zrobienia. Jedną z przyczyn, dla których zespoły borykają się z tym, że mają do realizacji wiele inicjatyw produktowych jednocześnie, może być to, że te inicjatywy są za duże, ciągną się długo i po prostu pod naporem priorytetów, czy takich rzeczy, jak Jacek powiedział, rzeczy, które po prostu już nie mogą czekać, zaczyna się ten multitasking i zaczyna on boleć. Zdolność do dzielenia jest czymś, czego się trzeba nauczyć, ale zespoły, które umieją to robić, również osoby zarządzające priorytetami, umiejące zdecydować na temat tego, co jest w tym czymś, co robimy, z tym ważną cząstką i tę trochę mniej ważną, one dzięki temu są w stanie uzyskać możliwość dostarczania mniejszych kawałków inicjatywy szybko. No i ewentualnej decyzji, co dalej jest z tą pozostałą częścią, albo zapauzowanie jej i przepuszczenie przodem kolejnej inicjatywy, albo w ogóle może zrezygnowanie z tego, jeśli tak pokaże feedback rynku, albo tak się okaże, że jak już mamy coś, jakąś cząstkę, to tej pozostałej części już tak bardzo nie potrzebujemy.

Jacek: No i tutaj takim klasykiem, który niezmiennie z Kubą obserwujemy, to jest przepisywanie systemu, zmiana jakiejś platformy, zmiana technologii, gdzie mamy pewien gotowy produkt, on posiada już jakieś funkcje, można z tego produktu korzystać, no ale przepisujemy go od zera. Bardzo często to przepisywanie, to jest takie przepisywanie moduł po module, dosłownie jeden do jednego, idziemy po kolei z tym naszym produktem i jak wszystko przepiszemy, no to tak naprawdę możemy powiedzieć, OK, to jest zrobione. Tutaj zdecydowanie byśmy rekomendowali, żeby podejść krytycznie do takiego przepisywania, zastanowić się, co tak naprawdę jest esencją tego produktu, co jest najczęściej używane. Zaczerpnąć trochę informacji zwrotnej od faktycznych użytkowników tego systemu no i dopiero wtedy podjąć decyzję, co tak naprawdę byłoby mądrze dostarczyć na wczesnym etapie, jak również refleksja, która na pewno się pojawi, że tak naprawdę nie wszystko dosłownie jeden do jeden, co znajduje się w tym produkcie jest nam potrzebne w tej naszej nowej wersji.

Kuba: Jeśli temat dekompozycji produktu to coś, czego potrzebujesz, sprawdź nasz webinar, gdzie podajemy 9 sposobów na dzielenie produktu i omawiamy na przykładach, jak to zrealizować w zespole produktowym. Sprawdź nasz materiał pod adresem porzadnyagile.pl/deko.

Jacek: Przechodzimy do przedostatniej rekomendacji na dzisiaj, czyli twórz dynamiczne podzespoły skupione na wybranych obszarach. Płyniemy coraz bardziej z nurtem, jak słyszysz w tej poradzie już, no tak właściwie zaakceptowaliśmy, że tych tematów jest sporo. No i to, co można zrobić, to podejść tak generalnie dosyć zwinnie i płynnie. Czyli zastanowić się, w jaki sposób możemy się mądrze podzielić w zespole, tak, żeby pewne wybrane osoby, zestaw też jakichś konkretnych kompetencji, był skupiony na wybranych obszarach. Czyli zamiast sytuacji, w której wszyscy są skupieni na wszystkim, tego jest bardzo dużo, no to jednak powiedzieć sobie dobrze w tym wielkim natłoku tematów, nie musimy robić wszystkiego, nadal tego jest sporo, no to powiedzmy sobie, co to jest to sporo i przydzielmy podzespoły czy jakieś takie grupy w ramach naszego zespołu, które jednak będą, no nazwijmy to w miarę komfortowych warunkach, na tyle na ile to jest możliwe, jednak skupione na jakimś wybranym, konkretnym obszarze.

Kuba: Oczywiście to podejście zakłada, że zespół jest odrobinę większy, że jest kogo dzielić, że tutaj na przykład podziale na pół i ten zespół dalej zachowuje zdolność do dostarczania rozwiązania. Ale sam byłem świadkiem kilku odmian realizacji tej praktyki i w skrócie najczęściej to wygląda tak, że albo na planowaniu iteracji czy Sprintu czy na planowaniu jakiegoś dłuższego okresu, na przykład kwartału czy czasu realizacji dla największej inicjatywy takiej trwającej kilka tygodni, zespół w ramach samoorganizacji ustala kto jest potrzebny do tego, żeby zrealizować dane przedsięwzięcie. Ludzie się tak nazwę tymczasowo przydzielają do tej inicjatywy, no i na czas realizacji tej inicjatywy być może działają po prostu jako pewna podgrupa w ramach zespołu, aż nie potrzebują wrócić do swojego oryginalnego zespołu, czy to po pomoc, czy po prostu wracają, bo już wyczerpali dane przedsięwzięcie, zakończyli je w satysfakcjonujący sposób. Więc tutaj mamy do czynienia z pewnego rodzaju podziałem. Ten podział jest tymczasowy, czyli tutaj nie ma potrzeby jakichś większych reorganizacji. Ten podział jest też bardzo taki elastyczny, więc są zespoły, które też tak troszkę go stosują, ale troszkę go łamią, ale to jest taka dojrzałość zespołu w tym, żeby dostosowywać się, być może przełamać taką przede wszystkim zasadę, że absolutnie wszyscy wszystko robią równocześnie wspólne wielkie Daily, wspólne wielkie planowania, wspólne wielkie warsztaty, gdzie to po prostu może być mało wartości dodane, a za to wielki koszt. Jest to oczywiście poziom dojrzałości zespołu, pewna umiejętność, na którą trzeba z zespołem wejść, ale jest to jeden z przedostatnich w naszym przypadku ze sposobów na to, żeby sobie poradzić z wieloma produktami realizowanymi jednocześnie.

Jacek: I ostatnia porada na dzisiaj. Rozwijaj bardziej uniwersalny profil kompetencyjny członka zespołu. Może być tak, że czasami te kompetencje, które mamy w zespole będą podsuwały pomysł, że być może powinniśmy pewne inicjatywy zrównoleglić, bo w jednej z nich nie ma pracy dla kompetencji pozostałych członków zespołu. I prowadzi to do sytuacji, w której ten Product Owner czy Product Manager, czy dowolna inna osoba decydująca o tym, czym zajmuje się zespół, w pewnym sensie jest zmuszany do uruchamiania kolejnych wątków po to, żeby wysycić dostępne osoby w zespole. Czyli po prostu, żeby każda osoba miała pracę. 

Kuba: I tutaj przed oczami mam takie wspomnienie pewnego konkretnego zespołu IT, z którym miałem bardzo fajny okres współpracy, gdzie pewna programistka w czasie planowania kolejnego etapu pracy zaczęła właśnie od stwierdzenia – Kurczę, ciągle robię API. I wszyscy jej słuchający myśleli, że właśnie zgłasza się po kolejną metodę, którą będzie brała, no ale ona bardzo wyraźnie tak z odrobiną pauzy dopowiedziała i chciałabym robić coś innego. I to był fajny moment dla tego zespołu, bo to był moment, gdy jakby przestali ciągle ci sami brać ciągle te same zadania, tylko właśnie z inicjatywy jednej z programistek spróbowali trochę zamienić sobie kartki, na których rysują i po prostu wziąć trochę inne zadania niż zazwyczaj brali. W efekcie w tym konkretnym zespole doszło do fajnego miksu kompetencji, do pewnego transferu wiedzy i umiejętności, na innych częściach systemu niż zawsze. No i też efekt taki bym powiedział wielowymiarowy, no bo nowe osoby trafiły do części systemu, które zwyczajowo były rozwijane przez jedną albo maksymalnie dwie osoby, więc tam było okazji trochę do refaktoringu, trochę do popatrzenia na sprawy świeższym okiem. Ale też zespół stał się właśnie uniwersalny, zdejmując trochę to zmartwienia, od którego zaczął Jacek ten punkt, że Product Owner w tym przypadku musiał generować pracę dla wysoko wyspecjalizowanych profesjonalistów, zamiast po prostu skupiać się na tym, co jest celem i pogodzić się z tym, że zespół sobie sam poukłada pracę. Oczywiście w podejście w krótkim okresie wiąże się z tym, że ta konkretna programistka weźmie się za kawałek, na którym się mniej zna, więc prawdopodobnie jej chwilowa wydajność będzie lekko słabsza, ale już w średnim okresie to się powinno zacząć fajnie balansować. A w długim okresie zespół uzyskuje dużą zdolność do tego, żeby brać się za różne rzeczy, móc się też intensywnie zabrać za jedną, jedyną rzecz, która jest w danym momencie najbardziej potrzebna i dzięki temu maksymalnie szybko zrealizować to, co jest ważne dla produktu.

Jacek: Taka domykająca myśl dzisiejszego odcinka jest taka, że jeśli nawet te ostatnie punkty, które sugerowaliśmy, które trochę już są takim kompromisem albo granie tymi kartami, które mamy dostępne, jeśli one nawet nie brzmią realistycznie dla Twojego kontekstu, to obawiamy się, że być może masz inny, znacznie większy problem, niż jak poradzić sobie z wieloma inicjatywami produktowymi jednocześnie.

Kuba: I co mamy na myśli, mówiąc takie enigmatyczne stwierdzenia? No, w materiale zawarliśmy dużo porad. Pierwsze z nich są bardzo takie strategiczne, systemowe, ogólno organizacyjne. Kolejne już wiążą się z podejmowaniem decyzji. Te ostatnie wiążą się z tym, jak sobie po prostu radzić na zasadzie zorganizowania się. Jeśli nie jesteś w stanie zapewnić, że zespół się organizuje, albo są pewne blokady, że to w ogóle jest niewykonalne, to bardzo obawiam się o to, czy na przykład zespół ma możliwość stanowienia o swoim procesie pracy, na ile w ogóle słuchane są osoby, które mają jakieś pozycje liderskie bezpośrednio z tym zespołem. I może się okazać, że to, że nieusprawniony jest ten aspekt, to jest tylko pewien symptom tego, jak bardzo niesamodzielne, jak bardzo dociśnięte managersko są zespoły czy zasoby, które w tym zespole bezpośrednio nie pracują. To tylko hipoteza, być może nietrafna, ale postanowiliśmy zostawić takie zawieszone pytanie i refleksje na koniec.

Kuba: Podsumowując, jak radzić sobie z wieloma produktami w jednym zespole? Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematów. Zmniejsz liczbę tematów przekazywanych do zespołów jednocześnie. Zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produkt.

Jacek: Realizuj inicjatywy produktowe w sposób sekwencyjny. Wyodrębniaj esencję z tego, co jest do zrobienia. Twórz dynamiczne podzespoły skupione na wybranych obszarach i rozwijaj bardziej uniwersalny profil kompetencyjny członka zespołu.

Kuba: Ten odcinek to tylko fragment tego, co oferujemy w naszych programach rozwojowych dla osób zarządzających produktami w zwinnych zespołach. Wspieramy rozwój kluczowych kompetencji takich jak budowanie strategii produktowej, tworzenie Road map produktowych, dzielenie pracy na mniejsze elementy i efektywne planowanie pracy w zespole. Nasze podejście łączy praktyczne warsztaty, mentoring oraz superwizje realnych inicjatyw, by maksymalnie wspierać uczestników w codziennej pracy. Jeśli czujesz, że potrzebujesz takiego wsparcia, skontaktuj się z nami przez porzadnyagile.pl/kontakt.

Jacek: Notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo tej rozmowy znajdziesz na stronie porzadnyagile.pl/128.

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

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

Grupa Product Ownerów z jednej z firm zadała nam pytanie: „Czego w praktyce możemy oczekiwać od Scrum Mastera?”. To zagadnienie zainspirowało nas do szerszej dyskusji o tym, jak powinna wyglądać taka współpraca ze Scrum Masterem z perspektywy dowolnego członka Zespołu Scrumowego. Jeśli zarządzasz Scrum Masterami lub jesteś członkiem Zespołu Scrumowego, to ten materiał jest właśnie dla Ciebie. Scrum Masterzy też znajdą tu przydatne informacje. Pomożemy Ci zrozumieć, jak skutecznie komunikować swoją rolę i odpowiedzialności.

Spis treści

• Kiedy Scrum Master, poprawnie realizuje swoją odpowiedzialność?
• Co zrobić, jeśli sposób pełnienia roli SM wymaga usprawnienia?
• Transkrypcja podcastu „Czego oczekiwać od Scrum Mastera?”

To podstawowy element pracy, gdzie oczekujemy, że Scrum Master, rozpoczynając współpracę z zespołem lub firmą, potrafi opowiedzieć, czym się zajmuje, co planuje robić, jakie techniki stosuje i na jakich zasadach będzie współpracować. Jeśli twój Scrum Master tego nie zrobił — niezależnie od tego, czy jesteś Product Ownerem, liderem zespołu czy deweloperem — i masz poczucie niedosytu lub nikt z grona Scrum Masterów nie wyjaśnił ci, czym się zajmuje, to uważamy, że jest to pierwszy, wręcz zerowy krok. Scrum Master powinien wyjaśnić, na czym polega jego funkcja. Umiejętność przedstawienia swojej oferty świadczy o tym, że jest ona dobrze przemyślana i wykracza poza wsparcie zespołu tylko podczas wydarzeń scrumowych. Scrum Master może zaoferować o wiele więcej, i samo zastanowienie się nad tym, co faktycznie może zrobić w organizacji, jest czymś, do czego zachęcamy.

Oczekujemy, że Scrum Master potrafi wyjaśnić nie tylko sam framework Scrum, który w wielu firmach stanowi podstawę pracy zespołów, ale także rozumie, czym jest zwinność. Popularność Scruma sprawiła, że wiele technik i praktyk jest kategoryzowanych jako scrumowe, co może prowadzić do zapomnienia o podstawowych zasadach wynikających z podejścia zwinnego lub inspirowanych innymi metodami pracy. Ważne jest, aby Scrum Master rozumiał te zasady i umiał je sensownie wytłumaczyć zespołowi.

W praktyce oznacza to edukowanie zespołu w obszarach takich jak samozarządzanie — koncept, że zespół sam organizuje swoją pracę bez potrzeby koordynatora czy managera. Scrum Master powinien umieć wyjaśnić temat Celu Sprintu, podpowiedzieć, jak go zastosować, i przeprowadzić zespół przez niezbędne zmiany. Dotyczy to również zarządzania Backlogiem Produktu, technik priorytetyzacji czy sposobów opisu elementów Backlogu.

Oczekuję\emy, że Scrum Master potrafi zaproponować praktyki odpowiednie do problemów zespołu, przedstawić przykłady, szablony czy modele. Ważne jest także, aby umiał wdrożyć te rozwiązania w życie, pomóc zespołowi w ich zastosowaniu, doradzić, jak zrobić to po raz pierwszy i jak udoskonalić proces. Jeśli Scrum Master wraz z zespołem mówi: „Nie umiemy tego robić”, to oznacza, że powinien nadrobić w zakresie edukacji zespołu.

Z bólem serca czasami słyszymy od zespołów stwierdzenia typu: „Nasze Daily nie ma sensu”, „Nie warto realizować Retrospektywy” czy „To, co mamy w Backlogu Produktu, jest zupełnie bezcelowe i nie ma sensu tego uzupełniać”. Dla nas to sygnał, że jest coś do poprawy. Przekuwając to na pozytywy, wszystkie elementy Scruma, w które wierzymy, praktykowaliśmy i obserwowaliśmy mają sens. To Scrum Master potrafi to przekazać zespołowi zrozumiałym językiem i sprawić, by ten sens pojawił się w zespole. Zwłaszcza zespół początkujący lub mający swoje wyzwania może wykonywać te elementy niedoskonale. To od Scrum Mastera oczekujemy, że drobnymi korektami i podpowiedziami sprawi, że rzeczy w naszym Scrumie zaczną się składać w większą całość.

Pierwszym krokiem z perspektywy Scrum Mastera powinno być zrozumienie wszystkich niuansów, aby móc komentować wydarzenia i artefakty oraz ich celowość i sensowność. Najpierw trzeba odrobić lekcję pod tytułem: „Po co tak naprawdę to robimy? Dlaczego ten konkretny element Scruma jest tu, gdzie jest? Dlaczego powinniśmy na niego zwracać uwagę?” To oczywiście prowadzi do rekomendacji, aby zadbać o edukację i naprawdę zrozumieć, dlaczego te konkretne elementy zostały wymyślone. Rozmawianie z praktykami, uczestnictwo w szkoleniach prowadzonych przez osoby, które faktycznie to rozumieją — są to przykłady działań, które można podjąć, aby uzyskać takie zrozumienie.

Ciągłe doskonalenie jest absolutnym fundamentem zarówno podejścia zwinnego, jak i Scruma. Zadbanie o to, by usprawnienia faktycznie miały miejsce, jest jedną z najważniejszych funkcji Scrum Mastera. Ważne jest, aby te usprawnienia były rzeczywiście realizowane przez zespół zgodnie z ustaleniami. Ponadto warto upewnić się, że dotyczą one faktycznie obszarów, które poprawią pracę zespołu, a nie są jedynie wygodnymi tematami zastępczymi.

Jak możemy rozpoznać, że Scrum Master wspiera zespół w usprawnianiu? Przede wszystkim poprzez organizację Retrospektyw Sprintu. Niestety, w wielu zespołach to wydarzenie scrumowe jest pomijane lub traktowane bardzo powierzchownie. Dobry Scrum Master sprawia, że zespół rozumie cel Retrospektywy, zna jej przebieg i wie, czego się od niego oczekuje podczas tego spotkania. W efekcie cały zespół dochodzi do konkretnych wniosków. Retrospektywa nie jest tylko jednym z popularnych negatywnych wzorców, ale miejscem, gdzie zespół wychodzi z poczuciem: „Tak, od najbliższego Sprintu wprowadzimy jedną, dwie lub trzy rzeczy, które realnie zmienią naszą pracę”. Jeśli któryś z tych negatywnych wzorców, wymaga poprawy, warto rzucić okiem na nasz webinar o tym, jak powinna wyglądać porządna Retrospektywa Sprintu. Jest on dostępny pod adresem porzadnyagile.pl/retro.

Przeszkody w Scrumie to ogólne pojęcie odnoszące się do sytuacji, w których zespół spowalnia pracę, doświadcza niepotrzebnych przestojów, ma trudności w realizacji celów lub ewidentnie stoi w miejscu i nie jest w stanie zrealizować swoich planów. 

Scrum Master dąży do usuwania tych przeszkód. Może to robić samodzielnie, ale także przysłużyć się zespołowi poprzez świadomą eskalację problemów do odpowiednich osób poza zespołem lub wspierać innych członków zespołu w ich rozwiązywaniu. Na przykład poprzez przypominanie o problemie, nieignorowanie go, dostrzeganie jego istnienia i w ten sposób zachęcanie całego zespołu do wspólnego znalezienia rozwiązania.

Dobrego Scrum Mastera w tym aspekcie poznamy po tym, że rejestr przeszkód istnieje i jest widoczny. Nie jest to coś, co Scrum Master trzyma dla siebie i do czego zespół nie ma dostępu. Powinno być wręcz przeciwnie: to są przeszkody zespołowe, które Scrum Master będzie próbował rozwiązać samodzielnie lub z pomocą innych, ale będzie dbał o to, by tematy posuwały się naprzód. Ważne jest także, aby rozmawiać o faktycznych, źródłowych przyczynach problemu, a nie tylko o powierzchownych aspektach. Trzeba zagłębić się w problem i zrozumieć, z czego on tak naprawdę wynika.

Kiedy mówimy o efektywności, mamy na myśli relację między efektami uzyskanymi przez zespół a kosztami poniesionymi na ich osiągnięcie. Nie chodzi o to, jak bardzo ludzie są zajęci, zapracowani czy jak szybko pracują — to nie ta droga. Istotna jest prosta zależność między efektami a kosztami.

 Choć ta relacja jest prosta, sposób jej mierzenia nie zawsze jest łatwy, więc dla każdego zespołu może to wyglądać inaczej. W zależności od produktu, firmy czy branży, w której zespół działa, efekty mogą mieć różny charakter. 

Zadaniem Scrum Mastera jest zwracanie uwagi na to, czy w ogóle mówi się o efektywności. Ważna jest współpraca z Product Ownerem, aby cały Zespół Scrumowy był świadomy, gdzie leży wartość biznesowa, na czym firma zarabia i dlaczego klienci czy użytkownicy chcą konkretnego elementu. To strona wyników, ale równie istotna jest rozmowa o kosztach. Czy zespół pracuje tak wydajnie, jak powinien? Czy są możliwości zaoszczędzenia pewnych kosztów?

Nie chodzi tu tylko o koszty ludzkie. Każdy zespół ponosi również koszty związane z infrastrukturą, licencjami, niepotrzebnymi działaniami, niską jakością czy nieefektywnymi praktykami. Wszystko to kumuluje się, powodując, że koszt wytworzenia efektu jest wyższy niż mógłby być. Ważne, aby Scrum Master poruszał te kwestie z zespołem —  uświadamiał, wyjaśniał, pokazywał pewne mierniki i zadawał trudne pytania, które skłaniają do refleksji. Dzięki temu zespół nie będzie realizował bezmyślnie zadań bez wartości ani wykonywał ich w sposób bardzo kosztowny.

Więcej na ten temat znajdziesz na blogu Kuby, gdzie powstała dedykowaną stronę poświęconą efektywności: https://www.kubaszczepanik.pl/efektywnosc/

Ostatnie oczekiwanie wobec Scrum Mastera dobrze realizującego swoją rolę stanowi pewnego rodzaju klamrę. Wszystkie poprzednie punkty, które omówiliśmy, muszą być zrealizowane w określonym stylu. Scrum Master powinien wyjaśniać intencje swoich działań. Mamy duży problem ze Scrum Masterami, którzy zachowują się enigmatycznie i bez wyraźnego pytania nie potrafią powiedzieć, dlaczego coś proponują, jaką technikę stosują, zadają pytania czy proszą o wykonanie konkretnej instrukcji.

Od dobrego Scrum Mastera oczekuję, że bez konieczności pytania potrafi powiedzieć: „Robimy to i to, ponieważ… Chcę coś osiągnąć, chcemy jako zespół coś osiągnąć.” Odważnie i szczerze deklaruje pewne rzeczy i oczekiwania, pokazuje swój plan działania. Nie ma ukrytej agendy, manipulacji czy tajemnicy, której zespół nie jest w stanie zrozumieć.

To jest istotne, aby Scrum Master nie kreował wizerunku osoby z tajnym planem czy ukrytą agendą, ani nie sprawiał wrażenia nadrzędnej roli wobec zespołu, gdzie on wszystko wie i mówi, jak ma być, a reszta ma tylko słuchać. Intencje Scrum Mastera powinny być maksymalnie jasne i transparentne dla zespołu. Zespół powinien doskonale rozumieć, że konkretne pytania, sugestie czy propozycje nie wynikają z osobistych kaprysów Scrum Mastera, który przeczytał mądrą książkę i teraz udaje, że wie lepiej. Zamiast tego, Scrum Master powinien być wsparciem dla zespołu, pomagając wspólnie osiągnąć konkretny, sensowny rezultat.

Podkreślając działanie wspólnymi siłami, zauważamy, że wiele z omawianych kwestii jest w rzeczywistości wspólną odpowiedzialnością całego zespołu scrumowego. To cały zespół się usprawnia, cały zespół usuwa przeszkody, cały zespół dba o swoją efektywność. Scrum Master może wspierać i sugerować rozwiązania, ale tak naprawdę to wszyscy razem musimy rozumieć, do czego dążymy. Nawet jeśli Scrum Master ma dobre pomysły, to jeśli narzuca je zespołowi, zazwyczaj nie przynosi to pożądanych rezultatów.

Jeśli rozpoczynasz współpracę ze Scrum Masterem, warto zacząć od zaproponowania spotkania. Może to być rozmowa jeden na jeden lub spotkanie z całym zespołem, podczas którego omówicie, jak mogłaby wyglądać oferta wsparcia ze strony Scrum Mastera. To także okazja, by zastanowić się, jak oceniamy aktualne pełnienie tej roli i czy istnieje przestrzeń do wprowadzenia zmian lub usprawnień.

Z naszego doświadczenia wynika, że wiele zespołów lub poszczególnych ich członków ma uwagi do pracy Scrum Mastera, ale brakuje przestrzeni do otwartej rozmowy na ten temat. Często w firmach nie ma wystarczającej kultury udzielania informacji zwrotnej, co utrudnia bezpośrednią komunikację. Dodatkowo, Scrum Masterzy nie zawsze praktykują aktywne proszenie o feedback. Dlatego warto wyjść z inicjatywą, spotkać się z konkretnym Scrum Masterem lub Scrum Masterką z twojego zespołu czy otoczenia i zainicjować dialog.

Niektóre osoby nadal nie w pełni rozumieją, czym zajmuje się Scrum Master, co utrudnia szczerą i rzetelną rozmowę o ewentualnych niedociągnięciach czy możliwościach usprawnień. Przygotowaliśmy ten materiał właśnie po to, aby pomóc w refleksji nad tym, jak rola Scrum Mastera jest realizowana w twoim zespole. Jeśli uważasz, że któryś z punktów wymienionych wcześniej wymaga poprawy lub ma potencjał do usprawnienia, powiedz o tym otwarcie. Dla twojego Scrum Mastera nasz materiał powinien być wiarygodnym źródłem i podstawą do wspólnej rozmowy.

Pewne przeszkody czy elementy, które nie są realizowane przez Scrum Mastera, mogą być w danym kontekście szczególnie istotne. Na przykład, może największym problemem jest obecnie brak wsparcia dla osób biznesowych lub dla Product Ownera. Być może Backlog Produktu nie jest tak przejrzysty i dobrze poukładany, jak mógłby być. W związku z tym spoczywa na tobie pewna odpowiedzialność, aby wskazać obszary do usprawnienia, szczególnie te, które są najbardziej istotne z twojej perspektywy lub z perspektywy twojej organizacji.

Zalecamy trzymać się konkretów i faktów. Spróbuj na tym etapie:

Większość usprawnień, które Scrum Master może wprowadzić w swoim sposobie działania, jest silnie zależna od tego, jak funkcjonuje cały zespół. Scrum Master samodzielnie może niewiele zmienić bez wsparcia przynajmniej części zespołu. Dlatego zachęcamy cię do ustalenia, co wszyscy w zespole lub jego większa część mogą zrobić, aby wspólnie wyeliminować braki lub usprawnić obszary wymagające poprawy.

Ustalcie plan działania, aby konkretnie zlikwidować luki, zaczynając od najważniejszej. Przez plan działania rozumiemy jasne, jednoznaczne i wykonalne kroki. Nie chodzi o ogólne sformułowania, lecz o konkretne, precyzyjne działania: 

Warto również ograniczyć liczbę tematów, nad którymi pracujemy jednocześnie. Zacznijmy od najważniejszego, rozpocznijmy nad nim pracę i skupmy się na doprowadzeniu go do końca lub do satysfakcjonującego etapu. Dopiero wtedy przechodzimy do kolejnych tematów, aby uniknąć pułapki rozgrzebywania wielu wątków bez ukończenia żadnego.

Zaproś Scrum Mastera z innego zespołu, aby udzielił feedbacku. Zakładamy, że w naszej organizacji istnieje inny Scrum Master, którego można zaprosić — w większych czy średnich firmach to zwykle jest możliwe. W tej prostej sugestii kryje się wiele wartości, z których sami korzystaliśmy i nadal korzystamy. Świeże spojrzenie jest nieocenione. Osoba głęboko zaangażowana w temat i zanurzona w konkretnym kontekście może nie dostrzegać pewnych aspektów.

Dlatego cenimy sobie, gdy przychodzimy na nasze warsztaty i podpowiadamy sobie wzajemnie co jest do poprawy. Podobny efekt może przynieść Scrum Master z innego zespołu, który dołączy do Sprintu lub weźmie udział w wybranym spotkaniu, warsztacie czy innym wydarzeniu scrumowym. Dzięki temu może zwrócić uwagę na pewne kwestie, które pomogą naszemu Scrum Masterowi w lepszym realizowaniu swojej roli.

Należy ustalić odpowiedni styl współpracy  — może to być coaching, mentoring, konsulting lub szkolenie, a także my. W zależności od sytuacji zdecydujemy się na jedną z tych form. Ważne jest dobranie adekwatnych narzędzi do poziomu rozwoju danej osoby oraz właściwe zdiagnozowanie potrzeb dalszej pracy.

Nie każdy ma możliwość zaangażowania zewnętrznego eksperta, gdyż często wiąże się to z rolami liderskimi czy menedżerskimi. Jednak nawet jeśli samodzielnie nie możesz tego zorganizować, zawsze możesz rozpocząć rozmowę na ten temat. W niektórych organizacjach jest to rutynowa praktyka, choć może jeszcze o tym nie wiesz. Jeśli więc jako zespół, w porozumieniu ze Scrum Masterem, czujecie, że mogłoby to pomóc, warto to rozważyć i porozmawiać z odpowiednimi osobami.

Jedną z klasycznych pułapek w rozmowach o usprawnieniach jest to, że choć ustaliliśmy konkrety i stworzyliśmy plan, nie wracamy do niego i nie podsumowujemy podjętych działań. Warto porozmawiać ze swoim Scrum Masterem o tym, jak zamierzacie sprawdzić efekty umówionych działań i kiedy to zrobicie. Jeśli jesteś członkiem Zespołu Scrumowego, możesz wykorzystać najbliższą lub kolejną Retrospektywę, aby poświęcić kilka minut na omówienie, czy realizacja roli Scrum Mastera faktycznie się poprawiła. To dobra okazja, by docenić wykonane działania i ewentualnie przekazać informację zwrotną na temat obszarów, które nadal wymagają uwagi.

Podsumowując jak można zmienić sposób, w jaki realizowana jest odpowiedzialność Scrum Mastera w Twoim zespole? 

 Jeśli nie masz pewności, czy Scrum w twojej organizacji jest realizowany w satysfakcjonującym stopniu lub czujesz, że nadal jest potencjał na usprawnienie, ale nie masz pomysłu, jak się za to zabrać, skorzystaj z naszego eksperckiego doradztwa. Dołączamy do organizacji, wykonujemy diagnozę stanu zwinności i na tej bazie rekomendujemy konkretne praktyki oraz zmiany, których celem jest poprawienie efektywności pracy zespołów. Więcej informacji o tej usłudze znajdziesz na stronie porzadnyagile.pl/diagnoza

Kuba: Niedawno na warsztacie, który realizowaliśmy razem z Jackiem w jednej z firm, Product Ownerzy zebrani w tej grupie zapytali nas czego tak naprawdę w praktyce mogą oczekiwać od Scrum Mastera. Uznaliśmy to za świetne pytanie, zwłaszcza ten kontekst takiej praktycznej realizacji odpowiedzialności Scrum Mastera. Przepracowaliśmy sobie na tamtym warsztacie wspólnie odpowiedź, ale po uogólnieniu czujemy, że ta perspektywa jest interesująca dla wszystkich, nie tylko dla Product Ownerów. Zdecydowaliśmy, że to temat na ten odcinek. Więc sponsorami odcinka merytorycznymi jest grupa Product Ownerów ze znanej nam firmy, między innymi Łukasz i Adrian, których pozdrawiamy.

Jacek: Odcinek kierujemy do osób, które zarządzają Scrum Masterami oraz do członków Zespołów Scrumowych, którzy pracują ze Scrum Masterem. To nie znaczy, że Scrum Master powinien wyłączyć to nagranie, wręcz przeciwnie. Posłuchaj, jak tłumaczymy innym to, co należy do Twojej odpowiedzialności. Dokonaj samodzielnej refleksji, zarówno na poziomie tego, jak potrafisz tłumaczyć sens swojej roli, jak i to, co faktycznie jest przez Ciebie realizowane, a w czym możesz się jeszcze poprawić.

Kuba: W tym odcinku powiemy o tym, że Scrum Master, poprawnie realizujący swoją odpowiedzialność, inicjuje rozmowę o swojej ofercie, edukuje zespół w temacie zwinności i Scruma, sprawia, że wydarzenia i artefakty scrumowe mają sens.

Jacek: Zapewnia, że zespół się regularnie usprawnia, doprowadza do usuwania przeszkód, zwraca uwagę zespołu na jego efektywność i wyjaśnia intencje swoich działań.

Kuba: Temat interesujący, posłuchaj reszty odcinka. Spis treści tego odcinka jest prosty, zawiera dwa rozdziały. Jeden, to, czego możesz oczekiwać od Scrum Mastera, gdzie powiemy w szczegółach to, co przed chwilą wymieniliśmy, a w drugiej części skupimy się na tym, co zrobić, jeśli sposób pełnienia roli Scrum Mastera wymaga usprawnienia.

Jacek: I, zanim pójdziemy dalej, informacja, to taka najprostsza instrukcja, świadomie wyselekcjonowaliśmy to, co jest najistotniejsze naszym zdaniem i w szczególności naszą ambicją nie było zrobienie tutaj kalki z Przewodnika po Scrumie.

Kuba: Ok, to pierwszy rozdział. Czego możesz oczekiwać od Scrum Mastera? Zaczęliśmy od tego, że Scrum Master inicjuje rozmowę o swojej ofercie. Jest to takie BHP pracy scrum masterskiej, gdzie oczekujemy, że Scrum Master, który rozpoczyna pracę z danym zespołem czy w ogóle w danej firmie, umie opowiedzieć o tym, czym się zajmuje, co planuje robić, jakie techniki stosuje i w jakich zasadach współdziałania będzie operować. Tutaj, jeśli czujesz, że twój Scrum Master w Twoim zespole tego nie zrobił, albo nie zrobił to swoją osobą, tutaj zakładamy, że może nasi Słuchacze są w różnych rolach, jako Product Owner, lider zespołu czy konkretna funkcja w gronie deweloperów, jeśli masz poczucie niedosytu, albo no ewidentnie, nikt nigdy w gronie scrummasterskim z Tobą nie rozmawiał na temat tego, czym Scrum Master się zajmuje, no to uważamy, że to jest jakby taki pierwszy, wręcz zerowy krok. Scrum Master powinien wyjaśnić, na czym polega ta funkcja.

Jacek: I to brzmi banalnie, na zasadzie, no cóż, wielce tutaj można opowiadać, natomiast umiejętność opowiedzenia, przedstawienia takiej oferty świadczy o tym, że jest ona dosyć dobrze przemyślana i co ważne, wybiega tylko poza wsparcie zespołu w trakcie wydarzeń scrumowych. Tych rzeczy, które Scrum Master może zaoferować, jest o wiele więcej i samo ćwiczenie polegające na zastanowieniu się, co ja tak naprawdę mogę zrobić w organizacji jako Scrum Master, jest czymś, do czego z Kubą gorąco zachęcamy. 

Jacek: Kolejna rzecz, którą możesz oczekiwać od Scrum Mastera, to to, że edukuje on zespół w temacie zwinności oraz Scruma. Czyli spodziewamy się tutaj, że zarówno jest w stanie wytłumaczyć framework scrumowy, który w wielu firmach jest jakiegoś rodzaju fundamentem, na którym opiera się praca zespołów, natomiast oczekiwalibyśmy tutaj nieco więcej, czyli zrozumienie też, czym tak naprawdę jest zwinność. Popularność Scruma doprowadziła do tego, że często pewne techniki czy praktyki są kategoryzowane jako scrumowe, no i w tym wszystkim bardzo łatwo zapomnieć, że za tym wszystkim stoją pewne pryncypia, pewne techniki wynikające czysto z podejścia zwinnego, czy inspirowane z innych metod pracy, czy z innych frameworków. Zrozumienie tego oraz umiejętność sensownego wytłumaczenia tego w zespole jest czymś, czego spodziewałbym się od Scrum Mastera.

Kuba: I co mamy na myśli w praktyce w takim punkcie, że Scrum Master edukuje? Mamy tu na myśli między innymi chociażby samo zarządzanie, czyli koncept tego, że zespół sam organizuje sobie pracę i nie potrzebuje żadnego koordynatora, żadnego managera, żadnej osoby zewnętrznej lub nadrzędnej nad zespołem. Zespół często boryka się z tematem Celu Sprintu. Tutaj też oczekujemy, że Scrum Master umie to wyjaśnić, podpowiedzieć, jak to zastosować, umie też przeprowadzić zespół przez pewną zmianę, żeby coś takiego wprowadzić w życie. Czy szereg tematów związanych na przykład z zarządzaniem, Backlogiem Produktów, gdzie tu są techniki związane z prioretyzacją, jakieś szablony stosowania konkretnych sposobów opisu tych elementów? Wymieniam tylko kilka takich najpopularniejszych, ale tak generalizując, oczekuję, że Scrum Master umie powiedzieć, jaką praktykę można by zastosować dla problemu, jaki dany zespół ma, każdy ma swoje. Umie też powiedzieć, słuchajcie, można to robić tak, czy to poprzez przykłady, czy poprzez jakieś szablony, czy poprzez jakieś podpowiedzi z jakichś konkretnych modeli. Ale co ważne, też umie też wprowadzić to w życie i pomóc zespołowi to zastosować, podpowiedzieć jak to zrobić po raz pierwszy, podpowiedzieć jak to zrobić jeszcze lepiej. Czyli tutaj, jeśli Scrum Master razem z nami wszystkimi w zespole mówi, nie umiemy tego robić, to myślę, że jednak to Scrum Master ma tutaj coś do nadrobienia w temacie umiejętności edukacji zespołu.

Kuba: Trzecia rzecz, której możesz oczekiwać od swojego Scrum Mastera to to, że sprawia, że wydarzenia i artefakty scrumowe mają sens. Coś, co z bólem serca czasami słyszę od zespołów, to stwierdzenia typu: Nasze Daily nie ma sensu, albo nie ma sensu realizować Retrospektywy, czy to, co mamy w Backlogu Produktu jest zupełnie bezcelowe, bezsensowne, nie ma sensu tego uzupełniać. To jest dla mnie sygnał, że tu jest coś do poprawy i tak zamieniając to na pozytyw, wszystkie elementy Scruma, tak jak ja w niej ja go wierzę, jak go praktykowałem, jak go widziałem na własne oczy przez kilkanaście lat, mają sens. Po coś są, są realizowane z pewną intencją i to Scrum Master umie to do zespołu przekazać, zrozumiałem językiem, ale też tak sprawić, żeby ten sens się w zespole pojawił. Zwłaszcza zespół początkujący, albo mający jakieś swoje wyzwania może robić te wszystkie elementy bardzo niedoskonale, ale to od Scrum Mastera oczekuję, że drobnymi korektami, drobnymi podpowiedziami sprawiamy, że pewne rzeczy w naszym Scrumie zaczynają się składać w większą całość.

Jacek: I pierwszym krokiem z perspektywy Scrum Mastera byłoby na pewno zrozumienie tych wszystkich niuansów, żeby móc komentować wydarzenia i artefakty oraz ich celowość i sensowność, to najpierw trzeba odrobić lekcje pod tytułem po co tak naprawdę to robimy? Dlaczego ten konkretny element Scruma jest tu, gdzie jest, dlaczego powinniśmy na niego zwracać uwagę? Co oczywiście prowadzi do rekomendacji, żeby jednak zadbać o edukację i tak naprawdę, naprawdę zrozumieć, po co te konkretne klocki zostały wymyślone. No i z mojej perspektywy i na bazie moich doświadczeń, to jest coś więcej niż tylko lektura Przewodnika po Scrumie. Jednak rozmawianie z praktykami, uczestnictwo w szkoleniach, w których jest to tłumaczone przez osoby, które faktycznie to rozumieją, to są na pewno przykładowe rzeczy, które można zrobić, żeby takie zrozumienie uzyskać.

Jacek: Kolejna rzecz, którą możesz oczekiwać od Scrum Mastera. Zapewnia, że zespół się regularnie usprawnia. Usprawnianie się jest absolutnym filarem zarówno podejścia zwinnego, jak i Scruma. I zadbanie o to, żeby faktycznie to usprawnianie miało miejsce, jest jedną z ważniejszych funkcji Scrum Mastera. Z jednej strony ważne, żeby takie usprawnienia faktycznie były realizowane, czyli to na co się umówimy, żeby było faktycznie przez zespół wykonywane. Z drugiej strony warto byłoby zadbać o to, żeby były to faktycznie te rzeczy, które usprawnią pracę zespołu, a nie były tylko jakimiś takimi wygodnymi tematami zastępczymi.

Kuba: I po czym możemy poznać, że taki Scrum Master wspiera zespół właśnie w usprawnianiu? Przede wszystkim realizuje Retrospektywy Sprintu. Tutaj w wielu zespołach to wydarzenie scrumowe albo niestety jest pomijane, albo jest traktowane bardzo po macoszemu. Dobry Scrum Master sprawia, że zespół czuje o co chodzi w tej Retro, czuje też jaki ma przebieg, jakich instrukcji oczekuje od członków zespołu, które uczestniczą w tym wydarzeniu. No i w efekcie właśnie cały zespół dochodzi do konkretów. To nie jest tylko narzekanie, to też jeden z popularnych wzorców negatywnych, ale że zespół wychodzi z poczuciem – Tak. Od najbliższego Sprintu zrobimy tą jedną, dwie, trzy rzeczy, które faktycznie spróbują zmienić realia pracy tego zespołu. Jeśli któryś z tych wzorców negatywnych, o których wspomniałem w poprzednim zdaniu, jest do poprawy, to być może warto rzucić okiem na nasz webinar o tym, jak powinna wyglądać porządna Retrospektywa Sprintu. Jest ona do znalezienia pod adresem porzadnyagile.pl/retro.

Kuba: Kolejna rzecz, o którym poznać, że Scrum Master realizuje swoją odpowiedzialność w poprawny sposób, to to, że doprowadza do usuwania przeszkód. Przeszkody to jest takie bardzo scrumowe ogólne pojęcie na to, że zespół albo spowalnia swoją pracę, albo niepotrzebnie ma jakieś przestoje, czy trudności w realizacji swoich celów, czy po prostu ewidentnie utyka w miejscu i nie jest w stanie zrealizować swoich planów. Co ważne, tutaj specjalnie mówimy dość ogólnie, bo też tak to w praktyce jest realizowane. Scrum Master swoimi działaniami doprowadza do usuwania przeszkód, ale to nie jest tak, że Scrum Master osobiście usuwa te przeszkody, bo tutaj sposobów realizacji tego może być więcej. Scrum Master niektóre przeszkody może usuwać osobiście, ale też może się przysłużyć zespołowi poprzez świadomą eskalację problemów do odpowiednich osób poza zespołem albo wsparcie innych członków zespołu w tym, żeby to usuwanie faktycznie nastąpiło. Na przykład poprzez przypominanie o temacie, nie ignorowanie tematu, dostrzeganie, że on w ogóle istnieje i tym sposobem zachęcenie całego zespołu do wspólnego rozwiązania problemu.

Jacek: Dobrego Scrum Mastera w tym aspekcie poznamy po tym, że ten rejestr tych przeszkód, jakiś Backlog przeszkód, lista przeszkód, ona istnieje, ona jest widoczna, to nie jest coś, co Scrum Master sobie gdzieś tam kitra na boku i to jest coś takiego jego, do czego zespół nie ma dostępu. Powinno być absolutnie odwrotnie, czyli tak naprawdę to są przeszkody zespołowe, które oczywiście Scrum Master będzie próbował rozwiązać samodzielnie czy z pomocą innych osób, ale jednak będzie powodował, że te tematy będą szły do przodu. Istotnym aspektem w kontekście usuwania przeszkód jest zadbanie o to, żeby rozmawiać o faktycznych przyczynach źródłowych problemu, żeby nie rozwiązywać jakichś takich powierzchownych, widocznych aspektów, a jednak zagłębić się trochę w głąb problemu i zrozumieć z czego on tak naprawdę wynika.

Jacek: Przedostatnia porada w kontekście czego możesz oczekiwać od Scrum Mastera, zwraca uwagę zespołu na jego efektywność. Kiedy mówimy o efektywności, mamy tutaj na myśli relacje efektów uzyskanych przez zespół w kontekście do tego jakie były koszty doprowadzenia do tych rezultatów, do tych efektów. W szczególności nie mamy tutaj na myśli patrzenia na to jak bardzo ludzie są zajęci, czy jak bardzo są zapracowani, czy jak szybko pracują. Kompletnie to nie ta ścieżka, raczej ta prosta relacja efektów do poniesionych kosztów. 

Kuba: I relacja jest prosta, ale sposób tego mierzenia nie zawsze będzie prosty, więc tutaj co zespół to będzie trochę inna historia. W zależności od tego jaki jest produkt, jaka jest też firma, jaki jest biznes, w którym dany zespół funkcjonuje, to te efekty mogą mieć różny smak. Dzisiaj w tym nagraniu głębiej w to nie wyjdziemy, za chwilę polecę materiał dodatkowy. Natomiast coś, co Scrum Master tutaj ma za zadanie to to, żeby zwracać na to uwagę czy w ogóle o tej efektywności się mówi. Myślę, że tutaj duża porcja pracy z Product Ownerem danego zespołu, żebyśmy wszyscy jako cały Zespół Scrumowy byli uświadomieni, gdzie tu jest wartość biznesowa, na czym firma zarabia, dlaczego klienci, użytkownicy chcą tego konkretnego elementu. No i tutaj jest ta strona właśnie wyników, ale również rozmowa o kosztach. Czy zespół pracuje tak wydajnie jak trzeba, czy są jakieś potencjały na to, żeby może zaoszczędzić niektórych kosztów? Myślę tutaj niekoniecznie o kosztach ludzkich, ale każdy zespół ma też sporo kosztów po stronie, na przykład infrastruktury, licencji niepotrzebnych wykonanych ruchów, słabej jakości, słabych praktyk. To wszystko się kumuluje w to, że koszt wytworzenia pewnego efektu jest trochę wyższy niż mógłby być. Ważne, że Scrum Master to porusza z zespołem, uświadamia, wyjaśnia, pokazuje pewne może mierniki zadaje pewne trudne pytania, które dają wszystkim do myślenia w tej kwestii tak, żeby zespół nie realizował bezmyślnie zadań, które są bezwartościowe, albo realizował te zadania w sposób, który jest bardzo kosztowny. Więcej na ten temat, jeśli jest to interesujące dla Ciebie, znajdziesz na moim blogu, gdzie stworzyłem dedykowaną stronę tematowi efektywności, znajdziesz to pod adresem kubaszczepanik.pl/efektywnosc, akurat bez polskich znaków.

Kuba: I ostatnie oczekiwanie, które miałbym względem Scrum Mastera dobrze realizując swoją odpowiedzialność, to taki rodzaj pewnej klamry. Wszystkie te poprzednie punkty, które wymieniliśmy już w tym nagraniu muszą być zrealizowane w pewnym konkretnym stylu. Scrum Master musi wyjaśniać intencje swoich działań. Mam duży problem ze Scrum Masterami, którzy zachowują się bardzo enigmatycznie i bez wyraźnego zapytania nie umieją powiedzieć, dlaczego coś proponują, jakąś technikę, zadają jakieś pytanie, czy proponują, czy proszą o wykonanie konkretnej instrukcji. Od dobrego Scrum Mastera oczekuję, że niepytany w gdzieś nieczeledżowany sposób umie powiedzieć – Robimy to, to i to dlatego, że chcę coś osiągnąć, chcemy coś jako cały zespół osiągnąć. Odważnie i szczerze deklaruje pewne rzeczy deklaruje pewne oczekiwania. Pokazuje swój plan działania. Też tak odwracając nie ma żadnej tutaj ukrytej agendy jakiejś manipulacji, jakiejś tajemnicy, której zespół nie jest w stanie zrozumieć.

Kuba: No i taka incepcja w tym nagraniu. Jacek dlaczego naszą intencją jest to żeby deklarować intencję sposobu działania Scrum Mastera?

Jacek: Jest to istotne, dlatego, żeby Scrum Master nie budował sobie wizerunku osoby, która ma jakiś tajny plan, jakąś ukrytą agendę czy żeby ktoś sobie pomyślał, że Scrum Master jest jakąś taką nadrzędną rolą w stosunku do zespołu i on coś wie i mówi jak ma być, a ludzie mają tak naprawdę słuchać. No jest zupełnie odwrotnie. Czyli te intencje powinny być maksymalnie jasne, powinny być transparentne, powinny być jasne dla zespołu i zespoł powinien doskonale rozumieć, że przykładowe jakieś konkretne pytanie zespołu, czy jakaś sugestia, czy propozycja nie wynika z jakiegoś tam widzimisię, Scrum Mastera, który przeczytał mądrą książkę i teraz udaje, że wie, a raczej ma być pomocą dla zespołu, żebyśmy wspólnymi siłami osiągnęli jakiś konkretny sensowny rezultat.

Kuba:  Ten akcent na wspólnymi siłami, czyli wiele z tych rzeczy, o których mówimy tak naprawdę ma jakąś taką wspólną odpowiedzialność całego Zespołu Scrumowego. Bo to cały zespół się usprawnia, to cały zespół usuwa przeszkody, to cały zespół dba o swoją efektywność i mógłbym tak podsumowywać wszystkie punkty wymienione wcześniej. Scrum Master tutaj może wspierać, podsuwać, ale tak naprawdę to wszyscy razem musimy rozumieć o co nam chodzi. Scrum Master być może ma dobre pomysły, ale jeśli ma te pomysły wciskane zespołowi, to najczęściej nic to nie daje.

Kuba: I zanim przejdziemy do kolejnego rozdziału, przypominam, że trwają zapisy na moje warsztaty, Prawdziwe Przypadki Scrumowe. Grupa jest już liczna i silna w momencie tego nagrania, nadal są pojedyncze wolne miejsca, zapraszam na 202procent.pl/przypadki-scrumowe po więcej szczegółów i informacje organizacyjne.

Jacek: Dobrze, przechodzimy do drugiej części nagrania, czyli tak nieco bardziej praktycznie. Co zrobić, jeśli sposób pełnienia roli Scrum Mastera wymaga usprawnienia. Przede wszystkim z Twojej Słuchaczu perspektywy, jeżeli wchodzisz w relację ze Scrum Masterem no to warto byłoby zacząć od zaproponowania spotkania. Może to być spotkanie jeden na jeden, może to być też spotkanie zorganizowane wspólnie z zespołem, gdzie omówicie jak tak naprawdę ta oferta Scrum Mastera mogłaby wyglądać. Jak się czujemy z tym jak aktualnie ta rola jest pełniona no i być może pojawi się tutaj przestrzeń na to, żeby porozmawiać o tym, co można byłoby zrobić inaczej.

Kuba: I bardzo wprost mówimy o tym, żeby to było wspólne spotkanie dlatego, że naszym doświadczeniem jest to, że wiele zespołów albo pojedynczych osób tworzących zespół ma jakieś uwagi do Scrum Mastera. Nie za bardzo jest przestrzeń na to, żeby o tym rozmawiać. Czasami w niektórych firmach nie ma kultury wystarczająco funkcjonującej, związanej z informacją zwrotną, więc trochę trudniej się o tym rozmawia wprost, a Scrum Masterzy czasami niestety nie realizują jakiejś praktyki, związanej z proszeniem o informację zwrotną. Więc tutaj pierwszy punkt jest o tym, żeby wyjść z inicjatywą, spotkać się z konkretnym Scrum Masterem lub Scrum Masterką z Twojego zespołu czy z Twojego otoczenia i zainicjować rozmowy.

Kuba: Druga rekomendacja, to powołaj się na nasz materiał jako punkt odniesienia. Niestety jest trochę tak, że wiele osób nadal nie do końca rozumie, czym Scrum Master się zajmuje i z tego powodu trochę trudniej, rzetelnie i szczerze tak porozmawiać o tym, gdzie są niedociągnięcia lub gdzie jakieś są potencjały na usprawnienie. Przygotowaliśmy ten materiał z pełną świadomością, że może on służyć właśnie dokładnie do tego, żeby zrobić sobie swego rodzaju rachunek sumienia, zastanowić się jak w Twoim zespole rola Scrum Mastera jest realizowana. Jeśli czujesz, że któryś z punktów, który wymieniliśmy w pierwszym rozdziale ma niedociągnięcia, ma potencjały, to wprost o tym powiedz. Powinno być tak, że dla twojego Scrum Mastera nasz materiał pochodzi ze zaufanego źródła i jest bazą do wspólnej rozmowy.

Jacek: Kolejny punkt. Wylicz rzeczy, których Ci brakuje. Tak jak Kuba wspomniał, materiał może być punktem odniesienia, ale oczywiście należałoby tutaj uwzględnić kontekst organizacyjny. Pewne przeszkody, pewne rzeczy, które nie są realizowane jako Scrum Master być może w danym kontekście są nieco bardziej istotne. Czyli przykładowo, może największy problem aktualnie dotyczy braku wsparcia dla osób biznesowych, braku wsparcia dla osoby Product Ownera. Być może Backlog Produktu nie jest tak przejrzysty i sensownie poukładany jak mógłby być. No stąd tutaj jakby trochę na Tobie pewna odpowiedzialność spoczywa, żeby wskazać tę paletę rzeczy, które można usprawnić. Jednocześnie wskazując te, które są z Twojej perspektywy czy z perspektywy twojej organizacji najbardziej istotne.

Kuba: Natomiast mocna rekomendacja, żeby się trzymać konkretów, faktów. Spróbujmy na tym etapie może mniej oceniać, mniej robić sobie wyrzuty, może też nie róbmy jakiejś recenzji dotychczasowych działań danego Scrum Mastera, tylko raczej bardzo nastawienie na przyszłość. Nastawienie takie o myśleniu o tym, co moglibyśmy wszyscy razem zrobić, a nie co do tej pory nie zadziałało u tej osoby albo u poprzednika, poprzedniego Scrum Mastera czy poprzednich członków zespołu.

Kuba: Czwarta nasza rekomendacja. Poproś, żeby nad tym wspólnie popracować z zespołem. Mocno to akcentowaliśmy w temacie intencje i tutaj to wraca. Większość usprawnień jakie Scrum Master może wprowadzić w swoim sposobie działania jest silnie współzależna od tego, jak działa cały zespół. Czyli Scrum Master indywidualnie może naprawdę niewiele zmienić, jeśli nie będzie jakiegoś rodzaju wsparcia, przynajmniej od części zespołu. Więc tutaj od razu kierujemy Twoje myśli w stronę tego, żeby ustalić co wszyscy w zespole albo co duża część zespołu może zrobić, żeby wspólnie usunąć rzeczy, których na razie brakuje, albo poprawić rzeczy, które wymagają usprawnienia.

Jacek: Kolejny krok. Ustalcie plan działania, jak konkretnie usunąć luki, zaczynając od najważniejszej. Mówiąc plan działania, mam tutaj na myśli konkretne kroki takie bardzo jasne, niewieloznaczne, rabialne. Nie jakieś wielkie ogólne sformułowania, tylko trzeba się spotkać z tą i z tą osobą, trzeba zrobić spotkanie z tym i z tym, trzeba przygotować jakiś materiał, trzeba coś przeanalizować, czyli bardzo konkretnie. No i w tym wszystkim to, co już trochę wybrzmiało w poprzednich punktach, warto limitować sobie tą szerokość tematów, którymi się zajmujemy. Zacząć od najważniejszej, rozpocząć pracę nad tym tematem, skupić się na tym, żeby tą najważniejszą rzecz doprowadzić albo do końca, albo do jakiegoś satysfakcjonującego momentu i dopiero wtedy brać się za kolejne tematy, żeby nie wpaść w pułapkę, że porozgrzebujemy bardzo dużo wątków, a tak naprawdę żaden z nich nie będzie zrealizowany do końca.

Kuba: Kolejna porada, już trochę opcjonalna, ma parę założeń, to zaproś Scrum Mastera z innego zespołu, żeby dał feedback. Założenie najważniejsze, że w naszej organizacji w ogóle jest jakiś jeszcze inny Scrum Master, którego można zaprosić, no ale odpowiednio o dużych czy średnich organizacjach już to ma miejsce. Natomiast w tej instrukcji, tak prostej, jest dużo magii. Magii, z której sami z Jackiem korzystaliśmy czy stosujemy ją wręcz do dzisiaj. Jednak co świeże oko, to świeże oko. Ktoś, kto jest bardzo zaangażowany w temat, ktoś, kto jest bardzo zanurzony w dany kontekst, może po prostu pewnych rzeczy nie dostrzegać. Więc ja do dzisiaj sobie cenię, że Jacek przyjdzie na mój warsztat i mi podpowie, że w niektórych miejscach wpadam w za duże dygresje albo w innych miejscach może moja instrukcja wymagała poprawy i dokładnie ten sam efekt może dać się inny Scrum Master z innego zespołu, który przyjdzie, dołączy na Sprint, czy dołączy, chociaż na pojedyncze wybrane spotkanie czy warsztaty, czy konkretne wydarzenie scrumowe. I na tej bazie zwrócił uwagę na pewne rzeczy, które mogą pomóc danemu konkretnemu, naszemu Scrum Masterowi w realizacji swojej roli.

Jacek: Opcjonalnym punktem rozbudowującym to, co Kuba przed chwilą opowiedział, jest zaangażowanie zewnętrznego eksperta, który wesprze rozwój Scrum Mastera. Tutaj do ustalenia jest możliwy styl współpracy. To może być relacja coachingowa, to może być relacja mentoringowa, to może być wejście bardziej w rolę konsultanta, może to będzie bardziej rola trenerska, a może tak naprawdę w zależności od konkretnej sytuacji będziemy umawiać się na jedną z tych konkretnych podstaw. Oto co warto zadbać, to żeby dobrać adekwatne narzędzia do poziomu rozwoju danej osoby, no i dobrze mieć zdiagnozowane potrzeby dalszej pracy. Nie każdy z naszych Słuchaczy jest w pozycji do tego, żeby zaangażować zewnętrznego eksperta, bo to się raczej wiąże się z rolami liderskimi czy managerskimi, ale nawet jeśli Ty samodzielnie nie jesteś w stanie do tego doprowadzić, to na pewno możesz rozpocząć taką rozmowę. Jest to praktyką, niektóre organizacje robią to dość rutynowo i to jest może możliwe, tylko może jeszcze wasze organizacje niepraktykowane, a może nawet praktykowane, tylko jeszcze o tym nie wiecie. Więc tutaj, jeśli czujecie jako zespół w porozumieniu ze Scrum Masterem, że to jest coś, co mogłoby pomóc, to warto to rozważyć i spróbować porozmawiać z tym z odpowiednimi osobami.

Jacek: I dodam tak bardzo wprost, że tymi odpowiednimi osobami możemy być my z Kubą.

Kuba: Tak. I ostatni punkt w naszej instrukcji. Umówcie się na sprawdzenie efektów. Jedną z klasycznych pułapek rozmowy o usprawnianiu się jest to, że się nawet umówiliśmy na konkrety i nawet zrobiliśmy plan, tylko nie wróciliśmy, nie podsumowaliśmy odpowiednich działań. Tutaj możemy porozmawiać ze swoim Scrum Masterem o tym, jak sprawdzicie, jakie efekty da jakieś umówione działanie i też, kiedy do tego wrócicie. Jeśli jesteś członkiem Zespołu Scrumowego, to jest spora szansa, że można się przyczepić do po prostu konkretnej, najbliższej albo jeszcze kolejnej Retrospektywy i tam sobie wygospodarować parę minut na to, żeby sobie powiedzieć, czy umówiony aspekt realizacji roli Scrum Mastera faktycznie się poprawił. To jest dobra okazja, żeby sobie docenić wykonane działania i być może też dać informację zwrotną do tego, co nadal jeszcze jest pewnym potencjałem.

Jacek: Podsumowując. Jak można zmienić sposób, w jaki realizowana jest odpowiedzialność Scrum Mastera w Twoim zespole? Zaproponuj spotkanie jeden na jeden lub z zespołem. Powołaj się na nasz materiał jako punkt odniesienia. Wylicz rzeczy, których ci brakuje. Poproś, żeby nad tym wspólnie popracować zespołem. 

Kuba: Ustalcie plan działania, jak usunąć luki zaczynając od najważniejszej. Zaproś Scrum Mastera z innego zespołu, żeby dał feedback. Zaangażuj zewnętrznego eksperta, który wesprze rozwój Scrum Mastera i umówcie się na sprawdzenie efektu.

Jacek: Jeżeli nie masz pewności, czy Scrum w Twojej organizacji realizowany jest w satysfakcjonującym stopniu albo czujesz, że nadal jest potencjał na usprawnienia, ale nie masz pomysłu, jak się za to zabrać, skorzystaj z naszego eksperckiego doradztwa. Dołączamy z Kubą do organizacji, wykonujemy diagnozę stanu zwinności i na tej bazie rekomendujemy konkretne praktyki oraz zmiany, których celem jest poprawianie efektywności pracy zespołów. Więcej informacji o tej usłudze znajdziesz na stronie porzadnyagile.pl/diagnoza.

Kuba: Natomiast notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo naszej rozmowy znajdziesz na stronie porządnyagile.pl/127.

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

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

Poznaj narzędzie Circle of influence, które pomaga zespołom zwinnym zidentyfikować, na co mają pełny, częściowy lub żaden wpływ. Dzięki temu zespoły mogą skupić się na obszarach, które są w ich zasięgu, co prowadzi do efektywniejszych usprawnień i zwiększenia satysfakcji z pracy. Dowiesz się też jakie zastosowanie ma Circle of influence w Retrospektywie oraz innych kontekstach, takich jak zarządzanie zależnościami czy planowanie zmian w organizacji.

Ostatnio podczas warsztatów przeprowadziliśmy dyskusję z pewnym zespołem, który był przekonany, że nie ma już niczego, co można usprawnić. Po głębszym zbadaniu tematu doszliśmy do wspólnego wniosku, że istnieją obszary do poprawy, ale nie leżą one w zasięgu mocy sprawczej zespołu. Próby rozmowy o tych kwestiach były frustrujące, więc zespół postanowił całkowicie zrezygnować z Retrospektyw.

Spis treści

• Czym jest Circle of influence?
• Jakie problemy rozwiązuje Circle of influence?
• Jak z tego skorzystać?
• Do jakich działań można użyć Circle of influence?
• Transkrypcja podcastu „Circle of influence”

Ten przypadek był pojedynczym wydarzeniem z warsztatu, ale jest znamienny, takie sytuacje spotykamy częściej. Kiedy zespół ma poczucie, że nic nie da się poprawić, zwłaszcza w obszarach poza jego kontrolą, jednym z rozwiązań, które najczęściej proponujemy, jest narzędzie zwane Circle of influence.

Koncept Circle of influence został stworzony przez psychologa Kurta Lewina, a później spopularyzowany i nieco zmodyfikowany przez Stephena Coveya, autora znanych koncepcji związanych z nawykami efektywnego działania. Będziemy używać terminu „Circle of influence” jako nazwy narzędzia, mimo że istnieje polskie tłumaczenie „krąg wpływu.” Trzymamy się angielskiej nazwy, ponieważ w biznesowym obiegu jest ona częściej używana, a polskie tłumaczenia, zwłaszcza w szczegółach, nie zawsze oddają dokładnie niuanse tej koncepcji. Czym dokładnie jest ta koncepcja? Zakłada ona, że istnieją trzy poziomy naszego wpływu: 

W psychologicznych korzeniach tej koncepcji mocno wybrzmiewa założenie, że niektóre osoby poświęcają zbyt dużo uwagi na rzeczy, na które nie mają wpływu. To powoduje stres, blokuje działanie, wywołuje poczucie bezsilności i brak satysfakcji. Psychologiczny aspekt tej koncepcji ma na celu przekierowanie uwagi na rzeczy, na które faktycznie mamy wpływ, i skupienie się na nich, zamiast na tych, które są poza naszą kontrolą.

W zespołach zwinnych stosujemy to narzędzie, aby pobudzić refleksję nad możliwymi zmianami oraz nad tym, jaki wpływ zespół ma na swoje otoczenie. Wracając do historii z początku, są zespoły, które koncentrują się na dużych niedoskonałościach znajdujących się poza ich strefą wpływu i skupiają się na tym, że nie mogą tych elementów zmienić. Jednocześnie zaniedbują obszary, na które mają wpływ, zarówno bezpośredni, jak i pośredni, i gdzie faktycznie mogliby dokonać zmian.

Przytoczymy ci po jednym, celowo różnym, przykładzie, aby pokazać, gdzie zastosowalibyśmy Circle of influence w konkretnych sytuacjach biznesowych.

Pierwszym przykładem jest praca z grupą liderów, którzy starali się poprawić współpracę między sobą, aby skuteczniej i bardziej skoordynowanie przeprowadzić zmianę w organizacji. Zapytani o ostatnie usprawnienia, które zrealizowali, przedstawili różne tłumaczenia, że „nie da się”, „jest szklany sufit”, „próbowaliśmy wielokrotnie”, „odbijaliśmy się od organizacji” i generalnie nie ma poprawy. Wprowadzenie Circle of fnfluence pokazało, że tematy, które próbowali rozwiązywać, były poza ich strefą wpływu. Rekomendacja dla tego zespołu liderów polegała na tym, aby skupili się na rzeczach, na które mają częściowy, a zwłaszcza pełny wpływ i skierowali tam całą swoją energię. Zastanowili się się, jak organizują się jako liderzy, jak pracują z zespołami i jak wspierają procesy w organizacji. W wymienionych obszarach mieli możliwość wprowadzenia realnych zmian, bo  właśnie tam mieli pełny lub częściowy wpływ.

Kolejna historia wykorzystania Circle of influence wiąże się z pomocą pewnemu zespołowi, który pracował Scrumem od dłuższego czasu i był w tym naprawdę dobry. Zespół osiągał świetne wyniki, miał poczucie, że wiele poprawił, dobrze współpracował i kończył zadania, których się podejmował. Wiedzieli, że są już bardzo mocnym zespołem, jednak potrzebowali wsparcia, ponieważ zaczęło brakować im pomysłów na dalsze usprawnienia. Kiedy zagłębiliśmy się w temat, okazało się, że zespół łatwo wyliczał rzeczy, które można by zmienić, ale były to głównie zmiany o dużym kalibrze – organizacyjne, procesowe, dotyczące całej firmy. Byli na tyle zaawansowani, że widzieli potrzebę zmian na poziomie całej organizacji, choć w tej firmie jeszcze nie było na to gotowości.

To prowadziło do pewnego marazmu w zespole – czuli się nieco lepsi od reszty, ale jednocześnie widzieli, że pewnych zmian obiektywnie nie da się na razie wprowadzić. Retrospektywy często kończyły się albo rozmowami o zmianach, które nie mogły się wydarzyć, albo na mało istotnych, zastępczych tematach, na które szkoda było czasu. Kuba przeprowadził dla nich Retrospektywę z użyciem Circle of influence. Zespół szybko zauważył, że są rzeczy poza ich strefą wpływu, które nie powinny być przedmiotem dalszej dyskusji oraz usprawnień. Zauważyli również obszary, na które mają przynajmniej częściowy wpływ i mogą spróbować je poprawić. Po tej Retrospektywie zespół poczuł zastrzyk nowej inspiracji i energii do dalszych usprawnień, które wcześniej im nie wychodziły bądź były poza ich zasięgiem.

Jakie efekty daje wykorzystanie Circle of influence?

Oryginalnie Circle of influence jest przedstawiane w literaturze jako zestaw zawierających się kręgów, co jest celowe i daje nazwę tej metodzie. Jednak równie dobrze można to zobrazować jako tabelkę czy grupy zagadnień, co jest równie skuteczne. Podstawą podejścia jest klasyfikowanie zagadnień otaczających daną osobę, zespół, czy całą organizację do trzech kategorii: 

Na bazie takiej klasyfikacji, grupa lub osoba korzystająca z tego narzędzia może świadomie wybrać zagadnienia i skupić się na tym, co rzeczywiście można zmienić. W kolejnych krokach warto przejść do konkretnego planu działania, określając, co chcemy zrobić z tymi wybranymi zagadnieniami.

Ciekawym wątkiem pobocznym, który często pojawia się przy wykorzystaniu Circle of influence, jest to, że w niektórych zespołach może wywołać bardzo żywą dyskusję na temat różnic w postrzeganiu wpływu. Ktoś może stwierdzić, że nie ma wpływu na proces wytwórczy, a inna osoba może odpowiedzieć, że jak najbardziej mamy wpływ, bo to od nas zależy, jak go stosujemy, albo możemy wpłynąć na niego pośrednio, wystarczy jedno słowo. Takie różnice zdań mogą być wyraźne i jeśli prowadzisz tego typu ćwiczenie w swoim zespole, zachęcamy cię, aby zatrzymać się na tym etapie. Warto wejść w lekką konfrontację, wymienić się argumentami, aby dać wybrzmieć różnym perspektywom i ustalić, jaka jest rzeczywistość.

Circle of influence może ujawnić różnice między pesymistami i optymistami w zespole, i warto zadbać o to, by pesymiści nie dominowali narracji, twierdząc, że nic nie da się zmienić i że status quo musi być zachowane. Choć Circle of influence nie jest narzędziem stworzonym do tego celu, może dostarczyć cennych refleksji na temat różnic w postrzeganiu spraw w zespole, zwłaszcza gdy połączymy je z technikami facylitacji i poszerzaniem perspektyw.

Circle of influence może być konkretnym modułem lub elementem większego planu na Retrospektywę Sprintu. Widzimy tutaj idealne zastosowanie tego narzędzia po etapie generowania przemyśleń, na przykład listy tematów do poruszenia, problemów, które zespół dostrzega, czy pomysłów na zmiany. Jeśli tematów jest dużo i pojawia się poczucie, że niektóre z nich są absolutnie nieruszalne, Circle of influence może pomóc przefiltrować te tematy. Przepuszczając je przez trzy kręgi lub klasyfikacje, można szybko dokonać wstępnej selekcji: tematy, na które nie mamy wpływu, możemy odłożyć na później, a skupić się na tych, na które mamy pełny lub częściowy wpływ. Te właśnie warto dalej procesować, na przykład przez głosowanie czy selekcję. Może się okazać, że po tym etapie lista jest na tyle krótka, że można omówić wszystko dokładnie i głęboko.Jeśli temat etapu generowania nie jest Ci znany albo nie czujesz się komfortowo z tematem struktury Retrospektywy, to zdecydowanie polecamy sprawdzić nasz webinar „Porządna Retrospektywa Sprintu”. W nim omawiamy m.in. kroki i strukturę, które pozwalają na skuteczne przeprowadzenie Retrospektywy Sprintu. Webinar znajdziesz pod adresem porzadnyagile.pl/retro

Często zespoły domyślnie odpowiadają na pytanie, co można zrobić z zależnościami zewnętrznymi, stwierdzeniem: “właściwie nic nie możemy zrobić, bo to leży poza naszym obszarem wpływu.” Nasze doświadczenie pokazuje, że po głębszym zastanowieniu można zrobić więcej niż tylko stwierdzić brak wpływu. W praktyce może się okazać, że istnieją działania, na które mamy częściowy wpływ, na przykład zaangażowanie kogoś z zewnątrz we współpracę. Możemy również podjąć działania po naszej stronie, takie jak obniżenie ryzyka, przygotowanie się na ewentualność, że pewna zależność zewnętrzna nie zostanie zrealizowana na czas.

Circle of influence może być użyte w bardziej świadomy i specyficzny sposób. To już nie jest kwestia ogólnego wpływu na całą rzeczywistość, ale bardziej zawężone i szczegółowe pytanie. Na przykład, jeśli polegamy na interfejsie od zespołu B, możemy zastanowić się co możemy konkretnie zrobić, na co mamy wpływ, a na co nie. Oczywiście, możemy nie mieć wpływu na to, czy zespół B dotrzyma obietnicy, ale mamy wpływ na to, czy dobrze nas rozumieją, bo to my przekażemy im informacje. Możemy też zabezpieczyć się po naszej stronie, na przykład poprzez monitoring lub planowanie, które zminimalizuje ryzyko, że coś pójdzie nie tak.

To przykład, gdzie grupa liderów transformacji, osoby zarządzające lub zaangażowane oddolnie w transformację, mogą wspólnie zastanowić się nad zmianami w firmie, używając Circle of influence. Często spotykamy zespoły, które blokują się, nie wykonując tego ćwiczenia, i szybko zaczynają dostrzegać jedynie przeszkody – jak system budżetowania, sposób zarządzania, postawa prezesa, brak strategii – i wyliczają powody, dla których nie da się nic zmienić. Choć te spostrzeżenia mogą być obiektywnie prawdziwe, prowadzą do tego, że zespół przestaje dostrzegać obszary, które faktycznie można zmienić. Czasem te zmiany są kluczowe i mogą stać się paliwem do odważniejszych kroków, co może skłonić do ponownego przemyślenia, czy naprawdę nie da się zmienić procesu budżetowego lub postawy prezesa.

To ćwiczenie może być szczególnie ważne i interesujące, kiedy dostrzegasz w sobie lub w osobach, z którymi wprowadzasz zmiany, że popadacie w marazm. Może pojawić się poczucie, że tempo zmian jest niesatysfakcjonujące, że chcesz robić wielkie, spektakularne rzeczy, ale w rzeczywistości jest przestrzeń tylko na drobne usprawnienia w twoim najbliższym otoczeniu. Każda organizacja ma swoje tempo zmian i swój apetyt na nie, a próba podjęcia zbyt ambitnych tematów może na dłuższą metę demotywować. Circle of influence może być świetnym sposobem na zwizualizowanie mapy działań i lepsze zrozumienie, z czym tak naprawdę się mierzymy.

Wyobraź sobie, że pracujesz w organizacji, niezależnie od poziomu, i widzisz mnóstwo różnych opcji, tematów, które możesz podjąć. Taki natłok tematów może być przytłaczający. Z drugiej strony, możesz nieświadomie zacząć zajmować się sprawami, które nie są w pełni w obszarze twojego wpływu. Circle of influence może pomóc ci zastanowić się, w które bitwy warto się zaangażować i gdzie będziesz potrzebować wsparcia. Jednocześnie pozwala jasno określić, które obszary lepiej na razie zostawić, co może obniżyć poziom demotywacji czy niezadowolenia, wynikającego z niemożności osiągnięcia zamierzonych celów. Przegląd tego, co jest sensowne do ruszenia, sprawia, że Circle of influence staje się bardzo użytecznym narzędziem.

Może to dotyczyć zarówno samorozwoju, jak i wsparcia innych osób. W kontekście samorozwoju, możesz zastanowić się, jaki wpływ masz na swój rozwój, jakie działania warto podjąć, a które lepiej odpuścić, aby się nie frustrować. Z kolei, jeśli jesteś trenerem, mentorem, nauczycielem czy coachem, Circle of influence może być cennym narzędziem w pomaganiu innym w ich rozwoju osobistym. Szczególnie przydatne jest to narzędzie, gdy mamy do czynienia z różnorodnością opcji rozwojowych.

Każdy z nas ma wiele możliwych ścieżek do osiągnięcia celu. Kiedy cel jest zdefiniowany, warto rozszerzyć dostępne opcje, a następnie przefiltrować je przez pryzmat tego, na co mamy pełny, częściowy lub żaden wpływ. Dzięki temu unikniemy blokowania się na scenariuszach typu chciałbym rozwijać się jako Scrum Master, ale firma nie wysyła mnie na konferencje, więc nie mam wpływu na swój rozwój. To typowa pułapka myślenia, w której koncentrujemy się na tym, czego nie możemy zmienić, zamiast dostrzegać inne dostępne możliwości rozwoju. Circle of influence pomaga odblokować to myślenie i skierować uwagę na działania, które są w naszym zasięgu.

W takich sytuacjach pomocna może być druga para oczu i uszu. Osoba, która towarzyszy nam w procesie – mentor, coach czy nauczyciel – może swoimi komentarzami i pytaniami pomóc odblokować nasze myślenie. Czasem rozmowa z kimś może sprawić, że zaczniemy dostrzegać szanse, na które mamy częściowy wpływ, a może nawet znajdziemy pomysły, które możemy samodzielnie zrealizować.

Koncepcja Circle of influence zakłada, że istnieją trzy poziomy naszego wpływu: rzeczy, na które mamy pełny wpływ, takie, na które mamy częściowy wpływ, oraz takie, na które kompletnie wpływu nie mamy.

Circle of influence może być użyte do:

Circle of influence bywa stosowane na Retrospektywie zespołu, w pracy indywidualnej oraz przy planowaniu zmian na poziomie organizacji.

Na koniec chcemy ogłosić kolejną edycję Prawdziwych Przypadków Scrumowych dla Scrum Masterów i Agile Coachów, która odbędzie się 22 i 23 października 2024 roku w Warszawie. 

Spotkamy się stacjonarnie, aby przepracować case studies prawdziwych historii z prawdziwych zespołów. Te przypadki są zawsze skomplikowane, więc wspólnie zastanowimy się, jak można by postąpić w danej sytuacji i jakie praktyki zastosować. Może nawet poruszymy temat Circle of influence. Będziesz mieć okazję do refleksji nad tym, jak te popularne historie przekładają się na życie zawodowe, zespoły i firmy. Wyjdziesz z tego spotkania z nową dawką inspiracji oraz pomysłami na narzędzia i praktyki, które mogą wzbogacić narzędziownik Scrum Mastera lub Agile Coacha.

Wszystkie szczegóły organizacyjne oraz możliwość zapisu znajdziesz na stronie 202procent.pl/przypadki-scrumowe

Jacek: Przeprowadziliśmy ostatnio dyskusję z pewnym zespołem podczas warsztatów, w którym to zespole funkcjonowało dosyć mocne przekonanie, że nie ma już niczego, co mogą usprawnić. Jednak po pogłębieniu tego tematu doszliśmy do wspólnego wniosku, że istnieją rzeczy, które są możliwe do usprawnienia, jednak nie są one w zasięgu mocy sprawczej zespołu. Próba rozmowy o tych tematach frustrowała, więc żeby  się nie denerwować, zespół odpuścił kompletnie realizowanie Retrospektyw.

Kuba: Ten przypadek był pojedynczym z pojedynczego warsztatu, ale jednak jest on znamienny, bo spotykamy takie sytuacje częściej. Jedno z rozwiązań, jakie najczęściej proponujemy w takiej sytuacji, czyli zespołu, który ma poczucie, że nic się nie da poprawić, albo przynajmniej nie da się poprawić niczego, co jest poza sprawczością zespołu. Te przypadki zdarzają się częściej, dlatego postanowiliśmy poświęcić cały odcinek w narzędziu, który nazywa się Circle of influence.

Jacek: W dzisiejszym odcinku powiemy czym jest Circle of influence, powiemy jakie problemy rozwiązuje, powiemy jak z tego narzędzia korzystać oraz do jakich działań możemy go użyć.

Kuba: Zaczynając pierwszy rozdział, czym jest Circle of influence? Definicja, a może nawet zamiast definicji zacznę od historii. Koncept Circle of influence stworzył psycholog Kurt Lewin, a rozpopularyzował go i troszkę też zmodyfikował Covey, czyli autor znanych wątków związanych np. z nawykami efektywnego działania. Od razu też zastrzeżenie będziemy używać w nagraniu stwierdzenia Circle of influence jako narzędzia. Istnieje polskie tłumaczenie, spotkaliśmy się z czymś takim jak krąg wpływu, ale będziemy się trzymać nazwy angielskiej, bo też w obrocie takim biznesowym częściej widzimy zastosowanie właśnie tego, a zwłaszcza jak to bywa z polskimi tłumaczeniami. O ile do kręgu wpływu jeszcze nie mamy uwagi, to już do szczegółowych elementów tej koncepcji uważamy, że niuanse tłumaczenia nie zostały odpowiednio dobrze oddane. Więc wszystkim bardziej zafascynowanym polskimi tłumaczeniami, no wybaczcie, musimy was poprosić o to, żeby wytrzymać z naszym Circle of influence.

Jacek: Czym dokładnie jest ta koncepcja? Zakłada ona, że istnieją trzy różne poziomy naszego wpływu. Pełny wpływ, kolejny poziom to częściowy wpływ i ostatni poziom to taki, na którym nie mamy wpływu na nasze otoczenie.

Kuba: I zwłaszcza w korzeniach psychologicznych tej koncepcji mocno wybrzmiewa pewne założenie, że wybrane osoby za dużo uwagi, przykładają do tego, co jest bez wpływu. To stresuje, to blokuje działanie, to powoduje, że ciągle dana osoba lub grupa osób się tym martwi, nie ma satysfakcji, bo jest też takie poczucie bezsilności. No to ten psychologiczny aspekt próbuje przekierować uwagę, albo co najmniej rozdzielić uwagę na to, że faktycznie są rzeczy, na które wpływu nie mamy. Ale dla równowagi są również te i to tymi trzeba się zająć, na które wpływ jest. 

Jacek: I w zespołach zwinnych stosujemy to narzędzie z Kubą, żeby wywołać refleksje nad możliwymi zmianami oraz tym, jaki wpływ ma zespół na swoje otoczenie. I tutaj nawiązując do tej historii z początku odcinka, są zespoły, które widzą bardzo dużą niedoskonałości poza obszarem swojego wpływu. I tak bardzo mocno skupiają się na tym, że akurat tych elementów czy tych rzeczy nie da się zmienić. Jednocześnie niewystarczająco mocno zwracają uwagę na to, co jest w strefie ich wpływu, bezpośredniego lub pośredniego i co faktycznie może zostać.

Kuba: Ok, to przechodząc do kolejnego rozdziału, jakie problemy rozwiązuje Circle of influence? Przytoczymy z Jackiem po jednym przykładzie, różnym przykładzie od siebie, świadomie to dobraliśmy, które pokażą, gdzie jeszcze użylibyśmy Circle of influence w konkretnych sytuacjach biznesowych.

Jacek: Pracowałem jakiś czas temu z grupą liderów, która była na ścieżce polepszania tego, jak między sobą współpracują, po to, żeby w lepszy sposób, bardziej skoordynowany, przeprowadzać zmianę w organizacji. Na moje pytanie o ostatnie usprawnienia, które zrealizowali, słyszałem odmieniane przez różne przypadki tłumaczenia, że nie da się, jest szklany sufit, próbowaliśmy wielokrotnie, odbijaliśmy się od organizacji, generalnie nie ma poprawy. Wprowadzenie i użycie Circle of influence pokazało, że te tematy, które próbowali adresować i rozwiązywać, były poza strefą ich wpływu. Moja rekomendacja dla tego konkretnego zespołu liderów była następująca. Skupcie się na rzeczach, na które macie bądź częściowy, a w szczególności pełny wpływ i tam wsadźcie maksimum energii. Spójrzcie na to, jak się organizujecie jako liderzy. Spójrzcie na to, jak pracujecie z zespołami. Spójrzcie na to, jak wspieracie procesy w organizacji, bo najprawdopodobniej w tych obszarach, które wymieniłem, możecie tak naprawdę wszystko zmienić i macie albo pełny, albo częściowy wpływ.

Kuba: Moja historia wykorzystania Circle of influence wiąże się z pomocą pewnemu zespołowi. Zespół pracował Scrumem już od dłuższego czasu i był w tym naprawdę niezły. Mówię tu bez żadnej ironii, ani żadnego przekąsu. Zwłaszcza wewnętrzni mieli poczucie, że są naprawdę nieźli, że wiele rzeczy poprawili, że naprawdę dobrze ze sobą przede wszystkim współpracują, że też kończą rzeczy, których się podejmują. Więc mieli takie poczucie, że w zasadzie sporo już zrobiliśmy i jesteśmy naprawdę mocnym zespołem, ale trafiłem do tego zespołu na takie wyraźne ich zaproszenie. Kurczę, kończą nam się tematy, w których czujemy, że może nastąpić jeszcze jakaś realna zmiana. Okazało się, że jak weszliśmy głębiej, to zespół bardzo łatwo wyliczał rzeczy, które można by zmienić, ale były to rzeczy dosyć grubego kalibru. Zmiany organizacyjne, zmiany sposobu działania, całych procesów. Zespół był na tyle dobry faktycznie, że troszkę wyprzedzał swoje czasy i dużo rzeczy widział takich, które powinny być zmienione na poziomie całej organizacji. A w tej organizacji jeszcze może nie było, jeszcze nie była pora, jeszcze trochę za wcześnie na pewne większe rzeczy. Natomiast to powodowało w zespole pewien lekki marazm, no bo byli we wnętrznym poczuciu trochę lepsi od wszystkich. Pewne rzeczy faktycznie obiektywnie nie dało się na razie wprowadzić, więc no Retrospektywy wiązały się albo z tymi tematami, jak można by zmienić organizację i momentalnie kończyło się ustaleniem, że nic się nie da zrobić. Albo tematami, które były bardzo mało istotne. Jakieś takie zastępcze, drobne, w gruncie rzeczy, trochę szkoda czasu na takie wątki. Przeprowadziłem temu zespołowi jako gościnny Scrum Master, Retro z użyciem właśnie Circle of influence. Szybko sobie wszyscy w całym zespole zwrócili uwagę na to, że są rzeczy, które są poza ich sferą wpływu i być może nie powinny być nawet w ogóle uruchamiane do dalszej dyskusji. Ale są też takie rzeczy, na które mają wpływ co najmniej częściowy i mogą spróbować je zaatakować i faktycznie poszukać usprawnień w tej sferze. Sam zespół, zwłaszcza po tym Retro miał poczucie, że dostał zastrzyk nowej inspiracji, że tutaj jakby na nowo spojrzeli na rzeczywistość i też nową energię dostali do dalszych usprawnień, które do tej pory im wychodziły, ale gdzieś tam wyczerpała się klasyczna, znana i widoczna im przed oczami pulą.

Jacek: Jakie efekty daje wykorzystanie Circle of influence w zespole? Identycznie postrzegamy to, jaki w ogóle mamy wpływ na daną sytuację. Wiemy jaki mamy wpływ na konkretny temat. Inspirujemy się do dalszych ciągłych usprawnień. Wybieramy te usprawnienia, które faktycznie są możliwe do wprowadzenia. I zauważamy możliwość pośredniego wpływu na wybrane sytuacje.

Kuba: Oryginalnie Circle of influence w literaturze, książkach, w teorii przedstawia się jako zawierające się kręgi, więc ta nazwa jest nieprzypadkowa nazwa metody, ale w gruncie rzeczy nie ma to tak naprawdę istotnego znaczenia, jeśli chcemy to zobrazować też jako pewną tabelkę, czy pewne grupy zagadnień, to będzie równie dobre. Natomiast podstawą podejścia jest po prostu zaklasyfikowanie zagadnień, jakie otaczają daną osobę albo z zespół w naszym przypadku pewnie częściej, czy całą organizację do trzech kategorii. Pierwsza kategoria to Circle of concern, czyli te rzeczy, które są istotne, ale nie mamy na nie wpływu z perspektywy tego obiektu, osoby czy zespołu, z której rozpatrujemy dane zagadnienie. Circle of influence, czyli takie, na które wpływ jest, ale jest on częściowy albo pośredni. I Circle of control, czyli sprawy, które są całkowicie pod kontrolą danej osoby, zespołu lub firmy i też pod pełną decyzyjnością tej rozpatrywanej perspektywy.

Jacek: I na bazie takiej klasyfikacji, o której Kuba powiedział, grupa czy osoba korzystająca z tego narzędzia może bardzo świadomie dokonać wyboru zagadnień i skupić się na tym, co realnie może zmienić. W kolejnych krokach warto oczywiście przejść do konkretnego planu działania, co z tymi zagadnieniami chcemy zrobić.

Kuba: Ciekawy wątek poboczny, który wychodzi przy wykorzystaniu Circle of influence, to to, że w wybranych zespołach może wiązać się bardzo żywa dyskusja na temat tego, jak różnie postrzegamy to poczucie wpływu. Ktoś powie, nie mamy wpływu na proces wytwórczy, a ktoś inny powie, jak nie mamy. No przecież to w zasadzie to tylko od nas samych zależy, jak my to dokładnie stosujemy, albo wystarczy, że szepniemy słowo i pośrednio bardzo mocno możemy na to wpłynąć. Może się tak zdarzyć, że te różnice zdania będą wyraźne i, zwłaszcza jeśli mówię w tej chwili do osoby, która poprowadzi tego typu ćwiczenie w swoim zespole, to zachęcam Cię, żeby zatrzymać się na tym etapie, żeby może wejść w leki konflikt, różnice zdań, powymieniać się argumentami, żeby różne osoby powiedziały, jak sprawy postrzegają, po to, żeby jednak dać wybrzmieć różnym perspektywom i faktycznie ustalić, jaka jest rzeczywistość. Bo może się okazać, że Circle of influence przy okazji wyciągnie trochę pesymistów i optymistów z zespołu. No i fajnie byłoby, żeby zwłaszcza ci pesymiści nie nadawali tonu, że nic się nie da, że wszystko musi być tak jak jest, że status quo musi być zachowany. Więc tutaj Circle of influence, zwłaszcza z połączeniem z technikami facylitacji i takim rozszerzeniem perspektywy, może dać bardzo ważny głos na temat różnic w zespole i może nie jest to narzędzie samo w sobie do tego, ale jednak da pewną refleksję na temat postrzegania spraw.

Jacek: Ok, to w praktyce do jakich działań można użyć Circle of influence?

Kuba: Pierwsza rzecz, która przychodzi mi do głowy oczywisty sposób, to Retrospektywa Sprintu w zespole. Już tutaj użyliśmy przykładu, ja podałem jeden, w zasadzie Jacek powiedział o warsztacie, który miał bardzo podobny charakter jednak takiej refleksji nad procesem. I tutaj Circle of influence może być bardzo konkretnym modułem, czy bardzo taką konkretną cząstką większego planu na Retrospektywę. No i widzimy tutaj bardzo konkretne miejsce po etapie generowania przemyśleń, czy to jest lista tematów do poruszenia, czy lista problemów, który zespół dostrzega, czy jakaś lista pomysłów, co może można by zmienić. Po takim etapie użyłbym Circle of influence do przefiltrowania tematów. Jeśli jest tych tematów zwłaszcza dużo i zwłaszcza jest poczucie, że pewne rzeczy są absolutnie nie do ruszenia, to dzięki takiemu przepuszczeniu przez te trzy kręgi albo trzy zagadnienia, czy trzy klasyfikacje, można dosyć szybko uzyskać taką właśnie wczesną, wstępną selekcję może rzeczami, na które nie mamy wpływu, po prostu się na razie nie zajmujmy, wytypujmy te, na które mamy wpływ kompletny albo częściowy i tylko te procesujmy dalej do na przykład głosowania, do na przykład selekcji, a może, pokaże się, że po tym etapie to już w zasadzie lista jest tak krótka, że możemy omówić dokładnie i głęboko wszystko to, co na tej liście się znajduje.

Kuba: Jeśli temat etapu generowania nie jest Ci znany albo nie czujesz się komfortowo z tematem struktury Retrospektywy, to zdecydowanie sprawdź nasz webinar o „Porządnej Retrospektywie Sprintu”, gdzie między innymi poruszamy właśnie to, z jakich kroków, czy w jakiej strukturze można przeprowadzić dobrze Retrospektywę Sprintu. Ten webinar znajdziesz pod adresem porzadnyagile.pl/retro

Jacek: Drugi przykład praktycznego zastosowania Circle of influence to zarządzanie zależnościami zewnętrznymi w zespole. Takim często domyślnym sposobem odpowiadania zespołów na temat, co można zrobić z zależnościami zewnętrznymi jest odpowiedź, „No właściwie nic nie możemy zrobić”. Tak naprawdę absolutnie leży to poza naszym obszarem wpływu. Nasze wspólne doświadczenie z Kubą mówi nam, że jeśli się tak dobrze jednak zastanowić, to możemy zrobić coś więcej niż powiedzieć, że nie mamy wpływu. W praktyce może się okazać, że są rzeczy, na które mamy częściowy wpływ, czyli możemy na przykład zaangażować kogoś z tej strony, od której zależymy w jakąś współpracę. Możemy też porobić pewne akcje po naszej stronie, obniżyć ryzyko, przygotować się, być gotowym na wariant, co jeśli pewna zależność zewnętrzna nie zostanie zrealizowana czy dostarczona na jakąś spodziewaną z naszej strony datę.

Kuba: I tutaj to Circle of influence może być użyte w taki bardzo świadomy, trochę inny sposób, gdzie bardziej sobie zadajemy pytanie, „Ok, to w tej sytuacji jak różne poziomy wpływu możemy zyskać?”. Czyli to już nie jest, jaki wpływ mamy na całość rzeczywistości, tylko jest bardzo takie zawężające czy doszczegółowujące pytanie. Ok, w tym zagadnieniu polegania na interfejsie od zespołu B, co my możemy konkretnie zrobić, na co mamy wpływ częściowy, a na co nie mamy kompletnie wpływu. No i oczywiście pewnie wpływu nie mamy na to, czy oni zrobią to, co obiecują, ale już mamy wpływ na to, czy dobrze nas rozumieją, bo to my im przekażemy informacje i na przykład po naszej stronie możemy się zabezpieczyć jakimś monitoringiem, może takim ustawieniem planu, żeby to nas kompletnie nie zawaliło.

Kuba: Trzeci przypadek, gdzie w praktyce można użyć Circle of influence, to planowanie zmiany w organizacji. To w zasadzie jest przykład historii Jacka, czyli grupa liderów transformacji, osoby może zarządzające, może jakieś osoby zaangażowane oddolnie w transformacje mogą wspólnie dokonać refleksji na temat zmiany w firmie właśnie przez pryzmat Circle of influence. Tutaj często spotykam takie zespoły, które też się właśnie blokują, nie robiąc ćwiczenia typu Circle of influence i na przykład dosyć szybko widzą wszystko to, co powoduje, że się nie da zmienić firmy, bo taki mamy system budżetowania, taki mamy system zarządzania, tutaj prezes jest taki, a nie inny, taką mamy, albo jej nie mamy strategię. Można długo wyliczyć, dlaczego nic się nie da zmieniać i to są obiektywnie pewnie dosyć prawdziwe spostrzeżenia. Tylko to może powodować, że niestety przestajemy widzieć rzeczy, które faktycznie zmienić się mogą i może się okazać, że one są potrzebne, one są pewnym paliwem do ośmielenia się do dalszych zmian i jednak zredefinowania sobie, czy faktycznie nie jesteśmy w stanie zmienić procesu budżetowego albo postawy prezesa.

Jacek: I w szczególności może to być ważne czy interesujące ćwiczenie, kiedy dostrzegasz w sobie albo w osobach, z którymi przeprowadzasz zmianę, że wpadamy czy wpadacie w marazm. Takie poczucie, że w sumie to tempo zmian jest absolutnie niesatysfakcjonujące. Chcielibyśmy robić te duże rzeczy, te duże zmiany, spektakularne, a może tak naprawdę jest przestrzeń tylko na drobne rzeczy, na usprawnienia w naszym podwórku, bo każda organizacja ma swoje tempo zmian, ma swój apetyt na zmianę. Jakby próba zaatakowania zbyt ambitnych tematów może tak naprawdę na dłuższą metę nas demotywować. I Circle of influence może być bardzo fajnym sposobem na to, żeby sobie tę mapę działań, ten obraz, tego, z czym tak naprawdę się mierzymy, dobrze sobie zwizualizować.

Jacek: Kolejnym przykładem wykorzystania Circle of influence może być praca indywidualna. Wyobraź sobie, że pracujesz z organizacją, tak naprawdę nie ma to dużego znaczenia na jakim poziomie i widzisz całą masę różnych opcji, tematów, które możesz ruszyć, rzeczy, którymi możesz się zająć. Po pierwsze, taki natłok tematów może nas trochę przygnieść. Z drugiej strony możemy w sposób taki trochę nieprzemyślany zacząć atakować tematy, które być może nie do końca są w obszarze naszego wpływu. Circle of influence w tym przypadku może pozwolić nam na to, żeby zastanowić się, w których bitwach tak naprawdę chcemy wziąć udział, do których bitew będziemy potrzebowali wsparcia. Natomiast wyraźnie też sobie powiedzieć, są pewne obszary, których tak naprawdę nie warto na tym etapie dotykać i być może pozwoli nam to troszeczkę obniżyć poziom demotywacji czy takiego niezadowolenia. Może nie do końca to jest to, co chcielibyśmy robić. Tak więc taki jasny przegląd tego, co jest sensowne do ruszenia, bo w tym przypadku Circle of influence jest bardzo sensownym narzędziem.

Kuba: I ostatni przypadek, gdy wykorzystałbym Circle of influence to wsparcie przy mentoringu i coachingu rozwoju osobistego. I to może dotyczyć zarówno samorozwoju, czyli trochę w klimacie tego, co Jacek powiedział, mogę też patrzeć na perspektywy, jaki wpływ mam na swój rozwój, jakie działania rozwojowe mogę robić, na które może lepiej sobie odpuścić i nie denerwować. Ale też, gdy jestem już dla kogoś trenerem, nauczycielem, mistrzem, ekspertem czy coachem, to to również są narzędzia, które mogą pomóc w rozwoju osobistym danej osoby. To zwłaszcza jest ten aspekt właśnie różnorodności opcji. Każdy z nas zazwyczaj ma mnóstwo możliwych ścieżek pójścia czy dotarcia do pewnego celu. Jeśli zdefiniowany jest ten cel, to właśnie dobrze też ewentualne opcje rozszerzyć, ale później przefiltrować przez pryzmat tego, na co wpływ mam, a na co mam wpływ mniejszy albo żaden. Żeby też się właśnie nie blokować na scenariusze typu, no rozwinąłbym się jako zawodowy i doświadczony Scrum Master, ale firma nie wysyła mnie na konferencję, więc nie mam wpływu na swój rozwój. Co jest piękną pułapką myślenia, że faktycznie może nie masz wpływu na budżety szkoleniowe, jakie masz w swojej firmie, ale masz wpływ na wiele innych sposobów tego, jak rozwinąć się zawodowo i nawet konkretnie jak wziąć udział w konferencji, nawet jeśli firmie szkolenia nie są sfinansowane w ten sposób. Tutaj to jest Circle of influence, to jest też narzędzie, które możemy pomóc komuś w rozwoju, czy pomóc przejść i odblokować się właśnie od tej pułapki myślenia o tym, że są rzeczy, na które nie mam wpływu, ale za bardzo je dostrzegam i za bardzo one mnie męczą i powodują, że przestaję myśleć w otwarty sposób.

Jacek: Tutaj myślę w szczególności pomocna może być druga para oczu i uszu, właśnie wszystkie te osoby w tych rolach, o których Kuba mówił, ja jakby to uproszczę, druga osoba, która uczestniczy w tym procesie, komentarze tej osoby, pytania, wsparcie mogą też pomóc odblokować nasze myślenie no i wyjść trochę z takiej pułapki, że wydaje nam się, że na coś kompletnie nie mamy wpływu, ale porozmawianie z mentorem, czy z osobą towarzyszącą może spowodować, że nagle zaczniemy dostrzegać jednak pewne szanse, na które być może mamy częściowy wpływ, a może nawet jakieś pomysły, które absolutnie samodzielnie możemy zrealizować.

Jacek: Podsumowując całość odcinka. Koncepcja Circle of influence zakłada, że istnieją trzy różne poziomy naszego wpływu. Rzeczy, na które mam pełny wpływ, takie, na które mamy częściowy wpływ oraz takie, na które kompletnie wpływu nie mamy.

Kuba: Circle of influence może być użyte m.in. do refleksji nad wpływem w kontekście tematów, którymi się zajmujemy, wsparciem przy wyborze usprawnień, które są możliwe do wprowadzenia i zauważenie możliwości pośredniego wpływu na sytuację i zaplanowanie realizacji odpowiednich działań, żeby tę sytuację zmienić.

Jacek: Circle of influence bywa stosowane na Retrospektywie zespołu w pracy indywidualnej i przy planowaniu zmian na poziomie organizacji.

Kuba: Na koniec chciałbym ogłosić kolejną edycję Prawdziwych Przypadków Scrumowych z zebraną grupą Scrum Masterów i Agile Coach’ów, 22 i 23 października 2024 roku w Warszawie stacjonarnie spotkamy się, żeby przepracować case studies prawdziwych historii, prawdziwych zespołów. Te przypadki są zawsze skomplikowane, zastanowimy się jak można by postąpić w tej sytuacji, jakie praktyki zastosować, m.in. być może wpadniemy też na Circle of influence, no i w efekcie wszyscy uczestnicy dokonują refleksji na temat tego, jak te historie popularne przekładają się na ich życie zawodowe w ich konkretnych zespołach czy firmie, ale też gdzieś każdy wychodzi z bagażem, inspiracji, jakie jeszcze narzędzia, materiały, praktyki może dorzucić do swojego narzędziownika Scrum Mastera czy Agile Coach’a. Wszystkie szczegóły organizacyjne oraz możliwość zapisu znajdziesz na 202procent.pl/przypadki-scrumowe

Jacek: Cóż więcej mogę dodać, ja po prostu polecam, żebyście rozważyli te warsztaty na jesień tego roku. Natomiast notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/126

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

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

Poprawnie skonstruowany Cel Sprintu to wyzwanie dla niejednego zespołu. Widzimy to dosyć często w naszej codziennej pracy. Z czego może wynikać ten problem? Zdradzamy kilkanaście naszych hipotez. Mamy też dla Ciebie kilka rozwiązań, które pomogą poprawnie skonstruować Cel Sprintu.

Cel Sprintu jest zobowiązaniem będącym częścią Backlogu Sprintu. Jest on ustalany przez Zespół Scrumowy podczas planowania Sprintu. Określa, co zespół chce osiągnąć w ramach Sprintu. Dobrze sformułowany Cel daje developerom pewną swobodę w doborze rozwiązania w trakcie Sprintu. Cel Sprintu pozostaje niezmienny przez cały Sprint, co zapewnia zespołowi skupienie, spójność współpracy i stały punkt odniesienia przez cały czas trwania Sprintu.

Spis treści

• Powody problemów w konstruowaniu celu Sprintu
• Jak rozwiązać problemy w zbudowaniu celu Sprintu? 
• Transkrypcja podcastu „Dlaczego tak trudno ustalić Cel Sprintu?„

To bardzo podstawowy, ale istotny problem. Obserwujemy, że brak dobrego zrozumienia, dlaczego Cel Sprintu jest obecny w Scrumie, prowadzi do problemów z jego praktycznym wykorzystaniem podczas Sprintu. Cel Sprintu jest narzędziem, które pozwala nam osiągnąć skupienie. Z natłoku różnych tematów, którymi moglibyśmy się zająć w trakcie Sprintu, wybieramy jeden określony kawałek – coś, co chcemy osiągnąć na koniec Sprintu, czy to funkcjonalnie, czy biznesowo. Cel Sprintu powinien być dla nas najistotniejszy i pomagać w podejmowaniu codziennych decyzji podczas pracy w Sprincie.

Mamy tutaj do czynienia z nadinterpretacją teorii, która mówi, że cel zapewnia skupienie i pozwala na współpracę. Choć to prawda, przesadne zrozumienie tego może prowadzić do myślenia, że Cel Sprintu musi pokryć 100% elementów wziętych do Sprintu, włącznie z tymi, które są nieco inne niż główne zadanie. 

Podobnie problem może dotyczyć developerów. Jeśli zespół składa się z sześciu developerów, pięciu może realizować główne zadanie, ale szósty może zajmować się np. zadaniami utrzymaniowymi. W takich przypadkach zespoły próbują na siłę włączyć wszystkie zadania i wszystkich developerów do Celu Sprintu, co prowadzi do tworzenia celów zbyt ogólnych lub wieloelementowych. Naszym zdaniem jest to antywzorzec.

Odwracając ten problem, Cel Sprintu nie musi pokrywać całego zakresu i nie musi dotyczyć każdego developera w danym momencie. Ważne jest, aby zrozumieć specyfikę danego zespołu i skupić się na głównym celu, który jest najistotniejszy dla Sprintu.

Wyobraź sobie sytuację, w której zespół konstruuje Cel Sprintu i pewne prognozowane elementy z Backlogu Produktu wchodzą w jego zakres. Nagle ktoś mówi, że naprawa jakiegoś błędu jest również ważna, ale skoro nie ma jej w Celu Sprintu, to zespół nie będzie się na niej skupiać. Cel Sprintu ma wskazywać drogę, być drogowskazem, latarnią morską dla zespołu, ale to nie oznacza, że rzeczy spoza Celu Sprintu są kompletnie nieważne i można je zignorować.

W praktyce może się zdarzyć, że rzeczy poza Celem Sprintu, gdy w trakcie Sprintu odkryje się problemy, mogą stać się kandydatami do renegocjacji. Jednak na etapie planowania Sprintu nie powinniśmy od razu zakładać, że czegoś nie zrobimy tylko dlatego, że nie jest w Celu Sprintu.

Realizacja Celu Sprintu jest rozliczana przez management, co może być źródłem problemów. Dlaczego? Ponieważ zespoły zaczynają podejmować niewskazane negocjacje. 

Jeśli zespoły są ściśle monitorowane i kontrolowane, ustalają taki Cel Sprintu, aby jak najszybciej go zaliczyć. Niestety, widzieliśmy na własne oczy, że jako Cel Sprintu formułowane jest coś, co można zrealizować w 1-2 dni. Oczywiście, zespół wykonuje wiele innych zadań, ale ma potencjał, aby wyznaczyć bardziej ambitny Cel Sprintu. Jednak zespoły są zachęcane przez management do tego, aby zawsze mieć wszystko „na zielono”. W rezultacie cel jest albo banalny, albo tak negocjowany, żeby go zawsze zaliczyć. To powoduje, że Cel Sprintu nie spełnia swojej podstawowej funkcji, a staje się narzędziem do unikania problemów i zapewnienia, że wszystko wygląda dobrze w raportach.

Takie podejście jest zrozumiałe w korporacyjnym świecie, ale może być bardzo frustrujące dla Product Ownerów, którzy chcieliby stawiać bardziej ambitne cele. Ponadto, koncepcja pracy eksperymentalnej i przyrostowej całkowicie się rozmywa, ponieważ zespół skupia się na bezpieczeństwie i zaliczaniu celów, zamiast na faktycznym rozwoju i dostarczaniu wartości.

Dlaczego tak trudno ustawić sensowny Cel Sprintu? Jednym z głównych powodów jest brak pracy przyrostowej. Mówimy o sytuacji, w której zespół realizuje z góry założony zakres konkretnego produktu lub projektu, ale brakuje chęci poukładania tego w sensowne przyrosty. Na pierwszy rzut oka, patrząc na Backlog Produktu, może się wydawać, że jest on sensownie przemyślany i można z niego wyłonić Cele Sprintu. Jednak w rzeczywistości jest to po prostu lista rzeczy do zrobienia, a podczas planowania Sprintu trudno wyłapać z tej listy coś, co można zamknąć w sensowny Cel Sprintu.

Problem tkwi w braku przyrostowości. Wiele zespołów ma trudności z formułowaniem Celów Sprintu, ponieważ Sprinty nie przynoszą przyrostów. Jest to wynik tego, że zadania są tak poukładane, że trzeba zrobić wszystko. Wybierane są nie te kombinacje realizacji zakresu, które dają przyrostowość, ale te, które z jakiegoś powodu ładnie pasują do planu. Problem polega na tym, że brakuje przyrostowości, a koncepcja robienia pełnych kroków i osiągania sensownych celów zanika.

To klasyczny problem, który najczęściej prowadzi do antywzorca, który nazywamy „wielocelem”. Oznacza to, że zespół ma w planie zrealizować funkcjonalność X, poprawić wskaźnik KPI ABC o Y oraz rozwiązać 10 błędów. Taki „wielocel” najczęściej można rozpoznać po wielu połącznikach w formule celu, gdzie wszyscy widzą i wiedzą, że to są dwie, trzy, cztery, a czasem nawet więcej wyraźnie odseparowanych zadań. Są one wzięte do Sprintu, zgodnie z decyzją Product Ownera, być może samodzielnie, a być może pod naciskiem interesariuszy, komitetów lub innych czynników.

Na etapie planowania zespół łatwo odkrywa, że musi złapać wiele wątków. Product Owner nie jest skłonny do zmiany tej sytuacji. Ewentualnym mini rozwiązaniem jest uzgodnienie, że zespół wykonuje wiele różnych rzeczy, ale tylko jedna z nich trafia do Celu Sprintu. Jednak wówczas wracamy do problemów, które wcześniej wspomnieliśmy.

Jeśli nie wykonuje się odpowiedniej pracy przed planowaniem Sprintu, nie mamy na myśli tylko procesu Refinementu, ale także bardziej wysokopoziomowej analizy, która pozwala spojrzeć na produkt z szerszej perspektywy, to później trudno jest określić Cel Sprintu. Jeżeli nie mamy jasno określonego sensownego Celu Produktu, bardzo trudno jest ustalić konkretne kroki, czyli Cele Sprintu, które będą nas prowadzić do tego Celu Produktu. Jeżeli Cel Produktu jest dla Ciebie interesującym tematem, odsyłamy Cię do odcinka 111 na stronie porzadnyagile.pl/111.

W skrajnych przypadkach dopiero na planowaniu Sprintu ustala się, co właściwie znajduje się w Backlogu. Często zespół dopiero ustala kryteria, dokonuje estymacji i dzieli zadania. Powoduje to, że są ważniejsze sprawy niż rozmowa o Celu Sprintu. Jeśli Backlog Produktu jest nieuporządkowany, prawdopodobnie nie było czasu na rozmowy o Celach Produktu jako całości, kolejnych większych krokach, przyrostach czy pomysłach na rozwój produktu. Najczęściej wynika to z braku wystarczającego czasu na Refinement.

Jednym z pytań, jakie zadalibyśmy zespołowi mającemu problemy z Celami Sprintu, jest: „Jak wygląda wasz Backlog Produktu?” Na ile jest gotowy i jak daleko w przód jest zaplanowany? W dyskusjach, pracach i aktywnościach refinementowych widzimy silną korelację – nieuporządkowany Backlog powoduje trudności z planowaniem i ustalaniem Celu Sprintu.

Kolejny problem, który uniemożliwia łatwe i skuteczne tworzenie Celu Sprintu, to sytuacja, w której zespół rozwija wiele produktów jednocześnie lub pracuje nad wieloma projektami. 

W takiej sytuacji zespół jest traktowany jako zasób, do którego można wrzucać dużą liczbę różnych wątków, streamów czy kontekstów. Zwykle prowadzi to do tego, że pojedyncze osoby lub małe podgrupy (2-3 osoby) obsługują te wątki. Jeśli mamy kilka takich wątków na Sprint, nie jesteśmy w stanie stworzyć Celu Sprintu, który jest wspólny dla całego zespołu. Cel Sprintu powinien angażować większość zespołu, budując poczucie zespołowości i wspólnego dążenia do celu. Kiedy wątków jest wiele, wyklucza to możliwość stworzenia takiego celu, który daje wartość zespołowi i poczucie wspólnego osiągnięcia konkretnego celu. W skrajnym przypadku może to oznaczać, że każdy członek zespołu ma swój własny Cel Sprintu, ponieważ wątków jest tyle, ilu członków zespołu. To kompletnie się nie sprawdza. 

Zespół może być skoncentrowany na jednej specjalizacji technologicznej, podczas gdy produkt ma wiele warstw, obsługiwanych przez inne zespoły. Może to być też zespół składający się z wybranych kompetencji, ale niezdolny do stworzenia sensownego produktu jako całość. W takich przypadkach Cele Sprintu są zupełnie nieadekwatne. Możemy na przykład postawić serwis, ale to nie jest ani funkcjonalność, ani cel biznesowy. Jest to, tylko etap w rozwoju. Zespół może czuć, że sensowny cel jest ustalany na poziomie kilku zespołów lub, na przykład w komitecie zarządzania, ale na pewno nie na poziomie tego konkretnego zespołu. Kluczowe jest więc to, jak skonstruowane są zespoły w organizacji. Nie można winić pojedynczego zespołu za brak możliwości określenia Celu Sprintu, jeśli nie tworzą produktu jako całość.

Chodzi tutaj o drobne zlecenia, rzeczy, które są od siebie bardzo różne, co jest podobne do dwóch poprzednich punktów, o których pisaliśmy. Jednak jest to o tyle specyficzna sytuacja, że spotykamy zespoły, które nazywają siebie bądź są nazywane w organizacji zespołami utrzymaniowymi. Czasem jest to utrzymanie konkretnego produktu, czasem całego obszaru. Kluczowe jest to, że bardzo trudno jest przewidzieć, czym dokładnie taki zespół będzie się zajmował. Większość ich pracy polega na reagowaniu na bieżące potrzeby, zamiast realizowania jakiejś wizji czy konkretnej koncepcji.

Oczekiwanie od takiego zespołu, że wymyśli i wybierze sensowny Cel Sprintu, może być trudne. Wyobraźmy sobie sytuację, w której w ramach utrzymania zmieniana jest konkretna wersja biblioteki, co wymaga pracy na wielu frontach i w różnych miejscach. Wtedy może to być kandydat na Cel Sprintu. Jednak, gdy różne zadania wpadają od różnych interesariuszy z różnych stron organizacji, próba stworzenia wspólnego Celu Sprintu dla takiego zespołu może być nierealistyczna.

Przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep

Określiliśmy, jakie mogą być powody, mające wpływ na skonstruowanie Celu Sprintu. To pokazuje, jak myślimy o problemach, kiedy pracujemy z klientami. Teraz wskażemy, co można zrobić, aby poradzić sobie z tymi problemami. Poniżej proponujemy, kilka rozwiązań, które warto rozważyć. 

Pierwsze możliwe rozwiązanie to uporządkowanie i rozbudowanie swojej wiedzy na temat Celu Sprintu. Zakładamy, że sposób wprowadzenia, tłumaczenia i pokazywania Celu Sprintu na przykładach wpływa na jego późniejsze stosowanie. Kierujemy to głównie do Scrum Masterów, Agile Coachów i Product Ownerów.  Mogą istnieć powody, na które nie masz wpływu, takie jak konstrukcja zespołów czy ogólnofirmowe procesy, ale w każdym zespole można dużo osiągnąć, jeśli wiedza o Celu Sprintu jest uporządkowana i dobrze zrozumiana. Im lepiej rozumiesz to narzędzie, tym skuteczniej wprowadzisz je do swojego zespołu. Szukaj informacji, sprawdzaj różne źródła, nie bój się zadawania trudnych pytań trenerom i mentorom. Jeśli coś nie działa, spróbuj inaczej. Jako Scrum Master, Product Owner czy Agile Coach masz wpływ na to, jak przekazujesz i wprowadzasz Cel Sprintu jako narzędzie.

W przeciwieństwie do pierwszej porady zachęcamy, aby zrozumienie Celu Sprintu nie było tylko w głowie jednej osoby. Ważne jest, aby cały zespół uczestniczył w szkoleniach lub warsztatach, które mają na celu wyrównanie poziomu wiedzy. Istotne jest, aby skupić się na pracy na realnych przykładach Celów Sprintu. Można wziąć przykładowy zakres Backlogu Produktu lub wcześniejsze Cele Sprintu i zastanowić się, jaki mały krok może sprawić, że te Cele będą lepsze. Nawet jeśli wiemy, że nie osiągniemy od razu idealnego Celu Sprintu, warto dążyć do stopniowego ulepszania i zbliżania się do sensownego Celu Sprintu.

Zespół często ma problem z rozpoczęciem pracy nad celami lub z ich rewizją. Zachęcamy do wytrwałości i cierpliwości w realizacji celów przez kilka kolejnych Sprintów. Ważne jest, aby regularnie wprowadzać Cel Sprintu, poświęcać na to czas i zatrzymywać się jako cały zespół, zamiast unikać trudności i wybierać bezpieczne, ale niedocelowe rozwiązania. Eksperymentuj z różnymi formułami i sposobami dochodzenia do Celu Sprintu. W niektórych zespołach Product Owner proponuje szkic Celu Sprintu, w innych developerzy sami próbują go wyłapać, słysząc, co jest do zrobienia. Istnieje również kilka wariantów pośrednich. Nie ma jednego dobrego sposobu – spróbuj różnych podejść i zobacz, który najlepiej pasuje do twojego zespołu, aby wprowadzić to do swojej rutyny.

Zakładamy, że w twoim zespole już istnieje jakiś proces Refinementu, ale warto zainwestować dodatkowy czas w te spotkania. Może to polegać na spojrzeniu na Backlog Produktu z szerszej perspektywy, a nie tylko na niskopoziomowe elementy Backlogu. Oprócz dzielenia, uszczegóławiania czy szacowania zadań, warto zastanowić się nad poprawą efektywności procesu, co może dać więcej czasu na refleksję nad długoterminowym układem Backlogu Produktu. Jeśli interesuje Cię odpowiedzialność Zespołu Scrumowego podczas Refinementu, czyli rola Product Ownera, Scrum Mastera i developerów, zapraszamy do odcinka na stronie porzadnyagile.pl/89

Trzy ostatnie problemy były ściśle związane z konstrukcją zespołów: za dużo produktów, za dużo wątków lub brak konkretnego produktu i prace utrzymaniowe. To może sugerować, że dzisiejsza konstrukcja zespołów, ich granice, skład osobowy lub kompetencyjny nie są doskonałe, co utrudnia realizację Celów Sprintu. Nie chodzi tylko o same Cele Sprintu, ale o to, że trudności z ich realizacją mogą być sygnałem, że warto zaangażować management i porozmawiać o konfiguracji zespołów.

Ważne jest, aby zespoły były zgodne z koncepcją zespołów samodzielnych, autonomicznych, produktowych, realizujących pracę przyrostowo. Te składowe są często w zasięgu działania managementu, i to na wyższym poziomie niż pierwszy stopień menedżerski. Wymaga to zwołania sojuszu Product Ownerów, Scrum Masterów, sąsiadujących zespołów i kilku menedżerów mających podobny problem. Ktoś musi tę rozmowę rozpocząć i zainspirować innych myślą, że można to zrobić inaczej. Takie rozmowy potrafią trwać miesiącami, ale każdy dzień jest dobry, aby je zacząć i porozmawiać o możliwości zrekonfigurowania zespołów przy najbliższej okazji.

Czasem po prostu nie da się zmienić układu zespołów z różnych powodów, często politycznych, i dostajemy komunikat, że musi pozostać tak, jak jest. W takiej konfiguracji może być bardzo ciężko ustawić dobre Cele Sprintu. Jeśli nie można ustawić sensownych Celów Sprintu, może to być sygnał, że Scrum nie jest odpowiednim frameworkiem dla twojej sytuacji, zespołu lub aktualnej konfiguracji. Warto potraktować to jako sygnał ostrzegawczy. Może lepiej odpuścić Cele Sprintu, zamiast konstruować je tylko po to, by odhaczyć ich istnienie. Warto zastanowić się, czy Scrum jest właściwym narzędziem dla Twojego zespołu. Jeśli chcesz pogłębić tę myśl, odsyłamy do odcinka „Kiedy Scrum nie jest odpowiedzią” na porzadnyagile.pl/68

Podsumowując, jakie mogą być powody problemu w konstruowaniu Celu Sprintu?

Przygotowujemy kolejny webinar, tym razem o tym, jak skutecznie pracować z Celem Sprintu. Wiemy z doświadczenia, że temat jest istotny i trudny dla wielu osób. Sami mamy poczucie, że w dostępnych materiałach jest on mało pokryty. Jeśli jest to ważny temat dla Ciebie, zostaw swój e-mail na stronie webinaru i bądź jedną z pierwszych osób, które dowiedzą się, że webinar jest już dostępny. Stronę webinaru i formularz do zostawienia maila znajdziesz pod adresem porzadnyagile.pl/cs.

Oczywiście ten e-mail wykorzystamy tylko do poinformowania Cię, że webinar jest już gotowy. Notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/125.

Kuba: Tematem tego odcinka jest, dlaczego tak trudno ustalić Cel Sprintu. Podczas warsztatów z zespołami, podczas pracy faktycznej, codziennej, coachingowej z wybranymi Zespołami Scrumowymi, obserwujemy, że poprawne wykorzystanie Celu Sprintu przysparza kłopotów, jest jakimś wyzwaniem. Skonstruowanie poprawnego Celu Sprintu, albo przychodzi z dużą trudnością, albo jest pomijane, czy też występuje kilka różnych od siebie sposobów na to, żeby wypełnić Cel Sprintu, ale tak naprawdę nie osiągnąć tego, o co chodzi z tym konkretnym zobowiązaniem. I postanowiliśmy nagrać na ten temat odcinek, ale odcinek będzie silnie skupiony głównie na powodach, dlaczego jest to problem, czy wyzwanie. Powody mogą być bardzo różne od siebie. Tutaj zebraliśmy kilka różnych kategorii i kilka różnych powodów. Opowiemy o tym, dlaczego ciężko jest ustalić Cel Sprintu i z czego to może wynikać.

Jacek: Spis treści dzisiejszego odcinka jest następujący. Przypomnimy, czym jest Cel Sprintu. Wylistujemy powody problemów w konstruowaniu Celu Sprintu i przytoczymy możliwe rozwiązania na problem ustalania Celu Sprintu.

Kuba: To przechodząc do pierwszego rozdziału, krótkie przypomnienie, czym jest Cel Sprintu. Cel Sprintu jest zobowiązaniem wchodzącym w skład Backlogu Sprintu. Cel Sprintu jest ustalany przez Zespół Scrumowy na planowaniu Sprintu. No i Cel Sprintu wskazuje, co jest jakimś takim celem, zobowiązaniem, dążeniem do tego, co jest do osiągnięcia w ramach Sprintu. Często ten Cel Sprintu jest jakąś formą powiedzenia, jaki ma mieć kształt przyrost, który uzyskamy w tym Sprincie. Czasami jest to coś bardziej biznesowego, czasami to jest bardziej funkcjonalne, albo takie skupione na jakimś konkretnym kawałku zakresu. No ale dobrze sformułowany Cel Sprintu daje pewną swobodę rozwiązania, doboru rozwiązania w trakcie Sprintu przez deweloperów, bo Cel Sprintu w całym Sprincie jest niezmienny i to on jest taką składową czy stałą, która zapewnia skupienie zespołowi, zapewnia spójność współpracy i powoduje też, że zespół ma się do czego odnieść przez cały czas pracy w trakcie Sprintu.

Jacek: Więcej informacji o tym, czym jest Cel Sprintu pokryliśmy już w odcinku numer 7. Jeżeli jesteś zainteresowany, bądź zainteresowana, żeby ten odcinek sobie przypomnieć albo poznać, to zapraszamy cię na porzadnyagile.pl/7

Kuba: Natomiast w tym odcinku chcemy się skupić na tym, z czego dokładnie może wynikać problem w konstruowaniu Celu Sprintu i to tu się skupimy, tutaj ten wątek poszerzymy. Powodów wyliczymy jedenaście, więc tutaj zachęcamy do wytrwałości razem z nami. Ale po kolei, jakie mogą być powody, problemów w konstruowaniu Celu Sprintu?

Jacek: Pierwszym powodem jest brak zrozumienia, czym jest Cel Sprintu. Jest to taki bardzo podstawowy powód. Jednakże obserwujemy z Kubą, że brak dobrego zrozumienia, po co tak naprawdę Cel Sprintu znajduje się w Scrumie, powoduje dalsze problemy z jego praktycznym wykorzystaniem w trakcie Sprintu. To, co z mojej perspektywy jest istotne, jeśli chodzi o Cel Sprintu, to to, że jest to narzędzie, które pozwala nam osiągnąć skupienie. Czyli z natłoku różnych tematów, którymi potencjalnie moglibyśmy się zająć w trakcie Sprintu, chcemy się umówić na pewien określony kawałek, na coś, co tak naprawdę chcielibyśmy osiągnąć na koniec Sprintu, czy to funkcjonalnie, czy to biznesowo, tak jak Kuba przed chwilą opowiadał? I to powinno być dla nas tym, co jest najistotniejsze i powinno to wskazywać nam decyzje czy podpowiadać decyzje, które będziemy na co dzień w trakcie pracy w Sprincie podejmować.

Kuba: Kolejnym powodem problemu ze sformułowaniem Celu Sprintu może być błędne założenie o tym, że cel dotyczy całego zakresu pracy w Sprincie i wszystkich deweloperów. Tutaj jest takiego rodzaju nadinterpretacja tego kawałka teorii, że cel zapewnia skupienie, pozwala na współpracę, to jest wszystko prawda. Natomiast przerysowana interpretacja powoduje takie zatrzymanie się albo takie zblokowanie się, że Cel Sprintu, który jest sformułowany przez dany zespół, musi pokryć 100% elementów wziętych do Sprintu, wszystkie możliwe, włącznie z tymi, które ewidentnie są jednak trochę inne niż ta główna rzecz, którą robimy. No i podobnie problem może dotyczyć deweloperów. Czyli z sześciu deweloperów, z jakich składa się ten Zespół Scrumowy, pięciu będzie faktycznie realizowało to główne coś i tak będzie mocno współpracować, ale ten szósty z jakiś powodów jednak zajmuje się czymś trochę innym, na przykład zadaniami utrzymaniowymi. No i tutaj wtedy zespoły zaczynają dokonywać jakichś fikołków albo jakiegoś takiego mentalnego wysiłku, żeby jednak tego szóstego dewelopera, i to siedemnaste zadanie zupełnie inne, też jeszcze próbować wcisnąć do Celu Sprintu i wtedy te Cele Sprintu stają się jakieś takie albo zbyt ogólne, albo właśnie wieloelementowe, czyli kilka takich wskazówek, które zawarliśmy w tym wspomnianym przez Jacka siódmym odcinku, jako jednak naszym zdaniem antywzorce. Czyli odwracając ten problem, Cel Sprintu, nie musi koniecznie pokrywać całego zakresu i nie musi w danym momencie, w danym Sprincie dotyczyć absolutnie każdego jednego dewelopera, jaki w Sprincie jest, bo może to być pewna specyfika danego zespołu.

Jacek: Trzeci powód problemu w konstruowaniu Celu Sprintu to poczucie, że jeśli coś nie jest w Celu Sprintu, to nie jest ważne. To jest trochę podobno do tego, co Kuba mówił przed chwilą, czyli wyobraźmy sobie sytuację, że zespół konstruuje Cel Sprintu i pewne prognozowane elementy z Backlogu Produktu faktycznie wchodzą w zakres tego, co byśmy nazwali Celem Sprintu. Natomiast nagle odzywa się ktoś, kto mówi, no ale przecież przykładowa naprawa jakiegoś błędu, też jest ważna. No ale skoro nie ma jej w Celu Sprintu, to znaczy, że kompletnie nie będziemy się na tym skupiać. Oczywiście to nie jest prawda. Cel Sprintu ma wskazywać nam pewną drogę, ma być drogowskazem, ma być taką latarnią morską dla zespołu, ale to nie oznacza, że rzeczy, które nie wchodzą w skład Celu Sprintu, że są kompletnie nieważne i że możemy je zignorować. 

Kuba: Choć w praktyce może się zdarzyć, że akurat rzeczy poza Celem Sprintu, gdy w środku Sprintu jakieś odkryje się problemy i nie ma znać przedłużenia, to być może to będą kandydatury na rzeczy do renegocjowania, ale w szczególności nie na planowaniu Sprintu rozmawiamy o tym, że w zasadzie od razu mówimy, że tego nie zrobimy, bo nie jest w Celu Sprintu.

Kuba: Ok, to kolejny powód, dla którego może być to wszystko bardzo trudne. Trochę już z innej beczki to to, że realizacja Celu Sprintu jest rozliczana przez management. I dlaczego to jest możliwy powód problemów? Bo zespoły podejmują negocjacje, taką niewskazaną negocjację. Skoro coś jest bardzo rozliczane, coś jest śledzone, coś jest gdzieś tam kontrolowane, to ustalmy taki Cel Sprintu, żeby jak najszybciej zaliczyć. I to mogą być takie historie, też niestety widzieli na własne oczy, że jako Cel Sprintu jest formułowane coś, co w zasadzie w 1-2 dni w Sprincie jest zrobione. Oczywiście zespół robi mnóstwo innych rzeczy. Jest też potencjał w tym zespole na Sprint, taki troszkę bardziej pojemny Cel Sprintu, który jest może też trochę bardziej ambitny. Ale zespół ma zachęty takie no, managerskie do tego, żeby mieć się zawsze na zielono. Więc ten cel będzie albo zupełnie banalny, albo będzie tak negocjowany, żeby go zawsze zaliczyć. To powoduje, że nie spełnia tej swojej podstawowej funkcji frameworkowej, tylko staje się jakimś takim sposobem, żeby nie podpaść czy negocjacją tego, żeby to było wszystko miłe, łatwe i przyjemne. Co oczywiście z jednej strony w korporacyjnym świecie nic mnie nie zdziwi, ale może być bardzo irytujące np. dla Product Ownerów, którzy mieliby ochotę jakieś bardziej ambitne cele postawiać. Czy w ogóle koncepcja takiej pracy eksperymentalnej, przyrostowej, też tutaj się całkowicie rozwala, bo jest jakby podejście byle bezpieczniej, byle zaliczyć, byle nie podpaść, byle dobrze wypaść w jakichś dashboardach czy tabelkach?

Jacek: Piąty kolejny powód, dlaczego tak trudno ustawić sensowny Cel Sprintu, to brak pracy przyrostowej. Mówimy tutaj o sytuacji, kiedy zespół realizuje z góry założony zakres konkretnego produktu czy jakiegoś projektu przy jednoczesnym braku chęci poukładania tego w sensowne przyrosty. Czyli pozornie patrząc na Backlog Produktu możemy mieć poczucie, że to, co widzimy, jest jakoś sensownie przemyślane, być może stoi za ten jakiś cel produktowy czy może wyłaniają się z tego jakieś sensowne Cele Sprintu, ale tak naprawdę jest to po prostu pewna lista rzeczy, które trzeba zrobić i patrząc na ten Backlog, w szczególności w sesji planowania, możemy mieć bardzo dużą trudność, żeby z tej listy, z takiego strumienia tematów do zrobienia wyłapać coś, co moglibyśmy zamknąć w sensowny Cel Sprintu.

Kuba: I tak zaakcentuję mocniej, że nie chodzi nam o to, że być może w niektórych przedsięwzięciach ten zakres jest do przewidzenia, albo w miarę jest on znany i naprawdę nie jest aż tak przekomplikowany, żeby się go nie udało ustalić, tylko jednak ten aspekt przyrostowości. Wiele zespołów ma problem z Celami Sprintu, ponieważ Sprinty nie przynoszą przyrostów i wynika to z tego, że jest to po prostu tak poukładane, że i tak musimy zrobić wszystko, a w dodatku wśród wielu możliwych kombinacji i realizacji pewnego zakresu wybierana jest nie ta, która daje pewną przyrostowość, daje pewną celowość wykonania kolejnych kroków, tylko taka, która z jakiegoś innego powodu ładnie pasuje, na przykład zróbmy cały pierwszy ekran. Chociaż nawet jeśli wtedy to byłoby ujęte jako Cel Sprintu, to może jeszcze nie byłoby tragedii, no ale tej przyrostowości tu nie ma i cała ta koncepcja robienia pełnych kroków i osiągania pewnych sensownych celów zanika.

Kuba: Inny powód, szósty już, to to, że realizowanych jest wiele równoległych wątków w jednym Sprincie. To jest klasyk, który najczęściej prowadzi do takiego antywzorca, który nazywamy z Jackiem wielocelem. Czyli zespół ma w celu zrobić funkcjonalność x, poprawić czynnik KPI, ABC, o Y oraz rozwiązać 10 błędów. Ten wielocel najczęściej można poznać po połącznikach w formule celu, gdzie wszyscy widzą i wiedzą, że to jest dwie, trzy, cztery, czasem nawet więcej wyraźnie odseparowanych rzeczy. Są one do wzięcia do Sprintu, tak podjął decyzję Product Owner. Być może samodzielnie, być może pod naciskiem również jakiegoś otoczenia, czy to interesariuszy, czy jakichś komitetów, czy jakichś jeszcze innych czynników. W to tak głęboko nie chcemy tutaj wnikać, no ale fakt jest w sumie prosty. Na planowaniu zespół w toku ustalania pracy dosyć łatwo odkrywa, że w zasadzie trzeba złapać wiele strok za ogon. Nie za bardzo, Product Owner jest skłonny do tego, żeby to zmienić. Ewentualnym takim mini rozwiązaniem jest powiedzenie sobie, że robimy bardzo dużo różnych rzeczy, ale do Celu Sprintu ląduje tylko jedna z nich, no ale to wtedy już wracamy mniej więcej do problemów, które wcześniej wspomniałem.

Jacek: Kolejny problem. Produkt nie jest rozwijany przez cele. Trochę o celu powiedziałem przed chwilą, mówiąc o Celu Produktu no i generalnie jest tak, że jeśli nie jest wykonana praca taka przed planowaniem Sprintu, nie mam na myśli tutaj tylko procesu Refinementu, ale takiej pracy nawet bardziej wysokopoziomowej, gdzie staramy się spojrzeć na produkt trochę z szerszej perspektywy, z lotu ptaka, no to potem jest problematyczne, żeby powiedzieć, jaki tak naprawdę jest Cel Sprintu. Jeżeli nie mamy ustawianego sensownego Celu Produktu, no to bardzo trudno może nam być ustalać te konkretne kroki, czyli Cele Sprintu, które do tego Celu Produktu będą nas prowadzić. Jeżeli Cel Produktu jest dla Ciebie interesującym tematem, to odsyłamy Cię do odcinka 111 wpisując adres porzadnyagile.pl/111

Kuba: Ósmym powodem problemu z ustaleniem Celu Sprintu może być to, że Backlog Produktu nie jest uporządkowany. Mamy tu na myśli, no może w skrajnym przypadku dosłownie takie coś, że, no dopiero na planowaniu Sprintu de facto ustala się co tam w tym Backlogu w zasadzie właściwie jest, na czym to polega. Często zespół dopiero na planowaniu ustala jakieś kryteria wycenia, robi estymaty, dzieli zadania. To wszystko powoduje, że są ważniejsze rzeczy niż rozmowa o Celu Sprintu. No ale przechodząc nawet czy łącząc się z tym, co chwilę temu Jacek powiedział, no, jeśli Backlog Produktu jest nieuporządkowany, no to nie było prawdopodobnie czasu na rozmowę o Celach Produktu jako całości o jakichś kolejnych większych krokach, przyrostach czy nawet właśnie o pomysłach na to jak rozwijać ten produkt i jakie cele on tutaj mógłby w sobie zawierać. Najczęściej wynika to z niewystarczającego czasu na Refinementy, o czym jeszcze dzisiaj trochę wspomnimy, no ale jednym z pytań jakie bym zadał zespołowi, który ma problem z Celami Sprintu, to jest właśnie rozmowa – A jak wygląda wasz Backlog Produktu? Na jak dużo w przód ten Backlog Produktu jest gotowy albo chociaż rozpoczęty? W takich dyskusjach, pracach, aktywnościach refinementowych różnego typu, no bo tu widzimy bardzo silną korelację, nieuporządkowany Backlog powoduje trudności z planowaniem i m.in. z ustalaniem Celu Sprintu.

Jacek: Kolejny problem, który uniemożliwia łatwe i skuteczne tworzenie Celu Sprintu to sytuacja, w której zespół rozwija wiele produktów jednocześnie bądź jeśli nie mówimy o produktach, to projektów. Jest to sytuacja, w której zespół jest traktowany jako pewien, nazwijmy to, zasób, do którego można wrzucać sporą liczbę różnych wątków, streamów, kontekstów. Co zwykle prowadzi do tego, że pojedyncze osoby lub ewentualnie jakieś bardzo małe podgrupki, 2 może 3-osobowe są w stanie taki jeden z wątków obsłużyć. Jeśli takich wątków mamy kilka na Sprint, to oczywiste jest, że nie jesteśmy w stanie stworzyć Celu Sprintu, który można by powiedzieć, że jest wspólny dla całego zespołu. Taki Cel Sprintu powinien co do zasady jednak angażować większość zespołu tak, żeby rodziło się pewne poczucie zespołowości, poczucie grania do wspólnej bramki. Jeżeli tych wątków jest wiele, no to tak naprawdę wykluczamy sobie możliwość, żeby stworzyć Cel Sprintu dający taką wartość dla zespołu, pod tytułem, jesteśmy tutaj razem chcemy wspólnie osiągnąć jakiś konkretny cel.

Kuba: W skrajnym przypadku to może wręcz oznaczać, że każdy członek zespołu ma swój Cel Sprintu, ponieważ jest tyle wątków w zespole ilu członków. No to zupełnie się nie klei. Przedostatni powód podobny trochę do tego, co Jacek powiedział, to zespół nie tworzy kompletnego produktu. Tutaj ponownie jest temat tego jak poukładany jest zespół, tylko tym razem zespół nie ma wiele produktów jak w Jacka przykładzie, tylko zespół nie ma całego produktu. To może być zespół złożony wyłącznie na przykład w jednej specjalizacji technologicznej, ale produkt ma parę warstw i te parę warstw jest już w innych zespołach, a może to jest zespół złożony wyłącznie z wybranych kompetencji, ale nie jest w stanie jako zespół, jako całość stworzyć sensownego produktu. I tutaj mamy do czynienia wtedy z takim przypadkiem, że te Cele Sprintu albo są takie zupełnie, zupełnie na odwal się. No bo możemy wyłącznie postawić serwis, ale w zasadzie to nie jest ani nawet funkcjonalność. A to na pewno nie jest żaden cel biznesowy, to jest co najwyżej osiągnięcie jakiegoś tam etapu w rozwoju, no albo ten zespół ma poczucie, że to jest jakaś bzdura, że ten taki sensowny cel, to jest coś, co się ustali na poziomie kilku zespołów, a może gdzieś enigmatycznie nawet nie wiadomo gdzie. Może na jakimś komitecie albo właśnie w jakimś zespole zarządzania, ale na pewno nie na poziomie tego konkretnego zespołu.  No i myślę, że kluczowy akcent jest tutaj na to jak skonstruowane są w ogóle zespoły w tej organizacji, no ale nie winiłbym tego pojedynczego zespołu o to, że no, jeśli nie stworzą produktu, no to też bardzo trudno oczekiwać, że będą umieli powiedzieć, jaki mają Cel Sprintu.

Jacek: I ostatnia przeszkoda utrudniająca tworzenie sensownych Celów Sprintu to sytuacja, kiedy zespół realizuje głównie zadania utrzymaniowe. Jakieś drobne zlecenia rzeczy, które są od siebie bardzo różne to jest trochę podobna sytuacja do tych dwóch poprzednich punktów, o których mówiliśmy. Jednak jest o tyle specyficzna, że spotykamy zespoły, które nazywają siebie bądź nazywane są w organizacji zespołami utrzymaniowymi. Czasem jest to utrzymanie, które dotyczy konkretnego produktu, czasem utrzymywany jest obszar. Natomiast to, co jest niezmienne w tych zespołach to to, że bardzo często jest trudno przewidzieć, czym tak naprawdę ten zespół będzie się zajmował. Spora część ich pracy to jest reagowanie raczej na to, co się dzieje dookoła, niż realizowanie jakiejś wizji, jakiejś konkretnej koncepcji. Oczekiwanie od takiego zespołu, że wymyśli, wybierze sobie jakieś sensowne Cel Sprintu, może być trudne. Wyobrażam sobie sytuację, że w ramach utrzymania, przykładowo zmieniana jest jakaś konkretna wersja biblioteki i to wymaga pracy na wielu frontach w różnych miejscach. Wtedy być może jest to jakiś kandydat na Cel Sprintu, natomiast w sytuacji, kiedy wpadają różne zadania od różnych interesariuszy z różnych stron organizacji, próba stworzenia wspólnego Celu Sprintu dla tak skonstruowanego zespołu może być mrzonką.

Kuba: Ok, zanim zaczniemy ostatni rozdział, przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep

Jacek: Dobrze, no to narysowaliśmy z Kubą, to jakie mogą być powody, że Cel Sprintu jest trudno skonstruować. To pokazuje też trochę jak myślimy o problemach, kiedy pracujemy z klientami. Natomiast teraz chcielibyśmy się skupić na tym, co tak naprawdę można byłoby zrobić, żeby z tymi problemami sobie poradzić. Jednocześnie nie mamy tutaj ambicji pokrycia wszystkich możliwych opcji, ponieważ zrobiliśmy to już we wspomnianych na początku odcinka materiałach. Natomiast kilka rozwiązań zaproponujemy pod Twoją rozwagę.

Scrum Masterzy coraz częściej mierzą się z ogromną odpowiedzialnością, ale brakuje im adekwatnego wsparcia. Nierealistyczne oczekiwania stanowią dla nich wyzwanie, a jednocześnie są dużym problemem na drodze do wzmacniania zwinności w organizacji. Skąd się to bierze? Proponujemy Ci kilka praktycznych rozwiązań, które pomogą lepiej wspierać Scrum Masterów, umożliwiając im efektywniejszą pracę.

Scrum Masterzy coraz częściej mierzą się z ogromną odpowiedzialnością, ale brakuje im adekwatnego wsparcia. Nierealistyczne oczekiwania stanowią dla nich wyzwanie, a jednocześnie są dużym problemem na drodze do wzmacniania zwinności w organizacji. Skąd się to bierze? Proponujemy Ci kilka praktycznych rozwiązań, które pomogą lepiej wspierać Scrum Masterów, umożliwiając im efektywniejszą pracę.

Spis treści

• Definicja problemu Scrum Masterów, od których oczekuje się niemożliwego
• Dlaczego management może wymagać zbyt wiele od Scrum Masterów? Z czego to może wynikać?
• Co zarządzający transformacją mogą zrobić, by wesprzeć Scrum Masterów?
• Podsumowanie
• Transkrypcja podcastu „Scrum Masterzy samodzielnie nie zmienią Twojej firmy„

Co mamy na myśli, gdy definiujemy problem Scrum Masterów, od których oczekuje się niemożliwego? Co się za tym kryje? Obserwując Scrum Masterów, można mieć wrażenie, że odpowiadają oni za całą masę rzeczy, także takich, które wychodzą poza ich podstawowy zakres obowiązków. Spada na ich głowę odpowiedzialność za:

To całkiem spora lista odpowiedzialności jak na jedną osobę. 

Kiedy mówimy, że Scrum Master nie ma wsparcia, mamy na myśli brak odpowiedniego wsparcia, poparcia i współdziałania od kluczowych ról, takich jak top management, managerowie procesów oraz liderzy zespołów. Brakuje współpracy z osobami odpowiedzialnymi za produkt, takimi jak Product Managerowie czy Product Ownerzy. W wielu firmach Scrum Masterzy nie otrzymują wsparcia nawet od osób odpowiedzialnych za agile’a. Jeśli rola Agile Coach’a lub lidera transformacji agile’a jest oddzielona, może pojawić się rozdźwięk między Scrum Masterami a promotorami zwinności w organizacji. Dodatkowo brak wsparcia ze strony HR-u może prowadzić do licznych konfliktów.

Oto nasza lista hipotez:

Pierwsza hipoteza jest dosyć prosta i łatwa do przewidzenia. Zmiana prowadzona jest w sposób powierzchowny. Organizacja kopiuje pewien wzorzec postępowania, w tym przypadku wzorce związane z frameworkiem scrumowym. Firmy wiedzą, że trzeba powołać stanowisko Scrum Mastera, ale na tym kończy się ich świadomość. Poza zatrudnieniem zawodowych Scrum Masterów, wiele kolejnych kroków, które powinny zostać podjęte, nie jest realizowanych. Brakuje również osób, które mogłyby to skorygować.

Firmy, które potrzebują zmiany, mają nadzieję, że Scrum, przyniesie pozytywne rezultaty. Jednak błędnie zakładają, że cała odpowiedzialność spoczywa na Scrum Masterze. Przerysowana jest interpretacja, że tylko Scrum Master odpowiada za wdrażanie i usprawnianie Scruma oraz zwinności w firmie.

Wysokie oczekiwania względem Scrum Masterów wynikają z kwestii nowych etatów i zarobków. Stanowisko Scrum Mastera często wiąże się z tworzeniem nowych etatów lub reorganizacją, aby te etaty się pojawiły. Te stanowiska są solidnie opłacane w porównaniu do średnich zarobków w organizacji, często na poziomie menedżerskim lub wyższym od specjalistów. W związku z tym może pojawić się uzasadnione oczekiwanie, że skoro Scrum Master jest dobrze wynagradzany, powinien dostarczać wyraźne rezultaty i efekty. Management, decydując się na zatrudnienie Scrum Mastera, buduje inflację oczekiwań, oczekując maksymalnych korzyści z jego funkcjonowania w organizacji.

Management chce rezultatów zwinności, ale często jej nie rozumie i nie inwestuje w zrozumienie. W efekcie nie pojmuje w pełni potrzeby stojącej za zmianami i nie potrafi tych zmian odpowiednio wesprzeć.

W wielu organizacjach, z którymi współpracujemy, część managerów, w tym najwyżsi zarządzający, skupia się głównie na bieżącej działalności, projektach, terminach oraz końcach miesiąca, kwartału czy roku. Mniej uwagi poświęcają rzeczom strategicznym, długofalowym oraz doskonaleniu procesów, sposobu funkcjonowania zespołów czy transformacji zwinnej. Jak już wspominaliśmy, transformacja zwinna jest niekończącym się procesem, który nie da się ukończyć w parę miesięcy czy kwartałów. W sytuacji, gdy cała organizacja jest skupiona na bieżącej pracy operacyjnej, Scrum Masterzy są osamotnieni, ponieważ nikt inny nie zwraca uwagi na dojrzałość zespołów i inne kluczowe aspekty. W efekcie praca długofalowa nie jest powszechna w organizacji.

Jeżeli chcesz pogłębić wiedzę jeszcze bardziej, niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie: porzadnyagile.pl/sklep.

Co zatem zarządzający transformacjami mogą zrobić, by wesprzeć Scrum Masterów? W tytule rozdziału bardzo świadomie podkreślamy, do kogo kierujemy te porady. Jeśli jesteś liderem transformacji, sojusznikiem zmiany lub sponsorem zmiany w swojej organizacji, to te punkty są dokładnie dla Ciebie. Jeśli współpracujesz z taką osobą, może to jest lista porad lub sugestii, które warto jej przekazać. Może cały artykuł warto zarekomendować. Co mamy jako pierwsze rozwiązanie na naszej liście?

Niezależnie od modelu zmiany, zawsze pojawia się pytanie, dlaczego powinniśmy się zmieniać? Ważne jest, aby ludzie zrozumieli, dlaczego powinniśmy robić rzeczy inaczej niż dotychczas. Pomóż im zrozumieć, że zmiana jest poważna i nie jest to kolejny trend rynkowy, ale rzeczywista potrzeba, dyktowana wewnętrznie lub zewnętrznie. Wymagaj, aby osoby zaangażowane w zmianę znalazły sposób na jej realizację. Odpowiedzi takie jak „Nie da się”, „tak zawsze robiliśmy” czy „tego nie można zrobić w naszej branży” nie powinny być akceptowane.

Dlaczego ta porada znalazła się pierwszym miejscu? Zbyt często spotykamy w organizacjach osoby, które wiedzą lub czują, że wystarczy przeczekać zmianę albo mocno zaargumentować, że nic się nie da zrobić, że zawsze działaliśmy w ten sposób i tak będzie dalej. Osoby chcące wprowadzić zmiany, zwłaszcza na poziomie oddolnym, często bez władzy w organizacji, jak Scrum Masterzy, mają trudności w przekonywaniu innych, np. działów prawnych czy osób odpowiedzialnych za compliance i bezpieczeństwo, które niechętnie reagują na zmiany.W każdej firmie są takie osoby, choć nie chcemy nikogo stygmatyzować, dobrze byłoby, gdyby cała organizacja, włącznie z osobami mającymi konkretne obszary odpowiedzialności, ustawiła się w trybie „spróbujmy coś zrobić”, aby dopasować się do ducha zmiany, który jest powszechny i współdzielony przez wszystkich.

To nadbudowuje poprzednią myśl, ale chcemy mocno zaakcentować, że w niektórych organizacjach zmiana jest prowadzona i zdefiniowana zbyt wąsko od samego początku. Na przykład transformacja zwinna dotyczy tylko wytwarzania oprogramowania, ale już zespoły wspierające czy odpowiedzialne za pewne procesy uważają, że są poza tą zmianą. Czasem nawet jest to jasno zdefiniowane, że transformacja odbywa się bez udziału biznesu lub pewnych obszarów.

Może to być sensownym pierwszym krokiem, jeśli nie ma innej możliwości lub aktualna sytuacja na to nie pozwala. Jednak docelowo warto zdawać sobie sprawę, do jakich konsekwencji takie podejście prowadzi. Możemy mówić o lokalnych optymalizacjach, które czasami są postrzegane jako małe sukcesy. Jednak gdy spojrzymy na szerszy obraz, okazuje się, że drobne zmiany mogą nie mieć większego znaczenia, ponieważ wąskie gardła i nieefektywności mogą być schowane w innych częściach procesu.

Istotne jest, aby cele wypływały z potrzeby zmiany, były kaskadowo przeniesione na adekwatne poziomy w strukturze organizacji. Przykładem może być sytuacja, w której wszyscy uczestniczący w zmianie mogą mieć wspólny wysokopoziomowy cel, na przykład skrócenie „time to market”, lub cele zdefiniowane na poszczególne obszary. Z perspektywy działu zamówień może to być kontraktowanie się z uwzględnieniem realiów pracy zwinnej. Z perspektywy działu wdrożeń może to być skrócenie cyklu release’ów, a z perspektywy działu jakości – automatyzacja testów.

Ta porada jest odpowiedzią na problem różnych priorytetów w różnych częściach organizacji. Jeśli cele są rozbieżne i nie wspierają zmiany, transformacja nie będzie poważnie traktowana i odpowiednio wspierana. Kiedy organizacja chce i potrzebuje się zmienić, wspólne cele dla wszystkich uczestników powinny wspierać te zmiany. Współpraca jest kluczowa, ponieważ żadna osoba solo, ani Scrum Master, ani pojedynczy manager, ani członek zarządu nie osiągnie transformacyjnych celów bez wsparcia średniego i niższego szczebla managementu.

To, na co chcemy jeszcze zwrócić uwagę to bycie ostrożnym wobec komunikatów typu „Ta zmiana mnie nie dotyczy” lub „Nie dotyczy mnie w takim stopniu„. Ważne jest, aby wszyscy w organizacji mówili jednym językiem, grali do jednej bramki, rozumieli te same pojęcia i potrafili odróżnić stary sposób pracy od nowego. Prędzej czy później każda osoba będzie musiała przejść przez szkolenie tłumaczące podejście zwinne. To absolutne minimum, które stanowi zaczyn do dalszych rozważań.

Przez lata rosnąca popularność Scruma oraz rosnąca odpowiedzialność Scrum Mastera sprawiły, że pojęcie to stało się niejednoznaczne. Dla jednej osoby Scrum Master znaczy coś innego niż dla drugiej, a Scrum wygląda inaczej w każdej firmie. Ważne jest, aby nawet na poziomie zarządu, lider prowadzący zmianę lub najstarszy Scrum Master dobrze przepracowali w gronie managerskim, czym tak naprawdę jest rola Scrum Mastera. Należy jasno określić, które zadania kierować do Scrum Masterów, a których nie. Trzeba rozwiać mity, które narosły wokół tej roli, tak aby nie stosować antywzorców. Należy je korygować na jak najwcześniejszym etapie. 

W wielu branżach Scrum jest już na tyle popularny, że nie trzeba wyjaśniać roli Scrum Mastera od zera. Niestety, niektóre osoby mogły natrafić na źle zorganizowaną funkcję Scrum Mastera w swojej karierze. Ważne jest, aby w organizacji dobrze zdefiniować i wypracować zrozumienie roli Scrum Mastera, uwzględniając zarówno negatywne, jak i pozytywne doświadczenia z przeszłości.

Materiałem, który polecamy jako rozszerzenie tego punktu, jest odcinek o nazwie Budowanie autorytetu Scrum Mastera, który znajdziesz na stronie porzadnyagile.pl/82.

Kolejne rozwiązanie, które rekomendujemy zarządzającym transformacjami, aby wsparli Scrum Mastera, to praktykowanie zwinności na własnej skórze. W niektórych organizacjach zwinność jest stosowana tylko przez zespoły projektowe czy produktowe, natomiast na poziomie managerskim używa się klasycznych technik lub nie stosuje się żadnych. W sytuacjach, gdzie zarządzający są również Product Ownerami lub sponsorami dla najważniejszych inicjatyw w firmie, mogą oni praktykować zwinność osobiście.

Mogą tworzyć zespoły zadaniowe i stosować podejście zwinne, aby doświadczyć interakcji z zespołem zwinnym oraz rozwijać produkt zwinny. Nawet jeśli nie stosują zespołowych wymiarów zwinności, mogą korzystać z drobniejszych praktyk zwinnych, takich jak Kanban Board do zarządzania inicjatywami, projektami na poziomie całego portfela, czy nawet do osobistej efektywności, konkretnych działań, kroków czynności.

To nie tylko pomaga lepiej zrozumieć, czym jest zwinność, ale także pokazuje, że zmiana jest traktowana na poważnie i dotyczy całej organizacji. Ludzie zauważają, jeśli zmiana jest stosowana nie tylko na niższych szczeblach. Taka niespójność może podważyć zaufanie do całego procesu transformacji.

Scrum Masterzy, pracując zarówno na poziomie zespołu, jak i współpracując z Product Ownerem oraz na poziomie organizacji, mają cenne, przekrojowe obserwacje. Jako sponsor transformacji warto od czasu do czasu bezpośrednio dyskutować ze Scrum Masterami. Może to być w formie sesji warsztatowych z większą liczbą Scrum Masterów lub rozmów jeden na jeden. Dzięki temu usłyszysz ich perspektywę, obserwacje, wątpliwości i zagrożenia, które widzą z pierwszej ręki. Może to również być okazja do skorygowania pewnych działań, podtrzymania energii Scrum Masterów do pogłębiania zmian oraz zadeklarowania wsparcia tam, gdzie czują się bezsilni. 

To takie pominięcie poziomów, jako pewna praktyka managerska może spowodować w zasadzie obustronne korzyści zarówno dla Scrum Masterów, którzy dostają wyjątkowe wsparcie, nawet też nietypowe jak na realia danej organizacji, ale też pewien wygląd rzeczywistość, która być może wygląda trochę inaczej niż klasyczne ścieżki zarządzania, gdzie przez kolejne statusy, kolejne spotkania, kolejne jakieś pisane raporty ta rzeczywistość może wyglądać na przykład bardziej optymistycznie, niż widzą to osoby z poziomu zespołu.

Ta porada jest szczególnie ważna w organizacjach o wielu warstwach struktury organizacyjnej lub kulturze organizacyjnej, gdzie istnieje dystans do władzy lub rozdźwięk między szczeblami zarządzania a zespołami. Pominięcie poziomów jako praktyka managerska może przynieść obustronne korzyści. Scrum Masterzy otrzymają wyjątkowe wsparcie, a zarządzający zyskają rzeczywisty obraz sytuacji, który może wyglądać inaczej niż ten przedstawiany w raportach i statusach.

Ostatnia porada dla zarządzających transformacją, jak mogą wesprzeć Scrum Masterów, to regularnie sprawdzaj postęp zmiany. Zatrzymaj się, wykonaj świadomą stopklatkę i sprawdź, gdzie są postępy, gdzie transformacja utknęła, jak wyglądają mierniki, które ustaliliście, oraz realizacja celów, o których wspominaliśmy. Dzięki temu osoby napędzające zmianę i zaangażowane w nią będą miały wspólne zrozumienie i refleksje oraz wspólnie ustalone plany działania dotyczące kolejnych kroków. Unikniesz w ten sposób desynchronizacji działań i sytuacji, w której ktoś działa niezgodnie z potrzebami organizacji, a w najgorszym razie w przeciwnym kierunku. Regularne sprawdzanie postępów zmiany jest konieczne, aby dostosowywać kolejne działania do zmieniającego się środowiska.

Jeżeli potrzebujesz pomocy w kompleksowym spojrzeniu na zmiany w twojej organizacji, odezwij się do nas. Powoli szykujemy nasze kalendarze na jesień, które już teraz widzimy, że się dość mocno wypełniają. Chętnie wesprzemy twoją organizację i zespoły. Napisz do nas o swojej potrzebie na porzadnyagile.pl/kontakt, dobierzmy razem adekwatne rozwiązanie.

Jacek: Ostatnio obserwuję organizacje, w których mam poczucie, że na Scrum Masterów została zrzucona bardzo duża odpowiedzialność, jednocześnie bez zapewnienia odpowiedniego wsparcia. I ta myśl stała się dla mnie i dla Kuby pretekstem do nagrania tego odcinka.

Kuba: Żeby była jasność, na początek zastrzeżemy naszą intencję. Na pewno nie chcemy znęcać się nad Scrum Masterami, którzy mają zbyt dużą odpowiedzialność albo za słabe wsparcie. Nie dołączamy też do chóru hejterów Scruma albo głosów, że agile już się skończył. Natomiast chcemy zwrócić uwagę na to, że w wielu firmach istnieją nierealne oczekiwania co do roli i działań Scrum Masterów, których obiektywnie uważamy, że nie są w stanie spełnić, ponieważ Scrum Masterzy i cała idea zwinności w danej organizacji może nie być, a czasem nie jest wystarczająco wspierana.

Jacek:W spis treści dzisiejszego nagrania. Zdefiniujemy problem Scrum Masterów, od których oczekuje się niemożliwego. Następnie zaproponujemy kilka hipotez, dlaczego management może wymagać zbyt wiele od Scrum Masterów oraz na koniec podpowiemy, co zarządzający transformacjom mogą zrobić, by wesprzeć Scrum Masterów w skutecznym działaniu.

Kuba: Przechodząc do pierwszego rozdziału. Co mamy na myśli, gdy definiujemy problem Scrum Masterów, od których oczekuje się niemożliwego? Co się za tym kryje?

Jacek: Jest to sytuacja, w której obserwując Scrum Masterów, można mieć wrażenie, że odpowiadają oni za całą masę rzeczy, także takie, które wychodzą poza ich, nazwijmy to, podstawowy zakres obowiązków. Czyli spada na jej głowę odpowiedzialność za motywację zespołu, za jakość techniczną. Tego, co jest wytwarzane odpowiadają za pełną koordynację prac w zespole oraz pomiędzy zespołami. Odpowiadają za posiadanie kontroli nad postępami prac, odpowiadają za terminowość działań Zespołu Scrumowego, jak również za wdrażanie zwinności w zespole oraz w całej organizacji, a bardzo często jeszcze na to zakładają czapkę lidera w zespole. Uff, całkiem spora lista odpowiedzialności.

Kuba: Gdy mówimy, że Scrum Master nie ma wsparcia, mamy na myśli sytuację, w której Scrum Masterzy w danej organizacji nie dostają odpowiedniego wsparcia, poparcia, współdziałania od takich ról, przekrojowo patrząc jak top management organizacji, jak managerowie poszczególnych procesów. Na przykład te osoby odpowiedzialne za wdrożenia, osoby odpowiedzialne za jakość, czy osoby odpowiedzialne za jakiś konkretny krok czy narzędzie, nie dostają również wsparcia od liderów zespołów lub nie mają z nimi odpowiedniego współdziałania. Nie ma wsparcia, nie ma zrozumienia, nie ma współdziałania z osobami odpowiedzialnymi za szeroko rozumiany produkt. W niektórych firmach nazywają się takie osoby biznesem, w innych są to może Product Managerowie, Product Ownerzy. W każdym razie nie wszędzie ta współpraca wygląda dobrze, a to zawsze rodzi kłopoty. Czasami Scrum Masterzy nie dostają też wsparcia, o ironio, od osób, które nazywają się ludźmi od agile’a w firmie. Jeśli jest to rola oddzielona od Agile Coach’y, od jakiejś głowy agile’a, czy ludzi odpowiedzialnych za transformację, to też może się pojawić bardzo niebezpieczny rozdźwięk pomiędzy grupą Scrum Masterów a ludźmi nakręcającymi zwinność na poziomie całej organizacji. No i coś, co też jest niepokojące to brak wsparcia od szeroko rozumianego HR-u, gdzie też tych punktów styku może być wiele, ale i okazji do konfliktów trochę.

Jacek: No dobrze, to dlaczego naszym zdaniem management może wymagać zbyt wiele od Scrum Masterów? Z czego to może wynikać? Jaka jest to nasza lista hipotez?

Kuba: Pierwsza hipoteza jest dosyć prosta i chyba łatwa do przewidzenia. Zmiana prowadzona jest w sposób powierzchowny. Czyli w danej organizacji kopiowany jest pewien wzorzec postępowania, w tym przypadku będzie to cała seria wzorców związana z frameworkiem scrumowym. Firmy są wystarczająco świadome, że trzeba powołać stanowisko Scrum Mastera, ale na tym się ta świadomość kończy. Też takie odpowiednie wsparcie, te zmiany po prostu nie jest wystarczająco głębokie. No i niestety poza pojawieniem się zawodowych Scrum Masterów szereg kolejnych rzeczy, które powinny mieć miejsce, miejsca nie mają. No i nie ma to, kto tego skorygować.

Jacek:Druga hipoteza. Występuje przerysowana interpretacja odpowiedzialności Scrum Mastera. Firmy, które faktycznie potrzebują zmiany, mają nadzieję, że zwinność, a w szczególności Scrum, da dobry impuls do tego, żeby się zmieniać. Jednak błędnie zakładają, że całość odpowiedzialności leży w osobie Scrum Mastera. Czyli mówimy tutaj o sytuacji, kiedy przerysowana jest interpretacja, że tylko Scrum Master odpowiada za wdrażanie czy usprawniania Scruma i zwinności, patrząc szerzej w firmie.

Kuba: Trzecia hipoteza. Wysokie oczekiwania względem Scrum Masterów idą za kwestią nowych etatów i zarobków. Nie ukrywając tutaj zawód, Scrum Mastera wiąże się najczęściej z pojawieniem się nowych etatów organizacji lub gdzieś tam odpowiednim wymanewrowaniem reorganizacji, tak żeby te etaty się pojawiły. No i te etaty też są bardzo solidnie opłacane na tle przeciętnej organizacji, więc siłą rzeczy może się pojawić takie w pewnym sensie uprawnione oczekiwanie, no to skoro ci solidnie płacimy – zawodowi, doświadczeni Scrum Masterzy potrafią zarabiać zarobki menedżerskie, a na pewno powyżej specjalisty – no to wszystko może powodować jednak takie oczekiwanie, no to skoro już jesteś, to działaj, dawaj rezultaty, pokazuj efekty. Jesteś doświadczony, doświadczona, no i tak dalej i tak dalej. Czyli jeśli już management się zdecydował na ten krok, no to też buduje się pewna inflacja oczekiwań. Skoro już jesteś, to maksymalnie pokaż swoje korzyści czy korzyści ze swojego funkcjonowania w organizacji.

Jacek: Kolejna hipoteza brak zrozumienia, potrzeby wsparcia, zmian. Zwykle wynika to z tego, że management wprawdzie chce rezultatów zwinności, ale tak nie do końca ją rozumie i nie do końca też inwestuje w jej zrozumienie. No co w efekcie powoduje, że tak naprawdę nie rozumieją do końca potrzeby stojącej za zmianami i nie potrafią tych zmian wesprzeć.

Kuba: I ostatnia hipoteza, którą chcemy wymienić, choć pewnie jest ich więcej, to hipoteza, że priorytetem staje się praca operacyjna. W wielu organizacjach, z którymi mamy przyjemność współpracować, niestety część managerów, czasami włącznie do najwyższych zarządzających, swój priorytet mają w bieżącej działalności organizacji, w kolejnych projektach, kolejnych terminach, kolejnych końcach miesiąca, kwartału czy roku i trochę mniej uwagi poświęcają rzeczom strategicznym, długofalowym, ale również doskonaleniu procesów, sposobu funkcjonowania zespołów czy po prostu transformacji zwinnej, którą, jak już wiesz, z poprzednich naszych nagrań uważamy, że nie da się skończyć w parę miesięcy czy w parę kwartałów, bo jest to niekończący się proces. No i w takiej sytuacji, gdy cała organizacja jednak jest skupiona na tu i teraz, na takiej bieżącej, ważnej oczywiście pracy operacyjnej, Scrum Masterzy są osamotnieni, dlatego że po prostu nikt inny nie zwraca uwagi na dojrzałość zespołów czy wszystkich tych rzeczy, które już zdążyłem wymienić na początku tej wypowiedzi. Więc praca taka długofalowa staje się czymś, co nie jest powszechne w całej organizacji.

Jacek: I zanim zaczniemy ostatni rozdział, przypomnienie, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej, niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie: porzadnyagile.pl/sklep.

Kuba: Przechodząc do ostatniej części tego nagrania, co zarządzający transformacjom mogą zrobić, by wesprzeć Scrum Masterów? I tutaj w tytule rozdziału bardzo świadomie podkreślamy, do kogo kierujemy te porady. Jeśli jesteś liderem transformacji, sojusznikiem zmiany, sponsorem zmiany w swojej organizacji, to te punkty są dokładnie dla Ciebie. Jeśli jesteś obok takiej osoby, to może to jest lista porad lub podpowiedzi, co można by takiej osobie zasugerować. Może cały odcinek się nadaje też do zarekomendowania. Więc co mamy jako pierwsze rozwiązanie na naszej liście?

Jacek: Wypracuj potrzebę zmiany i jej nieuchronność. Jakiego modelu zmiany byśmy się nie chwycili, to ta potrzeba, dlaczego tak naprawdę powinniśmy w ogóle się zmieniać, w tych modelach występuje. No i jest niezwykle istotna, żeby ludzie faktycznie zrozumieli, dlaczego mielibyśmy robić nagle rzeczy inaczej, niż dotychczas robiliśmy. Ważne jest tutaj, żeby pomóc ludziom zrozumieć, że zmieniamy się na poważnie, że nie jest to jakiś kolejny wymysł, czy podążanie z jakimś trendem rynkowym, tylko faktycznie mamy, czy dyktowaną wewnętrznie, czy rynkiem zewnętrznym, potrzebę zmiany w organizacji. No i istotne jest, żeby wymagać, żeby osoby, które są zaangażowane w zmianę, znalazły faktycznie sposób na to, żeby ta zmiana się wydarzyła. Czyli przykładowo odpowiedź „Nie da się”, „Tak zawsze robiliśmy”, „Tego nie można zrobić w naszej branży” i tak dalej, no, to najprawdopodobniej są odpowiedzi, których nie chcielibyśmy słyszeć.

Kuba: I, dlaczego taka porada i to dlaczego w zasadzie od razu na pierwszym miejscu? Zbyt często spotykamy w organizacjach osoby, które wiedzą albo mają wyczucie, że w zasadzie to wystarczy wyczekać, przeczekać albo odpowiednio mocno zaargumentować, że nic się nie da zrobić, że tak zawsze działaliśmy i tak właśnie będzie. No i osoby, które tę zmianę chcą nakręcić, zwłaszcza takie, które są związane ze zmianą już jednak na takim poziomie oddolnym, też często bez władzy w organizacji, a tak postrzegamy często Scrum Masterów, no po prostu mają krucjatę i męki pańskie, jak muszą faktycznie porozmawiać z działem prawnym, który na przykład bardzo kiepsko reaguje na zmiany jakimiś osobami odpowiedzialnymi za compliance, za bezpieczeństwo w organizacji. I pewnie w każdej firmie jest ktoś taki, ja nie chcę tutaj ani stygmatyzować, ani też wskazywać kogoś takiego, ale w każdym razie dobrze byłoby, żeby cała organizacja ustawiła się, włącznie z osobami, które mają jakieś konkretne swoje obszary czy nisze, ustawiła w trybie, spróbujmy coś zrobić, żeby dopasować się do ducha zmiany, który jest powszechny i współdzielony przez wszystkich.

Kuba: Druga porada, to zaangażuj w zmianę osoby z obszarów firmy, które podlegają zmianie. To jest coś, co w zasadzie nadbudowuje na tej poprzedniej myśli, ale bardzo mocno chcemy zaakcentować to, że w niektórych organizacjach zmiana zbyt wąsko prowadzona i zbyt wąsko zdefiniowana jest już od samego początku. Więc na przykład transformacja zwinna dotyczy tylko wytwarzania oprogramowania, ewentualnie może z uwzględnieniem osób odpowiedzialnych za działania produktowe, ale już zespoły wspierające, zespoły odpowiedzialne za pewne procesy po prostu uważają, że są poza tą zmianą, albo wręcz wprost tak jest to zdefiniowane, że na razie transformacja, ale bez biznesu albo na razie transformacja, ale absolutnie jakieś zagadnienie nie jest do ruszenia.

Jacek: I to faktycznie może być sensownym pierwszym krokiem, jeżeli nie można inaczej, albo aktualna sytuacja na to nie pozwala, nie ma klimatu, natomiast docelowo warto zdawać sobie sprawę, do jakich konsekwencji takie podejście prowadzi. Będziemy mogli mówić na koniec dnia tylko o pewnych lokalnych optymalizacjach. I czasem taka lokalna optymalizacja może być już odczytywana jako jakiś tam mały sukces, ale bardzo często, gdy spojrzymy na szerszy obrazek, na to jak funkcjonują procesy w naszej organizacji, no to okazuje się, że ta drobna zmiana tak naprawdę nie ma większego znaczenia, no bo tak naprawdę jakieś wąskie gardła czy nieefektywności schowane są zupełnie gdzie indziej w tym długim procesie.

Jacek: Trzeci sposób, aby wesprzeć Scrum Masterów w pracy, jak również i zmianę to postawienie jasnych celi wspierających zmianę. Istotne jest, żeby cele te wypływały z potrzeby zmiany, o której przed chwilą z Kubą rozmawialiśmy i zostały kaskadowo przeniesione na adekwatne poziomy w strukturze organizacji. To może być sytuacja, w której wszyscy uczestniczący w zmianie mamy jakiś wysokopoziomowy cel, czyli na przykład skrócenie time to market, albo może to być kaskada celów zdefiniowanych na poszczególne obszary. Czyli na przykład z perspektywy działu zamówień, może to być oczekiwanie, że będziemy kontraktować się, uwzględniając realia pracy zwinnej. Patrząc z perspektywy działu wdrożeń, to może być skrócenie cyklu release’ów, a na przykład patrząc z perspektywy jakości, to może być oczekiwanie, że testy będą automatyzowane.

Kuba: I ta porada jest jakimś rodzajem odpowiedzi na wątek różnych priorytetów różnych części organizacji. Jeśli cele są rozbieżne, a konkretnie zamiast tych celów wspierających zmianę ktoś ma na przykład takie cele indywidualne, własne, niezwiązane z transformacją albo cele na przykład biznesowe, no to gdy przychodzi czas rozliczeń, no to niestety, ale te priorytety zwyciężają i transformacja nie będzie poważnie traktowana, nie będzie odpowiednio wsparta lub będzie robiona działaniami takimi minimalnymi możliwymi, żeby nie dostać żadnych zarzutów o może brak współpracy. Więc tutaj absolutnie w momencie, w którym cała organizacja chce się zmienić, potrzebuje się zmienić, i mamy to jasno zdefiniowane w sumie zgodnie z poprzednimi poradami, no to wsparciem tych zmian niech staną się wspólne cele dla wszystkich i też możliwość kontrybuowania do ich realizacji, bo to często akurat jest bardzo, bardzo połączone, że takich transformacyjnych celów żadna osoba solo nie osiągnie. Nie osiągnie ich Scrum Master, od czego zaczęliśmy ten odcinek, no ale również pojedynczy manager, członkowie zarządu bez wsparcia średniego i niższego szczebla managementu i po kolei mógłbym wszystkie te kombinacje wymieniać.

Kuba: Czwarta porada, to zadbaj o edukację wszystkich zaangażowanych w zmianę. Temat zwinności często wiąże się z nowymi nawykami, z nowymi umiejętnościami. Często transformacja jest wsparta jakąś akcją edukacyjną, natomiast w tym wątku jednak mocniej podkreślimy to, że po pierwsze te działania nie powinny wygasać albo być porzucone po pierwszym jakimś kroku, o tym wspominaliśmy w poprzednim materiale, ale również chcemy położyć nacisk na to, że zwłaszcza w gronie zarządzających zmianą czy całą organizacją, czy zarządzających odpowiednimi częściami firmy, czy procesów, trzeba dopasować materiały i może wejść poza standardowe szkolonko za podstaw zwinności i Scruma z perspektywy pojedynczego zespołu. I jednak dopasować materiały przez pryzmat, czy to zarządzających, czy osób zarządzających poszczególnymi zespołami, tak żeby tutaj każdy odnalazł się i zrozumiał swoją perspektywę, swoją rolę i dobrze doedukował się, co ta zmiana oznacza dla tej danej osoby.

Jacek: Tutaj warto być ostrożnym na komunikaty w stylu „No tak, ale mnie ta zmiana nie dotyczy” albo „Nie dotyczy mnie w takim stopniu”. Doświadczenie nasze mówi nam, że żeby zbudować poczucie grania do jednej bramki, żeby dobrze zrozumieć tak naprawdę jakie możliwości stwarza nam podejście zwinne, no to generalnie potrzebowalibyśmy, żeby ludzie w organizacji mówili jednym językiem. Pewne pojęcia rozumieli w ten sam sposób, potrafili odróżnić stary sposób pracy od nowego sposobu pracy. No i tak w praktyce okazuje się, że prędzej czy później tak naprawdę wszystkie osoby będą musiały co najmniej raz przejść przez jakieś szkolenie, które tłumaczy, czym jest podejście zwinne. No i ten raz to jest takie absolutne minimum, które daje tylko taki, można powiedzieć, zaczyn do dalszych rozważań.

Jacek: Kolejna wskazówka. Zrozum rolę Scrum Mastera i oczekiwania do tej odpowiedzialności. Przez lata rosnąca popularność Scruma, jak również rosnąca odpowiedzialność Scrum Mastera doprowadziła do tego, że no to pojęcie zostało można powiedzieć, w pewnym sensie wyświechtane. Czyli dla jednej osoby Scrum Master znaczy coś innego niż dla drugiej osoby, no a Scrum co firma to troszeczkę inna wersja. No i tak naprawdę istotne jest, żeby nawet na poziomie zarządu, albo co najmniej jakiś lider, który prowadzi zmianę albo jakiś najstarszy Scrum Master musi dobrze przepracować w gronie managerskim, czym tak naprawdę jest Scrum Master. Które zadania kierować do Scrum Masterów, których nie kierować? Za co odpowiada? Za co nie odpowiada? No i myślę, że tutaj w szczególności istotnym aspektem jest to, żeby rozwiać mity, które przez lata narosły w tej roli. Ktoś może dołączyć do organizacji z innej firmy, w której Scrum Master pełnił rolę bardziej taką sekretarza ogarniacza, no i próba przenoszenia tych antywzorców do innych organizacji, powinna być wyłapywana i korygowana na jak najwcześniejszym etapie.

Kuba: I trochę się powtórzę, ale swoimi słowami powiem to samo, co Jacek w końcówce tej wypowiedzi sprzed chwili. W wielu branżach Scrum jest już na tyle popularny, że raczej nie mówimy o tym, żeby wyjaśnić się rolę Scrum Mastera od zera. Niestety jest tak, że wybrane osoby mogły trafić swojej karierze dotychczasowej albo na źle zorganizowaną funkcję Scrum Mastera w całej organizacji, albo źle wypełnioną tą konkretną odpowiedzialność przez daną osobę i te skojarzenia niestety czasami powodują już złe takie dopowiedzenia czy założenia co do kolejnych sytuacji, gdzie Scrum i Scrum Mastery funkcjonują. Więc jeśli założeniem w tej organizacji jest Scrum, to moim zdaniem bardzo mocna przestroga jest z tym, żeby dobrze sobie zdefiniować, wypracować to zrozumienie roli Scrum Mastera i może nawet właśnie zderzyć się z tymi przemyśleniami na temat niedoskonałości Scrum Masterów z przeszłości, czy to z tej organizacji, z jakiejś jej poprzedniej inkarnacji i transformacji, czy z organizacji, w których ktoś funkcjonował. No i nie bądźmy tylko oczywiście negatywni. Prawdopodobnie też, tak twierdzę, spotkało się już też w odpowiedniej częstotliwości fajnych Scrum Masterów, więc może sobie zdefiniujmy, żeby nasi Scrum Masterzy byli tak fajni jak przykładowa Ania, Krzysiek czy Maciek z przeszłości, a nie jak osoby, które nam się negatywnie skojarzyły.

Jacek: Materiałem, który polecamy jako rozszerzenie tego punktu jest odcinek o nazwie Budowanie autorytetu Scrum Mastera, który znajdziesz na stronie porzadnyagile.pl/82

Kuba: Kolejne rozwiązanie, które rekomendujemy zarządzającym transformacjom, by wsparli Scrum Mastera, to coś trochę przewrotnego. Praktykuj zwinność na własnej skórze. I mamy tu na myśli taką sytuację, w której w niektórych organizacjach zwinność jest w czymś, w czym działają czy z czym działają zespoły. Jakieś projektowe, wytwórcze, jakkolwiek firma je nazywa, produktowe. Natomiast już na poziomie managerskim stosuje się klasyczne techniki, albo nie stosuje się ich żadnych. Myślę, że wszędzie tam, gdzie jest jakaś inicjatywa, czy to sytuacja, w której zarządzający są dla najważniejszych inicjatyw w całej firmie Product Ownerami, albo jakimiś sponsorami, czy sytuacja, w której trzeba okazjonalnie stworzyć jakiś zespół, może zadaniowy, może jakiś nietypowy, wyjątkowo tymczasowy zespół. Tam można zastosować podejście zwinne i akurat osoby najwyższego szczebla zarządzające mogą bardzo konkretnie popraktykować, jak to jest mieć interakcję z zespołem zwinnym, jak to jest rozwijać produkt zwinny, jak to jest też wejść na przykład w odpowiedzialność właśnie wspomnianego Procuct Ownera. Ale nawet gdyby nie stosować zespołowych wymiarów zwinności, to można też użyć o wiele konkretniejszych, drobniejszych praktyk zwinnych, jak na przykład chociażby Kanban Board, czy to inicjatyw usprawnieniowych, czy dotyczących się projektów na poziomie całego portfela, czy nawet po prostu Kanban Board do takiego poziomu osobistej efektywności, konkretnych działań, konkretnych kroków, czy konkretnych czynności, jakie się wykonuje.

Jacek: To co mówi Kuba nie tylko pomaga lepiej zrozumieć, czym jest zwinność na własnej skórze, ale jest też bardzo dobrym sposobem, żeby pokazać, że zmiana jest traktowana na poważnie i że dotyczy całej organizacji, a nie tylko, że ktoś tam sobie gdzieś wysoko w strukturze organizacji wymyślił, że będziemy pracować inaczej. Natomiast praca na tym poziomie przebiega właściwie bez zmian. Wbrew pozorom ludzie takie rzeczy widzą, wyłapują, no i wtedy zaczyna im się cała zmiana nie spinać.

Jacek: Przedostatnia porada, którą przygotowaliśmy brzmi komunikuj się bezpośrednio ze Scrum Masterami. Scrum Masterzy z racji tego, że pracują zarówno na poziomie zespołu, jak i na poziomie wspierania i współpracowania z Product Ownerem oraz na poziomie organizacji, potrafią mieć bardzo ciekawe, przekrojowe obserwacje. Jako sponsor transformacji warto zadbać o to, żeby od czasu do czasu mieć możliwość bezpośredniego podyskutowania ze Scrum Masterami, czy to w formule takiej sesji warsztatowych, gdzie tych Scrum Masterów będzie więcej, czy tak naprawdę gdzieś sobie porozmawiać jeden na jeden, po to, żeby usłyszeć ich optykę, ich obserwacje, ich wątpliwości, zagrożenia, które widzą z pierwszej ręki. Z drugiej strony może to być fajna też okazja do tego, żeby skorygować pewne działania, jeśli taka potrzeba się pojawi. Może też być to fajna okazja, żeby podtrzymać energię Scrum Masterów do pogłębiania zmian. No i dobrze by było też zadeklarować wsparcie, tam, gdzie Scrum Masterzy czują się bezsilni, no i jeśli ta deklaracja faktycznie wystąpi, no to zadbać, żeby rzeczywiście to wsparcie się pojawiło.

Kuba: Ta porada, dobrze, żeby szczególnie była świadomie wykorzystana w organizacjach, w których jest sporo warstw na poziomie struktury organizacyjnej, albo na poziomie kultury organizacji jest jednak pewien dystans. Czy to dystans do władzy jako takiej, czy może pewien rozdźwięk między szczeblami zarządzania a zespołami faktycznie wykonującymi pracę. To takie pominięcie poziomów, jako pewna praktyka managerska może spowodować w zasadzie obustronne korzyści zarówno dla Scrum Masterów, którzy dostają wyjątkowe wsparcie, nawet też nietypowe jak na realia danej organizacji, ale też pewien wygląd rzeczywistość, która być może wygląda trochę inaczej niż klasyczne ścieżki zarządzania, gdzie przez kolejne statusy, kolejne spotkania, kolejne jakieś pisane raporty ta rzeczywistość może wyglądać na przykład bardziej optymistycznie, niż widzą to osoby z poziomu zespołu.

Kuba: I ostatnia porada dla zarządzających transformacją, jak mogą wesprzeć Scrum Masterów, to regularnie sprawdzaj postęp zmiany. Mamy tu na myśli zatrzymanie się, wykonanie bardzo świadomej stopklatki i sprawdzenie, gdzie są postępy, gdzie transformacja utknęła, jak wyglądają mierniki, które sobie sformułowaliśmy, jak wygląda realizacja celów, o których też dzisiaj wspominaliśmy. Tak, żeby osoby, które napędzają zmianę, osoby które napędzają, osoby w tę zmianę zaangażowane miały wspólne zrozumienie. Wspólne też może refleksje i faktyczne plany działania wspólnie ustalone na temat tego, gdzie wykonane zostaną następne kroki. Żeby uniknąć właśnie jakiejś dysynchronizacji, żeby uniknąć też może takiego działania, w których realia się zaczynają powoli zmieniać, a ktoś nie dostał odpowiedniej informacji. Niestety działa w nie tym kierunku, co trzeba, a w najgorszym razie dosłownie w przeciwnym kierunku, niż trzeba.

Jacek: Ta myśl kojarzy mi się też z koncepcją, którą dzieliliśmy się też na ramach podcastu z Kubą o tym, że transformacja to pewna niekończąca się przygoda, więc trudno też oczekiwać, że zaplanujemy sobie pewne działania, rozdamy zadania i tak naprawdę będziemy oczekiwać na osiągnięcie tego wymarzonego stanu. Tak naprawdę w momencie, kiedy ten nowy stan będzie miał już nadejść, nasze oczekiwania mogą być już nieco inne. Na pewno w międzyczasie zmieni się rynek, na pewno konkurencja też nie próżnuje i też się zastanawia, jak pewne rzeczy robić lepiej. Więc ta regularność, jeśli chodzi o sprawdzanie postępów zmiany, jest konieczna m.in. po to, żeby dostosowywać kolejne działania do zmieniającego się środowiska.

Kuba: Ok, to podsumowując. Co zarządzający transformacją mogą zrobić, by wesprzeć Scrum Masterów? Wypracuj potrzebę zmiany i jej nieuchronność. Zaangażuj w zmianę osoby z obszarów firmy, które podlegają zmianie. Postaw cele wspierające zmianę i zadbaj o edukację wszystkich zaangażowanych w zmiany.

Jacek: Zrozum rolę Scrum Mastera i oczekiwania do tej roli. Praktykuj zwinność na własnej skórze. Komunikuj się bezpośrednio ze Scrum Masterami i regularnie sprawdzaj postęp zmiany.

Kuba: Jeżeli potrzebujesz pomocy w komplektowym spojrzeniu na zmiany w Twojej organizacji, odezwij się do nas. Powoli szykujemy się do zaplanowania naszych kalendarzy

na jesień, które już teraz widzimy, że się dość mocno wypełniają. Chętnie wesprzemy jednak Twoją organizację i zespoły, ale napisz do nas o swojej potrzebie na porzadnyagile.pl/kontakt i dobierzmy razem adekwatne rozwiązanie.

Jacek: Notatki do tego odcinka, artykuł, transkrypcję naszej rozmowy oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/kontakt.

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

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

Obserwujemy, że w niektórych firmach kompetencje zwinne rozwijane są tylko na początku transformacji zwinnej. Potem zwinność i kompetencje z nią związane powoli zanikają. Z czego to może wynikać? Poznaj dziewięć sposobów na to, żeby wzmacniać kompetencje zwinne w zespołach.

Bazując na naszych doświadczeniach, mamy dla ciebie kilka przykładów sytuacji, co się zadzieje, jeśli organizacja zaniecha rozwijania kompetencji w zespołach. 

Pierwszy z nich dotyczy szybkiego wzrostu liczebności zespołu, z kilku do kilkunastu osób bez uwzględnienia ich doświadczenia w procesie rekrutacji. W konsekwencji nowi pracownicy zdobyli swoje doświadczenie poprzez obserwację kolegów, wykorzystujących konkretne praktyki na co dzień. Finalnie nowym osobom zabrakło zrozumienia w zakresie stosowania praktyk i zasad zwinnych. Osoby te nie do końca rozumiały koncepcji ciągłego usprawniania się, czy codziennych spotkań zespołu. 

Spis treści

• Jakie są zagrożenia braku dalszej nauki w praktykach zwinnych?
• Przyczyny zatrzymania rozwoju kompetencji zwinnych 
• 9 sposobów wzmacniania kompetencji zwinnych w zespołach
• Transkrypcja podcastu „Wzmacnianie kompetencji zwinnych w zespołach„

Przechodząc do kolejnego przykładu, w jednej z firm zwinność została wprowadzona przez grupę pasjonatów. Udało im rozpocząć pracę w zespołach, przekonać management do wsparcia zmian, co w efekcie przyniosło pozytywne rezultaty. Z biegiem czasu większość osób, które zainicjowały praktyki zwinne, odeszły z organizacji. Ogień do zmian i rozwoju zgasł pod ich nieobecność, co doprowadziło do marginalizowania zwinności. 

Zespoły kontynuowały pracę w iteracjach, cyklicznych spotkaniach, ale bez zrozumienia ich pierwotnego celu. Brak tego zrozumienia, praktyki, które stały się rutyną, doprowadziły, do tego, że zespół przestał rozumieć, dlaczego wprowadzono pewne techniki i standardy. Mieli trudności z podejściem do naprawy tego, co zostało stworzone, a co było realizowane.

Następnym przypadkiem, było zwolnienie Scrum Masterów przez jedną z organizacji. Firma ta miała przeświadczenie, że wszystko, co było związane ze zwinnością, zostało już osiągnięte. Nic bardziej mylnego. Brak wsparcia Scrum Mastera spowodował, że zabrakło osoby, która dostrzeże, potrzebę rozwoju zespołu, procesu współpracy oraz dostarczania rozwiązań na rynek. 

Finalnie lider w zespole skupiał się na technologii, przez co zwinność przestała być priorytetem. Sama praca zespołów budowana na filarach zwinności zaczęła odbiegać od standardów rynkowych, a tym samym przestała wyglądać jak porządny Agile.

Ostatnia historia jest o organizacji, która znalazła się w fazie szybkiego rozwoju/rozrostu. Wdrożyła Scrum poprawnie, na poziomie zespołów uporządkowała chaos, panujący przed wdrożeniem Scruma. Niestety wraz z ogólnym wzrostem napotykała problemy m.in. z rozwojem produktu.

Firma zaczęła potrzebować większej skali, aktualnej wiedzy m.in. jak Scrum (dotychczas stosowany był na poziomie zespołów) stał się niewystarczający. W efekcie tego brak pomysłów na wdrożenie nowych narzędzi i technik spowodował stagnację.

Brak konkretnego pomysłu wynikał z dawnych doświadczeń, gdy uczono się Scruma. Narzędzie to było postrzegane jako sposób na organizację pracy zespołu. Słusznie. Jednak bardziej ambitne rzeczy na tamtym etapie, były też poza zasięgiem ich realizacji. W efekcie zabrakło im wyższego wtajemniczenia i zaawansowania stosowania praktyk zwinnych. 

Poniżej przedstawiamy, kilka głównych hipotez, dla których rozwój kompetencji zwinnych często zatrzymuje się, przestaje być wspierany i rozwijany. Zobacz, jakie mogą z tego wynikać konsekwencje.

Firmy często są w przeświadczeniu, że wystarczy tylko jedno szkolenie, które będzie wystarczające na lata. Niezależnie czy jest to Scrum, Kanban, czy  Domain-Driven Design.

Transformacja zwinna traktowana jest jako projekt z początkiem i końcem, a także ograniczonym budżetem. Po zakończeniu projektu brak jest dalszego wsparcia zespołu, inicjacji dalszego jego rozwoju oraz brakiem budżetu na działania z tego zakresu.

Kolejnym przykładem jest zniechęcenie do zwinności jako ogólnej koncepcji, która mogła okazać się zbyt trudna w praktycznym wykorzystaniu. Może również nie spełniać obietnic, które były z nią związane. W związku z tym jest przekonanie, że to, co mamy i używamy, jest na tyle istotne, że chcemy to zachować.

Konkretnym powodem, który może hamować dalszy rozwój, stanowi koszt szkoleń. Szczególnie jeśli rozwój oznacza większy program szkoleniowy, wymagający angażowania trenerów i odejmujący ludzi od codziennej, projektowej lub rozwojowej pracy. Takie rozbudowane programy edukacyjne mogą być nierealne do wykonania ze względu na wysoki koszt lub brak odpowiednio wysokiego budżetu w danej organizacji.

Organizacje obserwując aktualne trendy na rynku, przenoszą swoje budżety lub chęci rozwoju pracowników na inne obszary. Może więc dojść do sytuacji, w której szkolenia dotyczące zwinności będą konkurować z innymi szkoleniami, na przykład z zakresu sztucznej inteligencji.

Następną przyczyną zatrzymania rozwoju kompetencji to identyfikacja w firmie obszarów, które wymagają jeszcze większego doskonalenia niż te, związane z kompetencjami zwinnymi. Spotykamy się z różnymi sytuacjami w organizacjach, gdzie, choć zauważamy potrzebę poprawy kompetencji zwinnych, istnieją obszary, które wymagają pilniejszej uwagi z zakresu:

Jeśli zestawimy ww. obszary obok siebie, mogą okazać się one ważniejsze niż rozwijanie kompetencji zwinnych. W takich organizacjach niezbędne jest skupienie się na kompetencjach, które znajdują się w jeszcze gorszym stanie wymagającym natychmiastowej poprawy.

Nasza ostatnia hipoteza sugeruje, że w organizacji nie pracuje się systematycznie, nie rozwija kompetencji w ogóle, bądź w spójny konkretny sposób angażując całe zespoły. Brak jest konsekwentnego procesu rozwoju. Często decyzje dotyczące szkoleń podejmowane są na poziomie lidera lub szefa zespołu, brakuje jednak spójnego i kompleksowego podejścia.

Przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej, niż robimy to w podcaście, to znajdziesz nasze płatne sklepy na stronie porzadnyagile.pl/sklep

Rozwój kompetencji zwinnych wymaga ciągłego wsparcia i odpowiednich działań. Poniżej dajemy ci kilka konkretnych propozycji, które mogą pomóc w utrzymaniu i rozwijaniu zwinności w zespołach.  

Zadaj sobie pytanie, w jaki sposób obecny sposób pracy zespołów odpowiada na potrzeby twojej organizacji? Nie istnieją uniwersalne rozwiązania ani metody pracy, które zawsze działają dla każdego zespołu, jednak to, do czego cię zachęcamy to przyjrzenie się:

Dlaczego taki kierunek? Podczas naszych rozmów z managerami organizacji często pojawiają się stwierdzenia, że zespoły nie dostarczają szybko. Napotykają trudności w pracy nad strategicznymi projektami, zadania są trudniejsze niż poprzednie. 

Z drugiej strony, mimo posiadania zwinnych lub Scrumowych zespołów, zdarza się, że zespoły nie radzą sobie z mechanizmami zwinnymi. Co sugeruje, że kompetencje zwinne wymagają ulepszenia.

Warto zastanowić się nad potrzebami organizacji i sprawdzić, czy obecne zespoły, które masz, spełniają te oczekiwania. Jeśli nie, być może konieczne będzie głębsze przemyślenie sytuacji nie tylko na poziomie zespołu, ale i całej organizacji. 

To, co proponujemy dla ciebie w kolejnym punkcie to diagnoza wewnętrznego stanu wiedzy wraz z przygotowanymi do nich adekwatnymi rozwiązaniami. Jeśli widzimy, że potrzebą organizacji są lepiej funkcjonujące lub współpracujące zespoły na większą skalę, warto zastanowić się, jakie kompetencje obecnie posiadają te zespoły. 

Bardzo dokładnie należy ocenić jednakowo: 

Niezbędne w tym zakresie jest przeprowadzenie dokładnego i systematycznego przeglądu, oraz analitycznego podejścia do sprawy. Na tej podstawie wyciągniesz wnioski dotyczące potrzeb i braków, które należy uzupełnić konkretnymi rozwiązaniami.

Częstym rozwiązaniem, po które sięgają firmy, jest zaproszenie osoby z rynku, która ma świeże spojrzenie i doświadczenie z wieloma organizacjami. Potrafi zobaczyć, jak pracuje zespół. Zbiera i dostarcza rekomendacje, obejmujące m.in. szkolenia lub konkretne aspekty związane z rozwojem. Nie wszystko jednak można naprawić za pomocą jednej techniki czy zmiany na poziomie organizacyjnym. Proste rekomendacje, takie jak uzupełnienie wiedzy na temat zwinności w zespołach lub zapewnienie wsparcia dla Product Ownerów, mogą okazać się strzałem w dziesiątkę.

Jako realizatorzy rekomendacji, przeprowadzenia diagnozy mamy do ciebie apel, o to, żeby już na początku współpracy z ekspertem jasno ustalić zakres rekomendacji. Tak, aby były one szersze, niż te w ofercie. Dlaczego?

Diagnoza nie powinna być pretekstem do sprzedania kilku szkoleń z portfolio eksperta. Warto jasno określić zasady współpracy z ekspertem, aby diagnoza koncentrowała się na wskazaniu brakujących kompetencji i dostępnych opcji, a nie na sprzedaży szkoleń z oferty. Nie każdy ekspert zna się na wszystkim, dlatego warto być otwartym na różne możliwości.

Ta rekomendacja jest powiązana z poprzednimi punktami. Niektóre organizacje wybierają skróconą ścieżkę i od razu chcą wejść w daną tematykę/warsztat. Nie unikamy tego, sami również organizujemy takie warsztaty, ponieważ mogą one odświeżyć atmosferę, dodać nowej energii oraz inspiracji. Wynikiem tych działań jest refleksja nad tym, jak działają zespoły. Mogą one również pomóc zidentyfikować luki kompetencyjne oraz potrzeby dalszego rozwoju lub wsparcia dla managementu.

Niektóre organizacje łączą te warsztaty z integracją, co jest ciekawym sposobem na przerwanie rutyny. Inne firmy organizują je na koniec kwartału lub roku, kiedy jest spokojniejszy okres. Jak dokładnie to zostanie rozwiązane, zależy od specyfiki firmy. Ważne jest, aby od czasu do czasu wprowadzać do organizacji świeże powietrze i nową inspirację poprzez warsztaty lub prelekcje praktyka.

Na skutek rekomendacji możemy otrzymać bardzo konkretne i gotowe produkty, takie jak szkolenia, warsztaty czy programy. Tym bardziej że z biegiem czasu rynek zwinności ewoluował i coraz bardziej wymagane jest tworzenie rozwiązań dopasowanych do konkretnych organizacji.

Przykładowo, może już minęła fascynacja Scrumem i trzeba zastanowić się, co dalej. Niektóre firmy skierują się bardziej w stronę Kanbanu, inne zainspirują się konkretnymi frameworkami skalowania zwinności. Ważne jest, aby rozwiązania były rzeczywiście dopasowane do potrzeb zespołów. Oznacza to, że warto poszukać dostawców, którzy są gotowi zaproponować coś odpowiedniego dla twojej organizacji, a nie tylko wyciągnąć flagowe szkolenie czy program z katalogu.

Przyjmujemy założenie, że w organizacji istnieje kompetencja zwinna na akceptowalnym poziomie. Wiele organizacji nie wykorzystuje w pełni tego potencjału. Doświadczeni specjaliści od zwinności mogą mieć nieodpowiednio spożytkowany potencjał, co stwarza okazję do zorganizowania wewnętrznego programu wymiany wiedzy poprzez: 

Bardziej zaawansowanym rozwiązaniem są:

Takie wewnętrzne konferencje mogą być bardziej rozsądnym wydatkiem niż wysłanie pracowników na te zewnętrzne, które, choć ciekawe, nie zawsze są dopasowane do kontekstu organizacji tak dobrze, jak historie zespołów wewnątrz firmy.

To ile wiedzy faktycznie istnieje w organizacji, jeśli tylko stworzyć przestrzeń dla osób, aby się nią podzieliły, może cię zaskoczyć. Odpowiednia struktura, zebranie właściwych osób i nadanie wydarzeniu właściwego tonu mogą stworzyć środowisko sprzyjające wypływaniu wiedzy i pojawianiu się pomysłów, które rzeczywiście rozwiązują problemy w organizacji.

To kolejna porada bazująca na tym, co już faktycznie jest zbudowane w organizacji. Wiele firm zapewnia ciągłe odświeżanie wiedzy i inspirowanie poprzez wewnętrzne warsztaty lub szkolenia, które są prowadzone przez osoby z organizacji. 

Kluczowe jest zorganizowanie tego w sensowny sposób, aby stało się to systemowym elementem organizacji, a nie sporadycznym wydarzeniem. W tym kontekście warto zrobić dwie rzeczy:

Warto, aby eksperci byli dobrze przygotowani, zarówno pod kątem wiedzy zwinnej, jak i umiejętności szkoleniowych. Szczególnie w dużych organizacjach wsparcie dla wewnętrznych ekspertów jest nieuniknione i konieczne, aby zapewnić zaawansowany poziom szkoleń.

W tym punkcie w odróżnieniu od szkoleń proponujemy, aby doświadczeni specjaliści lub osoby z doświadczeniem w pracy zwinnej w różnych rolach wspierały rozwój mniej zaawansowanych pracowników. 

Nasze doświadczenia, zarówno z jednej, jak i z drugiej strony tego typu relacji, pokazują, że towarzystwo mentora gdzie możemy podzielić się swoimi przemyśleniami, wspólnie uczyć się daje znacznie więcej niż sala szkoleniowa. 

Ważne jest, aby osoby z doświadczeniem miały bodziec i czas na realizację takich działań. Kluczowe jest tu wsparcie managementu, który powinien dawać przykład i angażować się osobiście, aby koncept wzajemnego uczenia się i przekazywania wiedzy był rzeczywisty w całej organizacji.

Jeśli czujesz, że nie masz w organizacji wystarczająco doświadczonych osób, warto rozejrzeć się za zewnętrznymi ekspertami z rynku, którzy mogą wnieść takie doświadczenie do Twojej organizacji.

Co się kryje za tą wskazówką? Chcemy, zwrócić twoją uwagę na to, że czasami brakuje pretekstu do podniesienia kompetencji, do dopingowania się i zdyscyplinowania do stosowania pewnych praktyk. Ta rada skierowana jest głównie do managementu. 

Jeśli z wcześniejszych porad wynika, że diagnoza wskazuje na pewne braki, a inspiracje pokazują, że trzeba się odświeżyć, możesz to zrobić przy okazji nowych projektów, rozpoczęcia nowego kwartału czy zbudowania nowego zespołu.

Management inicjuje, sygnalizuje, wraca do pewnych praktyk i oczekuje pewnego sposobu działania od zespołów. To wsparcie może być kluczowe dla wprowadzenia wcześniejszych porad w życie. Nawet najlepsze szkolenia i dobrze przemyślane inicjatywy mogą być trudne do wdrożenia, jeśli nie będzie oczekiwania, że praca ma się zmieniać i usprawniać. Wsparcie managementu poprzez postawienie jasnych oczekiwań co do poprawy sposobu działania zespołów jest niezbędne.

 Jakie są twoje doświadczenia we wzmacnianiu kompetencji zwinnych w organizacji?  Podziel się swoimi przemyśleniami. Chętnie dowiemy się, z jakimi problemami spotykasz się na co dzień, a co już udało ci się z powyższej listy wdrożyć. 

Zachęcamy cię również do zapoznania się z materiałami, które stanowią uzupełnienie tego artykułu. Dowiesz się z nich:  

Zachęcamy Cię do pogłębienia tego tematu i zapoznania się z dodatkowymi materiałami:

Kuba: Obserwujemy w niektórych firmach niepokojące zjawisko, że kompetencje zwinne są rozwijane w zespołach wyłącznie na początku zwinnej transformacji. Cokolwiek to znaczy ten początek, ale najczęściej jest to jakiś dany etap, czy jakiś start zespołu zwinnego i firma zapewnia jakieś podstawowe szkolenie czy warsztaty ze zwinnych metod czy zwinnych praktyk. Ale potem to wsparcie zanika i też te praktyki czy kompetencje też w zespołach zanikają. Jest to o tyle ważna kwestia, że postanowiliśmy poświęcić na to zagadnienie cały odcinek.

Jacek: Spis treści dzisiejszego odcinka. Omówimy zagrożenia związane z brakiem dalszej nauki, praktyk zwinnych. Omówimy możliwe przyczyny zatrzymania się, wzmacniania kompetencji w organizacji oraz zaproponujemy sposoby dalszego wzmacniania kompetencji zwinnych w zespołach.

Kuba: Przechodząc do pierwszego rozdziału, jakie są zagrożenia braku dalszej nauki w praktykach zwinnych?

Jacek: Przedstawimy z Kubą kilka przykładów na bazie naszych doświadczeń sytuacji, które pokazują problem zaniechania rozwijania kompetencji w zespołach. Pracowałem już jakiś czas temu z zespołem, który dosyć szybko się rozrósł i z kilku osób stworzyła się taka naprawdę już spora grupa kilkunastu. Zespół sporo zatrudnił nowych ludzi z rynku no i była to grupa osób zarówno dosyć młodych stażowo, jak również często zaczynająca dopiero swoją pierwszą pracę. Więc wszystko, czego te osoby nauczyły się o zwinności, nauczyły się obserwując koleżanki, wykorzystujące pewne konkretne praktyki zwinne na co dzień. W pewnym momencie liderka tego zespołu zaobserwowała, że brakuje w szczególności tym nowo dołączonym osobom zrozumienia, po co tak naprawdę te praktyki i zasady stosujemy. Czyli przykładowo nie do końca rozumieli, jaka idea stoi za koncepcją ciągłego usprawniania się, czy nie do końca rozumieli, dlaczego codziennie spotykamy się rano z zespołem, żeby porozmawiać. 

Kuba: Inna historia, ta jest możliwe, że bardzo uniwersalna i wiele osób może było w takiej sytuacji. Zwinność w pewnej firmie została wprowadzona przez kilkoro pasjonatów, osób, które bardzo oddolnie i bardzo z wewnętrznej motywacji spróbowały coś zmienić się w firmie. Udało im się to, wystartowali pracę w zespołach, udało się też przekonać odpowiednie grono managementu, żeby pewne zmiany zostały wsparte również odgórnie. Natomiast czas płynie, większość tych pasjonatów z różnych przyczyn w tej organizacji już nie ma, tego pierwotnego ognia też już nie ma, a zasady, które te osoby dawno temu wprowadziły wiele lat, zwłaszcza pod ich nieobecność zaczęły się powolutku, nazwę to, zdegradować. Czyli jeszcze są ślady tych praktyk zwinnych, jeszcze są stosowane konkretne techniki. Zostały przede wszystkim rutyny, czyli praca w jakichś iteracjach, jakieś regularne cykliczne spotkania o znanych nam wszystkim nazwach, ale ludzie już nie pamiętają o co w nich chodziło. Ludzie już być może robią to też tak po prostu z przyzwyczajenia i ci obecni już tam czy to liderzy zespołów, czy członkowie samych zespołów przestali rozumieć, po co to wszystko było kiedyś wprowadzone i też jak ewentualnie naprawić to, co obecnie jest realizowane. 

Jacek: Kolejny przykład. Firma zwalnia Scrum Masterów, myśląc, że wszystko, co było do zrobienia w temacie zwinności jest już zrobione. No i tym samym nie ma już nikogo w organizacji, kto by dostrzegł, że zespół nadal potrzebuje rozwijać swój proces współpracy i dostarczania rozwiązań na rynek. Nawet jeśli występuje lider w tym zespole, skupia się on bardziej na technologii, no i z wielu różnych powodów ta praca zespołu, która początkowo była budowana na filarach zwinności, coraz mniej przestaje wyglądać jak porządny agile. 

Kuba: I ostatnia historia firma się rozrasta, Scrum był wprowadzony poprawnie, był wprowadzony też słusznie we właściwych miejscach. Na poziomie zespołów uporządkował pracę, uporządkował pewien chaos, który był w tej firmie, zanim Scrum został zastosowany. Natomiast firma się dalej rozwija, produkt się komplikuje, też firma wraz ze wzrostem rynku zaczyna potrzebować trochę większej skali i aktualna wiedza na temat tego jak stosowany jest na przykład Scrum, który był stosowany na poziomie zespołów nie wystarcza. I da się słyszeć hasło typu Scrum to za mało, agile to za mało, potrzebne są jakieś dodatkowe narzędzia. Tylko nikt nie ma pomysłu jak to zrobić i wynika to między innymi z tego, że jak gdy Scruma się uczono parę lat temu. No to był on postrzegany i wtedy słusznie jako raczej sposób na uporządkowanie pracy zespołu, no bo bardziej ambitne rzeczy były po prostu na tamtym etapie poza zasięgiem możliwości realizacji. A dzisiaj jest potrzebne wyższe wtajemniczenie czy potrzebne są wyższe poziomy zaawansowania stosowania praktyk z winnych.

Jacek: Wyobrażam sobie, że wybrana bądź wybrana historia mogę z tobą słuchaczko lub słuchaczko rezonować. Uogólniając, spotykamy się z Kubą ze zjawiskiem, że wszelkiego rodzaju rozwój często w postaci szkoleń, warsztatów czy jakiejś takiej pracy wsparciowej nad zwinnością w zespole, ale też w organizacji odbywa się na jakimś umówionym początku. I uważamy, że jest to spore ryzyko, które może przełożyć się na to jakie rezultaty biznesowe ostatecznie dostarcza firma no i generalnie może prowadzić do wielu negatywnych zjawisk.

Kuba: Ok, to przechodząc do drugiego rozdziału chcielibyśmy podzielić się kilkoma hipotezami z czego może wynikać takie zjawisko zaprzestania dalszego wsparcia czy dalszego rozwoju kompetencji zwinnych w zespołach. 

Jacek: Pierwsza hipoteza. Panuje przekonanie, że uczymy się tylko raz. Czyli przykładowo, jeżeli wprowadzamy jakąś metodę pracy do organizacji wystarczy nam jedno szkolenie, czy to ze Scruma, czy to z Kanbanu, czy to z Domain-Driven Design cokolwiek, jakakolwiek jest to wiedza, którą dociągamy sobie jako organizacja, no to mamy poczucie, że wystarczy, że jedno takie szkolenie zrobimy no i ono generalnie powinno nam na, w sumie można powiedzieć, najbliższe lata wystarczyć.

Kuba: Inna hipoteza też taka dosyć prawdopodobna, którą czasami słyszymy jako wyjaśnienie to to, że transformacja zwinna jest zakończona, bo była projektem i miała swój początek, koniec i budżet, który się też skończył. No i teraz już ewentualne dalsze wsparcie zespołu, zwłaszcza związane z jakimiś większymi wydatkami, po prostu nie jest możliwe do przeprowadzenia, tak bym powiedział proceduralnie. No nie ma pod co podpiąć, nie ma budżetu, nie ma inicjatywy, nie ma żadnego powodu, do którego pewne rzeczy mogłyby się wydarzyć. Coś, co uzasadniało pierwsze szkolenia, niestety się wyczerpało i nie można już dalej tego w żaden sposób zorganizować. 

Jacek: Kolejny potencjalny powód to zniechęcenie do zwinności generalnie, która to mogła okazać zbyt trudna w takim faktycznym, praktycznym wykorzystaniu, no i być może też nie spełniła obietnic, które za tą koncepcją stały. Stąd nie rodzi się w głowach poczucie, że to co mamy, to co wykorzystujemy jest na tyle istotne, że chcemy to co najmniej utrzymać na pewnie w idealnym świecie ulepszyć. 

Kuba: Konkretny powód, dla którego dalszy rozwój może nie mieć miejsca to też koszt szkoleń. Zwłaszcza jeśli rozwój jest rozumiany jako konkretny, jakiś większy program szkoleniowy z zatrudnieniem trenera, z również odciągnięciem ludzi od pracy takiej codziennej, projektowej czy rozwojowej. No i faktycznie, zwłaszcza takie rozbudowane programy edukacyjne mogą po prostu nie być do wykonania z racji na ich wysoki koszt lub brak odpowiednio wysokiego budżetu w danej organizacji.

Jacek: Kolejnym powodem może być to, że firmy rozglądają się na rynku za aktualnymi trendami i przenoszą swoje budżety czy chęci, żeby ludzie się rozwijali po prostu na inne obszary. Czyli przykładowo możemy się zderzyć z sytuacją, w której szkolenia zwinne będą konkurować ze szkoleniami na przykład dotyczącymi szkoleniami dotyczącymi tematu sztucznej inteligencji. 

Kuba: Podobna kwestia to to, że być może w firmie albo w konkretnym zespole są obszary, które należy doskonalić jeszcze bardziej niż zgłaszane przez nas zagrożenie związane z kompetencjami zwinnymi. No i tutaj może być naprawdę różnie, ale faktycznie spotykamy w organizacjach, w których co prawda my zwracamy uwagę, że z kompetencjami zwinnymi jest coś do poprawy, ale faktycznie na przykład obszar feedbacku albo obszary umiejętności twardych programistów albo temat związany z technikami sprzedaży czy takie już może bardziej międzyludzkie rzeczy jak na przykład wzmacnianie mocnych stron u pracowników. To są wszystko rzeczy, które faktycznie jak gdyby je zestawić obok siebie wygrywają z potrzebą wzmacniania kompetencji zwinnych. Czyli w organizacjach, w których trzeba się skupić, do czego zazwyczaj zachęcamy jednak jest decyzja o tym, że trzeba skupić się na innych kompetencjach, które są w jeszcze gorszym stanie i wymagają jeszcze pilniejszego poprawienia.

Jacek: Ostatnia nasza hipoteza, nikt nie pracuje nad kompetencjami albo nie pracuje nad tymi kompetencjami w jakiś tam spójny, konkretny sposób angażując całe zespoły. Czyli to czy jest jakieś szkolenie czy nie, to bardzo często może być jakaś decyzja na poziomie lidera czy szefa zespołu. Natomiast brakuje spójnego kompleksowego systemowego podejścia do edukacji.

Kuba: To skończyło nasze hipotezy, ale oczywiście zapewne jest ich więcej. Warto sobie zadać pytanie, jeśli to co do tej pory powiedzieliśmy trafia w jakiś sposób do sytuacji twojej organizacji, sprawdź, zastanów się z czego może wynikać to, na co chcemy zwrócić uwagę w tym odcinku.

Kuba: I zanim zaczniemy następny rozdział, przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne sklepy na stronie porzadnyagile.pl/sklep

Kuba: To ostatnia chyba najważniejsza część tego odcinka. Co można z tym zrobić? Przedstawimy 9 rozwiązań do rozważenia, być może w Twojej organizacji adekwatnych będzie tylko kilka z nich, ale chcemy przedstawić taki rodzaj menu, opcji, które przychodzą nam do głowy w temacie dalszego, ciągłego rozwijania kompetencji zwinnych w zespołach.

Jacek: Pierwsza rekomendacja. Zastanów się, jak obecny sposób działania zespołów odpowiada na potrzeby organizacji. Nie ma uniwersalnych rozwiązań, nie ma metod pracy, które zawsze działają i dla każdego zespołu, więc warto się rozejrzeć i rozeznać w tym, gdzie są mocne strony tego, jak pracują zespoły, a gdzie są wyraźne obszary do poprawy. Warto przyjrzeć się temu, jak obecnie pracują zespoły nad tym, żeby w konkretnych tematach się rozwijać, oczywiście zakładając, że faktycznie taki rozwój występuje, a jeśli nie, to warto zadbać o to, żeby taka refleksja w ramach zespołu, czy może nawet szerzej w ramach organizacji pojawiła się.

Kuba: Dlaczego takie rozwiązanie? Ono jest przyznam dosyć generyczne i takie ogólne, natomiast jak rozmawiam z managerami organizacji, to w zasadzie w sąsiednich zdaniach potrafią paść następujące stwierdzenia. Z jednej strony nasze zespoły nie dostarczają tak szybko jak potrzeba, albo mierzymy się teraz ze strategicznymi projektami, które są trochę trudniejsze niż te, które robiliśmy w przeszłości, i tutaj zespoły nie współpracują tak jak trzeba. I to są takie jakby potrzeby organizacji, jednocześnie wyzwania, przed którymi stoją zespoły. No i w drugim sąsiednim zdaniu może być coś w stylu: „Nie no, agile’a  już mamy”, albo „No, wszystkie zespoły są scrumowe”. Mnie się to nie łączy w całość. To znaczy, jeśli są zwinne zespoły, jeśli są zespoły scrumowe, no to one powinny sobie z tymi mechanizmami zwinnymi już radzić z tymi wyzwaniami. Jeśli jednak sobie nie radzą, to możliwe, że właśnie te kompetencje w tych zespołach związane ze zwinną pracą, współpracą, zwłaszcza z tymi trudniejszymi aspektami jak praca w kilka zespołów, praca nad jakimiś takimi większymi przedsięwzięciami być może daleko wykraczającymi poza oprogramowanie, no to by sygnalizowało, że te kompetencje zwinne, kompetencje współpracy, wytwarzania, dostarczania wartości małymi krokami, że to wszystko jest do poprawy. Stąd warto się zastanowić i zacząć od tego, jakie są potrzeby organizacji i czy zespoły, które masz, odpowiadają na te potrzeby. Jeśli nie, no to być może trzeba to przemyśleć mocniej. 

Kuba: I przechodzi to bardzo płynnie do drugiej naszej porady. Zdiagnozuj wewnętrzny stan wiedzy no i przygotuj adekwatne rozwiązania. Jeśli widzimy, że potrzebą organizacji są lepiej funkcjonujące zespoły albo lepiej współpracujące zespoły w większej skali, to warto zastanowić się, jakie dzisiaj kompetencje w zespołach są. Zarówno od strony profesjonalistów, jak i też może tak pomiędzy, jak zespoły są doświadczone, jak sobie radzą z takimi rzeczami, jakie praktyki stosują. No i trzeba tu naprawdę zrobić porządny rachunek sumienia, prawdopodobnie bardzo systematycznie i bardzo tak analitycznie do sprawy podejść i na tej bazie wyciągnąć wnioski na temat tego, co jest potrzebne i jakie rozwiązania, jakie luki są do zagospodarowania, jakie rozwiązania te luki uzupełnią.

Jacek: I często z Kubą rekomendujemy w procesie obsługi zapytania od firm. Na zasadzie odzywają się do nas organizacje z pytaniem, czy jesteśmy w stanie na przykład dostarczyć jakieś warsztaty czy szkolenie związane ze zwinnością. Rekomendujemy, żeby najpierw zbadać faktyczne potrzeby osób, które znajdują się w zespole, bo to nam bardzo dużo powie na temat tego, gdzie faktycznie są te luki. Może być tak, że firma, która patrząc na nią z boku, możemy mieć poczucie, że oni są już bardzo zaawansowani w podejściu zwinnym. Po przeprowadzeniu ankiety okazuje się, że tak naprawdę ludzie mają problemy z rzeczami, które nazwalibyśmy tematami bardzo podstawowymi. Nie mając tej wiedzy, nie badając tego, co tak naprawdę ludzie potrzebują i co jest dla nich wyzwaniem możemy trafić być może z jakimś tam rozwiązaniem, szkoleniem czy jakimś programem mentoringowym, ale to nigdy nie będzie tak dobrze dopasowane jak w sytuacji, kiedy oprzemy się na konkretnych badaniach.

Jacek: Trzecia porada. Poproś eksperta zewnętrznego o rekomendacje zmian w procesach. Częstym rozwiązaniem, po które sięgają firmy, jest zaproszenie kogoś z rynku, ktoś, kto ma świeże spojrzenie, ktoś, kto widział wiele organizacji, wiele miejsc pracy, po to, żeby spojrzał świeżym okiem na to, jak pracuje konkretny zespół. Zwykle tego typu wsparcie kończy się zestawem konkretnych rekomendacji, obserwacji, które taka osoba, patrząc z boku, jest w stanie zebrać. I wśród konkretnych rekomendacji mogą być rekomendacje dotyczące czy szkoleń, czy jakichś konkretnych aspektów związanych z rozwojem. Nie wszystko da się naprawić rekomendując konkretną technikę, nie wszystko da się naprawić rekomendując jakąś zmianę na poziomie organizacyjnym. Czasem po prostu, można powiedzieć, tak banalna rekomendacja, jak uzupełnicie wiedzę na temat zwinności w zespołach albo zapewnicie wsparcie dla Product Ownerów mogą się okazać konieczne i są tak naprawdę strzałem w dziesiątkę.

Kuba: Natomiast jako osoba, która realizuje takie rekomendacje i przeprowadza takie diagnozy, na pewno zaapelowałbym o to, żeby się od razu na początku zakontraktować z takim ekspertem, żeby te rekomendacje były szersze niż tylko to, co ten ekspert ma w ofercie. Czyli niech to nie będzie tak, że diagnoza jest sposobem na sprzedanie paru szkoleń z portfela szkoleń tego trenera. Wielu ekspertów, wielu doradców, jakich znam, tak naprawdę nie ma żadnego problemu z tym, żeby zarekomendować fajne warsztaty czy wartościowe szkolenia z tak zwanej konkurencji. Sami też to regularnie robimy, zwłaszcza że na przykład nie realizujemy szkoleń certyfikowanych, a niektórzy potrzebują certyfikacji. Więc tutaj warto ten temat jasno i klarownie postawić we współpracy z ekspertem. Czyli wyjść z diagnozy, ale też być otwartym na to, żeby ten ekspert raczej pokazał jakie kompetencje są do uzupełnienia, jakie są opcje, a nie jakie szkolenia później razem zrobimy, bo to nie zawsze będzie najlepsze dopasowanie. Nie każdy ekspert zna się na wszystkim, a zwłaszcza na wszystkich możliwych warsztatach i szkoleniach.

Kuba: Czwarta porada. Zorganizuj inspiracyjne warsztaty. Tutaj może jest to do połączenia z poprzednimi punktami. W niektórych organizacjach chce się zrobić ścieżkę na skróty i od razu wskoczyć ten temat. Nie stronimy, od tego. Sami też od czasu do czasu coś takiego robimy i wydaje mi się, że może mieć to sens, żeby tak odświeżyć trochę powietrze. Być może dać nowy zastrzyk energii, gdzieś wprowadzić do organizacji nową inspirację poprzez fajne inspirujące warsztaty, może jakąś prezentację z jakimś case’em, czy po prostu warsztaty, z których wyniknie refleksja na temat tego, jak działają zespoły. Gdzie są ewentualne luki kompetencyjne i też potrzeby, by kontynuować czy to działania rozwojowe, czy to już działania związane z odpowiednim wsparciem managementu. Niektóre organizacje łączą to np. z integracją, co też jest ciekawym sposobem na takie odrywanie się od pewnej rutyny. Inne firmy znajdują pretekst, żeby np. połączyć to z końcem kwartału albo końcem roku, poszukać jakiś takich momentów, gdy jest trochę spokojniej w danej organizacji, w danej branży. Jak to zostanie dokładnie rozwiązane, już nie nasza sprawa. Natomiast zastanowiłbym się nad tym, żeby od czasu do czasu takie świeże powietrze, zastrzyk nowej inspiracji wprowadzić poprzez warsztaty lub prelekcje praktyka.

Jacek: Kolejna porada. Dopasuj program rozwoju do potrzeb Twoich zespołów. Trochę to nawiązuje do tego, co Kuba powiedział wcześniej, że na skutek rekomendacji możemy dostać bardzo konkretne i gotowe produkty, na zasadzie takie konkretne szkolenia, albo taki konkretny warsztat, albo taki konkretny program. No tutaj zdecydowanie im dłużej jest zwinność funkcjonuje na rynku, tym moim zdaniem bardziej rodzi się rynek na to, żeby jednak tworzyć rozwiązania, które są dopasowane do konkretnych organizacji. Te zwykle są już po jakichś przejściach. Czyli przykładowo być może minęła już fascynacja Scrumem i trzeba byłoby się zastanowić, co zrobić dalej. Być może jakieś firmy skręcają bardziej w stronę Kanbanu, inne firmy inspirują się jakimiś konkretnymi frameworkami skalowania zwinności. W tym wszystkim warto zadbać o to, żeby te rozwiązania, które chcemy podsuwać do zespołów, faktycznie trafiały w potrzeby, co oznacza, że należałoby poszukać takich dostawców, którzy faktycznie będą gotowi zaproponować nam coś dopasowanego do potrzeb, a nie tylko wyciągnąć jakieś tam flagowe szkolenie czy flagowy program z katalogu.

Kuba: I tutaj znowu trochę szczerości z naszej strony, jako oczywiście osoby, które realizują tego typu rzeczy. Zapewne trenerzy czy tutaj osoby organizujące i prowadzące warsztaty mają interes w tym, żeby w miarę możliwości powtarzać te same schematy, robić te same ćwiczenia, nie budować nic indywidualnie pod danego klienta. No, ale to klient płaci, to klient wymaga i tutaj jak najbardziej warto włożyć tę dodatkową energię, bo oprócz wymiarów, które wymienił Jacek, to też spotykamy bardzo dużą istotność tego, żeby dopasować materiały pod branżę, żeby dopasować też może poruszane wątki do specyfiki konkretnych zespołów. No i tutaj ta różnorodność może być gigantyczna. Realia pracy z klientem i dostawcą, branże regulowane, branże, w których software nie jest najistotniejszym problemem, tylko np. wprowadzenie tego na rynek. Chociażby te wymiary już powodują, że te materiały takie bardzo uniwersalne albo takie, które się sprawdzają zazwyczaj, mogą się zupełnie nie sprawdzić w Twoich realiach. Więc tutaj zdecydowanie warto poświęcić tą energię i czas, warto też tego oczekiwać ze strony partnerów współpracujących czy to jako właśnie eksperci czy trenerzy, żeby ten program był dopasowany do potrzeby zespołów, a może nawet do pojedynczego zespołu, jeśli wewnątrz jednej organizacji ta różnorodność jest spora.

Kuba: Wymieniliśmy rozwiązania takie zewnętrzne. Dla równowagi skontrujemy taką kolejną poradą. Uruchom wewnętrzny program wymiany wiedzy. Przyjmuję w tej poradzie założenie, że wewnątrz organizacji jest kompetencja zwinna i ona nadal jest na jakimś minimalnym, akceptowalnym poziomie. Wiele organizacji trochę nie wykorzystuje tego potencjału. Fajniejsze zespoły albo bardziej doświadczeni, specjaliści od zwinności gdzieś może są już zagubieni, niekoniecznie odpowiednio, nazwę to brzydko, wykorzystani, więc jest okazja do tego, żeby bazować na tych specjalistach, zorganizować pewien program, dać im czas na to, żeby realizowali takie rzeczy i organizować na przykład wzajemne wizyty międzyzespołowe czy zapraszać na jakieś programy wymiany wiedzy zespół do zespołu, ale też również organizować jakieś szkolenia, jakieś pogadanki, jakieś może takie wewnętrzne gildie, gdzie jakieś tematy wychodzą, które są trudne i które wzajemnie zespołem mogą sobie pomagać. No, ekstremalną wersją tego i też bardzo ciekawą, to są jakieś rodzaje wewnętrznych konferencji czy wewnętrznych spotkań w wymiany wiedzy, gdzie odpowiednio dużej firmie znajdzie się parę zespołów, które mają ochotę podsumować jakiś ostatni etap, opowiedzieć o eksperymencie procesowym, o wykorzystaniu jakiegoś narzędzia czy o sposobie poradzenia sobie z jakąś trudną sytuacją. To mogą być bardzo inspirujące rzeczy i porównywalnie takie wewnętrzne konferencje w odpowiedniej skali mogą czasami być o wiele bardziej adekwatnym i rozsądnym wydatkiem niż wysłanie pół firmy na jakąś taką generyczną konferencję, na której są fajne wystąpienia, ale nie aż tak dopasowane do kontekstu, jak historia kilku zespołów z sąsiedztwa.

Jacek: No i tutaj generalnie można się całkiem mocno zaskoczyć, ile tej wiedzy faktycznie jest w organizacji. Jeśli tylko stworzyć przestrzeń dla osób, żeby ją w tych wszystkich formach, które Kuba wymienił, żeby tę wiedzę przekazały. To naprawdę, jeśli się połączy tą mądrość grupową, to okazuje się, że tak naprawdę i wiemy jakie są problemy i co do zasady znamy rozwiązania. I sam wielokrotnie doświadczałem takich momentów, kiedy konkretne zespoły czy nawet grupy zespołów dochodziły do naprawdę imponujących wniosków, ku zdziwieniu liderów czy managerów na zasadzie, jak do tego doszło. Moja odpowiedź na to jest taka, że odpowiednia struktura, zebranie właściwych osób, nadanie wydarzeniu odpowiedniego tonu powoduje, że po prostu robi się właściwe środowisko do tego, żeby ta wiedza wypłynęła i żeby pojawiły się pomysły, które faktycznie rozwiązują problemy w organizacji.

Jacek: Kolejna porada. Aktywuj istniejących w firmie ekspertów do prowadzenia warsztatów. Jest to kolejna porada bazująca na tym, co już faktycznie mamy zbudowane w organizacji. Bardzo często spotykam firmy, które zapewniają sobie ciągłe odświeżanie wiedzy i inspirowanie poprzez mniej lub bardziej zorganizowane formy, czy to warsztatowe, czy to szkoleniowe, które są prowadzone przez osoby z wewnątrz organizacji. Bardzo często osobami prowadzącymi stają się osoby, które są w roli Scrum Mastera, czy w roli Product Ownera, jeżeli tematy dotyczą bardziej tematów związanych z produktem, lub po prostu są to pasjonaci z winności, deweloperzy, testerzy. Tak naprawdę tutaj ta rola jest drugorzędna. Bardzo podobnie jak w poprzednim punkcie. Zwykle te osoby już mamy w organizacji. Bardzo często te osoby mają już spory autorytet zbudowany. No i tak naprawdę jedyne co trzeba zrobić, to zorganizować to w jakiś sensowny sposób, żeby to nie działo się od wielkiego dzwona, tylko żeby faktycznie było to coś, co jest systemowo zapewnione w organizacji.

Kuba: Powiedziałaś, jedyne co trzeba zrobić. Ja myślę, że dorzucę jeszcze z dwie rzeczy, które warto zrobić w takiej sytuacji. Ci pasjonaci zwinności, czy eksperci wewnętrzni, jakich mamy mogą być dobrzy ze strony zwinności, ale niekoniecznie najlepsi w temacie szkoleń. Więc tutaj być może warto dla równowagi takie osoby trochę wzmocnić od strony struktury warsztatowej, prowadzenia, sesji i tego typu rzeczy. Czyli taki aparat narzędziowy dobrego szkoleniowca. A z drugiej strony jest jeszcze zagrożenie, że osoby, które się zgłoszą do tego typu inicjatyw szkoleniowych, mogą jednak mieć pewne luki związane z wiedzą na temat zwinności. I wtedy jest trochę zagrożenie, że np. ktoś ma pewne błędne zrozumienie, np. Scruma. Niestety uczy kolejne osoby tego błędnego zrozumienia i jak przewiniemy taśmę parę odcinków albo parę sezonów w przód, no to się może okazać, że w firmie zaczyna się jakieś ugruntowywane odchylenie od powiedzmy obowiązujących praktyk. Nawet nie o to mi chodzi, że ktoś tam grzeszy przeciwko świętemu Scrumowi, ale jednak może jest tak, że pewne rzeczy są niepotrzebnie utrwalane, które mogłyby być robione inaczej. Więc eksperci, tak, mocno to rekomendujemy. Zwłaszcza do takich masowych rzeczy, w dużych organizacjach to chyba jest nieuniknione, wtedy takich ekspertów trzeba wesprzeć od strony takiego już naprawdę zaawansowania i umiejętności szkoleń.

Kuba: Przedostatnia porada, stwórz program mentoringowy. Tu w odróżnieniu od szkoleń chodzi nam o to, żeby również ludzi łączyć się w pewne grupy. Być może tych doświadczonych specjalistów czy osoby z doświadczeniami w pracy zwinnej w dowolnej roli w organizacji wspierały w rozwoju osoby mniej zaawansowane. Nasze doświadczenia, chyba po każdej ze stron z tego typu relacji pokazują, że naprawdę dużo więcej się można nauczyć niż na sali szkoleniowej, gdy ktoś nam towarzyszy, gdy z kimś możemy poodbijać myśli, gdy też wspieramy się wzajemnie w takim wspólnym uczeniu się. Bo może to nie tylko program mentoringowy, ale też takie pary wspólnego uczenia się. Tutaj to może mieć się różne odpowiednio dopasowane ramy, ale ważne, żeby tutaj osoby z doświadczeniem dostały bodziec do pracy w tym stylu i żeby dostały też czas na to, żeby takie działania realizować. No i żeby management wspierał tego typu inicjatywy, być może również samemu, samodzielnie dawał przykłady, angażował się osobiście w tego typu działania, tak żeby w całej organizacji ten taki koncept uczenia się wzajemnie, budowania i przekazywania tej wiedzy był prawdziwy.

Jacek: I dwa komentarze do tego, co Kuba przed chwilą powiedział. Pierwszy jest taki, że taki mentoring może być rozwiązaniem, które jest bardziej dopasowane do faktycznych wyzwań, z którymi mierzą się konkretne osoby i te wskazówki, które dostaniemy w ramach programu mentoringowego mogą i pewnie będą zwykle bardziej dopasowane niż to, co moglibyśmy dostać w formie jakiegoś wcześniej przygotowanego szkolenia. Natomiast druga myśl jest taka, że jeżeli czujesz, że nie masz osób doświadczonych w organizacji,  no to warto tutaj rozejrzeć się za zewnętrznymi ekspertami z rynku, którzy to mogą takie doświadczenie wnieść do Twojej organizacji.

Jacek: I ostatnia myśl. Odśwież oczekiwania co do pracy zwinnej przy okazji nowych inicjatyw. Co się kryje za tą wskazówką Kuba?

Kuba: To jest ostatnia też dosyć generyczna myśl o tym, że czasami brakuje pewnego pretekstu do tego, żeby może podnieść kompetencję, żeby też może trochę z powrotem się dopingować czy zdyscyplinować do stosowania pewnych praktyk. I tutaj taka rada bardzo dla managementu, jeśli czujesz, że z wcześniejszych porad wynika, że faktycznie diagnoza mówi, że są pewne braki, że tutaj inspiracje uzyskane wskazują na to, że trzeba się troszkę odświeżyć, to być może to odświeżenie musi nastąpić. Czy jest temu pretekst przy okazji startującego nowego projektu, otwarcia nowego kwartału, zbudowania nowego zespołu, który ma się czymś tam podjąć. Czyli też taka managerska inicjatywa, czy może takie mocniejsze zasygnalizowanie, że wracamy na pewne tory, że oczekujemy pewnego działania, czy stawiamy jako oczekiwanie względem zespołów, żeby praca przebiegała w następujący sposób. I to może być bardzo wspierające wszystkie poprzednie porady, jeśli którejś z nich wprowadzisz. Bo może być bardzo trudno w praktykę przenieść nawet najfajniejsze szkolenia, dobrze dopasowane, dobrze przemyślane, jeśli nie będzie oczekiwania, że ta praca faktycznie będzie się zmieniała, usprawniała, czy stan, sposób działania zespołów będzie się polepszał. Więc tutaj takie managerskie wsparcie, poprzez postawienie oczekiwań, że praca będzie wyglądała trochę lepiej, niż wyglądała do tej pory.

Jacek: Sporym plusem nagrywania 123. odcinka podcastu Porządne Agile jest to, że mamy już sporą bazę materiałów, które mogą być poszerzeniem tego, o czym mówimy dzisiaj w odcinku. Jakie konkretne odcinki rekomendujemy jako rozszerzenie odcinka 123?

Kuba: Są cztery odcinki, które tematycznie wiążą się z tym, co wspomnieliśmy w tym nagraniu. W odcinku 2., Jak się rozwijać w roli Scrum Mastera, wspominaliśmy właśnie nasze porady dla każdego indywidualnego Scrum Mastera, co można zrobić, żeby się rozwinąć. Znajdziesz je pod adresem porzadnyagile.pl/2. W odcinku 37, pod tytułem Wyszkoliliśmy się ze zwinności i co dalej. Również pokazujemy pewne dalsze kroki, jakie mogą podjąć Scrum Master, czy grupa Scrum Master wewnątrz organizacji, żeby faktycznie dalej pogłębiać swoje zrozumienie z winności i stosowania z innych praktyk. To do znalezienia pod adresem porzadnyagile.pl/37. Odcinek trzeci z naszej rekomendowanej puli to odcinek 63, Ocena stanu z winności firmy. Tam pogłębiamy temat, który był w puli naszych dzisiejszych porad, związany z tym, jak oceniać, jak analizować z winności w organizacji. Znajdziesz to pod adresem porzadnyagile.pl/63. I ostatnia rekomendacja dalszych materiałów to odcinek 65, Jak dobrze organizować szkolenia. Tutaj więcej na temat tego, jak zorganizować, jak dopasować materiału i jak przeprowadzić szkolenie, tak żeby ono było wartościową inwestycją w polepszenie sposobu działania zespołów. Ten materiał do znalezienia pod adresem porzadnyagile.pl/65.

Jacek: Podsumowując dzisiejszy odcinek. Jak można zadbać o dalszy rozwój kompetencji zwinnych? Zastanów się, jak obecny sposób działania zespołów odpowiada na potrzeby organizacji. Zdiagnozuj wewnętrzny stan wiedzy. Poproś eksperta zewnętrznego o rekomendacje zmian w procesach. Zorganizuj inspiracyjne warsztaty z ekspertem.

Kuba: Dopasuj program rozwoju do potrzeb twoich zespołów. Uruchom wewnętrzny program wymiany wiedzy. Aktywuj istniejących firmie ekspertów do prowadzenia warsztatów. Stwórz program mentoringowy i odśwież odczekiwania co do zwinności przy okazji nowych inicjatyw.

Jacek: Jeżeli czujesz, że to jest odcinek, który dotyczy twojej firmy i czujesz, że wzmacnianie kompetencji zwinnych w zespołach to coś, co powinno się wydarzyć, to zdecydowanie zachęcamy do kontaktu z nami przez formularz na stronie porzadnyagile.pl. Pomagamy firmom wykorzystywać zwinność do budowania przewagi konkurencyjnej.

Kuba: Natomiast notatki do tego odcinka artykuł na jego podstawie, transkrypcję naszej rozmowy oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/123.

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

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.

Lessons Learned jest narzędziem pracy powszechnie stosowanym w zarządzaniu projektami (bardzo popularnym u kierowników projektów). Dowiesz się, dlaczego naszym zdaniem ta koncepcja jest antywzorcem? W tej rozmowie usłyszysz o ciągłym doskonaleniu procesu i produktu wraz z listą rekomendacji, co można zrobić, żeby uniknąć pułapki zbyt późnych usprawnień.

Lessons Learned, czyli wyciąganie wniosków na końcu projektu, dla wielu wydaje się, być sensownym podejściem. Dowiedz się, dlaczego warto zrewidować tę koncepcję i jak efektywniej usprawniać produkty i procesy.

Pomysł na poruszenie tego tematu pojawił się podczas konferencji dotyczącej zbierania wymagań. Jacek opowiadał na niej o tym, dlaczego koncepcja Lessons Learned jest bardziej antywzorcem niż polecaną przez niego praktyką. Wzbudziło to duże zainteresowanie i postanowiliśmy rozwinąć to zagadnienie. 

Spis treści

• Czym jest Lessons Learned?
• Ciągłe doskonalenie procesu
• Dlaczego warto się usprawniać?
• Ciągłe doskonalenie produktu
• Podejście iteracyjno-przyrostowe
• Korzyści z podejścia iteracyjno-przyrostowego
• Jak wprowadzić do zespołu podejście ciągłego doskonalenia procesu i ciągłego doskonalenia produktu?
• Transkrypcja podcastu „Jak uniknąć pułapki Lessons Learned?”

Lessons Learned jest powszechnym narzędziem stosowanym w zarządzaniu projektami. Polega na tym, że bazując na dotychczasowych działaniach, zbiera się i podsumowuje wnioski. Na tej podstawie ustalane są w zespole projektowym potrzebne zmiany, np. w podejściu do pracy zespołu lub do sposobu działania procesów, czy też dostosowania narzędzi dla kolejnych projektów w przyszłości. 

Najczęściej polega to na spotkaniu podsumowującym pracę po skończonym projekcie lub wdrożeniu. Cały zespół projektowy zastanawia się przez chwilę, co można było zrobić lepiej. Przemyślenia te i wnioski są spisywane, aby wiedziedzieć jak działać lepiej w przyszłości.

Koncepcja Lessons Learned ma rację bytu, w sytuacji, gdy jest to jedyna rzecz, jaką ma zrobić zespół w ramach wyciągania wniosków, czy szukania usprawnień. Pozwala ona, chociaż w małym stopniu unikać ponownych błędów lub zawirowań. Jednocześnie Lessons Learned może być taktyką organizacji, która się uczy, a także w pewnym sensie elementem rozwoju osobistego członków zespołu, z których każdy nabiera coraz lepszych doświadczeń na temat tego, co działa, co nie działa, jak działać lepiej. 

Z obserwacji niestety wiemy, że z implementacją tego podejścia bywa różnie, zwłaszcza gdy jest traktowana, tylko jako pewien punkt na liście do odhaczenia, zamiast stanowić szczerą refleksję.

Często jest ona też realizowana już po skończonym projekcie, kiedy ludzie są już myślami w nowych zadaniach, zespoły się mieszają lub realizują całkowicie odmienne projekty. Bywa to też traktowane jako smutny obowiązek bez dostrzegania pozytywnych aspektów, które mogą usprawniać działanie w przyszłości. 

Jednocześnie widzimy, że jest to po prostu zwykłe dokumentowanie pewnych wniosków i nacisk jest kładziony na to, żeby je dobrze spisać i to jest głównym celem ćwiczenia. Wnioski potem nie są wykorzystywane, a propozycji zmian nikt nie wdraża w życie. Bywa też tak, że ze spisanych przemyśleń korzysta zupełnie inny zespół, więc nie ma tu motywacji, żeby zrobić to rzetelnie.

Lessons Learned stoi trochę w kontrze z ciągłym doskonaleniem procesu, gdyż zgodnie z tym, co wspomnieliśmy powyżej, moment refleksji pojawia się trochę późno, bo na koniec projektu. Z kolei podejście ciągłego doskonalenia procesu sugeruje, aby takie ćwiczenie odbywało się częściej, np. co tydzień lub co 2 tygodnie albo po każdej iteracji czy innym rodzaju cyklu.  

Koncepcja ciągłego doskonalenia podczas korzystania ze Scruma zwykle łączona jest z Retrospektywami Sprintu, natomiast my chcemy Cię zachęcić do podejścia, jakie znamy od Alistair’a Cockburn’a, czyli do nano-usprawnień. Są to takie, naprawdę drobne usprawnia, dzięki którym ciągle się doskonalimy, ciągle poprawiamy swój proces pracy i  sposób działania zespołu, usprawniamy przebieg spotkań, szukamy lepszych narzędzi czy taktyk. Stawiamy sobie tu proste pytanie: co działa, co warto wypróbować, a potem robimy małe kroki i przeprowadzamy drobne eksperymenty. Można to robić np. na koniec Daily, gdzie zespół odpowiada na pytania: jak bardzo wartościowe było to spotkanie, co działa dobrze, a co można by zrobić lepiej. Wystarczy dosłownie 5 minut rozmowy każdego dnia, gdyż to już po tygodniu może doprowadzić, że Daily stanie się satysfakcjonujące i przydatne dla wszystkich. 

Nano-usprawnienia sprawdzą się w zasadzie przy każdej czynności, czy to w przypadku pojedynczego warsztatu z klientem, sesji planowania, czy Refinementu Backlogu Produktu. Nie ma tu potrzeby przeprowadzania jakiejś formy rozgrzewki, głosowania kropkami, czy długiej burzy mózgów. Wystarczy szybka rozmowa w zespole i wspólne zastanowienie się, czy jest coś, co można przetestować, zrobić inaczej, poprawić.

Podzielimy się 5 najważniejszymi naszym zdaniem powodami, dla których warto się nieustannie usprawniać.

Zespoły, z którymi rozmawiamy często narzekają, na popełnianie wciąż tych samych błędów, co jest bardzo frustrujące. Ciągłe usprawnianie procesu pomaga zidentyfikować te błędy, a następnie w prosty sposób je wyeliminować.

Więcej o tym, dlaczego się usprawniać, co może podlegać usprawnieniom i jak przeprowadzać sesje usprawnieniowe mówimy w naszym webinarze Porządna Retrospektywa Sprintu

Podobnie jak Lessons Learned są antywzorcem w przypadku wykonywania tego ćwiczenia na koniec projektu, to samo możemy powiedzieć o praktykowaniu tego na poziomie zarządzania rozwojem produktu. 

Bardzo często obserwujemy wyciąganie wniosków i wprowadzanie poprawek dopiero po weryfikacji rynkowej. Nie ma już okazji, aby szybko coś poprawić w ramach bieżącej inicjatywy, a wnioski, które się pojawią, zazwyczaj mało kogo już interesują.

Refleksja na temat produktu dopiero w momencie, kiedy ten produkt wydajemy czy pokazujemy światu, ma kilka zasadniczych wad:

W celu zminimalizowania opisanych przez nas problemów proponujemy podejście iteracyjno-przyrostowe, z wczesnym wdrożeniem pierwszej wersji i częstymi kolejnymi wdrożeniami rozwijającymi produkt.

Dzięki takiemu działaniu produkt rozwija się małymi krokami, począwszy od zaspokojenia takich podstawowych potrzeb klienta, a może nawet potrzeb tylko pewnej podgrupy klientów. Produkt już na wczesnych etapach trafia do odbiorcy docelowego, przez co jest okazja, aby zebrać informację zwrotną i wyłapać ewentualne błędne założenia.

W podejściu tym masz możliwość wprowadzania poprawek w przyszłości, zmniejszasz też presję na to, aby od razu stworzyć idealne rozwiązanie.

Więcej argumentów za tym, aby dzielić pracę na mniejsze kawałki, usłyszysz w rozmowie „Dlaczego warto dzielić pracę na małe części?”, do odsłuchania którego serdecznie Cię zachęcamy.

Na koniec podpowiemy Ci, co może pomóc w zmianie sposobu pracy zespołu i uwzględnienia koncepcji ciągłego doskonalenia.

Jeśli i Twój zespół wpadł w pułapkę Lessons Learned, czyli wyciągania wniosków na końcu, mocno zachęcamy Cię do zmiany podejścia i zaproponowania, aby wypróbować koncepcję ciągłego doskonalenia. Korzyści jest wiele, a metodą małych kroków i prostych eksperymentów, szybko można zauważyć poprawę efektywności i skuteczności. 

Jacek: Opowiadałem ostatnio na konferencji, która dotyczyła tematu zbierania wymagań, o tym, dlaczego uważam, że koncepcja Lessons Learned jest antywzorcem. Temat wzbudził zainteresowanie uczestników konferencji, stąd pomysł, żeby podzielić się tą koncepcją w podcaście. 

Kuba: Spis treści tego odcinka. Zdefiniujemy, czym są w ogóle Lessons Learned. Potem opowiemy o ciągłym doskonaleniu procesu. Nawiążemy też do ciągłego doskonalenia produktu i na koniec podsumujemy listą naszych rekomendacji, co można zrobić, żeby było lepiej.

Kuba: I zaczniemy od definicji. Czym jest Lessons Learned? Lessons Learned jest to narzędzie pracy powszechnie stosowane w zarządzaniu projektami, znane jako narzędzie pracy kierownika projektu. Lessons Learned polega na tym, że podsumowuje się wnioski i ustala w zespole projektowym możliwe potrzebne zmiany w podejściu do pracy, czy to zespołu, czy do sposobu działania procesów, czy dostosowania narzędzi dla kolejnych projektów w przyszłości. Najczęściej polega to na jakiejś sesji podsumowania pracy po skończonym projekcie, po skończonym wdrożeniu, po zakończonych pracach projektowych, gdzie cały zespół projektowy zastanawia się przez chwilę, co można było zrobić lepiej. Spisuje to, najczęściej w postaci jakiegoś bardzo konkretnego szablonu dokumentu, albo jakiegoś konkretnego narzędzia, w którym się te rzeczy zbiera i wyciąga wnioski na to, jak działać lepiej w przyszłości.

Kuba: Koncepcja co do zasady jest niezła i zwłaszcza w scenariuszu takim alternatywnym, w którym w ogóle nic takiego się nie robi, no to już lepiej, że się to robi, niż się nie robi. No i wiele zespołów bardzo cierpi na tym, że właśnie wszyscy wiedzą, co można było zrobić lepiej, ale nikt tego na głos nie nazwał. Jest jakiś taki słoń w pokoju, nie uczymy się, czy członkowie zespołu nie zbierają nowych doświadczeń, nie ustalają, co poszło nie tak. Też czasami w projektach są kryzysy i z tych kryzysów też nikt w sumie nie wyciąga żadnych wniosków, więc w niektórych organizacjach, w których takich Lessons Learned w ogóle się nie robi, jest niestety takie poczucie odrobiny dnia świstaka, gdzie każdy kolejny projekt kończy się identycznymi kłopotami, czy ma kolejne podobne zawirowania, bo nikt na głos nie nazwał, że może wreszcie przestańmy robić X albo zacznijmy częściej robić Y. No i tutaj Lessons Learned jest częścią takiej koncepcji organizacji, która się uczy, częścią koncepcji też takiego rozwoju osobistego, gdzie każdy członek zespołu nabiera coraz lepszych doświadczeń na temat tego, co działa, co nie działa, jak robić to lepiej. Więc podsumowując, Lessons Learned jest narzędziem pracy i służy temu, żeby się doskonalić.

Jacek: I po tym dosyć pozytywnym wstępie Kuby, w praktyce trzeba powiedzieć, że tak jak my to obserwujemy, no to z implementacją tego podejścia bywa różnie. Bardzo często jest to pewien formalizm, a nie taka realna, szczera refleksja. I zwykle dzieje się to na końcu projektu, gdzie już odpalamy kolejne, już ludzie są gdzieś tam lokowani do nowych zadań. No i tak naprawdę ja zwykle obserwuję, że to jest coś w stylu – smutny obowiązek, a nie faktyczne wydarzenie, które pomoże nam na przyszłość. Druga sprawa, bardzo często obserwuję, że to jest częściej dokumentowanie pewnych wniosków i nacisk jest kładziony na to, żeby to dobrze spisać. Tak jak Kuba wspomniał, często w jakiejś takiej ustrukturyzowanej formie, niż akcent na faktyczne wprowadzanie zmian. Tych zmian często nie ma, kto do końca wprowadzić, no bo zespół w tym kształcie, w którym funkcjonował, być może będzie jakby już rozłożony gdzieś tam w innych częściach organizacji. No i ten taki, mówiąc po staropolsku, commitment, zobowiązanie, że coś zostanie zrealizowane, to się zwykle dosyć mocno rozwadnia. No i trzecia obserwacja jest taka, że zwykle skorzysta na tych naszych przemyśleń jakiś zupełnie inny zespół niż nasz. Więc tak naprawdę nie ma jakiejś super dużej motywacji, żeby zrobić to rzetelnie.

Kuba: No i najważniejsza czwarta obserwacja do naszych takich przemyśleń na temat Lessons Learned jako narzędzia pracy, dlaczego są realizowane tak późno, dlaczego dopiero na koniec. To przenosi nas do drugiego punktu tego odcinka, czyli ciągłego doskonalenia procesu.

Jacek: Ciągłe doskonalenie procesu jest trochę w kontrze do tej koncepcji Lessons Learned, którą opowiedzieliśmy, gdzie zaczynamy projekt, realizujemy go i dopiero na końcu projektu pojawia się ten moment refleksji. Podejście ciągłego doskonalenia procesu zachęca nas do takiego ćwiczenia umysłowego, co by było, gdybyśmy taką refleksję robili co dwa tygodnie, czy to co tydzień, w zależności od tego, w jakich iteracjach, cyklach, Sprintach, jakkolwiek sobie to nazywamy, funkcjonuje nasz projekt. Te przykładowe dwa tygodnie, czy tydzień, to oczywiście najczęściej takie występujące w przyrodzie okresy, co ile zespoły sięgają pod tą koncepcję. Natomiast oczywiście można robić to częściej, zdecydowanie, jeżeli to ma sens. 

Kuba: Koncepcja ciągłego doskonalenia osoby, które korzystają albo znają Scrum, bardzo mocno wiążą z Retrospektywami Sprintu, natomiast my w tym nagraniu chyba chcemy podnieść poprzeczkę jeszcze wyżej i zachęcamy do koncepcji, którą my znamy od Alistair’a Cockburn’a, czyli koncepcję nano-usprawnień. Nano, czyli takich naprawdę drobnych usprawnień. Więc ciągle się doskonalmy, ciągle poprawiajmy swój proces pracy, sposób działania zespołu, spotkania, które stosujemy, narzędzia, których używamy, metody działania w ramach zespołu. Co działa, co można wypróbować, to jest dosłownie króciutkie pytanie. Na koniec na przykład Daily, gdzie po skończonym codziennym spotkaniu zespołu można poprosić o to, żeby podsumować się, jak wartościowe to spotkanie jest, czyli co w nim działa, ale co jeszcze można by zrobić inaczej. Dosłownie 5 minut rozmowy dzień w dzień może sprawić, że w ciągu na przykład dosłownie kilku dni z rzędu można doprowadzić Daily do takiego stanu, który jest bardzo satysfakcjonujący dla zespołu. No i te koncepcje nano-usprawnień można w zasadzie przylepić do dowolnej czynności, do pojedynczego warsztatu z klientem, do jednego dnia pracy w zespole, do sesji planowania pracy, do sesji Refinementu Backlogu Produktu. Wszystkie elementy, wszystkie takie objawy zespołowe można też skończyć jakąś naprawdę króciutką sesją bez całej rozbudowanej struktury, bez rozgrzewki, bez zbierania punktów, bez głosowania kropkami, tylko po prostu krótka, szybka rozmowa w zespole. Czy jest coś, co możemy spróbować, czy coś, co chcemy zrobić inaczej, co nie zadziałało, co zadziałało i co decydujemy się jako zespół, tę jedną rzecz, niewielką, drobną rzecz, żeby wprowadzić to do następnego przypadku. Do następnego dnia, następnego etapu, następnego warsztatu czy spotkania, tak jak wymieniałem jako przykłady. Więc tutaj jesteśmy za tym, żeby się ciągle doskonalić. Czasami to będzie raz na dwa tygodnie poprawianie sposobu działania w Sprincie, ale można nawet jeszcze lepiej. Dosłownie codziennie, czy co parę godzin się usprawniać i działać ciągle coraz lepiej.

Jacek: Jest kilka ważnych powodów, dla których warto się usprawniać. Podzielimy się takimi pięcioma najważniejszymi. Przede wszystkim ciągłe doskonalenie procesu pozwala uniknąć popełniania tych samych błędów. Słyszę czasem taki komentarz z zespołów, że to, co jest frustrujące, to jest to, że mamy te same błędy i się na nich nie uczymy i nie ma usprawnień. Jeżeli chcemy zidentyfikować błędy, jeżeli chcemy je usprawnić, no to ciągłe usprawnianie procesu może być bardzo prostym, a jednocześnie skutecznym narzędziem, które te błędy wyeliminuje z naszego procesu.

Kuba: Ciągłe doskonalenie może też prowadzić do poszukiwania innowacyjnych sposobów wykonywania pracy. Możemy wykonywać swoje działania ciągle tak samo, ciągle rutynowo, albo możemy z naszym procesem pracy eksperymentować. Spróbować nowego podejścia, innej techniki, poprowadzić spotkania zupełnie inaczej, poukładać swoje działania jako zespół zupełnie inaczej. I to może być dosłownie tylko i wyłącznie jednorazowe. Tak dla śmiechu zróbmy to inaczej, ale często w takich przypadkach, jeśli zespół ciągle się doskonali, to takie okazje do tego, żeby coś zrobić inaczej, nawet po prostu w szalony sposób inaczej, albo spróbować innego podejścia niż zwykle, prowadzi do tego, że ten zespół działa trochę lepiej, trochę inaczej, albo działa bardzo lepiej i bardzo inaczej dla dobra całego zespołu.

Jacek: Warto się usprawniać również z tego powodu, aby pozostać konkurencyjnym na rynku i ciągle dążyć do doskonałości. My jako organizacja możemy podjąć decyzję, że tego nie robimy, natomiast pamiętajmy, że nasza konkurencja może działać kompletnie inaczej. Wyobraźmy sobie sytuację, gdzie konkretna firma usprawnia się, powiedzmy raz na tydzień w ramach jakiegoś projektu. To są 52 okazje w ciągu roku, żeby usprawnić proces. Myślę, że nie muszę dopowiadać dalszej części tej historii. Ja bym wolał być w tej firmie, która faktycznie te usprawnienia wymyśla. No i co ważne, oczywiście wprowadza w życie.

Kuba: Ciągłe doskonalenie też daje okazję do tego, żeby uzyskiwać ten sam efekt mniejszym kosztem. Czyli zadbać o wydajność procesu, sprawić, że zespół ma mniej marnotrawstwa, szybciej wykonuje pewne działania, usuwa jakieś blokady w procesie czy spowolnienia. Bardzo namacalny, często wręcz dosłownie policzalny finansowo efekt, ale też po prostu wygodny dla zespołu, gdzie praca łatwiej idzie. Tak mówiąc potocznie, gdzie może jest mniej stresująca czy mniej denerwująca, czy mniej zmienna w taki nieprzewidywalny sposób.

Jacek: I ostatni powód, którym chcemy się podzielić. Usprawnianie się poprawia motywację zespołu. Jest to taki miękki kawałek tej historii, którą tutaj przytaczamy. Natomiast wielokrotnie słyszę od liderów, managerów pytanie. Jak mogę wpłynąć, jak mogę poprawić motywację zespołu? No i dla mnie oczywistą pierwszą myślą jest to usuńmy przeszkadzajki, usuńmy blokady, usuńmy to wszystko z procesu, co powoduje, że ludzie się frustrują. Wielokrotnie doświadczałem tego na własne oczy, jak zmienia się podejście, jak zmienia się energia w zespole, w sytuacji, w której ludzie, którzy są częścią tego zespołu, zaczynają dostrzegać, że ich działania usprawniające powodują, że przestrzeń środowiska, w którym pracują, jest po prostu bardziej przyjazne, jest bardziej efektywne. Naprawdę to są często małe zmiany, które prowadzą do naprawdę fajnych rezultatów.

Kuba: Więcej o tym, dlaczego się usprawniać, co podlega usprawnieniom i jak przeprowadzić taką sesję usprawnieniową zgodnie z rozbudowaną strukturą znajdziesz w naszym płatnym webinarze Porządna Retrospektywa Sprintu, który jest pod adresem porzadnyagile.pl/retro.

Jacek: Dobrze, przechodzimy do kolejnego kawałka dzisiejszego podcastu, czyli do części, w której powiemy o ciągłym doskonaleniu produktu.

Kuba: Dla wielu naszych słuchaczy, zwłaszcza tych, którzy są z nami od paru lat, którzy praktykują zwinne podejście też w swoich zespołach, koncepcja ciągłego doskonalenia sposobu pracy zespołu jest dosyć oczywista. Najczęściej realizowana rutynowo poprzez regularne retrospektywy Sprintu, jeśli stosowany jest na przykład Scrum. Natomiast to nie koniec tego odcinka, bo ta sama logika, która mówi, że Lessons Learned na koniec projektu są antywzorcem, może być przeniesiona też na poziom zarządzania rozwojem produktu. I za dużo razy obserwujemy zespoły, w których jakkolwiek to nazwiemy, wdrożenie, projekt, inicjatywa, jest dopiero tak weryfikowana rynkowo, dopiero na koniec, gdy już jest trochę za późno. I wszystkie te wady, o których mówił na samym początku Jacek, mają zastosowanie, czy mają tutaj podobną analogię. Nie ma okazji do tego, żeby skorzystać z wniosków, nie ma okazji do tego, żeby coś jeszcze poprawić w ramach bieżącej inicjatywy. Często te wnioski już nikogo nie interesują, bo zespół się w jakiś sposób przesuwa do innych działań, a może w ogóle zmienia kształt, więc tak jak zachęcamy do ciągłego doskonalenia procesu, i to jest oczywiste, tak samo przestrzegamy przed unikaniem ciągłego doskonalenia produktu.

Jacek: Jest kilka wad, podejścia, o którym powiedział Kuba, czyli refleksja na temat produktu dopiero w momencie, kiedy ten produkt wydajemy czy pokazujemy światu. Przede wszystkim ten moment weryfikacji założeń biznesowych pojawia się bardzo, ale to bardzo późno w tym procesie. Być może te założenia zostaną już z nami na zawsze, jeżeli ograniczenia organizacyjne nie zakładają, że będziemy robić jakąś kolejną rundę usprawnień czy jakichś takich dodatkowych przyrostów do produktu naszego projektu. Więc wszystkie te błędne koncepcje, błędne założenia, one po prostu wyjdą na rynek, no i będziemy musieli, niestety, ze smutkiem obserwować, jak bardzo się pomyliliśmy, jak bardzo nie udało nam się ogarnąć złożoności. No i w tym najgorszym przypadku nie będziemy mieć szansy na to, żeby te błędne założenia skorygować, albo będzie to bardzo kosztowna zabawa, żeby to zrobić na tak późnym etapie procesu.

Kuba: Jak sobie to tym swobodnie mówimy, to może się wydawać takie oczywiste, no to po prostu trzeba to poprawić po wdrożeniu, ale smutna realia wielu organizacji i taka też jednocześnie druga wada, którą dorzucę do puli, to to, że poprawienie czegokolwiek w wielu organizacjach z powodów proceduralnych, formalnych, narzędziowych po prostu wymaga na przykład zgłoszenie nowego projektu, albo zgłoszenie w jakiś ukryty sposób obejścia procesów i procedur. Na przykład zgłoszenie błędów jako tak naprawdę nowej funkcjonalności, albo znalezienie jakiegoś takiego wejścia od tyłu do Product Ownera, żeby tak nam grzecznościowo jakieś usprawnienie zrobił. I to wszystko powoduje, że poprawienie czegokolwiek w niejednej organizacji jest po prostu prawie niemożliwe, albo wymaga bardzo dużych wysiłków, takich również nieformalnych, co powoduje, że albo te poprawki są zrobione tak bardzo byle jak, takim minimalnym możliwym kosztem, żeby się nie narażać, albo przechodzą ścieżkę zdrowia. Zgłoszenie od nowa business case’a, zgłoszenia od nowa na jakiś portfel, na jakiś komitet i różne tego typu rzeczy. I oczywiście te wymienione przeze mnie procedury mają mało wspólnego z agile’em, ale jednocześnie z tego co widzę są codziennością wielu organizacji, cały czas stosowane narzędzia, więc wtedy tym bardziej trudno jest usprawnić swój produkt.

Jacek: Trzecią wadą podejścia, gdzie odsuwamy na koniec wdrożenie rezultatów projektu, jest fakt, że wiedząc, że tak z założenia nie będziemy mieć iluś tam podejść, nie będziemy mieli przestrzeni, żeby iterować, czy pracować w przyrostowy sposób, no pojawia się duża chęć, bardzo idealistyczna, żeby zrobić po prostu wszystko dobrze i perfekcyjnie za pierwszym podejściem. Co oczywiście ma swoje wady, bo blokuje kreatywność, powoduje, że wpadamy we wszelkiego rodzaju paraliże analityczne no i może też powodować, że cały ten proces decyzyjny będzie się wydłużał.

Kuba: Dobrze, to już wymieniliśmy wady podejścia wdrożenia na koniec. Co proponujemy zamiast? No, Jacek już to trochę powiedział, zdecydowanie optujemy za podejściem iteracyjno-przyrostowym, z wczesnym wdrożeniem pierwszej wersji do klienta i częstymi wdrożeniami kolejnymi rozwijającymi produkt. Produkt rozwija się małymi krokami, zaczynając właśnie z jakiejś bardzo prostej wersji zaspokajającej bardzo podstawowe potrzeby klienta, może nawet tylko pewnej podgrupy docelowej klientów, ale już na wczesnych etapach trafia do tego odbiorcy docelowego, mamy okazję zebrać informację zwrotną i ewentualnie wyłapać te błędne założenia, o których mówił Jacek. Mieć okazję do tego, żeby poprawić ten produkt, o czym ja wspominałem, czy też może trochę zmniejszyć ciśnienie na to, żeby od razu mieć idealne rozwiązanie, bo mamy parę okazji do tego, żeby to rozwiązanie skorygować. I to, co mówię, jest absolutnie realne w tych nawet smutniejszych organizacjach, o których wspomniałem, bo nawet jeśli mamy komitet i mamy wielki projekt, jakiś budżet i jakieś duże koncepcje, to dalej szukajmy okazji do tego, żeby w ramach jakiegoś większego przedsięwzięcia podzielić to na mniejsze kroki i poszukać okazji do wdrożenia mniejszego etapu czy kroku, czy fazy wcześniej.

Jacek: Jest sporo korzyści takiego podejścia, które Kuba opisał. Przede wszystkim pracując w ten sposób, otrzymasz wcześniej informację zwrotną, co pozwoli ci udoskonalić Twoje rozwiązanie. 

Kuba: Korzyścią drugą jest to, że wcześniej dostarczysz część wartości na rynek. Jest spora szansa, że to pierwsze rozwiązanie, może w drugim, trzecim kroku, będzie już na tyle wartościowe, że rynek zacznie go doceniać, ludzie zaczną za to płacić, klienci zaczną kupować czy zamawiać naszą usługę i dzięki temu jeszcze w trakcie trwania prac rozwojowych już zacznie się pojawiać jakiś zwrot z tej inwestycji. W zależności od tego, jakie są realia produktowe, może się okazać, że ten zwrot jest naprawdę wartościowy i w zasadzie już zaczyna spłacać wszystkie koszty inwestycji, co najczęściej jest bardzo dobrą wiadomością dla organizacji.

Jacek: Kolejna korzyść, łatwiej oddzielisz wartościowe elementy tego, co wytwarzasz od tych mniej wartościowych. Oczywiście wiąże się to z tym, żeby w ogóle z takiego podejścia przyrostowo-iteracyjnego skorzystać, no to na pewno będziemy musieli się zaprzyjaźnić ze sposobami dzielenia produktu, ze sposobami dzielenia wymagań na mniejsze kawałki. W tym procesie dzielenia zobaczymy, że coś, co początkowo wydaje nam się czymś dużym, co musimy zrobić od A do Z, po podzieleniu może się okazać, że tak naprawdę z tych 10 kawałków, które mamy po podzieleniu, to tak naprawdę wartość przynosi 5 albo 6 albo 7 i być może ta pozostała część będzie odłożona na później. No, ale w wariancie, który często obserwuję w praktyce, być może te pewne elementy, które pierwotnie nam się wydawało, że są istotne, po prostu nie zostaną nigdy zrealizowane.

Kuba: Kolejną konsekwencją tego, co Jacek powiedział, jest to, że podczas dzielenia odkryjesz niuanse pracy do wykonania. Wiele zespołów, które idzie w scenariusz wielkiego wdrożenia, czyli zrobimy wszystko, zrobimy kombajn, zrobimy uniwersalne narzędzie, które robi kompletne zarządzanie całym procesem, często nie patrzy się w niuanse czy w szczegóły. Jacek mówił o oddzielaniu wartościowych i mniej wartościowych rzeczy, a ja bym dorzucił jeszcze do puli w ogóle zrozumienie istoty tego, co jest do zrobienia. Jeśli szukamy bardzo prostej wersji pierwszej, drugiej, trzeciej, to może się okazać, że też większą uwagę skupiamy na tym, co jest istotą tego, co faktycznie jest produktem, co jest wartością. I lepiej zespół, interesariusze, sponsorzy zrozumieją, co jest faktycznie do zrobienia, co jest tutaj jakąś przewagą rynkową, a co jest może gdzieś mgliste lub może być zupełnie ominięte.

Jacek: Jeżeli chcesz poznać więcej argumentów, dlaczego warto dzielić pracę na mniejsze kawałki, zachęcamy do odsłuchania odcinka numer 76, „Dlaczego warto dzielić pracę na małe części?”. Odcinek ten znajdziesz pod adresem porzadnyagile.pl/76

Kuba: Dobrze, to w ostatniej części tego nagrania powiemy, co można zrobić, żeby było lepiej. Co można zrobić, żeby do swojego zespołu wprowadzić podejście ciągłego doskonalenia procesu i ciągłego doskonalenia produktu.

Kuba: Pierwsza rekomendacja. Sprawdź, jak dzisiaj często usprawnia się proces i produkt. Wiele zespołów kompletnie nie zdaje sobie sprawy, jak rzadko to robi, albo jest to po prostu codziennością, taką rzeczywistością, na którą nikt świadomie się nie pochyla, więc jako lider swojego zespołu, który przekonany jest do tego, że trzeba coś zmienić, możesz zebrać dane, zebrać fakty, cofnąć się trochę w przeszłość funkcjonowania twojego zespołu i przedstaw te fakty swojemu zespołowi i porozmawiajcie o tym, czy to jest satysfakcjonująca częstotliwość, czy może przegapiona okazja do tego, żeby się jednak zmieniać. Jeśli temat nakłuwa ciebie i przykuwa uwagę, to być może da się zrobić lepiej. Ja jestem ambitny i uważam, że w każdym zespole da się zrobić to jeszcze lepiej. Więc tutaj można łatwo na faktach i na pewnych konkretnych historiach lokalnych z tego swojego konkretnego zespołu pokazać, że da się proces usprawniać częściej niż robicie to aktualnie.

Jacek: Kolejny punkt, kolejna rekomendacja, buduj świadomość, dlaczego ciągłe usprawnianie się jest wartościowe. I tutaj zarówno mamy na myśli perspektywę członków zespołu, jak również organizacji. Czyli wszelkiego rodzaju te koncepcje, którymi dzieliliśmy się z Kubą w trakcie tego odcinka, mogą być właściwie gotowymi argumentami, gotowymi przykładami, którymi będziesz mógł lub mogła żonglować w rozmowie z zespołem. No bo tak naprawdę bez tej świadomości, jakby nie mając tego zrozumienia, dlaczego to może być wartościowe, no to zespół może odbierać tę zmianę jako coś niepotrzebnego, coś, co ma niższy priorytet niż zwykła taka bieżąca, codzienna praca.

Kuba: I w tym odcinku w kilku miejscach wymieniamy listę argumentów, dlaczego się usprawniać, dlaczego tego nie robić w zależności od kultury zespołu. Różna pula argumentów może być wykorzystana. Ja od siebie dorzucę jeszcze inną perspektywę. Można też zapytać, zwłaszcza członków zespołu z większym doświadczeniem, czy mają w przeszłości dobre wspomnienia po usprawnianiu się. W tej organizacji, może w poprzedniej, w której byli, wiele osób, które ma większe doświadczenie pracy, ma gdzieś w swojej historii takie fajne wspomnienie, jak to było ekstra, gdy ciągle zespół poprawiał, otwarcie mówił o tym, co może robić lepiej, czy na przykład o wiele częściej doskonalił produkt, bo to też często są bardzo inspirujące i bardzo konkretne historie? Więc tutaj możesz budować świadomość usprawniania się swoją historią i swoimi argumentami, możesz też poprosić członków zespołu do tego, żeby przynieśli swoje wspomnienia i swoje dobre historie. To też często bardzo przekonuje pozostałe osoby w zespole.

Kuba: Trzecia porada na temat tego, jak można usprawnić sposób usprawniania się zespołu. Przygotuj konkretną, prostą technikę, którą możesz pokazać zespołowi, by przeprowadzili sesje usprawnieniowe. Tutaj mam na myśli bardziej konkretnie historię związana z usprawnianiem procesu. Wiele zespołów niekoniecznie usprawnia swój proces, bo po prostu jednak nie za bardzo wie jak. Nie zna jakiejś struktur, nie zna sposobów. Zwłaszcza jeśli w zespole do tej pory w ten sposób się nie rozmawia, to może być takie trochę niezręczne, szczerze sobie powiedzieć, co nie działa. Może nie jest to częścią kultury organizacji, żeby też odważnie proponować różne zmiany, więc bardzo pomocne może być, jeśli jako lider lub liderka swojego zespołu po prostu zaproponujesz jakąś konkretną, prostą technikę usprawnieniową, która może otworzyć dyskusję, otworzyć co bardziej skryte osoby przed tym, żeby się nie wahały i jednak powiedziały co myślą i zaproponowały jakieś konkretne rozwiązania. Skąd brać te techniki? Wierni słuchacze wiedzą, że w wielu naszych odcinkach takie rzeczy wspomnieliśmy. Ja ponownie odeślę do naszego webinaru o retrospektywie do znalezienia pod adresem porzadnyagile.pl/retro. Oprócz samego webinaru jest częścią pakietu również zestaw instrukcji na temat tego, jak przeprowadzać konkretne techniki usprawnieniowe, które mogą być bardzo przydatne właśnie do tej rekomendacji, którą przed chwilą wymieniłem.

Jacek: Kolejna wskazówka, co można byłoby zrobić, żeby było lepiej w temacie ciągłego usprawniania się. Pomóż zespołowi w praktyce podzielić produkt na mniejsze elementy. Czyli to, o co mówił Kuba, to jest dostarczenie pewnej wiedzy, pewnych koncepcji. Natomiast tutaj przychodzi moment, kiedy należałoby sobie ubrudzić ręce i faktycznie namacanie na przykładach zespołowych pomóc wykorzystać tę wiedzę w praktyce. Dlaczego o tym wspominamy? Na bazie naszego doświadczenia brak umiejętności dzielenia jest jedną ze źródłowych przyczyn całego kłopotu. Zespoły często nie wiedzą, po co dzielić, nie wiedzą, że można dzielić, nie potrafią dzielić dostatecznie dobrze. I to niestety wpływa na to, że nie pracują przyrostowo, nie pracują interacyjnie, pracują na dużych elementach, które wchodzą albo wcale, albo w całości. I tak naprawdę to powoduje, że nie mamy zbyt wiele okazji do tego, żeby usprawniać zarówno produkt, jak i proces. Jeżeli temat tego, jak skutecznie dzielić prace na mniejsze kawałki jest dla Ciebie istotny, poruszyliśmy ten temat w naszym webinarze nazwanym Dekompozycja elementów Backlogu Produktu i znajdziesz ten webinar na stronie porzadnyagile.pl/deko.

Kuba: I ostatnia porada w temacie. Podsumuj rezultaty zmiany podejścia do usprawniania się. Przyjmijmy założenie, że wprowadzasz w życie rekomendacje wcześniejsze, które wymieniliśmy przed chwilą. Bardzo ważnym elementem wprowadzenia trwałej zmiany, zmiany nawyków, zmiany podejścia, czy po prostu zmiany kultury sposobu działania tego zespołu, to to, żeby jednak sobie świadomie zreflektować, czy jest lepiej. Czy to nowe podejście, częstsze rozmowy o tym, co możemy poprawić, czy inne podejście do rozwoju produktu, czy jest satysfakcjonujące, czy daje korzyści, daje te korzyści, które obiecywaliśmy, a może daje jeszcze jakieś nowe, o których nawet nie pomyśleliśmy? Pokaż miary. Jeśli masz jakieś miary procesowe, zrób rozmowę o tym, jak się usprawniacie, tak zwane Retro o Retro. Czyli czy ten sposób zmiany sposobu działania zespołu jest satysfakcjonujący, korzystny dla członków zespołu. Porozmawiajcie o tym, żeby bardzo świadomie sobie też zauważyć i docenić to, że ta zmiana faktycznie jest obiecująca, jest lepsza i że zespołowi się działa, dzięki temu lepiej czy efektywniej. Jeśli tego nie zrobimy, może być bardzo duże ryzyko, że gdzieś tam w takim codziennym pędzie życia projektowego, no po prostu przez chwilę było lepiej, ale nigdy sobie tego na głos nie powiedzieliśmy, no i niestety tak tutaj trochę incepcja wejdzie, ale wpadniemy w tę samą pułapkę, jak robienie Lessons Learned na koniec, albo w ogóle ich nierobienie. Czyli było przez chwilę lepiej, ale nigdy sobie tego na głos nie powiedzieliśmy, komuś gdzieś tam wypaliła się energia. Fajny moment będzie tylko wspomnieniem, a nie nową codziennością.

Jacek: I tym sposobem dotarliśmy do końca tego odcinka. Podsumowując, wiele zespołów pada w pułapkę Lessons Learned. Czyli wnioski dotyczące zarówno procesu, jak i produktu, pojawiają się na końcu procesu pracy.

Kuba: Zamiast antywzorca Lessons Learned na koniec, rekomendujemy ciągłe doskonalenie procesu pracy zespołu i ciągłe doskonalenie produktu. Daje to następujące korzyści. Zespół unika popełniania tych samych błędów. Może poszukiwać innowacyjnych sposobów wykonywania pracy. 

Jacek: Umożliwia pozostawanie konkurencyjnym na rynku i ciągłe dążenie do doskonałości. Uzyskiwanie tego samego efektu mniejszym kosztem i poprawia motywację zespołu.

Kuba:  Jeśli potrzebujesz wsparcia w zmienianiu kultury i chcesz zaszczepić ciągłe doskonalenie w swojej firmie, odezwij się do nas. Realizujemy programy wsparcia zespołów, których efektem jest nauczenie się przez nich i zbudowanie sobie nawyków poprawiania swojego sposobu pracy i poprawiania swoich produktów. Jeśli jest to narzędzie, które byłoby przydatne w twoich zespołach, odezwij się do nas na porzadnyagile.pl/kontakt.

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

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

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

Budowanie zaufania to kluczowy aspekt relacji klient-dostawca. Poznaj 4 aspekty tego procesu i zobacz, jak to możesz osiągnąć dzięki przejrzystości działań i komunikacji.

Spis treści

• Czym jest zaufanie?
• Jak budować zaufanie w software house?
• Transkrypcja podcastu „Budowanie zaufania jako software house”

Tytuł artykułu sugeruje, że jest skierowany głównie do firm typu software house, jednak naszym zdaniem jest to także ciekawa inspiracja dla wszystkich relacji klient-dostawca. Co istotne pojęcie klienta odnosi się zarówno do klienta wewnętrznego (biznes, inne rynki), jak i do partnerów z zewnątrz organizacji. W pierwszej części omówimy definicję zaufania, aby każdy z nas miał to samo zrozumienie. Następnie podamy cztery przykładowe aspekty budowania zaufania.

Zaufanie jest dla Jacka formą przekonania, że można na kimś polegać, a osoba, której zaufaliśmy, będzie postępować zgodnie z naszymi oczekiwaniami, wyobrażeniami i wartościami, a na końcu wywiąże się ze swoich zobowiązań.

Z kolei dla Kuby zaufanie jest wiarą w przewidywalność zachowań osoby, z którą ma on relacje zaufania. Zaufanie bazuje tutaj na wiarygodności albo na dotychczasowych dobrych doświadczeniach współpracy z tą konkretną osobą.

Oboje zgadzamy się z tym, że w realiach pracy w firmach typu software house zaufanie jest istotną płaszczyzną do budowania przyjaznych warunków pracy, dlatego zwykle firmy czy też zespoły chcą je rozwijać i utrzymywać.

Nasze rekomendacje podzieliliśmy na 4 obszary, w ramach których opiszemy konkretne praktyki oraz podzielimy się wskazówkami opartymi na naszym doświadczeniu i obserwacjach.

Najprościej ujmując, chodzi tu o to, że jeśli obiecamy, że coś zrobimy, czy dopilnujemy, to dotrzymamy danego słowa. Przykładowo, jeśli obiecaliśmy klientowi, że przygotujemy draft projektu i wyślemy mu go do konkretnej daty, to spełnieniem naszej obietnicy, jest wysłanie tego draftu w ramach ustalonego terminu. Pomaga to zbudować poczucie niezawodności, a klient wie, że może polegać na wykonawcy. Zwiększa to też przewidywalność działań i pozwala klientowi planować różnego rodzaju aktywności związane ze zleconym projektem.

Firmy bardzo poszukują tej przewidywalności, dlatego sami przeprowadzamy programy, w których pomagamy poprawić przewidywalność procesu wytwarzania. Przykładowo jeden z klientów Jacka dzięki takiemu 3-miesięcznemu wsparciu, poprawił przewidywalność zespołu z 43% do 78%.

Chodzi tu o utrzymywanie komunikacji, zarówno tej operacyjnej, jak i wysokopoziomowej, w pewnym standardzie jakościowym. Standard ten powinien uwzględniać zawartość komunikacji, punktualność, responsywność i spójność, które świadczą o rzetelności partnera.

Poczucie przewidywalności komunikacji budujemy poprzez np. w miarę stały czas odpowiedzi na maila klienta. Jeśli cały czas odpisywaliśmy na jego zapytania w ciągu godziny, zmiana tego schematu, może spowodować u klienta poczucie, że nie można polegać na zespole, bo jest nieprzewidywalny.

Dobrym sposobem na uniknięcie powyższej sytuacji jest informowanie o okolicznościach, które mogą zaburzyć dotychczasowy sposób działania, np. integracja firmowa czy zmiana lokalizacji biura mogą na kilka dni wydłużyć czas oczekiwania na odpowiedź. Klient jest o tym uprzedzony i rozumie zaistniałe zmiany.

Bazując na doświadczeniach pracy w software house, jedną z gorszych rzeczy, jaką można zrobić, to stawianie klienta w sytuacji, w której dowiaduje się on na końcu o powstałych problemach w ramach jego projektu. Wytłumaczenie, że zespół nie chciał denerwować lub myślał, że się jednak uda, nie jest dobrym pomysłem. Klient może to odebrać jako zatajanie mniej pozytywnych elementów projektu i w efekcie obniżać zaufanie.

Mocno rekomendujemy budowanie rzetelności od samego początku. Wiąże się to też z jak najwcześniejszym ostrzeganiem i wspólnym szukaniem rozwiązań, co wzmacnia poczucie partnerstwa i grania do tej samej bramki.

Odnosi się to zarówno do infomowania o rzeczach do poprawy, ale również do wzajemnego doceniania się oraz podkreślania, co wspiera pracę i ułatwia komunikację.

Sposób dzielenia się informacją zwrotną z klientem zależy od relacji, jaką zespół ma z klientem i na jaką otwartość może sobie pozwolić. Zazwyczaj najbardziej oficjalnym sposobem jest forma pisana, głównie poprzez e-mail, rzadziej wiadomością na komunikatorze. Głównym minusem takiej formy komunikacji jest to, że klient otrzymuje suchy komunikat, a na to, jak go zinterpretuje, masz niewielki wpływ. Aspekty kulturowe dodatkowo wzmacniają potencjalny szum i niezrozumienie. Z tych też powodów uważamy, że w miarę możliwości lepiej wybierać rozmowę, zwłaszcza gdy obie strony widzą się nawzajem i mogą odbierać również sygnały niewerbalne. 

Ponieważ klient przychodzi do Ciebie z konkretną potrzebą lub problemem do rozwiązania, to im szybciej otrzyma on nawet mały kawałek pracy, tym szybciej zobaczy, że może zobaczyć, że faktycznie może na Tobie lub Twoim zespole polegać. Dodatkowo widzi, że jest zrozumienie wyzwania, umiejętność łączenia kropek i różne osoby po stronie wykonawcy potrafią ze sobą współpracować. Budujesz w ten sposób poczucie przewidywalności i zaufania, bazując na konkretnych efektach pracy. Jednocześnie im wcześniej klient otrzyma pierwsze kawałki produktu, tym szybciej zaczniecie uczyć się efektywnej komunikacji, a to wpływa na kolejne etapy pracy.

Unikaj zbyt długiego trwania w fazie koncepcji i długich dywagacji, które nie prowadzą do niczego konkretnego. Oczywiście nie jesteśmy przeciwnikami dokładnego przemyślenia wyzwania oraz zrozumienia oczekiwań drugiej strony, jednak niekończące się warsztaty inicjujące start pracy lub tworzenie coraz to nowszych planów działania, mogą przynieść negatywne skutki. 

Zwykle zespoły współpracujące z klientem działają w formule iteracyjnej, a to ułatwia częstsze dostarczanie efektów pracy, do czego szczególnie zachęcamy. Nie zawsze jest to możliwe codziennie, ale warto to robić, chociaż kilkukrotnie podczas dwutygodniowej iteracji.

Przestrzegamy przed prezentowaniem tych efektów tylko podczas formalnych prezentacji, które niekoniecznie są polem do otwartej rozmowy i szczerej wymiany opinii. Dobrym pomysłem może być zaangażowanie osoby reprezentującej klienta do ściślejszej współpracy i częstszej, nawet codziennej, komunikacji.

My często działamy tak, że codziennie spotykamy się na kilkanaście minut z klientem, poruszamy najbardziej aktualne tematy, zbieramy feedback, patrzymy czy zmierzamy w dobrym kierunku. Już sama dyskusja bazująca na zwykłej makiecie może być cennym źródłem informacji, co do dalszych działań. Klient widzi, że jest słuchany i ma wpływ na tworzony dla niego produkt. 

Poniekąd porada ta stoi w sprzeczności z poprzednią, gdyż chcemy tutaj podkreślić, aby klient dostawał już coś namacalnego i funkcjonalnego. Pokazywanie pracy wykonanej głównie po stronie back-endu, która nie ma przełożenia na to, jak ostatecznie będzie wyglądał lub działał produkt, faktycznie będzie budować zaufanie, ale pewnie nie da klientowi żadnej wartości, zwłaszcza jeśli nie jest on developerem.

Dlatego trochę empatyzując z klientem i tym na co czeka, sugerujemy aby postarać się, jak najszybciej stworzyć coś co będzie chociaż w małym stopniu przypominać efekt docelowy. Może to być mocno uproszczona wersja, ale już zbliżająca się się do tego, co klient wyobraża sobie uzyskać. Dzięki temu rozpoczynają się ciekawe rozmowy o finalnym kształcie i doświadczeniach podczas korzystania z produktu.

Takim częstym antywzorcem współpracy między software housem a zamawiającym, jest opowiadanie o tym, jak projekt jest zarządzany, a nie o tym, co w ramach tego zarządzania powstało. Klient czeka na produkt, a nie na informacje o tym, jak planujecie prace, jakie spotkania się odbyły, czy jak często podsumowujecie w zespole postępy prac. Podobnie nie jest potrzebne prezentowanie schematu bazy danych, które faktycznie może zbudować poczucie złożoności projektu, jednak pytanie, czy to przyniesie jakąkolwiek korzyść obu stronom.

W przypadku klienta, który nie zna się zbyt mocno na kwestiach technicznych, może mieć on potrzebę pewnego wglądu w to, jak przebiega praca w zespole, który działa nad jego produktem. Można mu pokazać to poprzez np. prezentację tablicy scrumowej lub kanbanowej zespołu, na bieżąco informowaniu o etapach pracy czy krótkoterminowych planach oraz o potencjalnych ryzykach oraz dostęp do Backlogu Produktu.

Jest to o tyle ważne, że klient często jest setki lub tysiące kilometrów od software house, musi wierzyć w to, co usłyszał na rozmowie sprzedażowej i płacić faktury, a koniec końców niewiele widz, i co się dzieje. Dlatego uważamy, zwłaszcza na początku współpracy, warto być w pełni transparentnym. 

Nasza praktyka pokazuje, że udowodnienie na wczesnym etapie, że często dostarczamy gotowe rzeczy, że wszystko jest klarowne i przejrzyste, a ryzyka są natychmiast komunikowane, sprawia, że w pewnym momencie klient przestaje się interesować niskopoziomowymi kwestiami, zaczyna ufać, że prace trwają i zaczyna się skupiać na faktycznych rezultatach bez wgłębiania się w proces wytwórczy.

Klient nie musi się znać na funkcjonowaniu zespołów w software house, dlatego warto, aby poznał osoby, które dla niego pracują, czym się zajmują, na jakim są poziomie eksperckości w danym temacie. Dzięki temu wzmocnimy relację, klient będzie wiedział z kim się kontaktować i dlaczego się z tą, a nie inną osobą.  Dobrą praktyką jest też informowanie o urlopach lub dłuższych zwolnieniach lekarskich członków zespołu i kto daną osobę zastąpi. 

Budowanie zaufania to proces ciągły, który wymaga zaangażowania i konsekwencji ze strony wszystkich zaangażowanych stron. Stosując się do naszych rekomendacji, firmy mogą znacząco poprawić swoje relacje z klientami, co przełoży się na większą satysfakcję obu stron, wydajniejszą współpracę i wyższe wyniki biznesowe.

Miej z tyłu głowy jednak, że zaufanie nie jest czymś danym raz na zawsze. Wymaga ono pielęgnacji i ciągłego potwierdzania. Ważne jest, aby reagować na potrzeby klienta w sposób terminowy i profesjonalny, rozwiązywać problemy w sposób konstruktywny i zawsze dążyć do przejrzystości.

Jacek: Prowadziliśmy ostatnio wspólnie z Kubą warsztaty dedykowane dla firmy typu software house. Pośród poruszanych tematów jednym z nich było zaufanie, które budujemy z klientem zewnętrznym. Uznaliśmy z Kubą, że jest to na tyle ciekawy temat, że chcemy się nim z tobą podzielić.

Kuba: Temat jest bardzo dookreślony do pewnej konkretnej grupy firm, ale czuję też, że będzie to dosyć ciekawa inspiracja również dla osób czy firm, które nie mają tej relacji klient-dostawca. No bo jak odpowiednio zmrużyć oczy to relacje między wewnętrznym IT w bardzo dużej korporacji a jakimś biznesem, partnerami czy innymi rynkami z innych krajów mogą być bardzo, bardzo bliskie na tyle, że duża część z naszych rekomendacji również będzie inspiracją, nawet jeśli w twoim konkretnym przypadku nie jesteś częścią software house.

Kuba: Odcinek będzie miał spis treści, bardzo krótki. Zaczniemy od zdefiniowania zaufania, żebyśmy wiedzieli, o czym w ogóle to mówimy. Po czym podamy cztery przykładowe aspekty budowania zaufania w software house.

Jacek: Startując, spróbujmy zdefiniować czym jest zaufanie. Jest to pewne przekonanie, że można na kimś polegać, że ta konkretna osoba będzie postępować zgodnie z naszymi oczekiwaniami, wyobrażaniami, wartościami i będzie wywiązywać się z jakichś zobowiązań.

Kuba: Moja definicja zaufania jest ciutkę inna w niuansach. Dla mnie zaufanie to jest wiara w przewidywalność zachowań osoby, z którą mam relacje zaufania. Takie zaufanie bazuje albo na wiarygodności, lub na dotychczasowych dobrych doświadczeniach współpracy z tą konkretną osobą.

Jacek: No i w realiach pracy w firmach typu software house zaufanie to jest coś, co chcemy pielęgnować, coś, co chcemy rozwijać z tego względu, że jest to bardzo istotna i ważna płaszczyzna, która buduje bardzo przyjazne warunki do współpracy.

Kuba: To przejdźmy do zasadniczej części nagrania, w której powiemy, jak można takie zaufanie budować. I podzieliliśmy to na cztery aspekty, cztery takie grupy pojęciowe, w których mamy konkretne rekomendowane praktyki, czy konkretne podpowiedzi jak to zaufanie budować.

Kuba: Pierwszym tym aspektem jest wiarygodność. Jak można budować wiarygodność w tym konkretnym kontekście?

Jacek: Pierwsza rekomendacja w obszarze wiarygodności brzmi: Spełniaj złożone obietnice. Jest to dosyć pojemny punkt, pod który można podpiąć wiele różnych zachowań. No ale na koniec dnia chodzi o to, że jeżeli obiecamy, że coś zrobimy, że coś zrealizujemy, że czegoś dopilnujemy, no to tak naprawdę powinniśmy zadbać o to, żeby ta złożona obietnica została, mówiąc potocznie, dowieziona. Czyli przykładowo, jeżeli obiecaliśmy klientowi, że przygotujemy draft projektu i umówiliśmy się, że ten draft projektu wyląduje u klienta na skrzynce mailowej do jakiejś konkretnej daty, czy do jakiejś konkretnej godziny, no to spełnieniem złożonej obietnicy jest oczywiście wywiązanie się z takiej obietnicy.

Kuba: I tutaj te złożone obietnice, dowiezione, jak to powiedziałaś, budują takie wrażenie niezawodności, budują też takie przeczucie, że mogę na tobie polegać. Mogę polegać na Twoim zespole, mogę na Tobie polegać jako części firmy. Mogę polegać jako na przykład klient zewnętrzny na Twojej firmie jako dostawcy. Takim najmocniejszym przykładem i takim bardzo też często do poprawy zagadnieniem jest przewidywalność działań. Czyli zespoły, które pracują nad jakimiś działaniami projektowymi, czy rozwojowymi dla klienta mogą składać obietnicę, czy obiecywać, czy projektować, czy przewidywać, że coś zrobią, dostarczą jakiś ficzer na jakąś datę, dostarczą zawartość Sprintu albo Cel Sprintu, jeśli pracują z Scrumem, po czym te obietnice nie są dostarczane i to nie są dostarczane w taki, bym powiedział, spektakularny sposób. To nie buduje zaufania. Czyli odwracając, częścią zaufania jest składanie obietnic, które później mają pokrycie i robienie wszystko, żeby to dowiezienie potocznie mogą właśnie uzyskać.

Jacek: Przewidywalność jest czymś, czego na bazie naszych doświadczeń firmy poszukują, dlatego robimy takie programy, w których pomagamy poprawić przewidywalność procesu wytwarzania. Przykładowo jednego z moich klientów dzięki takiemu wsparciu, które trwało 3 miesiące, zespół poprawił przewidywalność z 43% do 78%. Więc jeżeli temat przewidywalności jest dla Ciebie ważny, to zachęcamy do kontaktu przez formularz na stronie porzadnyagile.pl/kontakt

Kuba: Drugim zagadnieniem, które wspomnimy w temacie budowania zaufania poprzez wiarygodność, jest komunikowanie w przewidywalny sposób. Chodzi tu o to, by komunikacja dowolnego typu, czy to taka bardzo operacyjna, niskopoziomowa, jak i ta najwyższego rzędu, taka firma do firmy, czy liderzy projektu do liderów dostawców, była przeprowadzona w pewnym standardzie jakościowym, jeśli chodzi o po prostu zawartość tej komunikacji, punktualność, responsywność i taka szeroko rozumiana spójność o pewnej obietnicy na temat rzetelności partnera.

Jacek: No byłoby źle, gdyby klient piszący do nas maila musiał na odpowiedź czekać jakoś długo albo w taki nieprzewidywalny sposób długo. Czyli jeżeli cały czas odpisywaliśmy szybko i nagle bez podania jakiejś sensownej przyczyny przestajemy odpisywać albo raz jest szybko, raz jest ten czas oczekiwania wydłużony, może to powodować takie poczucie, że nie do końca klient może na nas polegać, bo raz robimy tak, raz robimy tak i tak naprawdę nie ma sensownego wytłumaczenia. Pewnym rozwiązaniem tego problemu może być na przykład jakaś informacja wyprzedzająca do klienta, że rozpoczyna się jakieś działania w naszej organizacji czy w zespole, która może obniżyć responsywność. Przykładowo wyjeżdżamy na wyjazd integracyjny, czy jest jakaś impreza, która dzieje się w organizacji no i po prostu nie będziemy odpisywać tak, jak to zwykle robiliśmy. No jakby tutaj jasność tego, zakomunikowanie tego z wyprzedzeniem, co jak słyszysz jest dosyć prostą generalnie techniką, może zmienić postrzeganie tego jak my się zachowujemy w oczach naszego klienta.

Kuba: I użyliśmy przykładu maila, ale to tak naprawdę jest komunikacja dowolnego typu, zarówno komunikacja taka bezpośrednia lub pośrednia, ale na spotkaniach jakieś wideo, jak i komunikacja na chatach, czy komunikacja w narzędziach do pracy elektronicznej. Wszędzie te zasady tutaj spójności i przewidywalności tego, czego się można po naszym zespole, po każdym ze specjalistów w jego skład wchodzącym, czego się można spodziewać, żeby to było do jakby przewidzenia i żeby to było w miarę w spójny sposób dostarczone.

Jacek: Mówiliśmy o wiarygodności, teraz przejdziemy płynnie do aspektu komunikacyjnego i w tym obszarze przede wszystkim myślimy o takiej rekomendacji, żeby informować o ryzykach i o problemach na bieżąco. Na bazie moich doświadczeń w pracy w software house’ie myślę, że ona nie ma niczego gorszego niż postawienie klienta w takiej sytuacji, gdzie o konkretnych problemach dotyczących jego projektu dowiaduje się gdzieś tam na końcu i niestety bywałem świadkiem takich sytuacji. Najczęstszy komentarz, który słyszy się wtedy od klienta, to jest coś w stylu „Przecież mogliście powiedzieć mi to wcześniej, dlaczego tego nie zrobiliście?”. Zespół zwykle reaguje czymś w stylu „Myśleliśmy, że się uda”, albo „Nie chcieliśmy denerwować klienta” i jakieś takie tam różne. Różne mogą być powody. Natomiast to zawsze ma krótkie nogi, w sensie to nigdy nie jest dobry pomysł, żeby takie rzeczy zataić, więc budowanie komunikacji, która zarówno niesie pozytywne informacje, jak i wszelkiego rodzaju ryzyka, zagrożenia, rzeczy, które nie wyszły, jest bardzo istotnym fundamentem budowania długofalowego zaufania z klientami.

Kuba: Ja w relacji klient-dostawca o wiele częściej jestem po stronie zamawiających i to też jest często bardzo gołym okiem widoczne, że te tak naprawdę obietnice, że wszystko jest dobrze, że nie ma problemów, że idzie dobrze, że sobie poradzimy, że się gdzieś tam wyrobimy, to już z mowy ciała, to już z mikrozawahań pomiędzy zdaniami już wynika, że coś się zaczyna śmierdzieć. No ale tak naprawdę jest jakaś taka, zwłaszcza przy rozpoczynającej się współpracy, jakaś taka niepewność, co do tego jak zachowa się druga strona, a myślę, że jednak my tutaj obaj mocno rekomendujemy, zbuduj tę rzetelność na wczesnym ostrzeganiu, na jasnym powiedzeniu jak sprawy się mają. Coś, co może być też nawet wręcz taką ważną postawą, taką partnerską wspólnego rozwiązywania pewnych problemów, zwłaszcza jeśli jakieś nadciągające ryzyka są tak naprawdę do rozwiązania obustronnie. Czyli jakąś tam porcję pracy ma do wykonania zespół wykonawczy, ale być może jakąś część działań jest po stronie klienta i im wcześniej się zacznie o tym szczerze rozmawiać, tym większa szansa, że dla wspólnego sukcesu rozwiąże się to szybciej. No albo niestety w tym alternatywnym scenariuszu, tak się dosyć szybko zepchniemy w taką przepychankę, że wasza wina, nasza wina, nie powiedzieliście nam i to już źle wróży na dalszą współpracę.

Kuba: Druga kwestia związana z komunikacją, którą rekomendujemy, to „Dziel się informacją zwrotną”. Tutaj też to wzajemne zaufanie budowane jest poprzez takie dotarcie się, a to dotarcie się oczywiście będzie budowane na bazie informacji zwrotnej. I nie mamy na myśli tutaj tylko i wyłącznie mówienie sobie, co mogłoby się poprawić, ale również takie docenianie się wzajemne na to, co działa, co doceniamy, co nam pomaga, co sprawia, że ta relacja buduje się coraz lepiej. Jest na to szereg konkretnych praktyk, które tutaj zaraz Jacek kilka wymieni.

Jacek: Tak, bo przede wszystkim myślę, że to jest tak, w zależności od tego, jak blisko jesteśmy z klientem, jak formalna bądź nieformalna jest ta relacja, no to te formy mogą przybierać no najróżniejszą postać. Myślę, że taka najbardziej oficjalna to jest forma pisana, ona może się pojawić no najczęściej w formie właśnie jakiegoś maila, czy to na chatach rzadziej takie rzeczy spotykałem, no i ona ma swoją jakąś tam wartość niewątpliwie. Natomiast pewnym minusem jest to, że dostajemy bardzo suchy komunikat, no i jakby sporo zależy od tego, jak go zinterpretujemy. Jeśli nałożymy na to filtr kulturowy, no to np. informacja zwrotna pochodząca od osób z Londynu może brzmieć bardzo dobrze, a tak naprawdę wcale nie, tak bardzo dobrze nie jest. Więc pod okrągłymi słowami mogą kryć się czasem rzeczy, których no nie wyłapiemy na pierwszy rzut oka. No i z tej perspektywy feedbackowanie słowne, bardziej na zasadzie rozmowy, czy to rozmowy wideo, czy rozmowy audio, idealnie jak jest to jest rozmowa face to face, no bo oczywiście wtedy trochę więcej sygnałów możemy odczytać, no jest lepsza, można dopytać, można sparafrazować, można poprosić o jakiś konkretny przykład. Tak więc takie myślę, że dwie najprostsze formy, które mi przychodzą do głowy tutaj mają miejsce, mogą też się pojawić formuły takie wynikające być może ze sposobu, w jaki pracujemy. Czyli na przykład sensownym miejscem na porozmawianie o tym, co nam działa, co nam nie działa, no jest oczywiście wydarzenie typu Retrospektywa, czy jakieś warsztaty usprawniające, jakkolwiek sobie to nazwiemy, gdzie na temat informacji zwrotnej, na temat tego jak się nam pracuje, możemy spojrzeć w bardzo różny sposób i z wielu różnych perspektyw.

Jacek: Trzeci aspekt, który ma wpływ na budowanie zaufania z klientem to proces deweloperski, czyli proces wytwarzania. Pierwsza rekomendacja z tego obszaru brzmi, jak najwcześniej oddawaj działający produkt. Klient przychodzi do nas zwykle z pewnym problemem, ma jakąś konkretną potrzebę, chce coś zrealizować. Im wcześniej pokażemy, że potrafimy wytworzyć coś namacalnego, tym większa jest szansa, że klient zbuduje sobie wyobrażenie, że ok, ta firma faktycznie mówiła, że to zrobi i dostaje pierwsze namacalne rezultaty. Mogę to zobaczyć, mogę to być może kliknąć, mogę to przetestować, oczywiście rozumiejąc, że nie jest to nic finalnego, doskonałego, skończonego, ale pokazuje, że jednak pewne klocki jesteśmy w stanie połączyć. Chociażby taką prozaiczną rzecz jak to, że ten zespół, który pracuje na rzecz klienta, potrafi się dogadać, no i te wszystkie elementy front-endowe, back-endowe, jakościowe, być może tam jest jakiś UX, który też jakiś design proponuje, potrafią połączyć w sensowną i w logiczną całość.

Kuba: Ta nasza rekomendacja wynika z definicji, z tej części związanej z takim poczuciem przewidywalności, poczuciem tego, że można polegać na danej, drugiej stronie. No i tutaj to budowanie zaufania wprost wynika z tego, że po prostu zaczynamy udowadniać jako dostawca, że umiemy to dostarczyć, że to, co tworzymy faktycznie, ma konkretną postać. To też jest po prostu jak najwcześniej danie okazję do tego, żeby też się dopasować czy dogrzać te nasze zasady komunikacji, o których wspomnieliśmy też już chwilę temu. Natomiast rekomendacja ma też swoją taką jakby odwrotną stronę. Zdecydowanie nie polecamy zbyt długiego trzymania się w jakichś fazach jakiegoś Sprintu Zero, fazy incepcji, czy czegokolwiek, co tak kojarzy się z długimi dywagacjami, z których niewiele wynika. I to nie jest tak, że jesteśmy przeciwni przemyśleniu dobrze, co jest do zbudowania, albo dobremu zrozumieniu, co druga strona oczekuje, ale może być tak, że przekiszenie się na niekończących się warsztatach, budowanie jakichś kolejnych planów, Exceli, dokumentów, cokolwiek, co nie ma namacalnej postaci działającego produktu, po prostu będzie odwróceniem takiego ostatecznego testu, czy faktycznie się rozumiemy. Więc jeśli produkt jest bardzo złożony, to owszem duża pula takich prac związanych z budowaniem zrozumienia jest potrzebna, ale i tak dążmy do tego, żeby w najlepszym razie to było coś, co jest zrównoleglone. Bardzo podstawowa funkcja, chociaż pierwszy krok, pierwszy ekran, jakaś taki podstawowy, pierwszy przypadek użycia i równolegle budowane, bardziej rozbudowane elementy tego, co jest tam faktycznie do zrobienia.

Kuba: Druga nasza rekomendacja to „Pokazuj efekty pracy częściej niż na Demo”. Wiele zespołów działających z klientem pracuje w jakiejś formule iteracji, niektórzy nazywają to Sprintem, niekoniecznie jest to zgodne ze Scrumem, ale nie o tym będzie ten odcinek. Natomiast coś, do czego zachęcamy to to, żeby zbudować sobie taką relację z klientem i tak ustawić sposoby działania samego zespołu, żeby efekty pracy były pokazywane jak najczęściej, być może codziennie, jeśli to jest nierealistyczne, to chociaż kilkukrotnie w ciągu na przykład dwutygodniowej iteracji. Żeby nie było tak, że klient jest zaskakiwany elementami dostarczonymi dopiero na jakiejś formalnej prezentacji. Te formalne prezentacje też często nie są najlepszym środowiskiem do szczerej rozmowy, dobrego wniknięcia, o co chodzi. One często są takie dosyć poważne. Więc tutaj zwłaszcza z takimi osobami, które są jakiegoś rodzaju reprezentantem klienta współpracującym z naszym zespołem, zaciągnijmy je do takich krótkich pętli może codziennych, jak wspomniałem, tak żeby ewentualny też feedback albo dobre zrozumienie budować sobie jak najkrótszymi odcinkami czasowymi.

Jacek: I czasem przybiera to formułę taką, że mamy jakiś codzienny catch up z klientem, gdzie zwykle rozmawiamy o pewnych tematach, no i jeżeli to ma sens i mamy coś namacalnego i czujemy, że to jest ten moment właśnie, kiedy klient mógłby ręką pokazać w prawo czy w lewo, albo wypowiedzieć się, czy to jest tak jak sobie to wyobrażał, no to po prostu możemy czy udostępnić ekran, jeżeli pracujemy zdalnie, czy po prostu wyświetlić to na jakimś ekranie, jeśli akurat jesteśmy stacjonarnie, czy u klienta, czy u nas w software house’ie. No i po prostu porozmawiać o tym, skomentować to. I tak jak przed chwilą Kuba słusznie mówił o tym, żeby pokazywać działający produkt, no to tutaj z mojej perspektywy ma sens pokazanie nawet, nazwijmy to, jakichś półproduktów. Czyli podyskutowania o makiecie, może mieć sens, w sensie im wcześniej dostaniemy feedback, tym lepiej. Pokazanie nieskończonego front-endu też może być inspiracją do rozmowy, oczywiście tłumacząc klientowi, że to co widzi, no to jest tylko nazwijmy to jeszcze jakaś wydmuszka, coś co nie jest kompletne, żeby z drugiej strony nie budować poczucia, no przecież przed chwilą mi pokazywaliście, widziałem mój produkt – na zasadzie wydawało mi się, że to jest mój produkt, a teraz mówicie, że jeszcze miesiąc czy dwa będziemy budować jakiś back-end, jakieś rzeczy z tyłu. Więc jakby to ma sens, może być wartościowe, może wzbudzać zaufanie. Na zasadzie pytają się mnie jako klienta, w którą stronę skręcić. Fajnie mam poczucie, że mam wpływ, no ale jednocześnie warto tutaj jakieś takie minimalne wprowadzenie do tego jak tworzy się w ogóle software, no klientowi taką pigułkę po prostu zapewnić.

Jacek: Ostatnia porada w aspekcie procesu deweloperskiego brzmi „Dostarczaj kompletne, przekrojowe funkcje”. I stoi to trochę w sprzeczności z tą poprzednią poradą, bo tutaj jednak chcielibyśmy podkreślić z Kubą, że zależy nam na tym, żeby klient dostawał coś namacalnego, funkcjonalnego, konkretnego. Czyli pokazywanie czy dostarczanie rzeczy totalnie back-endowych, które nie mają żadnego przełożenia na to jak faktycznie będzie ostatecznie działał produkt, może wzbudzać zaufanie, na zasadzie deweloperzy mogą mieć poczucie, że to jest już coś, co pokazują, ale klient, on tam może widzieć jakieś krzaczki, ptaszki, jak nigdy nie napisał linijki kodu. No to po prostu to może nie mieć wartości. Więc trochę empatyzując z klientem, on jednak się spodziewa zobaczyć coś, co będzie w zgodzie z jego wyobrażeniem, nie wiem, aplikacji, produktu, w zależności czy to jest fizyczne, czy to jest software. Może to jest połączenie hardware’u i software’u? Więc jednak dążyłbym do tego, żeby jak najszybciej uzyskać taki efekt docelowy, nawet jeżeli pewne rzeczy są jeszcze uproszczone, zamockowane, nieskończone, żeby bazować na czymś, co maksymalnie przybliża nas do finalnego produktu. Bo to wtedy uruchamia ciekawe rozmowy na temat pewnego całego kształtu i takiego doświadczenia, które płynie nam, kiedy korzystamy z tego produktu.

Kuba: Powiedziałeś Jacek o empatyzowaniu z zamawiającym i sam tutaj wielokrotnie jestem po stronie zamawiającego, który współpracuje z jakimś dostawcą. No i niestety zdarzają się dwa takie antywzorce. Jeden antywzorzec jest taki bardziej zarządzania projektami, gdzie pokazywane są wykonane działania i tam jakieś długie opowieści, ruszenie rękami i parę slajdów na temat tego, jak już bardzo zbliżyliśmy się do rezultatu. Jak już naprawdę mamy wszystko dobrze zaplanowane, poprojektowane, odpowiednie spotkania odbyte. Ale tak naprawdę w ogóle jeszcze nie powstało żadne rozwiązanie, albo ono nie jest ukazywane. No i choć może być wrażenie, że dużo ruszenia rękami właśnie się odbyło, jakieś fajne show, no to tak naprawdę to zaufanie zbudowane zostanie, jak będzie rezultat. A druga rzecz, która też czasami jest pokazana, to na przykład dobry schemat bazy, albo parę diagramów, gdzieś tam modelu danych. No i to też znowu wygląda nieźle, buduje wrażenie jakiejś złożoności. Być może wypełni całe spotkanie pokazujące – no pracowaliśmy, namęczyliśmy się, już jesteśmy kroczek bliżej rezultatu. No, ale to nie o to nam tu chodzi. Jednak mocno, mocno tutaj rekomendujemy takie podzielenie produktu, takie podzielenie zakresu tych efektów, żeby pokazać, chociaż jeden prosty przypadek, ale jednak cały. Pokazać się pewien ekran, czy pewien proces end to end, nawet jeśli nie ma jeszcze wszystkich przypadków brzegowych. I też być może niektórych klientów wręcz nauczenie tego, że to nam pozwala jakby rozbudowywać. To też pokazuje jakieś pierwsze przybliżenie, czy się w ogóle rozumiemy. No bo prawdopodobieństwo, że dobrze zinterpretują model danych, albo schemat bazy danych jest o wiele mniejsze niż to, że dobrze zinterpretują, że no ale my tu inaczej chcielibyśmy klikać ten proces, no i na wczesnym etapie ewentualnie odkryjemy jakąś pułapkę, no albo odkryjemy jakieś wymagania, które nie były wyrażone, a jednak są dla klienta superważne i wiemy o tym najwcześniej jak to możliwe.

Kuba: I ostatni aspekt związany z budowaniem zaufania jako software house, to transparentność. Tutaj wymienimy dwa konkretne zagadnienia. Pierwsze to: „Zapewnij przejrzystość procesu wytwórczego”. Zwłaszcza klient, który nie jest fachowy, nie jest techniczny, może po prostu bardzo, bardzo potrzebować takiego pewnego rodzaju wglądu w to jak wyglądają prace w konkretnym zespole. Prace poprzez pokazanie na przykład tablicy scrumowej lub kanbanowej tego zespołu. Informacje takie w stylu Daily, co dzisiaj robimy, nad czym dzisiaj pracujemy, co jest ewentualnie w planach na kolejny jakiś tam krótki okres. Może też jakie mamy problemy, to by nawiązywało do tego przejrzystego informowania o ryzykach. No, a jeśli pracujemy na jakimś artefakcie typu Backlog Produktu, czy jakiś plan prac, czy plan zakres kolejnego wdrożenia, to również jasny, jawny i zrozumiały wgląd tego typu narzędzia. Tak, żeby klient po prostu widział pewnego rodzaju trybiki i widział, że te trybiki się kręcą i idą do przodu.

Jacek: Ktoś może mieć takie poczucie, że czy nie, aby nie schodzimy zbyt nisko poziomowo, co robimy dzisiaj, co robimy jutro. Ja myślę, że to warto pamiętać, że klient często jest tysiące kilometrów od nas i tak naprawdę oprócz jakichś tam obietnic, tego, co usłyszą na rozmowie sprzedażowej, tego, co mówi mu jakiś tam key account, to tak naprawdę niewiele widzi. Jeżeli dołożymy do tego sytuację, w której nie dostaje namacalnych rezultatów, no to wejdźmy w buty klienta. Płaci, przychodzą faktury, ale tak naprawdę nie kształtuje się poczucie, że te pieniądze zamieniają się w jakiś tam rezultat. Więc myślę, że w szczególności na początku warto pokazać pełną transparentność, zrozumieć z jakimi obawami może przychodzić klient. Natomiast praktyka mi pokazuje, że udowodnienie na wczesnym etapie, że często dostarczamy gotowe rzeczy, że wszystko jest transparentne, jasne, szybko wychodzą ryzyka, powoduje, że klient w pewnym momencie przestaje się tak super nisko poziomowo interesować, no bo te obawy pierwotne po prostu okazują się nieprawdziwe no i wtedy skupienie bardzo łatwo przenosi się już na te faktyczne rezultaty. 

Jacek: Drugą rekomendacją w zakresie transparentności to rekomendacja brzmiąca „Zadbaj o jasny skład zespołu”. Coś, co z perspektywy software house’u jest zwykle jasne, na zasadzie dla projektu X czy dla klienta Y pracują te konkretne osoby, wcale nie musi oznaczać, że klient ma takie poczucie. Może mieć takie wrażenie, że jest tam po prostu jakiś taki black box. Nie wiadomo jak to pudełko funkcjonuje, no i co jakiś czas to pudełko coś tam pokazuje, pojawiają się jakieś rezultaty. Jakby stąd informacja, ile mamy osób w zespole, jaki jest poziom tych osób, czy to są juniorzy, seniorzy, albo może jaka jest proporcja tych ról, czy mamy QA, czy nie mamy, czy mamy UX? A w jakim wymiarze? Kto czym się zajmuje? No są to absolutnie podstawowe informacje, które no uważam, że gdzieś już na początku w ogóle tego procesu współpracy powinny się pojawić do tego stopnia, że tak naprawdę klient powinien te osoby zobaczyć fizycznie. Jakby poznać się z imienia, przedstawić, powiedzieć dwa zdania. No po to, żeby zmaksymalizować to poczucie, że faktycznie po drugiej stronie jest mój zespół czy zespół, z którym pracuję. No bo w dobrej relacji będzie tak, że klient może się bezpośrednio zwracać do konkretnych osób, no i dobrze tak naprawdę, żeby nie było zaskoczenia, że próbuję złapać Tomka i odkrywa, że Tomek się zwolnił, albo że Tomek pracuje w innym projekcie, albo odkryć, że pracuje w dwóch projektach. No myślę, że nie są to rzeczy, które chcielibyśmy, żeby klient ich doświadczył znienacka.

Kuba: No i właśnie to zagadnienie związane z dostępnością, przykładowego Tomka, to też jest cząstka tej naszej rekomendacji o jasnym składzie zespołu. Sam też byłem świadkiem takiej sytuacji, gdzie właśnie przykładowy Tomek zaczął jakoś bardzo nieprzejrzyście w czasie spotkania tłumaczyć, że tam miała jakiś inny projekt, który właśnie zaczyna, szykuje, no i wszyscy w szoku, wszyscy wręcz właśnie też tak zdegustowani, no bo tutaj kluczowy programista projektu nagle zaczyna być niedostępny, nie wiadomo co chodzi, znika. W zasadzie to nie wiadomo, czy my upłacimy mu za ten jutrzejszy dzień, co on zapowiada, że go tam nie będzie. Więc tutaj, nawet jeśli faktycznie następują jakieś zmiany osobowe, to również częścią budowania tej przejrzystości jest również bardzo szczere sygnalizowanie co się dzieje, jak się dzieje oraz no, jeśli faktycznie następuje pewna zmiana, być może zupełnie poza naszą kontrolą, bo na przykład przykładowy Tomek postanowił kontynuować karierę w jakiejś innej organizacji, no to chociaż za sygnalizowanie, w jaki sposób zostanie przeprowadzone przekazanie wiedzy oraz obowiązków, tak żeby następca wspomnianego Tomka też mógł być rzetelnym członkiem zespołu projektowego, którego dostarczamy naszemu zamawiającemu.

Jacek: I tym sposobem zbliżamy się do końca tego odcinka. Podsumowując, jak możesz budować zaufanie jako software house? Spełniaj złożone obietnice. Komunikuj się w przewidywalny sposób. Informuj o ryzykach i problemach na bieżąco. Dziel się informacją zwrotną.

Kuba: Jak najczęściej oddawaj działający produkt. Pokazuj efekty pracy częściej niż na Demo. Dostarczaj kompletne przekrojowe funkcje. Zapewnij przejrzystość procesu wytwórczego i zadbaj o jasny skład zespołu.

Jacek: Jeśli chcesz podnieść zadowolenie klientów Twojego software house’u, to robimy z Kubą dedykowane warsztaty, w których przepracowujemy kwestie podobne do tych, które poruszliśmy w tym odcinku. Odezwij się do nas poprzez stronę porzadnyagile.pl/kontakt, jeśli chcesz tego typu warsztaty przeprowadzić w swojej firmie.

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

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

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.

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.

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”

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:

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.

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.

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?”.

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: 

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.

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.

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.

Czy Scrum Masterzy rzeczywiście słabo wykonują swoją pracę? Co daje nam największy napęd w szerzeniu “zwinności”? Czy agile umiera? Słuchacze pytają, a my odpowiadamy. W pierwszej rozmowie z cyklu Q&A wybraliśmy osiem pytań od naszych słuchaczy i odpowiedzieliśmy na nie.

Pytania te dotyczą różnych aspektów zwinności, od codziennych praktyk po zarządzanie zespołem i skalowanie. Nie są to wszystkie, które otrzymaliśmy, gdyż było ich bardzo dużo. W niedalekiej przyszłości wybierzemy kolejne kilka pytań, aby odpowiedzieć na jak najwięcej z nich.

Spis treści

• Jak monitorować i prezentować zespołowi codziennie Action Pointy z Retro w pracy zdalnej?
• Co daje Wam największy napęd („drive”) w szerzeniu zwinności?
• Jaka jest rola Scrum Mastera w procesie Release w Scrumie?
• Co w sytuacji, gdy Product Owner nie chce interesariuszy na Review, „bo nie ma co pokazać”?
• Czy obserwujecie, że wielu Scrum Masterów słabo wykonuje swoją pracę?
• Z jakich powodów agile umiera?
• Jak przekonać firmę do deskalowania zamiast skalowania, gdy nie ma do tego warunków?
• Jak pracować z ludźmi posiadającymi waterfall’owy mindset? 
• Transkrypcja podcastu „Q&A cz.1”

W pytaniu tym widzimy pewne założenie, że wcześniej, czyli przed pracą zdalną takie akcje usprawniające były monitorowane. Drugą rzeczą, która rzuciła nam się w oczy to, przeświadczenie, że za monitorowanie i prezentowanie akcje usprawniające odpowiada jedna osoba. Czy zawsze jest to Scrum Master lub lider? Z tym drugim założeniem nie do końca się zgadzamy. Naszym zdaniem odpowiedzialność tego typu powinna spoczywać na całym Zespole zwinnym.

Nim przejdziemy do propozycji monitorowania i prezentowania Action Pointów, warto zastanowić się, gdzie leży problem. Dlaczego teraz to sprawia trudność? Być może problem tkwi w ich sformułowaniu – jeśli są one jasne i precyzyjne, łatwiej je zrealizować i monitorować.

Ponadto być może jest ich za dużo, skoro muszą być monitorowane? Warto zastanowić się, czy wszystkie ustalenia są niezbędne i czy nie można ich zredukować do najważniejszych.

Jak prezentować i śledzenia akcje usprawnieniowe?

Co ważne, zachęcamy, aby nie porzucać spotkań i działań usprawniających, gdyż są one kluczowe dla rozwoju zespołu.

Pewnie nie odważylibyśmy się zrobić całego materiału na ten temat, ale nasza odpowiedź może być pewną inspiracją dla Ciebie.

Dla Kuby fascynujące jest to, że zwinność pozwala łączyć korzyści biznesowe z dobrymi warunkami pracy dla zespołów. Biznes jest zadowolony, bo agile daje profity, a jednocześnie członkowie zespołu lepiej działają, bo są częścią prawdziwego zespołu. Wszyscy skupiają się na konkretnych rzeczach, co zapewnia lepsze warunki pracy i jednocześnie daje namacalne rezultaty dla organizacji.

Patrząc historycznie, praca w zespole bez poczucia celu i w izolacji biznesowej była frustrująca. Zwinność stawia na bliską współpracę. Dla Jacka było to jednym z powodów, przez które zdecydował się porzucić programowanie i zajął się zarządzaniem projektami.

Co więcej, prawidłowo zastosowana zwinność daje poprawne rezultaty. Lubimy sensowne i przemyślane produkty, które działają i są porządne. Zwinność, oparta na eksperymentowaniu i wczesnym włączaniu klienta, daje właśnie takie efekty. Tworzone produkty są proste i zawierają wszystko, co jest potrzebne.

W całym pytaniu Słuchacza jest też nawiązanie do kwestii perspektyw zarobkowych. Jest to oczywiście bardzo subiektywne. Wiele zależy od tego, jak pokierujesz swoją karierą, czy będziesz się wciąż rozwijać i próbować nowych podejść. Jeśli chodzi o nas faktycznie, okazało się to dla nas opłacalne, jednak to nie zarobki były czy są głównym driverem. Spokojnie moglibyśmy pracować jako managerowie lub programiści, a zarobki może byłyby nawet lepsze. Oczywiście dzięki pracy chcemy zapewnić byt naszym rodzinom. Mieliśmy mnóstwo alternatywnych ścieżek kariery, ale tym bardziej stanęliśmy po stronie zwinności.

Warto jednak podkreślić, że agile jest wabikiem dla wielu osób, które chcą wejść do IT. Motywator finansowy jest istotny i nie można go ignorować. Natomiast w naszym przypadku nie był on decydujący.

Może panować przekonanie, że proces wdrażania produktu na środowiska docelowe jest zadaniem Deweloperów. Tym samym nie ma w nim miejsca dla Scrum Mastera. My patrzymy na Scrum Mastera jako na osobę, która odpowiada za efektywność szeroko rozumianego procesu wytwórczego. Oznacza to również fazę wdrożeniową.

Możliwe włączenie się SMa w etap release’u widzimy na parę sposobów:

Scrum Master nie musi być ekspertem od technicznych aspektów, jednak ważne jest, aby posiadał podstawową wiedzę technologiczną. Ułatwi mu to zrozumieć proces i zadawać odpowiednie pytania. Ponadto bez pewnego zrozumienia, co się dzieje, może nie być on traktowany jako równy partner w dyskusji.

Z kolei, jeśli Scrum Master twierdzi, że w jego procesie release’owym wszystko odbywa się już efektywnie, zachęcamy do odpowiedzenia sobie na pytanie: Czy mój zespół może wdrażać co 5 minut? Jeśli odpowiedź brzmi „nie”, to uważamy, że jest tu jeszcze pole do optymalizacji.

W dalszej części pytania wspomniano, że dotyczy to sytuacji, gdy “praca została wykonana, można ją zaprezentować i uzyskać feedback wcześniej niż po wypuszczeniu całości za 2 miesiące.”

Przede wszystkim należałoby się zastanowić i spróbować zrozumieć, skąd bierze się opór przed zaproszeniem interesariuszy. Powody takiego stanu rzeczy mogą być różne, np. 

Dopiero znając motywacje Product Ownera, można zaproponować konkretne wskazówki. Zwłaszcza że trudno nam wyobrazić sobie pracę Product Ownera z tak rzadkim zbieraniem informacji zwrotnej. Przecież każda decyzja produktowa to hipoteza, z którą wiąże się ryzyko błędnych wyborów.

Jakie konkretnie wsparcie może dać Scrum Master/ka w takiej sytuacji?

Pełne pytanie brzmiało nieco dłużej i w zasadzie zaczęło się od pewnej subiektywnej obserwacji:

“Mam poczucie, że wśród scrum masterów statystycznie więcej jest osób, które słabo wykonują tę pracę – w porównaniu do innych grup zawodowych. Z jednej strony to rozumiem, bo to bardzo trudna rola, która w dodatku często bywa opacznie rozumiana przez organizacje. Tym niemniej to zjawisko potrafi robić bardzo zły PR zwinności i wszystkim Scrum Masterom. Czy macie podobnie? A może zupełnie się z tym nie zgadzacie?”

Nie do końca zgadzamy się z tym założeniem. Wśród Scrum Masterów, podobnie jak w innych profesjach, można spotkać osoby o różnym poziomie zaangażowania i umiejętności. Pytanie brzmi, czy jest jakiś zawód, którego znaczna większość przedstawicieli profesjonalnie i z dużym zaangażowaniem wykonuje swoją pracę? 

Wydaje nam się, że powodami, przez który niektórzy mogą mieć poczucie braku profesjonalizmu, u większości Scrum Masterów są:

To pytanie również było dłuższe i bardziej złożone. W całości brzmi następująco:

“Dlaczego agile umiera? I dlaczego deweloperzy, gdy słyszą agile to się krzywią i uciekają? Czy biznes powinien się dostosować do procesu wytwarzania, a nie proces wytwarzania do biznesu? Czemu Scrum nie jest zwinny? Czy tylko konsultantom zwinności, agile coach’om i Scrum Masterom zależy na zwinności? Jak to się ma do krytyki postaw managerów, którzy mieli/mają być inhibitorami transformacji zwinnej, bo nie potrafili się odnaleźć w nowej rzeczywistości, gdzie nie mają narzędzi command and control nad zespołem.” 

Zatem dlaczego agile jest kwestionowane? Dlaczego zwinność budzi tak mieszane uczucia?

Po pierwsze, zwinność stała się modnym hasłem, które używane na wyrost, bez głębszego rozumienia, traci swoją pierwotną wartość. W rezultacie obserwujemy powierzchowne wdrażanie zwinnych praktyk, co prowadzi do frustracji i rozczarowania. Osoby, które miały do czynienia ze źle wdrożonym agile nie chcą tego ponownie doświadczać. W szczególności reakcję taką przejawiają osoby, które rozumieją czym zwinność tak naprawdę jest. W realiach swoich zespołów dostają tylko bardzo płytką namiastkę pracy w tym podejściu.

Po drugie, brak zaangażowania ze strony managementu utrudnia efektywne wdrażanie zwinności. Zarządzający przyzwyczajeni do tradycyjnych metod kontroli mogą czuć się zagrożeni nowym systemem. Agile bywa też traktowany jako dodatek dołożony do istniejących struktur i procesów bez ich zmiany. Dzieje się to bez faktycznego zrozumienia jak zwinność działa i dlaczego ważną częścią transformacji jest ciągła zmiana. 

Niemniej jednak, optymistycznie podchodzimy do kwestii odchodzenia od agile. Organizacje w obecnych czasach potrzebują szybkich iteracji, częstego wdrażania i ciągłego doskonalenia. Czasy, w których da się sztywno zaplanować pewne rzeczy, już minęły. Przynajmniej w pewnych branżach, a zwłaszcza w tych związanych z produktami cyfrowymi.

Podejście zwinne wraz ze swoimi wartościami będzie zawsze potrzebne. Co najwyżej będziemy je wykorzystywać jeszcze intensywniej, poprzez szybsze iteracje, częstsze eksperymenty i jeszcze bardziej dynamiczne ciągłe doskonalenia. 

Dodatkowo, zwinność nie jest panaceum na wszystkie problemy. Nie zastąpi ona kompetencji i zaangażowania zespołu. Niewłaściwie stosowana może prowadzić do chaosu i spadku produktywności.

Czy zwinność umiera? Niekoniecznie. Raczej przechodzi transformację. Doświadczenia z jej wdrażania, zarówno pozytywne, jak i negatywne, prowadzą do rewizji jej założeń i praktyk.

Czego potrzebujemy, żeby zwinność była stosowana porządnie?

Zwinność nie jest łatwa, ale jej korzyści są warte wysiłku. Szybsze wdrażanie, lepsza jakość produktu, większa motywacja zespołu – to tylko niektóre z nich. Ważne jest, aby nie skupiać się na etykietach i narzędziach, ale na wartościach i celach. Zwinność to nie tylko Scrum czy Kanban, ale przede wszystkim sposób myślenia i działania.

Przyszłość zwinności zależy od nas. Od tego jak wyciągamy wnioski z przeszłości i budujemy lepsze praktyk. I ta wspomniana w pytaniu “śmierć agile” jest w pewnym sensie pozytywnym zjawiskiem. Dalsze funkcjonowanie pseudozwinności w obecnej formule będzie się wiązać z niewykorzystanymi możliwościami, jakie agile naprawdę daje. Trudno o lepsze techniki czy podejścia w obecnym świecie VUCA i BANI. W realiach wielu firm i branż jest mnóstwo nieprzewidywalności, kruchości, niejasności, nieliniowości i niepewności.

Wstępem do tego pytania był krótki opis: “Członkowie zespołu dzieleni między zespołami, często dwoma. Problem z context switchingiem jest tu oczywisty, dwukrotna ilość spotkań, firma nie widzi problemu ponieważ chcą szybko rosnąć i wg. nich obecne rozwiązanie jest konieczne.”

Domyślamy się, że mamy tu do czynienia z firmą, która jest na etapie intensywnego wzrostu. Wraz ze wzrostem firmy rośnie liczba zespołów. Jednakże, zamiast zatrudniać nowe osoby do tych nowych zespołów, angażuje się specjalistów z już istniejących. W efekcie powstają zespoły złożone z osób zaangażowanych tylko na część swojego czasu. Pół etatu działają nad jednym projektem, a pół etatu nad drugim. 

Próba deskalowania zamiast skalowania w sytuacji, gdy firma rośnie, może być trochę ryzykowna i sugerować zatrzymywanie organizacji w jej rozwoju. Dlatego rekomendujemy ostrożne dobieranie słów i ocenianie tego, jak firma rośnie. 

Być może lepszym pomysłem od deskalowania, byłoby zastanowienie się, jak najlepiej odpowiadać na bieżące potrzeby. Czy tworzenie zespołów z osób działających w nich tylko na część etatu, jest odpowiedzią na te potrzeby? Czego firma potrzebuje? Na czym zarabia? Czy obecne podejście jest efektywne? Sugerujemy przyjęcie takiej narracji, która pokaże, że chcemy usprawnić działania zespołów i pomóc organizacji podnieść jej efektywność. Wówczas sugestia, aby nie tworzyć zespołów z dużym kosztem przełączania kontekstu, będzie miała uzasadnienie. Osoba zadająca pytanie będzie mogła pokazać, że rozwiązanie to spowalnia organizację, zamiast zwiększać intensywność i szybkość rozwoju jej produktów. 

Warto jednak spojrzeć na to z drugiej strony. Ktoś podjął taką decyzję i łamana jest dobra praktyka, aby zbyt często nie zmieniać kontekstu. Może jednak stoją za tym jakieś uzasadnienia biznesowe?

Sugerujemy też zastanowić się, czy rzeczywiście wszyscy członkowie całego zespołu muszą być na wszystkich spotkaniach? Jeśli z kolei faktycznie muszą na nich być, to czy na całości? Może można dopraszać osoby, na te części, w których faktycznie są niezbędne? 

Nie znamy pełnego kontekstu tej konkretnej sytuacji i organizacji, jednak chcemy zwrócić Twoją uwagę na jeszcze jedną kwestię. Nie zawsze należy ślepo podążać za dobrymi praktykami. One najczęściej dobrze wyglądają na papierze i w stabilnych środowiskach. W dynamicznie zmieniającej się organizacji, mogą nie spełniać swojej funkcji. Dlatego w przypadku dynamicznych organizacji, lub takich, które są w okresie dużej zmiany, należy zachować szczególną ostrożność. Proste koncepcje dotyczące definicji „dobrego zespołu” i „właściwego sposobu pracy” mogą okazać się nietrafione.

W zmiennym środowisku kluczowe jest dopasowanie do kontekstu. Lepiej jest się skupić na esencji agile’a, czyli dostarczaniu wartości i iterowaniu. Nawet jeśli wymaga to odejścia od sztywnych reguł Scruma.

Pytanie dotyczy sytuacji, w której tworzony jest nowy produkt, a zespół jest jeszcze niedojrzały i nieprzewidywalny. Zespołem zarządza Product owner, a jego przełożony rozlicza każdą minutę. Mamy tu do czynienia z typowym mikromanagementem.

W takiej sytuacji, gdy przełożony drobiazgowo rozlicza czas pracy zespołu i każe sztywno trzymać się terminów, warto zastanowić się nad poziomem ugruntowania zwinności w organizacji. Czy podejście to jest spójne i rozumiane na wszystkich szczeblach? Można w tym celu porozmawiać z liderem transformacji zwinnej, aby dowiedzieć się, jak przebiega zmiana na poziomie osób zarządzających.

Warto też spróbować porozmawiać z problematycznym przełożonym. Być może zabrakło komunikacji, a ten manager zawsze pracował w ten sposób. Do tej pory to działało, więc kontynuuje swój styl zarządzania. Ważna jest empatia i zrozumienie potrzeb managera. Wyjaśnij mu zasady zwinności i pokaż, jak można uzyskać kontrolę nad zespołem bez drobiazgowego rozliczania minut. 

Pokaż mu także alternatywy, prezentując narzędzia i praktyki zwinne, które umożliwiają kontrolę nad budżetem, postępami i realizacją celów. Jednak nie trać energii na próbę przekonywania ludzi niemających ochoty być przekonanym. Wówczas eskaluj temat do wyższego szczebla zarządzania.

Można też spróbować spotkać się w połowie drogi, proponując rozwiązania, które łączą tradycyjne podejście z elementami zwinności. Ostatnią wskazówką w tym nurcie jest koncepcja adapterów. Polega ona na dostarczaniu managerowi danych w tradycyjnej formie (np. rozliczone minuty), podczas gdy zespół pracuje w zwinny sposób. To rozwiązanie tymczasowe, które daje czas na przeprowadzenie głębszej rozmowy o zwinności i wypracowanie kompromisu.

To wszystkie pytania, które wybraliśmy spośród nadesłanych. Do kolejnych odniesiemy się w późniejszym terminie. Jeśli czujesz, że jakieś zagadnienie nie zostało wyczerpane i zasługuje na pogłębienie, to daj nam znać. Być może poszerzymy konkretne zagadnienie i poświęcimy mu osobny materiał. 

Kuba: Ten odcinek to odcinek formule Q&A, czyli pytania i odpowiedzi. Pomysł na ten odcinek wynika z badania Słuchaczy, które realizowaliśmy w listopadzie i grudniu. Poprosiliśmy w poprzednim nagraniu o podsyłanie nam pytań. Dostaliśmy tych pytań bardzo dużo. Dziękujemy za ten wkład wszystkim, którzy poświęcili swój czas. Pytań jest już na tyle dużo, że dobrze wiemy, że nie przerobimy ich w jednym nagraniu. Co najmniej dwa, jak nie więcej powstaną. Więc w tym odcinku, który się właśnie zaczyna, poruszymy 8 wybranych przez nas zagadnień, które podsunęli nam Słuchacze.

Jacek: Odcinek Q&A będzie się rządził trochę innymi prawami niż nasze klasyczne, typowe materiały. Przede wszystkim formuła będzie trochę bardziej spontaniczna niż nasze tematyczne odcinki. Z drugiej strony niektóre pytania są na tyle szerokie, że żeby sprawnie przekazać to, co o nich myślimy, musimy bazować na pewnych założeniach. Te założenia nazwiemy wprost. Natomiast na pewno nie wyczerpiemy wszystkich możliwych opcji odpowiedzi. Czasem też skierujemy Cię do dodatkowych materiałów, które już w ramach nagrywania Porządnego Agile’a przygotowaliśmy.

Kuba: I ponieważ odcinek rządzi się swoimi prawami, to nie podamy spisu treści. Odcinek będzie zawierał 8 pytań od słuchaczy. One są różne od siebie. Ten spis treści w zasadzie dublowałby rozpoczęcie, więc tutaj przeskoczymy od razu do zasadniczej części. Za każdym razem zaczniemy od przeczytania pytania, krótkiej parafrazy, a później podzielimy się naszymi przemyśleniami.

Kuba: Więc pytanie pierwsze. W jaki sposób monitorować i prezentować zespołowi codziennie action pointy z Retro w dobie pracy zdalnej? 

Jacek: Czyli pytanie jest o to, jak wszelkiego rodzaju ustalone akcje usprawniające są czy powinny być prezentowane i monitorowane w przypadku zespołu, który pracuje w formule zdalnej?

Kuba: Tutaj ja słyszę w tym pytaniu trochę założenie, że przed pracą zdalną takie action pointy prawdopodobnie łatwiej się monitorowało. Sam tego typu rzeczy w pierwszym Zespole Scrumowym, w którym byłem Scrum Masterem, faktycznie np. zapisywałem na jakimś flipchartcie, w miejscu, gdzie mieliśmy Daily Scrum. Te ustalenia były takie dosyć szybko widoczne czy łatwe do przeczytania w ramach Daily i w ramach też takiej codziennej pracy. Myślę, że ta filozofia jest do przeniesienia do pracy zdalnej. Czyli poszukanie formuły, w której te same sposoby wizualizacji są odzwierciedlone właśnie w sposób zdalny. Czy to jest jakaś mapa myśli? A może to jest jakieś przypomnienie, czy to jest jakaś lista ustaleń, którą bez problemu można wyświetlać? Zwłaszcza w pracy zdalnej wyobrażam sobie, że w ramach jakiegoś dzielenia ekranu czy wyświetlenia informacji spokojnie można wyświetlić ekran. I na nim np. przejechać, czy wjechać z jakimiś listami ustaleń. Więc tutaj wyobrażam sobie, że tak jak są one zapisane, tak mogą być wyświetlone. W tym sensie trochę upraszam problem, ale może widzisz tutaj jakieś dodatkowe dno.

Jacek: Tak, ja po pierwsze co z kolei mnie w tym pytanie uderzyło, to to prezentować zespołowi. I tutaj oczywiście to jest taki pierwszy przykład jakiegoś naszego założenia. Ale lubię myśleć o odpowiedzialności za ustalone akcje usprawniające, że to jest coś, za co odpowiada zespół. A tutaj trochę to słyszę, jakby to było prezentowane przez kogoś zespołowi. Więc pierwsza moja myśl jest taka, że może tutaj jest taki temat, że trzeba przemyśleć i przedyskutować z zespołem jak to jest z tą odpowiedzialnością za akcje usprawnieniowe. Na pewno to nie jest tak, że jakiś tam Scrum Master czy lider za to odpowiada. Raczej powinien za to odpowiadać zespół. Natomiast jeżeli chodzi, jak to można zrobić? No to z mojej perspektywy dobrze się sprawdza umieszczenie konkretnie ustalonych akcji usprawnieniowych w Backlogu Produktu, czy Sprintu. W iteracji zwykle to jest ta lista zadań, którą po prostu realizujemy czy to nazwiemy Backlog Sprintu, czy jakoś inaczej. No i wtedy naturalnie, jeżeli wyświetlamy sobie tę listę tematów, którą mamy do zrobienia na przykład na jakiejś formie stand-upu, no to oprócz tej pracy produktowej czy projektowej po prostu widzimy te akcje usprawniające. No i o wiele trudniej jest je przeoczyć.

Kuba: Jak o tym mówisz, o tym prezentowaniu to też mi się mocno nasunęło takie przemyślenie. Tutaj jednak faktycznie może być jakaś taka koncepcja, że te akcje usprawnieniowe to jest coś, co w ogóle musi być w jakoś jakby przypominane, że trzeba do tego powracać. Być może jakiś taki, to tylko hipoteza oczywiście, ale być może jest jakiś pierwotny problem wcześniejszy. Czyli na ile dobrze te action pointy z pytania są w ogóle dobrze ustalone. Tutaj wyobrażam sobie, że jeśli jest superklarowne co, kto, kiedy ma zrobić i naprawdę każdy jakby podejmuje na siebie, każdy członek zespołu te zadania, no to na przykład właśnie wkładając odpowiednie zadania do Backlogu Sprintu czy po prostu dosyć szybko odhaczając je na wczesnym etapie w środku pracy, no prawdopodobnie problem tego monitorowania może być trochę mniejszy. No i druga myśl. Trochę z kanbanowych klimatów, no, to jeśli jest coś, co musimy monitorować, to być może jest tego za dużo. Może tutaj za dużo na raz jest ustaleń i problem jest zupełnie w innym miejscu, że mamy aż tyle ustaleń, że to monitorowanie jest kłopotliwe i trzeba szukać na to sposobu. A być może ustalmy bardzo konkretne ustalenia usprawnieniowe i jest sprawnie też szybko jako zespół zróbmy. No może nie trzeba będzie monitorować. Tutaj jest pytanie o monitorowanie, a może problemem jest w ogóle, że trzeba monitorować, może tu też jest temat. 

Jacek: Natomiast na pewno monitorowanie brzmi tak dosyć poważnie, natomiast samo zapewnienie, że to, na co się umówiliśmy zostanie zrealizowane jako akcje usprawnieniowe, jest absolutnym filarem i fundamentem usprawniania się. Żeby uniknąć sytuacji, w której w zespole narodzi się poczucie, że tyle rozmawiamy, a nic się nie zmienia. To może przestańmy rozmawiać?  Co prowadzi do tego, że zespoły z dużą ulgą porzucają spotkania usprawniające. No, co oczywiście ma swoje konsekwencje.

Jacek: Ok. To drugie pytanie. Pytanie trochę takie bardziej do nas, o nas, ale nam się spodobało, więc wybraliśmy. Co daje wam największy napęd, czyli drive w szerzeniu zwinności? To, że daje ona lepsze produkty? Może efekt w postaci przyjemniejszej pracy dla ludzi? Ciekawe i opłacalne perspektywy zawodowe? A może jeszcze coś innego?

Kuba: No i tak jak Jacek mówi, wybraliśmy to pytanie, bo ono jest takie o nas. Sami byśmy pewnie nie odważyli się zrobić odcinka tylko o tym, co nas kręci. Więc tutaj chętnie powiemy, dlaczego mamy motywację do szerzenia zwinności, do propagowania i do poświęcania swojego czasu i energii na to. Jedna jest w wersji mojej własnej biografii. Mam coś takiego, co teraz z głowy spróbuję przytoczyć, że fascynuje mnie to, że mogę łączyć korzyści biznesowe z dobrymi warunkami pracy dla zespołów. I tak jak myślę o tym, co mnie motywuje, to jest właśnie takie fajne, unikalne połączenie czy taka sytuacja win-win, że biznes i tak powiedzmy bezdusznie, korporacja, finansowe perspektywy, jakichś tam zysków dla interesariuszy, dla właścicieli. Są zadowoleni z tego, bo agile daje korzyści, a jednocześnie daje te korzyści w sposób taki bardzo humanitarny. Członkom zespołu się lepiej działa, bo są członkami zespołu, faktycznie prawdziwego zespołu przez duże Z. Że robimy pracę w sposób, który nas satysfakcjonuje, bo ciągle ją doskonalimy. Też skupiamy się na bardzo konkretnych rzeczach. Więc tutaj są korzyści takie międzyludzkie, co mnie bardzo, bardzo kręci. W sensie lepsze warunki pracy, a jednocześnie to koniec końców daje też korzyści biznesowe, bardzo konkretne, namacalne rezultaty dla organizacji. Więc jeśli myślę o takiej wyższego rzędu motywacji profesjonalnej, zawodowej, to to jest właśnie to.

Jacek: Ja chyba dosyć podobnie. Jak tak sobie patrzę na to pytanie, na takiej zasadzie, że tak też patrząc historycznie, pracowałem jako programista wiele lat temu i wiem, jak to jest pracować w zespole, gdzie to jest bardziej grupa osób, taki powiedzmy zlepek, bez poczucia, tak naprawdę, po co pewne rzeczy robimy, trochę pracując też w izolacji biznesowej. Więc ta obietnica podejścia zwinnego, która stawia na bliską współpracę zarówno w ramach zespołu, jak i z tą stroną, nazwijmy to zamawiającą, no to jest coś, co mnie mocno kręciło. I był to jeden z powodów, dla których zdecydowałem się porzucić programowanie i zająć się zarządzaniem projektem. To jest ta perspektywa taka ludzka. Natomiast z drugiej strony lubię sensowne produkty, lubię przemyślane produkty, lubię rozwiązania, które działają, które po prostu są porządne. No i to jest ta druga część, która mnie kręci. Czyli sensownie zastosowana zwinność daje nam po prostu dobre rezultaty. Dlaczego? Dlatego, że opiera się na eksperymentowaniu. Dlatego, że chcemy wciągać naszego odbiorcę, klienta czy użytkownika na wczesnym etapie po to, żeby dostać informację zwrotną. Jak również podchodzić do rozwijania produktu w sposób krokowy. Czyli dodawać do niego tylko to, co jest sensowne i co jest potrzebne. Co powoduje, że aplikacja, czy produkt, czy usługa, z której korzystamy na koniec jest prosta. A jednocześnie mamy poczucie, że zawiera wszystko to, co jest potrzebne. Więc myślę, że z mojej perspektywy te dwa aspekty powodują, że podejście zwinne wydawało mi się w pewnym momencie takim wybawieniem. Taką możliwością, która spowoduje, że zarówno można pracować lepiej w fajniejszych warunkach, ale też ten rezultat pracy będzie po prostu lepszy.

Kuba: W tym pytaniu osoby, która nam zadała to pytanie doceniam też bardzo podchwytliwy moment. Czy tym drivem jest fakt, że są opłacalne perspektywy zawodowe? Tutaj oczywiście to jest zawsze bardzo subiektywne i każdy ma indywidualną sytuację. W obu naszych przypadkach choć trochę innych, ale jednak podobnych. Nasze perspektywy zawodowe alternatywne też były fajne. Bo tutaj może nie każdy jest naszym biografem i zagląda w nasze CV, no ale obaj z Jackiem byliśmy zarządzającymi organizacjami. Więc tu spokojnie ścieżka taka klasyczna, managerska, czy tutaj Jacka w przypadku bardziej klasyczna, na przykład programistyczna, spokojnie mimo wszystko wchodziła w grę. I być może z perspektywy takiej opłacalności co najmniej byłyby porównywalne, a może nawet lepsze niż takie trzymanie się agile’a tak jak się go trzymamy. Więc przynajmniej w konkretnie naszej, czy w konkretnie mojej sytuacji spokojnie mogę powiedzieć, że to nie opłacalność perspektyw zawodowych była jakimś tutaj driverem, czy do dzisiaj jest driverem. Oczywiście jednym z powodów dla których pracuję jest zapewnienie bytu mojej rodzinie. Ale tutaj tych alternatyw w naszych karierach było mnóstwo, więc kwestia opłacalności agile’a to jest ostatnie co można nam zarzucić. Bo naprawdę każdy z nas miał parę fajnych kroków pośrednich albo innych, albo alternatywnych, które z agile’em mogły być luźno albo wcale niezwiązane.

Jacek: Natomiast warto podkreślić, że dzisiaj jest to pewien wabik. Nawet bym powiedział nie od dzisiaj. Tak jak kiedyś programiści byli wciągani z rynku, żeby zacząć pracować w IT, testerzy, no tak też ta ostatnia wielka fala wciągania osób z obietnicą, że Scrum Master to jest też sposób na dostanie się do IT. Jest to na pewno ten motywator finansowy jest istotny. No i też nie można powiedzieć, że go nie ma na rynku. Natomiast tak jak Kuba powiedział ja programistą już byłem, więc gdybym chciał nim zostać tobym po prostu nim był dalej.

Kuba: Dobra, to przechodzimy do trzeciego pytania. Tutaj jest w zasadzie bardziej taka konkretna prośba o komentarz z naszej strony. Rola Scrum Mastera w procesie release i release w Scrumie. Pozdrawiamy Karolinę, która była jedną z pierwszych osób, która nam w ogóle zadała to pytanie.

Jacek: Ok, czyli pytanie jest o tym jak Scrum Master mógłby, jak rozumiem, wspierać proces wdrażania. Też tłumacząc słówko release, no i jakby jak mógłby się w tym odnaleźć. Dobre pytanie, fajne pytanie. Bo myślę, że może panować takie poczucie, że proces wdrażania, jeśli mówimy o produktach cyfrowych, bo tak zakładam produktu na środowiska docelowe, że to może być coś, co jest traktowane jako coś, co jest czysto deweloperskie i Scrum Master może bardzo elegancko otrzepać ręce i powiedzieć to nie moja robota. I to jest moim zdaniem pułapka myślenia, dlatego, że to jest proces związany z wytwarzaniem oprogramowania. Jeżeli patrzymy na Scrum Master jako na osobę, która odpowiada za efektywność procesu szeroko rozumianego, no to jak najbardziej Scrum Master może się w takim procesie odnaleźć. A nawet powiem więcej, powinien się w takim procesie pojawić.

Kuba: No i to jest kopalnia wątków tak naprawdę. Bo z jednej strony, może zacznę od wątku, który mi się nasuwa najczęściej. To abstrahowanie Scrum Master od procesu release’owego, może doprowadzić do takiej sytuacji, w której w tym procesie wdrożeniowym, czy może nawet jeszcze szerzej w ogóle w procesie przechodzenia przez kolejne środowiska, może jakichś testów przedwdrożeniowych, szeroko rozumiany proces udostępnienia rozwiązania dla klienta końcowego, że on może mieć w sobie mnóstwo nieefektywności i to takich nieefektywności, którymi nikt się nie zajmuje. Zwłaszcza jak nie daj Boże, jest to jakaś większa organizacja, w której ten proces jest wspólny dla kilkunastu, kilkudziesięciu zespołów, to pojedynczy zespół zupełnie nie ma wpływu na to, jak ten proces wygląda. Oddolnie go nie zmieni, więc tu naprawdę jest potrzebne jakieś wspólne działanie. Jakieś podejście do tego, jakieś przemyślenie. No i do tego Scrum Master może się świetnie nadawać. A nawet bym powiedział pewien zespół scrum masterski. Żeby tutaj być może nazwać jakieś nieefektywności, zwrócić uwagę na niedoskonałości z dowolnego poziomu. Bo tutaj zawsze jest kopalnia wątków, czy to jakościowych, czy organizacyjnych, czy po prostu wydłużenie czasu niepotrzebne, czy może jakieś ograniczenia biznesowe, które przestają być możliwe tylko dlatego, że taki, a nie inny proces wdrożeniowy mamy. Więc tutaj jest kopalnia nieefektywności! W ciemno zakładam, że jest nieefektywność, tutaj nawet nie mam cienia wątpliwości, że jest wszystko dobrze. No i Scrum Masterzy fajnie, jeśli się za to zabiorą. Konkretnie nazwą problem i spróbują to rozwiązywać kawałeczek po kawałeczku, ciągle ewoluując ten proces. Ale to nie wszystko, tylko że nie chce ci zjeść Jacek wszystkiego, więc pewnie dorzucisz jeszcze jakiś wątek.

Jacek: Tak. Ja tu przede wszystkim myślę o tym, że tutaj może się kryć taka pułapka oczekiwania, że Scrum Master będzie w stanie ten release zrobić własnymi rękoma. I ja myślę, że jakby nie w tym rzecz. No bo narzędzia jakieś tam CI/CD, no fajnie, żeby wiedział, że jest coś takiego, rozumiał, do czego to służy. Może nawet znał pewne podstawy, no ale na koniec jednak uważam, że to jest taka faktyczna praca, którą developerzy wykonują. Natomiast zapewnienie, że to będzie zrobione w optymalny sposób, zapewnienie, że wszelkiego rodzaju, tak jak Kuba wspomniałeś, nieefektywności, marnotrawstwa będą wyciągane, czy pomoc w spojrzeniu na ten proces tak od początku do końca, trochę z lotu ptaka, zapewnienie w tym procesie, że jest refleksja, że uczymy się, że ten proces jest coraz lepszy, no to są wypisz wymaluj rzeczy, które domyślnie każdy Scrum Master mógłby do takiego procesu wnieść. Przy czym, moim zdaniem musi mieć jakąś tam elementarną wiedzę technologiczną, żeby w ogóle rozumieć, o czym do niego inne osoby mówią. No bo brak takiego backgroundu, takiego przygotowania, może spowodować, że Scrum Master nie będzie w stanie zadać dobrych pytań oprócz takich najbardziej generycznych. I przez to może nie być potraktowany jako taki pełnoprawny partner dyskusji.

Kuba: No to jak Ciebie słuchałem, to mi się taka dodatkowa myśl właśnie nasunęła. Znam firmy i znam zespoły, znam też Scrum Masterów i Scrum Masterki, którzy właśnie mocno abstrahują od procesu releasowego, bo on jest skomplikowany, on jest może nawet mniej znany osobom, które jakiś rodzaj backgroundu pracy przy projektach mają. Mam na myśli tutaj na przykład analityków czy testerów, może nawet bardziej analityków, że czasami nawet mając doświadczenie projektowe, można nie do końca rozumieć i kojarzyć, na czym dokładnie polega cały proces wdrożeniowy w całej swojej złożoności. A co dopiero osoby, które przychodzą spoza świata IT? I może być bardzo uspokajające przemyślenie, że Scrum mi się kończy tam, gdzie kończy się obecne brzmienie Definition of Done. A jeśli na przykład w tym zespole Done jest wtedy, gdy mamy to na środowisku testowym albo jakimś tam kolejnym poziomie, ale jeszcze nie na środowisku docelowym, ale to to już jest zmartwienie kogoś innego. Nie wiadomo do końca kogo. Być może to są te same osoby, co pracują w Sprincie, ale to już nie jest w Sprincie. No to to jest jedna z wielkich pułapek. Takich pułapek, którą zgeneralizuję, to lepiej będzie widać na wideo, bo tutaj robię ruchy rękoma, ale takie myślenie, że Scrum jest od planowania do powiedzmy końca Retrospektywy, czyli taka optyka Sprintu, co Sprint, co Sprint, co Sprint. Tylko to, co jest wewnątrz Sprintu, to delivery, który robimy, to jest Scrum, a tak naprawdę z jednej strony jest cała ta sfera odkrywania wcześniej. Scrum na to mówi proces Refinementu, ale tutaj naprawdę dużo dobrego może się dziać, ale również dużo nieefektywności oraz to dostarczenie. Genialnie byłoby, gdyby te wszystkie rzeczy były w środku Scruma. Scrum Master je widzi i one wszystkie łącznie podlegają doskonaleniu. Bo coś, co jest moim doświadczeniem, to to, że zespoły bardzo usilnie próbują zoptymalizować proces jakby wytworzenia, a przeoczają to, że na przykład czas dostarczenia od pomysłu do wdrożenia, bardzo mocno pompowane jest długim czekaniem na pewne decyzje przed Planowaniem Sprintu i również długim czasem kiszenia się gotowego kodu, ale jeszcze niewdrożonego, bo coś tam. Bo okienko wdrożeniowe, bo seria testów regresyjnych czy tego typu wesołe historie.

Jacek: No i tutaj można wpaść, myślę, w pułapkę takiej lokalnej optymalizacji. Czyli co z tego, że mamy wydajny proces, jeśli, tak jak wspomniałeś, zbyt długo czekamy aż od pomysłu zacznie się wykluwać coś namacalnego, albo na drugą stronę możemy mieć zjawisko nadprodukcji. Czyli mieć gotowe rzeczy do wypuszczenia, no ale ze względu na niedojrzały proces on jest rzadki, czekamy na niego. Zresztą patrząc na ten release w Scrumie, to też mi się tak skojarzyło, że nadal pokutuje w środowisku takie poczucie, że release jest na koniec Sprintu. Czyli tam po tym, jak będzie błogosławieństwo na przeglądzie Sprintu, co też oczywiście z absolutnym mitem. Tak naprawdę wdrażamy wtedy, kiedy jesteśmy gotowi wdrożyć. I wtedy, kiedy to ma sens i nie ma co patrzeć na to, że Sprint się nie skończył. No bo to jakby jedno z drugim nie ma nic wspólnego. I to, co powiedziałeś, warto powiedzieć wprost. Scrum Master, który twierdzi, że w jego procesie release’owym już jest wszystko dobrze, to niech sam sobie odpowie na pytanie. Czy mój zespół może wdrażać co 5 minut? Jeśli nie może wdrażać co 5 minut, to nadal uważam, że jest jeszcze coś do zrobienia w procesie wytwórczym. I jest jeszcze praca do wykonania! A nie być zadowolonym, że po zakończonym Sprincie można wdrożyć raz na dwa tygodnie. Dla niektórych zespołów to już jest wielkie wow, ale to jeszcze nie jest meta. To jest tylko pewien etap w drodze.

Jacek: Kolejne pytanie. Co w sytuacji, gdy Product Owner nie chce interesariuszy na Review, bo – cytat „Nie ma co pokazać”. Koniec cytatu. Mimo że praca została wykonana, można ją zaprezentować i uzyskać feedback wcześniej niż po wypuszczeniu całości za dwa miesiące.

Kuba: Czyli tutaj w pytaniu mamy pewną historię, takiego micro case’a. Jak rozumiemy, osoba, która zadaje pytanie, pracuje z Product Ownerem, właścicielem produktu, który unika zapraszania interesariuszy albo ma pretensje o to, że tacy interesariusze się jednak pojawiają, bo choć pytający, pytająca pokazuje, że jest co zaprezentować, że można by zebrać feedback, to jednak Product Owner z tej historii ma jakieś opory i woli nie konfrontować się, czy nie zderzyć się, czy nie dostać feedbacku od interesariuszy. No i co można zrobić w takiej sytuacji?

Jacek: Ja myślę tak, że przede wszystkim, pierwsza rzecz do zeksplorowania z mojej perspektywy, gdybym ja był w tej sytuacji, tobym chciał zrozumieć, dlaczego, z czego wynika ten opór. Na takiej zasadzie, że muszą być jakieś argumenty w głowie Product Ownera, które powodują, że nie jest zainteresowany jak rozumiem, wystawianiem tego, co zostało wyprodukowane w taki sposób, żeby interesariusze mogli to skomentować. Tutaj powody mogą być przeróżne. To może być proste poczucie wstydu na zasadzie, to jeszcze nie jest gotowe, więc nie chciałbym tego pokazywać. Inny przykład to jest poczucie, jak to zacznę pokazywać, to zaczną wymyślać, mówiąc tak bardzo potocznie. No i to spowoduje, że jakieś tam moje plany zostaną naruszone. A trzecia przykładowa opcja, która przychodzi mi do głowy, to jest może coś w stylu, po co mamy to pokazywać, skoro i tak w organizacji funkcjonujemy w taki sposób, no, że to, na co się umówiliśmy, ma być zrobione i tak naprawdę im mniej nam ludzie będą w tym przeszkadzać, ludzie, to znaczy interesariusze, tym lepiej. To oczywiście te trzy rzeczy, które powiedziałem, to są jakieś tam przykłady, hipotezy. Natomiast z mojej perspektywy na pewno bez dogłębnego zrozumienia, z czego wynika opór Product Ownera, trudno doradzić coś takiego superprecyzyjnego, co stuprocentowo rozwiąże ten problem.

Kuba: Myślę, że nic innego nie wymyślę niż to, co powiedziałeś. Tak porównawczo Scrum jest na tyle schematyczną czy standardową metodą, że to Review i ta możliwość interakcji i współpracy z interesariuszami na Sprint Review, jednak co do zasady ma sens i co do zasady jest korzystna. Czyli jeśli ktoś jednak ma jakieś opory, to musi ku temu mieć jakieś powody. Ale to nie będą rzeczy, które będą obiektywnie wynikały z metody, tylko jakieś właśnie założenia, jakieś może historie, jakieś głębsze wątki, które warto zgłębić. Warto bardzo poważnie potraktować, spróbować też zrozumieć czy empatyzować. Ja sam akurat zawodowo Product Ownerem nie byłem, ale w wielu zespołach projektowych uczestniczyłem, czy sam, czy z Jackiem razem dużo rzeczy wymyślamy. Ja sobie nie wyobrażam, jaki to jest stres, próbować robić działania w długim horyzoncie czasowym bez okazji do uzyskania informacji zwrotnej. Na zasadzie takiej, że każda decyzja produktu Product Ownera to jest pewne założenie. To jest pewna hipoteza, to jest przypuszczenie, to jest ryzyko. No i jeśli będziemy przez na przykład 2 miesiące, jak w pytaniu zawarte, działać zupełnie po omacku na zasadzie może się uda, albo nikt może nic nie zauważy, nie zwróci nam uwagi, to ja bym nie chciał być w tym stresie. Dla mnie co dwa tygodnie to byłoby za rzadko i dążyłbym raczej do częstszych interakcji. Częstszego sprawdzania małymi porcjami moich założeń. Jeszcze na Refinemencie już takie jakieś dobre wejście w bliski kontakt. A potem również kawałeczkami w trakcie trwania Sprintu aż do fajnych sesji podsumowujących i zadawania sobie pytań na Sprint Review. Ja sobie nie wyobrażam, jaki to musi być stres. Ale w takim razie tym bardziej, jeśli na jednej szali jest ten stres, czy ja podjąłem jako Product Owner dobre decyzje, ale jednak mimo wszystko nie chcę tego Sprint Review, to tam pod spodem musi się w takim razie czaić jeszcze inny rodzaj jakiegoś ciężkiego stresu, który warto wydobyć na światło dzienne i zrozumieć co tam się dzieje. Oczywiście słyszałem parę argumentacji różnego typu, dlaczego to się nie dzieje. Jacek w zasadzie pokryłeś chyba wszystkie hipotezy. Jedna, którą dołożę, ona jest może podobna do tego, co mówiłeś, ale jednak taka koncepcja, że chcemy mieć wszystko dobrze naraz. I to zwłaszcza w organizacjach, które mają taką trochę tendencję do Big Bang, tendencję do takich show, też takiego podejścia, że raz w roku, ale musi być takie wielkie wow. No to, to mogą być organizacje, które mają jakby kulturowo przyzwyczajenie do tego, że robimy bardzo duże kroki. Bardzo spektakularne rzeczy. I tutaj Product Owner, który przyjdzie i pokaże jeden nowy przycisk, jedną nową zakładkę, jeden nowy kolejny krok, czy jakieś odgałęzienie w procesie, może być źle odebrany. Tylko dlatego, że pracuje przyrostowo, właśnie małymi krokami. Tu może się okazać, że temat jest do wydobycia od Product Ownera, ale do rozwiązania w jakimś innym miejscu. Lub do dużego wsparcia ze strony Scrum Mastera, żeby tutaj bardzo wspomagać tę koncepcję, czy promować w organizacji, tak naprawdę przede wszystkim w managemencie i to wyższym, koncepcję tego, że ciągle się doskonalimy. To nie jest obcy klimat, że się ciągle doskonali i poleruje rozwiązania. Tu bardzo łatwo taką filozofię sprzedawać. Ale rozumiem też, że w niektórych organizacjach management może nie być chętny, żeby to kupić.

Jacek: Chyba nic więcej do tego pytania, bo musielibyśmy, myślę, kolejne warstwy założeń dobudowywać, więc pójdziemy dalej. Zanim przejdziemy do pytania piątego, przypominamy, że jeżeli masz ochotę pogłębić wiedzę, jeszcze bardziej niż robimy to w podcaście, to nasze produkty premium znajdziesz na stronie porzadnyagile.pl/sklep.

Kuba: Więc pytanie piąte, w zasadzie zaczynające się od pewnego rodzaju stwierdzenia, czy obserwacji, trochę założenia. Mam poczucie, że wśród Scrum Masterów statystycznie więcej jest osób, które słabo wykonują tę pracę w porównaniu do innych grup zawodowych. Z jednej strony to rozumiem, bo to bardzo trudna rola, która w dodatku często bywa opatrznie rozumiana przez organizacje. Tym niemniej to zjawisko potrafi robić bardzo zły PR zwinności i wszystkim Scrum Masterom. Czy macie podobnie? A może zupełnie się z tym nie zgadzacie?

Jacek: Czyli z pytania słychać takie założenie czy obserwacje, że sporo Scrum Masterów, którzy są na rynku słabo wykonują swoją pracę. No i jakby, że wpływa to negatywnie na postrzeganie zwinności, no i na inne osoby, które również pełnią taką rolę. No i pytanie jest, czy się zgadzamy z tym założeniem, z taką hipotezą? Czy nie? Jaki tutaj jest nasz punkt widzenia na tę sytuację?

Kuba: Ja się nie zgadzam z założeniem, że w porównaniu do innych grup zawodowych więcej jest Scrum Masterów słabo wykonujących tę pracę. Ale czekaj, bo tutaj granat studni ląduje w innym miejscu niż myślisz. No ja niestety uważam, że bardzo wiele osób bardzo różnych profesji słabo wykonuje swoje prace. Niestety mam bardzo krytyczny stosunek, rzadko o tym mówię, ale takie pytanie mnie do czegoś takiego prowokuje. Bardzo rzadko widzę profesjonalnie wykonujące swoje zadania dowolne specjalizacje. Bo dokładnie to samo zdanie mam na temat zarządzających ludźmi, na temat kierowników projektu. Niestety na temat programistów, testerów, analityków i mogę długo wymieniać te profesje. Ja nie znam przykładu profesji, w której mogę powiedzieć, kogo bym nie spotkał z tych profesjonalistów, to po prostu wymiatają tak. Taki etos pracy, taki poziom zaangażowania. Taki poziom profesjonalizmu, że jakby w ciemno bije do profesji X, bo każdy jeden jest super dobry. Trochę przerysowałem oczywiście teraz tak felietonistycznie, ale mam na myśli coś takiego. Scrum Masterzy są tak samo nieprofesjonalni w społeczności, czy w społeczeństwie, jak wszystkie inne profesje. Jest tu jakiś wielki problem, co się nadaje na jakieś bardzo filozoficzne rozważanie. Ale mam wielki problem z małym poziomem profesjonalizmu u wszystkich członków zespołów wytwórczych i chętnie za chwilę podzielę się swoją hipotezą, z czego to wynika.

Jacek: Ja myślę, że to jest trochę tak, że Scrum Master staje się ze względu na tą nazwę, która rozumiem, dlaczego mówimy Scrum Master i co to ma implikować. Natomiast ta nazwa trochę przyczepia etykietkę takiej odpowiedzialności za Scruma, za to, jak zwinność generalnie jest wykorzystywana w organizacji. No i generalnie, tak jak Kuba mówi, że jest jakby kryzys profesjonalizmu, no to generalnie wykorzystanie zwinności, gdyby spojrzeć tak globalnie, no to też nie stoi na jakimś wybitnym poziomie. Jest taka myśl, która mówi, że dowolna koncepcja będzie albo zapomniana, albo będzie wykorzystywana w niewłaściwy sposób. No i stąd tyle kulawych implementacji Scruma czy wykorzystania zwinności w organizacjach? No i myślę, że to jest połączenie takich dwóch rzeczy. Pierwsza rzecz to jest to, o co powiedziałem. Druga jest taka, że spory napływ nowych Scrum Masterów, tak trochę wracając do tego punktu, o którym mówiliśmy wcześniej, pojawił się na rynku. No i niestety część z tych osób to były osoby, które dobrze robiły swoją robotę, a część osób poszła na jakiś tam kurs dwudniowy. Ktoś obiecał, że zostać Scrum Masterem i wejdź do branży. No i niestety to pierwsze wrażenie, które takie osoby zrobiły w organizacjach może często być nie do odwrócenia. Sam często dostaję pytania, czy Scrum Master powinien robić jakieś tam konkretne rzeczy albo nie robić konkretnych rzeczy. No i zwykle jestem zaciekawiony, dlaczego takie pytanie się pojawia. Jakaś tam dłuższa historia dopiero odsłania, że akurat ktoś miał pecha. I ten Scrum Master konkretny, który wspiera ten zespół, który mi te pytania zadaje, no, mówiąc tym Kuby językiem, nie był najwybitniejszym specjalistą w tej swojej dziedzinie. Więc myślę, co najmniej te dwa tutaj nurty się schodzą i powodują, że takie odczucie może się rodzić.

Kuba: To ja moją hipotezę nadbuduję nad tym, co powiedziałeś. Jestem w tej branży moim zdaniem dosyć wcześnie i już dość długo. Obaj w sumie z Jackiem jesteśmy, więc mieliśmy okazję zaobserwować zarówno takie dosyć wczesne czasy. Powiem, co to były te wczesne czasy. Jak sami z Jackiem byliśmy Scrum Masterami, to na Pracuj.pl ogłoszeń na stanowisko Scrum Master w tygodniu było jedno, dwa na całą Polskę. I naprawdę nie żartuję. Sam, jak robiłem jedną z pierwszych rekrutacji na „Scrum Mastera naprawdę”, to jest taki ukryty żart, tylko dla naprawdę starych agile’owców, no to mieliśmy zgłoszeń kilkanaście, z czego ludzie, którzy wtedy zostali wybrani, dzisiaj są trenerami, konsultantami, są zapracowanymi Scrum Masterami, a wtedy zaczynali. Więc na początku było bardzo krucho. Zarówno z profesją, jak i z jakby popytem na zawodowych, dobrych, dobrych jakościowo Scrum Masterów. No ale hipoteza jest następująca. Popyt na usługi Scrum Masterów przez długi czas był niezaspokojony istniejącą podażą. Czyli istniejący Scrum Masterzy w firmach albo mieli co robić, albo byli bardzo cenieni i wręcz trzymani na siłę, żeby czasem nie odeszli. Nie zawsze się to firmom udawało, ale jednak firmy walczyły, a z drugiej strony nie za bardzo było gdzie tych nowych Scrum Masterów dostać. Stąd popularność tych wszystkich szkół, akademii, kursów przyspieszonych i wszystkich tego typu działań, ale też niska selekcja. Po prostu, jeśli tylko mówiłeś po scrummasterskiemu, to zostawałeś Scrum Masterem. I teraz to jest dosyć brutalna rzecz, pewnie dosyć niechlujnie to przekazuję i mogę kogoś urazić, ale uważam, że każdy Scrum Master powinien raczej wziąć sobie do serca to, że praca rozwojowa dopiero się zaczyna, a nie kończy po tym, jak się jest rok lub dwa lata Scrum Masterem. I tutaj nie ujawnię źródła, ale pewna osoba, z którą niedawno rozmawiałem, osoba, którą uważam za bardzo doświadczonego specjalistę lub specjalistkę, żeby tutaj zdradzić, mówi mi, że w zasadzie pracuję już wiele lat w wielu firmach i ani razu nie miał okazji zetknąć się z kimś, kto by tę osobę tak zwana zczelendżował, jeśli chodzi o merytorykę zawodu Scrum Mastera. W małej ilości firmie są wewnętrzni doświadczeni, mentorzy scrummasteringu, agile coach’e czy okazję do współpracy z konsultantami zewnętrznymi, co powoduje, że jeśli robisz tę pracę jako Scrum Master jakoś, to to jakość po paru latach staje się po prostu pewną normą, pewnym przyzwyczajenie. I to przyzwyczajenie może być bardzo źle odbierane. 

Kuba: Ja myślę, że tutaj możemy postawić kropkę. Kolejne pytanie trochę, myślę, zahacza od obszary, o których przed chwilą powiedzieliśmy i brzmi ono następująco. Dlaczego agile umiera? Dlaczego deweloperzy, gdy słyszą agile, to się krzywią i uciekają? I dlaczego biznes powinien się dostosować do procesu wytwarzania, a nie proces wytwarzania do biznesu? Dlaczego Scrum nie jest zwinny? Czy tylko konsultantom zwinności, agile coach’om i Scrum Masterom zależy na zwinności? Jak to się ma do krytyki postaw managerów, którzy mieli, mają być inhibitorami transformacji zwinnej, bo nie potrafili się odnaleźć w nowej rzeczywistości, gdzie nie mają narzędzi, czyli command and control nad zespołem?

Kuba: I to jest akurat najdłuższe z pytań, które wybraliśmy, ale dziękujemy osobie, która je zadała, bo dała nam tutaj bardzo dobrą podbudowę, też taką pewnego tła, czy pewnego nastawienia w tym pytaniu. Więc w pytaniu przede wszystkim widzimy hasło, dlaczego agile umiera i tutaj chyba oddzielne dwa zdania na ten temat damy. No ale też słyszymy pewną opisową historię o tym, jak to developerzy unikają agile’a, a jedynymi, których na agile’u, czy konkretnie tutaj w pytaniu zadanym na Scrumie zależy, to są Scrum Masterzy, Agile Coach’e, konsultanci zwinności, czyli jacyś profesjonaliści od tego, żeby ten agile był, ale nie są to na przykład z jednej strony managerowie, a nie z drugiej strony właśnie developerzy. Czyli dlaczego z tym agile’em jest tak źle?

Jacek: Ja myślę, że to wynika z cyklu życia zwinności, która zaczęła się właściwie tak przygoda mainstreamowa powiedziałbym po stronie IT. Manifest Zwinnego Wytwarzania Oprogramowania, zebrał już pewne ruchy, które się działy, no i jakby z czasem zwinność stawała się coraz bardziej lotnym hasłem. No i właściwie jak z każdą ideą w momencie, kiedy twój fryzjer czy kosmetyczka już zaczyna też mówić o zwinności, no to znaczy, że to już jest bardzo popularne i jednocześnie, moim zdaniem, nie ma szans, żeby ta koncepcja czy idea nie została wypatrzona. Tak więc to, gdzie jesteśmy dzisiaj, jeśli chodzi o zwinność w tym konkretnym cyklu życia, no powoduje, że o zwinności mówią wszyscy. Zwinność jest odmieniana przez przypadki i właściwie do każdego innego pojęcia można przykleić słowo zwinny, czy zwinna, czy agile. No i tak naprawdę jest fajnie, ale problem jest taki, że najczęściej pod spodem niewiele się zmienia. Więc ja doskonale rozumiem alergiczną reakcję osób na pewne pojęcia w stylu Scrum, Scrum Master, agile, no przez to, że najprawdopodobniej zderzyły się z bardzo kiepskim wykorzystaniem tych pojęć, no i po prostu nie chcą tego doświadczać. Nie chcą tego jakby w tym kolejny raz brać udział. W szczególności, jeżeli są to osoby, które rozumieją czym to pojęcie tak naprawdę jest, a dostają tylko jakąś bardzo płytką i powierzchowną namiastkę pracy w środowisku zwinnym.

Kuba: Podoba mi się w pytaniu osoby, która tutaj podrzuciła nam ten wątek, jednak pewna podkręcona piłka w stronę managementu. I tutaj ja sam też mocno bym poszedł w tę stronę, że zwinność w organizacjach może mieć swoje kłopoty, może mieć swoje płytkie albo bardzo powierzchowne czy wykrzywione znaczenie, tak jak Jacek trochę opowiedziałeś, również przez postawę zarządzających. To mi się łączy z poprzednim pytaniem właśnie też z moją krytyczną uwagę na temat profesjonalizmu zarządzających. No niestety za dużo zarządzających widzę w grze o pozycję, o awanse, o utrzymanie swojego małego imperium w danej organizacji. Za dużo razy też widziałem osoby, które do agile’a mają takie nastawienie wyczekujące czy na przeczekanie, czy też na zasadzie OK, agile może być jako pewnego rodzaju dodatek obok tego, co robimy? Więc zarówno developerzy będą widzieć ten rozdźwięk między oczekiwaniami czy deklaracjami a tym, co się dzieje naprawdę, jak i też po prostu wszyscy uczestniczący w danej organizacji. Tym względem jestem pesymistą, że tutaj ten umierający agile to umiera przez managerów, ale jestem też optymistą, że na zwłokach tego umierającego agile’a tak naprawdę musi się na nowo odnaleźć z powrotem zrozumienie, że nie chodzi o etykietę, nie chodzi o Scruma, Kanban czy jeszcze jakąś inną technikę, tylko o nieunikniony kierunek. Potrzebują organizacje, zespoły, biznesy, produkty szybkich iteracji, częstego wdrażania, ciągłego doskonalenia. Czasy, w których da się zaplanować, pewne rzeczy już minęły. Czasy, w których można spokojnie odbębniać zgodnie z planem pewne działania, przynajmniej w konkretnych branżach, ale zwłaszcza w branżach związanych z produktami cyfrowymi już są przeszłością, jeśli w ogóle kiedykolwiek były codziennością. Agile rozumiany jako jego istota i esencja będzie zawsze potrzebny, co najwyżej będzie on potrzebny jeszcze intensywniejszy. Jeśli z tego powodu musimy zrzucić w siebie skórę jak jakiś gekon i na tle starych doświadczeń zbudować zupełnie nowe związane z tym, że będziemy jeszcze szybciej iterować, jeszcze bardziej eksperymentować, jeszcze bardziej się ciągle doskonalić, to może to mi się nazywać jak chce. Możemy to nawet nazwać „waterfall 3.0”, ale jeśli pod spodem będzie ten esencjonalny agile, to idziemy w dobrą stronę. Wyobrażam sobie, że tutaj jako cała branża, jako tak naprawdę cały świat doświadczamy jakiegoś takiego falowania na zasadzie zachłyśnięcia się, takiego cofnięcia się, żeby wyciągnąć wnioski i robić to jeszcze lepiej. Super, że agile umiera, chociaż nie zgadzam się z tym hasłem, niech umiera, niech na tym tle parę osób dokona trochę przemyśleń. Być może mniej profesjonalni zarządzający wypadną z tego pociągu i na kolejnym obrocie, na kolejnym cyklu zrobimy to wszyscy, którzy zostaną jeszcze lepiej.

Jacek: Lepiej bym tego nie powiedział na takiej zasadzie, że ja też wbrew pozorom, chociaż jestem częścią tej branży, patrzę z dużym optymizmem na to, że właśnie z każdej strony można słyszeć, że to jest koniec agile’a. I bardzo dobrze, bo jeżeli w tej obecnej formule to miałoby dalej funkcjonować, no to myślę, że jest sporo możliwości niewykorzystanych. To świetnie wraca do tych naszych motywatorów, o których mówiliśmy na początku. Na koniec dnia mnie interesują współpracujące zespoły, które czują motywację, zespoły, które biorą odpowiedzialność, zespoły, które mają wpływ i interesują mnie udane produkty. I teraz jakim frameworkiem, metodą, jakkolwiek sobie to nazwiemy, do tego doprowadzimy, tak naprawdę z mojej perspektywy nie ma znaczenia. Natomiast w świecie VUCA, w świecie BANI, gdzie jest tyle nieprzewidywalności, kruchości, niejasności, nieliniowości, niepewności, ja naprawdę nie znam lepszych technik, lepszych podejść, niż to, co naprawdę mamy już dostępne, bo mamy i Product Discovery, mamy i podejście zwinne, całą masę innych koncepcji i pojęć, które tak naprawdę, nie będzie trzeba ich wywrócić jakoś do góry nogami o 180 stopni, tylko na spokojnie zastanowić się, jak to wszystko poskładać w całość i być może na skutek tej syntezy pojawią się jakieś nowe pojęcia. Natomiast ja osobiście tych takich pojęć nie widzę, nie dostrzegam. Na zasadzie z tego popiołu na razie, moim zdaniem nie rodzi się Feniks, ale spokojnie, bo może się narodzi i to jest na pewno trend, który będę bacznie obserwował.

Kuba: No dobra, przejdźmy do kolejnego pytania. Pytanie przedostatnie, znowu zaczynające się od pewnego zarysu przypadku. Członkowie zespołu, dzielenie między zespołami, często dwoma. Problem z context switchingiem jest oczywisty, dwukrotna ilość spotkań. Firma nie widzi problemu, ponieważ chcą szybko rosnąć i według nich obecne rozwiązanie jest konieczne. Jak przekonać firmę do deskalowania zamiast skalowania, gdy nie ma do tego warunków?

Jacek: Czyli mówimy tutaj o sytuacji, kiedy mamy konkretne osoby w zespole, a właściwie w zespołach, czyli konkretny developer, chociaż nie mówimy nawet konkretnie, konkretna osoba w zespole, nie funkcjonuje tylko w jednym zespole w skupieniu, tylko z jakiegoś powodu wspiera też inne zespoły. No i jak słyszę, jest na to wytłumaczenie managementu. Natomiast osoba zadająca pytanie raczej skłania się tutaj do deskalowania, czyli jednak do zapewnienia, że ta osoba będzie pracować tylko w tym jednym zespole.

Kuba: I zwracam Twoją uwagę na to, że jednak ten przypadek jest stricte o firmie, która rośnie. To nie jest firma, która ma jakiś ustabilizowany sposób funkcjonowania i tam dzieli członków zespołu. Tylko jest bardzo konkretne dopowiedzenie, że mamy do czynienia z firmą, która jakoś intensywnie się rozbudowuje i jak rozumiem w ramach pomysłu managementu, a może nawet jakichś założycieli czy osoby zarządzające całą organizacją, to jest nieuniknione, że tak właśnie musi być. Że wraz ze wzrostem firmy rośnie liczba zespołów, ale też te zespoły są budowane tak trochę w pewnym sensie wirtualnie czy sztucznie, bo zamiast dotrudniać zupełnie nowych specjalistów do tych nowych zespołów, tworzy się takie zespoły złożone z pół etatu osoby pożyczonej z innego obszaru. Jakie tutaj mamy pomysły? Byłbym bardzo ostrożny z założeniem, które jednak w pytaniu się pojawia, czyli jak przekonać firmę do deskalowania zamiast skalowania. O ile ten sposób myślenia jest bardzo obiecujący i pewnie poruszymy go chwilę, to jednak bądźmy ostrożni, żeby nie wpaść tutaj w pułapkę tego kogoś, kto zatrzymuje organizację przed wzrostem. Wyobraźmy sobie, że na początku Facebooka jakiś Mark Zuckerberg i jego paru wspólników, o których już świat zapomniał, ma jakiegoś Scrum Mastera, który mówi, słuchajcie panowie, nie rozwijamy się, może zatrzymajmy się w rozwoju. To może być źle zrozumiane. Ja wiem, że pytający nie mówi, nie rozwijajmy się, ale tutaj jest bardzo ostrożna gra w to, co komunikujemy i jak komunikujemy na temat tego, jak firma rośnie. Więc tutaj ostrożnie komunikujmy pomysły na deskalowanie na zasadzie rozumiane jako nie dotrudniajmy ludzi, albo nie rośnijmy, czy nie twórzmy nowych zespołów, bo to obiektywnie może być najmądrzejsze, co ta organizacja potrzebuje robić, czyli jednak zwiększyć swoją skalę działania, zwiększyć swoje moce przerobowe. Móc szybko wejść na nowe rynki, zbudować jakąś nową ofertę dla kolejnych niszy rynkowych. Więc tutaj byłbym ostrożny z pomysłem na deskalowanie, bardziej bym się zastanowił jak to zrobić, żeby jak najlepiej odpowiadać na bieżące potrzeby i wokół tego bym raczej prowadził pewną narrację. Czyli czy te potrzeby firmowe, jaka firma ma, czy  uzyskujemy dobrą odpowiedź na nie poprzez takie zespoły na pół etatu. Bo być może to jest tylko działanie pozorne i ono jest, mimo że wydaje się, to jednak jest nieskuteczne. Wydaje się, że daje pozytywy, ale jednak nie prowadzi firmy we właściwym kierunku. Więc tutaj bardzo mocno to się sprowadza do rozmowy efektywności. Czego firma oczekuje, czego potrzebuje, na czym zarabia, gdzie są pewne potencjały i czy my taką, a nie inną konstrukcją zespołów faktycznie to uzyskujemy. Gdzie tu jest efektywność? Gdzie tu jest wartość dodana z istniejących zespołów? No i paradoksalnie, kompletnie nieefektywne może być to, co jest w historii opowiedziane, ale to może być zupełnie nieintuicyjne dla zarządzających. Więc będąc na pozycji pytającego, raczej bym zastanowił, jaką ja przyjmuję narrację, chcę pomóc organizacji podnieść jej efektywność i przyjrzałbym się kosztom i przychodom, jakby w stronie tej tutaj zasobowej, w stronie procesowej i w stronie tutaj uzyskiwanych korzyści. I to raczej z tej puli używał argumentów, że na przykład nie tworzymy zespołów z dużym context switchingiem, bo przez to, choć nie mamy takiej intencji, to cała organizacja spowalnia, zamiast przyspieszać, co jest potrzebne.

Jacek: No to była moja taka pierwsza myśl, jak to pytanie przeczytałem na takiej zasadzie, że może być tak, że w tym konkretnym kontekście ta decyzja jest słuszna, na takiej zasadzie, że niech teoria na temat przełączania kontekstu nie jest naszym jedynym orężem w dyskusji. No bo tak, co do zasady, no to wiadomo, lepiej nie przełączać kontekstu, może być tak, że są mocne argumenty na to, żeby jednak tę nazwijmy rekomendację łamać. I być może jest bardzo dobre wytłumaczenie biznesowe, dlaczego nie pójdziemy za dobrą praktyką, tylko zrobimy to inaczej, tylko być może to nie jest jasne dla organizacji. Czyli patrząc z boku, no to ktoś podejmuje decyzje, które powodują nieefektywność, ale być może jest tak, że biznesowo to ma jakieś tam bardzo sensowne uzasadnienie. To, co z kolei zwróciło moją uwagę, dodatkowo to jest tutaj ten komentarz, że tutaj mówimy o dwukrotnej ilości spotkań. Być może to nie jest wcale konieczne, może na ten aspekt trzeba byłoby spojrzeć z innej perspektywy. Wyobrażam sobie tutaj, dopowiadam, że zakładam, że ta osoba w obu zespołach jest literalnie na wszystkich spotkaniach, no nie wiemy, ile tych spotkań jest, ale zakładam, że jakaś tam licząca ilość. Być może to jest jakiś element, który warto byłoby zdiagnozować, zobaczyć, sprawdzić, poddać pod wątpliwość, czy naprawdę i na pewno musi być tak, że ta konkretna osoba czy osoby muszą być literalnie na każdym spotkaniu. Powiem dodatkowo, jeżeli już są na tym spotkaniu, czy naprawdę muszą być od samego początku do końca. Bo być może tutaj jest jakiś taki suwak, który możemy sobie poprzesuwać w prawo, w lewo, no i spowodować, że trochę tego czasu spędzanego na spotkaniach, zakładam w domyśle, że być może nieefektywnego odzyskać. 

Kuba: Jak słyszysz, trochę spekulujemy w tym pytaniu, bo trochę nie znamy kontekstu konkretnej organizacji, tylko z tych informacji, które mamy, potrafimy sobie tutaj znaki zapytania poumiejscawiać, natomiast na takim metapoziomie jednak zwrócę uwagę na pewną kwestię. Sam fakt, że to jest organizacja, która dynamicznie rośnie, potrzebuje się skalować, management ma jakiś swój pomysł, powoduje, że już zarówno ja wcześniej, jak i przed chwilą Jacek, zanegowaliśmy kilka dobrych praktyk. Tutaj bądźmy bardzo ostrożni w takim ślepym implementowaniu dobrych praktyk na temat wielkości zespołu, skupienia zespołu, pewnych praktyk spotykania się zespołu, tworzenia trwałości zespołu. Te wszystkie kwestie, one fajnie wyglądają na papierze, one są też bardzo przekonywające w realiach środowisk, w których pewnego rodzaju stabilność jest taka, bym powiedział, akceptowalna i w miarę do opanowania i może być kompletnie do przekreślenia, jeśli mamy do czynienia z organizacją bardzo zmienną, albo momentem w organizacji, jeszcze w historii organizacji, który aktualnie jest bardzo dynamiczny, bardzo niepewny, bardzo zmieniający się. Więc tutaj bądźmy bardzo czujni na to, że zwłaszcza takie bardzo podstawowe, bardzo proste recepty, co do tego, co to znaczy dobry zespół, albo jak się powinno pracować, one mogą być kompletnie nietrafione dla kontekstu bardzo innowacyjnej, bardzo dynamicznej organizacji. I to jest moja mocna przestroga, zwłaszcza dla tych z naszych słuchaczy, którzy na przykład mają do czynienia z agile’em w kontekście korporacyjnym, czy takich dużych organizacji, banki, ubezpieczalnie, jakieś bardzo duże software house, czy jakieś firmy, a też na przykład handlowe, które mają po prostu bardzo dużą skalę, ale też relatywnie nie aż tak dużą zmienność. One potrzebują agile’a, ale z trochę innych powodów. Tutaj w kontekście tej historii jednak słyszę, czy między wierszami czytam historię o organizacji, która jednak jest trochę bardziej dynamiczna. Więc tutaj bądźmy bardzo dopasowani do kontekstu i, zwłaszcza jeśli mówimy tutaj o agile’u, to jednak znowu wracamy do esencji agile’a. Skupmy się na tym, żeby uzyskiwać esencję agile’a, dowozić, dostarczać wartość, iterować, a to, czy po drodze trochę pogrzeszymy przeciwko świętemu Scrumowi, to niech to będzie najmniejszy nasz problem. I nawet jeśli nie zgadzamy się w którymś miejscu z jakąś książką, którą kiedyś poznaliśmy, ale działa, to może czas napisać naszą własną książkę, dlaczego ta nasza metoda zadziałała, lub po prostu zrozumieć kontekst, w którym pewne rzeczy nie są uniwersalną prawdą. Bo tak w ogóle w tym naszym złożonym środowisku mało co jest taką uniwersalną prawdą.

Jacek: No dobrze. Przechodzimy do ostatniego pytania dzisiejszej sesji Q&A i pytanie brzmi następująco. Jak pracować z ludźmi posiadającymi waterfallowy mindset, którzy chcą co do MD rozliczać DEF i betonują w głowie terminy wynikające z road mapy. Budujemy nowy produkt, zespół niedojrzały, nieprzewidywalny, POS zarządza zespołem, a jego przełożony rozlicza każdą minutę na timesheet.

Kuba: Tutaj mamy do czynienia ze sporym zagęszczeniem business ponglish, czyli jakiegoś takiego miksu języka angielskiego, biznesowego i polskiego, więc tutaj jak rozumiem z pytania, mamy do czynienia z sytuacją, w której przełożony zespołu czy też może również Product Ownera bardzo drobiazgowo rozlicza minuty pracy każdego członka zespołu, każe im raportować, co robią, każe im rozliczać się z tego, co wykonali, rozlicza też, jak mogę sobie to powiedzieć, rozlicza również odstępstwa, czyli również każe mocno deklarować, ile co zajmie, a później bardzo mocno też się tego trzyma i każe się tego z tego tłumaczyć, tłumaczyć również z terminów. Czyli tutaj pewnych obietnic z większego rzędu, że pewne funkcje, czy pewne projekty, czy pewne większe zadania zostaną zrealizowane na konkretną datę. Co powiedzieć, byliśmy tam, widzieliśmy to, może w naszych organizacjach, w których agile’a się uczyliśmy, tak nie było, ale później u niektórych klientów takie postacie spotykamy. No i temat oczywiście prosty nie jest. Pierwsza myśl, która mi przychodzi do głowy, to tutaj jest rozmowa o tym, jak w ogóle ugruntowane jest podejście zwinne w tej organizacji. Czyli tutaj ten przełożony, zabetonowany na terminy i rozliczający ludzi z każdego dnia roboczego, no prawdopodobnie działa w takim klasycznym stylu, albo dotychczasowym stylu, jaki w tej organizacji funkcjonował, a może w poprzednich organizacjach tego przełożonego, jeśli to jest osoba, która przyszła. Pytanie, gdzie są rodzice? Tak naprawdę pytanie, gdzie jest przełożony tego przełożonego? Gdzie są jacyś liderzy transformacji zwinnej i czy z tymi osobami ktoś pracuje? Czy liderzy transformacji widzą, że styl zarządzania przełożonych zespołów pozostał bez zmiany i stoi akurat w tym konkretnym przypadku w totalnej sprzeczności z filozofią podejścia zwinnego. Jest bardzo duża rozbieżność między posiadaniem kontroli, posiadaniem zrozumienia, gdzie zespoły są, posiadanie kontroli też nad budżetem, czasem postępami, to są wszystko wartościowe rzeczy, ale nie można ich robić w takim stylu, jaki wybrzmiewa trochę z klimatu zadanego pytania. Więc tutaj, gdybym miał powiedzieć, jak pracować z takimi ludźmi, to szczerze mówiąc, nie do nich najpierw bym poszedł, do tych tutaj betonujących terminy, tylko udałbym się do jakiegoś lidera lub grupy liderów transformacji zwinnej w organizacji, jakiegoś sojusznika agile’a dla tej organizacji i porozmawiał, jak pracują z managementem lub sam rozpoczął pewne nurty związane z pracą z managementem.

Jacek: Tak, to co Kuba powiedział myślę jest sensownym krokiem takim systemowym i zdecydowanie się z tym zgadzam. Wchodząc trochę w buty tej osoby, która no może musi z czymś zacząć pracować i działać, to sobie myślę o tym, że chyba po prostu zacząłbym rozmawiać z tą osobą na zasadzie, w myśl takiej koncepcji, że zmiana zaczyna się od momentu, kiedy zaczynamy o niej rozmawiać i może być tak, że po prostu zabrakło komunikacji, że się zmieniamy, zabrakło zarządzania, no i po prostu ten manager, tak jak pracował zawsze i najwyraźniej to działało, no po prostu kontynuuje swoją pracę. A widać z tej opowieści, że świat dookoła się zmienił. Na zasadzie, pojawił się, chociażby ktoś w organizacji, kto widzi, że to chyba nie do końca o to chodzi. Wyobrażam sobie, że zwinność też została już odmieniona przez co najmniej kilka przypadków. I być może, tak empatyzując ta osoba, po prostu została sama sobie no i po prostu działa, robi co może. I mam takie przypadki, że po prostu zwykłe rozpoczęcie dialogu z taką osobą przynosi sensowne rezultaty. Mamy masę przykładów, czy Product Ownerów takich, czy managerów, którzy w odpowiedzi na taką rozmowę zaczynali odkrywać zwinność, zaczynali dostrzegać, że ten styl, który akurat wykorzystują, być może można usprawnić, można go ulepszyć. Tak naprawdę okazywały się na koniec dnia, okazywały się bardzo otwartymi osobami. Ale żeby nie było tak kolorowo, może być też tak, że ten case to jest taka wysepka na morzu. Czyli cała wyspa się, całe morze to już jest zmieniona organizacja, a tutaj mamy do czynienia z osobą, którą można nazwać, by tam było hamulcowym opornikiem, czy jakkolwiek sobie to nazwiemy. No i tutaj oczywiście te strategie jakby tutaj się bardziej skłaniam do tego, co powiedział Kuba, czyli że być może to już jest coś w stylu, że musimy ten temat eskalować. No bo próba przekonania ludzi nieprzekonanych może spowodować, że tak naprawdę tracimy energię i potencjał nie w tym miejscu, w którym tak naprawdę powinniśmy spędzać nasz czas i poświęcać naszą uwagę.

Kuba: Natomiast podoba mi się Twoja empatia, bo teraz spróbuję być może bardziej taki przyziemny. Na bazie Twojej empatii zbuduję jeszcze jedną poradę, która jest trochę inna niż eskaluj albo idź do członka zarządu, który uruchomił transformację zwinną. Coś, na czym czasem łapię Scrum Masterów, którzy pracują z tego rodzaju managementem, o którym jest to pytanie, to to, że natychmiast wpada się w rejestry „źle zarządzasz ludźmi” albo rejestry „nie, w agile’u to tak nie wygląda” i nawet może pierwsza moja myśl była właśnie w tę stronę. Natomiast może być taki trik, że trzeba tym ludziom dać zastępnik, taką nową agile’ową analogię na to, co uzyskiwali do tej pory. I tutaj tylko dwa ślady tego, o co mi chodzi. Jeśli do tej pory bardzo drobiazgowo rozliczali ludzi, to warto może porozmawiać jak ma management kontrolę nad zwinnym zespołem. Wyjaśnić jakby interakcje pożądane na Sprint Review, pokazać raporty, czy mierniki, które można sobie budować na bazie istniejącego zespołu. Pokazać wartość biznesową dostarczoną co Sprint. Również być może, jeśli jest taka obiektywna potrzeba, rozmawiać o pewnego rodzaju prognozowaniu i monitorowaniu postępu pracy, jakiejś większej inicjatywy, żeby tutaj nie wpaść w taką pułapkę, że albo agile’owo, albo betonowo i nie ma nic pomiędzy. Myślę, że jest jeszcze sporo pomiędzy, gdzie możemy spróbować zrobić krok w stronę potrzeb takiego managera, który być może obiektywnie mają jakiś swój sens i teraz ten manager realizuje to dzisiaj w bardzo bezsensowny sposób, bardzo niezgodne z agile’em. A możemy, zamiast przekonać, żeby tego managera, żeby nie realizował tej swojej kontroli, może musimy mu dać po prostu jakieś nowe, nazwijmy to rozwiązania, zabawki, jakieś takie analogie, że może nie będzie miał tego, co było do tej pory, ale jednak coś będzie mieć. I bardzo konkretny pakiet, który możemy zaoferować takiej osobie. Być może ten pakiet jest czymś, co będzie spotkaniem się w połowie drogi, to nie będzie może najbardziej zwinny zespół na świecie i pewne praktyki będą mimo wszystko nadal kontrowersyjne, ale będzie lepiej. Nie będzie na przykład braku zaufania i być może uruchomimy pewną perspektywę oswajania się tego betonowego managera z tą rzeczywistością zwinną. Więc wyobrażam sobie, że tutaj każdy Scrum Master, czy Agile Coach, ale również Product Owner może musi umieć pokazać swoje alternatywy, czy odpowiedniki na posiadanie kontroli przez management. Kontroli nad budżetem, postępami, kontroli też nad tym, że praca po prostu idzie do przodu. Moim zdaniem management ma prawo posiadać taki dostęp do pewnej wiedzy i agile daje narzędzia do tego, żeby tak było.

Jacek: Jest taka koncepcja, z którą się kiedyś spotkałem tak zwanych adapterów, czyli organizacja wymaga od nas, trzymajmy się tego sporego uproszczenia jakichś takich danych i parametrów waterfallowych. Czyli na przykład te rozliczane minuty, no to ta koncepcja adapterów zakłada, że my jako zespół dostarczamy to tym, którzy tego potrzebują, tych informacji, natomiast jakby pod spodem zaczynamy już tę swoją transformację i zaczynamy pracować w inny sposób. I to nam daje, nazwijmy to pewien czas, po to, żebyśmy my się mogli rozwijać. Na razie organizacja, być może, czy ten manager, tak powiedziałem organizacja ogólnie, nie jest jeszcze gotowa na to, żeby zrezygnować z tego starego sposobu rozliczania, No więc być może na bazie pewnych uproszczeń, założeń jesteśmy w stanie te rozliczenia jakoś tam prowadzić, natomiast nie jest to z mojej perspektywy rozwiązanie permanentne, tylko to jest coś takiego, co nazwijmy to kupuje nam czas, no, żeby przeprowadzić tą właściwą, głęboką rozmowę, czyli no właściwie te porady, które pojawiły się na początku, jak zaczęliśmy to pytanie z Kubą rozpracowywać.

Kuba: No dobra, to odpowiedzieliśmy na 8 pytań, ale nie odpowiedzieliśmy na wszystkie te, które zostały zadane, więc tutaj dziękujemy za te pytania, wrócimy do nich w kolejnej części. Już odpowiedź na te 8 pytań dała nam długi odcinek, pewnie jeden z dłuższych w naszej historii, ale jeśli czujesz, że jakieś zagadnienie nie zostało wyczerpane i zasługuje na jakiś osobny odcinek, na poruszenie tego jeszcze głębiej niż to, co zrobiliśmy, chętnie to zrobimy, nie uciekamy od wątków, ale potrzebujemy konkretnych pytań, konkretnych podpowiedzi, konkretnych sugestii, w którą stronę mamy pogłębić lub poszerzyć dane zagadnienie.

Jacek: Sporo naszych reakcji na te pytania, to była jednego rodzaju diagnoza i spojrzenie z boku na to, co myślimy i jak można sobie poradzić z tymi sytuacjami, które zostały opisane. Tego rodzaju diagnozę przeprowadzamy dla organizacji, które są zainteresowane tym, żeby ktoś z boku ekspercko spojrzał na to, jak wykorzystywana jest zwinność, wskazał słabsze punkty i zarekomendował jakieś konkretne akcje usprawniające. Jeżeli takie spojrzenie z boku na to, jak zwinność funkcjonuje w twojej firmie brzmi dla ciebie ciekawe, to zapraszamy do naszej strony porzadnyagile.pl/diagnoza-zwinnosci lub o prostu kliknij w “Menu” na nowo utworzony dział współpraca. Na razie znajduje się tam tylko diagnoza podejścia zwinnego w Twojej organizacji, natomiast spodziewaj się, że wkrótce inne nasze produkty również będą tam dostępne.

Kuba: Natomiast notatki do tego odcinka, artykuł, transkrypcja naszej rozmowy, zapis wideo znajdziesz na stronie porzadnyagile.pl/119.

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

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