Porządny Agile

Czy wiesz, że ślepe podążanie za jednym modelem pracy może ograniczać Twój zespół? Nie istnieje jedna najlepsza metoda pracy. Dowiesz się jak łączyć różne podejścia i narzędzia, aby osiągać najlepsze efekty. Poznaj sześć inspiracji spoza agile, takich jak zarządzanie projektami, Lean, czy automatyzacja, które mogą odmienić sposób pracy Twojego zespołu. Porządny Agile · Jedna najlepsza metoda pracy nie istnieje Tytuł może brzmieć zaczepnie, ale dobrze oddaje istotę tego, o czym chcemy dzisiaj napisać. Ten materiał będzie o tym, jak czerpać z różnych podejść, łączyć je i dopasowywać do kontekstu, aby osiągać sensowne efekty. Wymieniamy poniżej sześć konkretnych inspiracji, które naszym zdaniem warto rozważyć, a które wykraczają poza klasyczne metody zwinne. Zarządzanie Projektami W zależności od twojego doświadczenia, firmy, w której pracujesz, oraz roli, jaką pełnisz, może cię to albo zaskakiwać, albo wydawać się oczywiste. Zarządzanie projektami często bywa przedstawiane jako przeciwieństwo podejścia zwinnego. Z tego powodu niektórzy na starcie odrzucają wszystko, co wiąże się z tym szerokim obszarem skutecznego zarządzania inicjatywami. Mamy doświadczenie zarówno w koordynowaniu projektów, jak i w ich zarządzaniu. Sięganie po narzędzia i techniki projektowe jest dla nas czymś naturalnym. Jednak obserwując rynek, widzimy, że wcale nie jest to tak powszechne podejście. Dlatego nieprzypadkowo umieszczamy zarządzanie projektami na pierwszym miejscu tej listy. Dlaczego zarządzanie projektami przyda się w zwinnej organizacji, zwinnym zespole czy produkcie? Wiele inicjatyw, które są realizowane przez takie zespoły, w praktyce faktycznie jest projektami . Zwłaszcza jeśli spojrzymy na to od strony czystej teorii. Konkretne praktyki, sposoby myślenia i organizowania przedsięwzięć wynikające z solidnych podstaw zarządzania projektami mogą okazać się wręcz niezbędne. Odrzucanie koncepcji zarządzania projektami może oznaczać niepotrzebne zamykanie się na zestaw narzędzi, które mogłyby być wartościowe. Dlatego warto sięgnąć po inspiracje płynące z tego obszaru. Wykres Gantta Jako konkretne narzędzie z zarządzania projektami wybraliśmy wykres Gantta. Bywa odrzucany na zasadzie „to jest ten stary, zły project management, a my przecież teraz pracujemy zwinnie”. Uważamy, że sama metoda może być bardzo pomocna w każdym zespole.  Jak zastosować wykres Gantta w praktyce zwinnego zespołu? Jacek wykorzystywał planowanie inspirowane wykresem Gantta do organizowania pracy na Sprint. Jego zespół starał się dobrze rozrysować kolejność działań, określić, kto będzie się czym zajmował, oszacować czas pracy. Mając przed oczami taki plan mógł zidentyfikować zależności i elementy krytyczne. Dzięki temu zespół wiedział, co musi zostać ukończone wcześniej, aby umożliwić kolejne kroki. Takie podejście bardzo dobrze działało – osiągali Cele Sprintu, mieli dobrą przewidywalność i lepszą kontrolę nad postępem. Wykres Gantta jako narzędzie jest adekwatny, ale kluczowe jest to, jak go umiejętnie połączyć ze zwinnością. Jedną z praktyk może być zespołowe planowanie pracy. Zauważ, że w powyższej historii o zespole Jacka cały zespół uczestniczył w tym procesie. Razem budowali plan, razem wyceniali, razem układali harmonogram. Wszyscy rozumieli, na czym polega struktura pracy, bo wykres Gantta jest narzędziem intuicyjnym. Oprócz zastosowania do planowania Sprintu, Wykres Gantta w zwinnych zespołach można też wykorzystać między innymi do: planowania wdrożenia,  planowania skomplikowanej migracji, koordynacji pracy wielu zespołów.  Zarządzanie finansami Często zwinne zespoły, zwłaszcza te zbyt mocno zapatrzone w konkretne frameworki, dystansują się od twardego świata finansów. Rozliczenia, budżetowanie, planowanie cash flow – te pojęcia bywają traktowane jako coś obcego, nienależącego do ich rzeczywistości. Dla wielu osób mogą to być terminy niezrozumiałe albo kojarzone z klasycznym, starym stylem zarządzania. Światem osobnych działów i specjalistów, którzy wymagają uzupełnionego szablonu i operują założeniami obcymi w zwinnym świecie. Widzimy niepokojący trend postrzegania agile’a jako narzędzia do poprawy komfortu zespołu, zamiast sposobu na osiąganie rezultatów biznesowych, również finansowych. Naszym zdaniem odseparowanie świata finansów od świata zwinności jest błędem. Jeśli organizacja rozwija produkty, usługi, czy też realizuje duże inicjatywy, to świadomość finansowa zespołu jest kluczowa.Na pewnym poziomie organizacyjnym dochodzi zawsze do zainteresowania kosztami, budżetowaniem i sposobem rozliczania pracy. Jeśli każda rozmowa o finansach będzie wywoływać dystans, to bardzo łatwo zbudować wizerunek zespołu, który nie rozumie realiów biznesowych. A przecież zespół nie działa w próżni – każda inicjatywa kosztuje, a firma inwestuje po to, żeby zarobić. Koszt Sprintu Konkretna praktyka, którą proponujemy, to monitorowanie i kontroling kosztów per Sprint. Sprowadza się to do dosyć prostego pytania: ile kosztuje firmę jeden Sprint danego zespołu? Nie chodzi o to, by porównywać zespoły między sobą, bo już sam różny skład osobowy sprawia, że koszty będą inne. Chodzi raczej o uświadomienie tego zespołowi i osobom zarządzającym procesem. Daje to szansę na podejmowanie lepszych decyzji menedżerskich dotyczących kosztów pracy i wartości, jaką dany zespół generuje. To podejście składa się z dwóch kluczowych elementów:  jakie są faktyczne czynniki kosztów – nie tylko koszty osobowe, ale także wszelkie dodatkowe wydatki; jak te koszty są liczone, jakie są ich typy i jak wpływają na organizację. Dla zespołu może to być nowa perspektywa, ale dla zarządzania całą firmą ma to ogromne znaczenie. Jest to ważne zarówno w kontekście efektywności pracy, jak i strategicznego podejmowania decyzji. Pamiętamy bardzo żywą reakcję zespołu, kiedy dowiedzieli się, że koszt jednego Sprintu wynosi kilkadziesiąt tysięcy złotych. Padł wtedy komentarz: „A my w tym Sprincie dowozimy tylko jakiś prosty checkbox na interfejsie użytkownika”. To był moment przełomowy – pojawiło się u nich poczucie, że każda zmiana, nawet najmniejsza, ma swój realny koszt. Ta świadomość skłoniła zespół do głębszej refleksji: czy na pewno wszystkie zaplanowane rzeczy są konieczne? Czy na pewno muszą być realizowane w tak szerokim zakresie? Zaczęli postrzegać swoją pracę nie tylko jako wykonywanie kolejnych zadań, ale jako inwestycję. Ostatecznie, żeby organizacja mogła działać, zapewniać wynagrodzenia, benefity i – w bardziej humorystycznym tonie – owocowe czwartki, firma musi generować przychody.  Przywództwo Jest wiele teorii zarządzania, które podkreślają, że w zależności od sytuacji i kontekstu należy stosować różne podejścia. Niewłaściwe zrozumienie koncepcji samorganizacji i samozarządzania może osłabić pozycję lidera. Może to prowadzić do sytuacji, w których oczekiwane i potrzebne są zdecydowane reakcje, a w rzeczywistości ich nie ma. Zwinne metody często zakładają, że ma się do czynienia z doświadczonym, zaangażowanym i zmotywowanym zespołem. Taki zespół sprawnie podejmuje decyzje, a jeśli pojawi się konieczność korekty – szybko ją wdraża. To są wartościowe postawy w wielu sytuacjach, jednak nie zawsze będą najlepszym wyborem. Co o roli przywództwa wspominają konkretne modele zarządzania? Situational Leadership – koncepcja znana z modeli Blancharda jasno mówi, że duża swoboda, przekazywanie odpowiedzialności i wyznaczanie celów bez ścisłej kontroli sprawdzają się u jednostek (i w efekcie – w zespołach) o wysokim poziomie dojrzałości i doświadczenia. Jeśli zespół jako całość jest początkujący, jeśli jego członkowie dopiero uczą się pracy w danym kontekście, to pełna autonomia może prowadzić do impasu lub błędnych decyzji. W takich przypadkach bardziej efektywne może być podejście, w którym lider zapewnia większe wsparcie i kierunek. Cynefin – koncepcja Snowdena podkreśla, że w sytuacjach złożonych zespoły mogą skutecznie eksperymentować i podejmować decyzje w sposób iteracyjny. Natomiast w sytuacjach chaotycznych, gdy konieczna jest natychmiastowa reakcja, potrzebne jest szybkie podejmowanie decyzji i wyznaczenie jasnego kierunku działania. W takich momentach nadmierne czekanie na samoorganizację zespołu może pogłębić problem. Obie koncepcje wskazują na to, że domyślne podejście zwinne, oparte na zespołowej współodpowiedzialności, nie zawsze jest najlepszym rozwiązaniem. Dobór odpowiedniego stylu zarządzania powinien zależeć od kontekstu i poziomu dojrzałości zespołu. Zachęcamy, by nie wykluczać wyraźnego i mocnego przywództwa w przypadkach, które tego wymagają. Koncepcja zarządzania Lean Kolejną inspiracją, którą uważamy za wartą rozważenia, jest koncepcja zarządzania Lean. Lean Management, znany z fabryk i optymalizacji procesów w firmach, składa się z wielu konkretnych praktyk oraz całej filozofii. W pewnym stopniu oddaje ją polskie tłumaczenie (choć niezbyt przez nas lubiane) – szczupłe zarządzanie. Jest to podejście ukierunkowane na szukanie okazji do optymalizacji procesów, obniżania kosztów oraz maksymalizowania wartości dodanej. Wartości zarówno z perspektywy klienta końcowego, jak i klienta procesu czy wartości uzyskanej z danej inicjatywy. Jak Lean łączy się ze Scrumem? Kilkanaście lat temu mieliśmy okazję uczestniczyć w szkoleniu prowadzonym przez Jeffa Sutherlanda, jednego ze współtwórców Scruma. W nazwie szkolenia oczywiście pojawiało się odniesienie do Scruma, ale zaskoczyło nas, to jak wiele miejsca prowadzący poświęcił Leanowi. Całe duże bloki i ćwiczenia dotyczyły m.in. identyfikowania marnotrawstwa, sposobów mierzenia procesów i eliminowania zbędnych działań. Było to dla nas niemałym zaskoczeniem, ponieważ spodziewaliśmy się bardziej „scrumowej” treści. Tymczasem okazało się, że zostaliśmy nakarmieni solidną porcją konkretnych narzędzi Lean, które można wykorzystać w pracy z zespołami. Raport A3 Jedną z praktyk, którą szczególnie rekomendujemy w kontekście Leana, jest raport A3. To klasyczna leanowa koncepcja wspierająca usprawnianie procesów poprzez ustrukturyzowane podejście do problemów. Można go potraktować jak schemat czy szablon, ale jego istotą nie jest samo wypełnianie kartki A3. Ważne jest przemyślenie kluczowych aspektów sytuacji: Jaki jest problem? Co stanowi główny bloker? Jaki jest kontekst sytuacji? Jakie są źródłowe przyczyny problemu? Jakie istnieją pomysły na usprawnienie? Uczestniczyliśmy również w klasycznym szkoleniu Lean kilka lat temu. Było to jedno z najbardziej wartościowych wydarzeń tamtego roku. Pełne było praktycznych wskazówek, a jednocześnie relatywnie tanie w porównaniu do typowych szkoleń agile’owych czy menedżerskich. Mieliśmy też okazję odwiedzić firmę, która działała w pełni zgodnie z Leanem. W każdym miejscu, gdzie pracował zespół, znajdowały się specjalne przegródki z wypełnionymi raportami A3 dotyczącymi usprawnień – tych już wdrożonych lub będących w trakcie realizacji. To świetna praktyka, którą warto przeszczepić do zespołów wytwórczych. Uczy ustrukturyzowanego podejścia do problemów, analizowania ich przyczyn i wdrażania eksperymentalnych usprawnień w duchu Kaizen. W szczególności rekomendujemy tę praktykę, jeśli czujesz, że twoje zespoły dużo czasu spędzają rozmowach o na usprawnieniach, ale masz poczucie, że nie przynosi to namacalnych efektów.. Inżynieria oprogramowania  Zwinność w realiach wielu firm nieodłącznie łączy się z procesem wytwarzania oprogramowania. Inżynieria oprogramowania to szeroka dziedzina, obejmująca wiele wątków – od zebrania wymagań, przez projektowanie, implementację, testowanie, aż po wdrożenie. Mamy jednak poczucie, że często traktuje się ją jako coś przestarzałego. Niektórzy uważają że teorie te były adekwatne dawno temu i nie warto do tego wracać. A zdecydowanie nie powinno tak być. Wszechobecna automatyzacja Jedną z kluczowych inspiracji, które można wynieść z inżynierii oprogramowania, jest wszechobecna automatyzacja. Niezależnie od etapu procesu, warto dbać o to, by jak najwięcej rzeczy było zautomatyzowanych. Zarówno w programowaniu, sprawdzaniu jakości, wdrażaniu, czy monitorowaniu działania systemu i infrastruktury. Są to po prostu dobre praktyki inżynierskie, a jednak często automatyzacja jest pomijana. Zamiast tego w wielu organizacjach wciąż widzimy procesy, które mogłyby być usprawnione, a mimo to są wykonywane ręcznie. Jeśli brak Ci technicznego backgroundu, to gorąco zachęcamy do rozwijania choćby podstawowej wiedzy o nowoczesnej, zdrowo rozumianej inżynierii oprogramowania.  Rekomendujemy przykładowo lekturę książki „Pragmatyczny programista”. Zawarte w niej metody i techniki to przede wszystkim zdroworozsądkowe, pragmatyczne podejście do wykorzystania zwinności w procesie wytwarzania oprogramowania. Zarządzanie zmianą Wiele zespołów zwinnych nieodłącznie wiąże się ze zmianą. Same się zmieniają, zmieniają swoją firmę, rynek, a także produkt, nad którym pracują. Jednak obserwujemy, że zespoły nie korzystają z gotowych narzędzi, koncepcji i strategii związanych z zarządzaniem zmianą. Mimo że świat od lat mierzy się z tym wyzwaniem i zdążył już wypracować skuteczne rozwiązania. Zamiast tego zespoły często próbują metodą prób i błędów odkryć rzeczywistość na nowo, co nie zawsze prowadzi do najlepszych efektów. Temat zarządzania zmianą może być szczególnie istotny, jeśli faktycznie wykorzystujesz podejście zwinne w swojej organizacji. Częścią tego podejścia jest poszukiwanie lepszych rozwiązań, ale żeby te pomysły – niezależnie od tego, czy pochodzą od ciebie, czy od twoich zespołów – miały realną szansę na wdrożenie.   Zarządzanie zmianą jest nam bardzo bliskie, ponieważ często wspieramy firmy w przechodzeniu przez proces zmiany. ADKAR Konkretnym narzędziem, które rekomendujemy i stosujemy jest model zarządzania zmianą ADKAR. ADKAR pochodzi od angielskich słów: Awareness, Desire, Knowledge, Ability i Reinforcement. Nie będziemy szczegółowo rozwijać jego założeń, ale warto podkreślić, że jest to model koncentrujący się na zmianie na poziomie indywidualnym. Zakłada on, że każda osoba musi: rozumieć zmianę,  chcieć zmiany, znać jej podstawowe założenia,  umieć wdrożyć ją w praktyce, otrzymać wzmocnienie.  Choć model ADKAR koncentruje się na pojedynczej osobie, widzimy jego skuteczność również na poziomie zespołów, działów, a nawet całych organizacji. Jak ADKAR przekłada się na zwinny zespół? Wyobraź sobie, że odkrywasz problem z niską przewidywalnością pracy zespołu. Warto najpierw zbudować świadomość wśród członków zespołu, że to faktycznie jest problem. Pokazać jakie są realne konsekwencje i że nie można tego ignorować. Następnie należy popracować z poszczególnymi osobami, upewniając się, że są na pokładzie, rozumieją sytuację i chcą zmian. Kolejny etap to dostarczenie wiedzy. Jeśli chcesz poprawić przewidywalność w zespole, być może jego członkowie muszą nauczyć się lepszego planowania zespołowego. Muszą umieć wprowadzić miary i narzędzia wspierające przewidywalność. Następnie daj wsparcie zespołowi, aby mógł wykorzystać powyższe rzeczy w praktyce. Wysłanie na szkolenie czy podesłanie artykułu może nie wystarczyć, jeśli nie dasz przestrzeni na wdrożenie tej wiedzy w codziennej pracy. Na koniec pojawia się wzmocnienie. Ważne, aby liderzy podkreślali pozytywne efekty zmiany, pokazywali różnicę między stanem sprzed i po wdrożeniu nowego podejścia. Dzięki temu ludzie zobaczą, że włożony wysiłek przyniósł realne korzyści i że warto podejmować kolejne kroki w kierunku usprawnień. Kontrowersje przy stosowaniu różnych koncepcji zarządzania Przedstawiliśmy sześć koncepcji, które według naszych doświadczeń nie zawsze są wykorzystywane i uwzględniane w organizacjach inspirujących się podejściem zwinnym. Łatwo jest zanegować te podejścia, wpaść w myślenie stereotypami lub stosować uproszczoną krytykę, odrzucając wszystko, o czym wspomnieliśmy. zarządzanie projektami – można spotkać się z opinią, że to bardzo predykcyjne podejście do świata, które daje złudne poczucie kontroli,  zarządzanie finansami  – wielka biurokracja, która nie daje wartości,  przywództwo – micromanagement, zabija samoorganizację, czego należy unikać, koncepcja zarządzania lean – software development to przecież nie fabryka,  inżynieria oprogramowania – to praktyki ze świata Waterfall od którego uciekliśmy poprzez zwinną transformację, zarządzanie zmianą – zgodnie z Manifestem Agile chcemy odpowiadać na zmianę, a nie podążać za jakimś planem. Celowo pobawiliśmy się stereotypami i ogólnikami, ale w każdym z tych stwierdzeń jest ziarno prawdy. My jednak chcemy tym artykułem zachęcić do inspirowania się i przełamywania schematów, zamiast odrzucania tych koncepcji. Przyszłość leży w podejściu pragmatycznym – zamiast szufladkowania warto skupić się na tym, co przynosi dobre rezultaty. Kluczowe jest czerpanie z różnych źródeł, które faktycznie wnoszą wartość i mogą wspierać naszą organizację w osiąganiu lepszych efektów. Warto jednak zachować ostrożność przy mieszaniem konceptów. Niektóre praktyki dobrze się ze sobą łączą, inne mają wspólne punkty, które wzajemnie się wspierają, ale nie wszystko warto łączyć na siłę i bezrefleksyjnie. Zachęcamy do czerpania z różnych podejść, ale z rozwagą. Ważne, żeby nie łączyć elementów, które wzajemnie się znoszą lub osłabiają swoje zalety. Zdecydowanie warto też dać sobie czas na sprawdzenie rezultatów. Testowanie koncepcji zarządzania to wartościowa droga, ale trzeba podejść do tego z rozsądkiem. Warto mieć punkt odniesienia, który pozwoli ocenić, czy faktycznie dana metoda przynosi korzyści. Spróbuj podejść do tego rzetelnie – przygotuj się, poczytaj, skonsultuj się z kimś, kto ma już w tym doświadczenie. Dzięki temu unikniesz sytuacji, w której niewłaściwe wdrożenie sprawi, że nie zobaczysz realnych rezultatów. Daj sobie również minimalny czas na obserwację efektów. Jedno nieudane spotkanie planistyczne nie oznacza jeszcze, że planowanie jest bez sensu. Może to być jedynie sygnał, że warto w nie zainwestować więcej czasu, doradztwa lub wsparcia od osób, które mogą pomóc zrobić to lepiej. The Oath of Non-Allegiance Ten artykuł kończymy inspiracją od Alistaira Cockburna, który jest niezmiennie naszym guru w obszarze zaawansowanego stosowania zwinnych metod. Alistair propaguje coś, o czym wspominaliśmy już wcześniej – koncepcję The Oath of Non-Allegiance. Nie ma bezpośredniego polskiego tłumaczenia, ale można to określić jako przysięgę niewierności. W dużym uproszczeniu oznacza ona zobowiązanie do nieodrzucania żadnej idei tylko dlatego, że pochodzi z konkretnego źródła. Niezależnie od tego, z jakiej szkoły czy nurtu pochodzi dana koncepcja, warto szukać tych, które najlepiej pasują do naszej sytuacji. Mówiąc prościej – nie ma znaczenia, skąd pochodzi dane narzędzie czy podejście. Jeśli działa i przynosi wartość, warto je rozważyć. Trzeba wyciągnąć własne wnioski, zamiast szufladkować je jako „zwinne” lub „niezwinne” i automatycznie odrzucać. To przede wszystkim zachęta do podchodzenia do różnych koncepcji zarówno z ciekawością, jak i ostrożnością. Może się zdarzyć, że eksperci będą mieć bardzo wyraziste zdanie na dany temat i wręcz dyskredytować inne podejścia. W takich sytuacjach zachęcamy, aby wysłuchać różnych opinii. Przemyśleć je, a na koniec samodzielnie zdecydować, czy świat faktycznie jest tak czarno-biały, jak bywa przedstawiany. FAQ: Jedna najlepsza metoda pracy nie istnieje Czy każda organizacja powinna stosować tylko zwinne podejście? Nie. Czasem praktyki z klasycznych metod, takie jak np. wykres Gantta, świetnie wspierają pracę zwinnych zespołów. Czy liderzy tracą swoją rolę w zwinnych zespołach? Wręcz przeciwnie! Silne przywództwo w kluczowych momentach, jak kryzysy, może znacząco zwiększyć skuteczność zespołu i przełamać impas. Co zrobić, by usprawnienia w zespole przynosiły realne efekty? Sięgnij po raport A3 z filozofii Lean – struktura, która pomaga systematycznie analizować problemy, poznać źródłowe przyczyny i znajdować skuteczne rozwiązania. Automatyzacja procesów – czy zawsze jest konieczna? Automatyzacja testów, wdrożeń czy monitoringu to nie tylko oszczędność czasu, ale też wyższa jakość i niezawodność produktów. Czy zarządzanie zmianą ma sens w zwinnych organizacjach? Tak. Model ADKAR pomaga płynnie wdrożyć zmiany: wewnątrz zespołu, w produkcie i reszcie organizacji. Jak łączyć różne metody zarządzania, by osiągać sukces? Kluczem jest pragmatyzm – wybieraj te narzędzia, które najlepiej pasują do Twojej sytuacji, bez przywiązania do konkretnej szkoły. Czy klasyczne zarządzanie projektami wciąż ma wartość? Tak! Choć zwinność jest popularna, zarządzanie projektami oferuje struktury i narzędzia, które świetnie uzupełniają zwinne podejście, jeśli zespół realizuje faktyczne projekty. Jakie inspiracje spoza agile’a warto znać i umieć stosować? Zarządzanie projektami – Zrozumienie klasycznego podejścia kaskadowego oraz koncepcji z nim powiązanych pozwala dopasować narzędzia do specyfiki zespołu i organizacji. Zarządzanie finansami – Świadomość kosztów ułatwia lepsze planowanie budżetów projektów i ich optymalizację. Dzięki temu można skuteczniej kontrolować ryzyko i unikać nieprzyjemnych niespodzianek finansowych. Przywództwo – Dobry lider z jednej strony daje przestrzeń w zespole do rozwoju, z drugiej potrafi wkroczyć i zarządzić sytuacją, gdy ta wymyka się spod kontroli zespołu. Koncepcja zarządzania Lean – Dzięki optymalizacji procesów i nieustannemu doskonaleniu organizacje mogą zwiększać swoją wydajność i szybko reagować na zmiany rynkowe. Ciągłe doskonalenie (Kaizen) czy skupienie na eliminacji marnotrastwa, pozwala zespołom zwiększać efektywność. Inżynieria oprogramowania – Dobra znajomość zasad inżynierii oprogramowania pomaga zespołom w tworzeniu skalowalnych i łatwych w utrzymaniu rozwiązań. Pozwala to podnieść jakość dostarczanego produktu. Zarządzanie zmianą – Każda organizacja musi umieć skutecznie wdrażać zmiany, by nie pozostawać w tyle za konkurencją. Wprowadzanie zmian w organizacji wymaga nie tylko technicznych umiejętności, ale też zrozumienia, jak ludzie reagują na zmiany. Po jakie podejścia związane z zarządzaniem spoza agile’a warto sięgnąć i dlaczego? Zarządzanie projektami Zarządzanie finansami Koncepcja zarządzania lean Inżynieria oprogramowania Zarządzanie zmianą Przywództwo Materiały dodatkowe Artykuł ze strony Planview na temat doboru metod pracy do kontekstu Punkt widzenia na temat różnych metod pracy ze strony ICAgile Opis metody Disciplined Agile Delivery, która rekomenduje hybrydowe i elastyczne podejście 📄Transkrypcja podcastu „Jedna najlepsza metoda pracy nie istnieje” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Tematem dzisiejszego odcinka jest – Jedna najlepsza metoda pracy nie istnieje. Temat jest taki zaczepny i oddaje istotę tego, co chcemy przekazać. Natomiast inspiracją do niego między innymi była pewna rozmowa, którą niedawno przeprowadziłem w firmie, którą wspieram jako doradca. Rozmawialiśmy o temacie metod pracy. W rozmowie uczestniczył jeden z dyrektorów, który do tej pory miał mniej do czynienia z moim wsparciem. No i porozmawialiśmy sobie na temat tego, jakie inicjatywy są realizowane, jaka jest ich charakterystyka, no i zgodnie z prawdą skwitowałem dosyć szybko, że w zasadzie akurat to, czym ta sfera się zajmuje, a był to temat styku bezpieczeństwa, infrastruktury i takich dosyć klasycznych projektów, no to ta sfera akurat na zwinne podejście niekoniecznie się nadaje. I nie ma co tutaj na siłę próbować ładować to w Sprinty, ładować tutaj jakieś ścisłe i konkretne nazwane metody zwinne. Coś, co mnie zaskoczyło, to taka bardzo szczera reakcja tego dyrektora, który stwierdził, że pierwszy raz w życiu widzi konsultanta agile, który proponuje zastosowanie klasycznych metod zarządzania, a nie, jak to ujął, pchanie wszędzie zwinności. Dla mnie to nie jest zaskoczenie, bo tutaj już zdążyliśmy dawno ustalić, że zwinność to nie jest złota recepta na wszystko, ale to była dobra inspiracja do tego, żeby poopowiadać trochę o tym, gdzie są dobre inspiracje związane z metodami pracy, metodami zarządzania. Jacek: I nie chcemy mówić tylko o tym, jak decydować, które inicjatywy, jakim trybem realizować. Chcielibyśmy zainspirować Cię do tego, by w ogóle nie szufladkować się na metody czy na frameworki. Jedne traktować zawsze właściwe, a inne zasady odrzucać. Więc dzisiaj generalnie będziemy mówić o tym, jak czerpać z wielu różnych miejsc po to, żeby osiągać sensowne efekty.  Kuba: Spis treści nagrania jest dosyć prosty. Wymienimy konkretnych sześć inspiracji, które uważamy za zasadne, a które wybiegają poza sferę ścisłych metod zwinnych. Potem odniesiemy się trochę do kontrowersji, jakie się z tym wiążą. I na koniec parę słów przestrogi. Jacek: Dobrze. Sześć inspiracji spoza zwinności, które warto znać i które warto umieć stosować. Kuba: Do każdego nurtu, który wymienimy, nurtu zarządzania, podamy po jednej wybranej przez nas praktyce. Wybieraliśmy takie praktyki, takie konkretne narzędzia związane z danym nurtem, które czujemy, że sami albo najczęściej stosujemy, albo mamy jakiś konkretny przykład. Natomiast od razu zastrzeżenie do każdego z tych nurtów bez problemu, moglibyśmy ciągnąć kolejne przykłady. Więc tutaj dajmy sobie wyrozumiałość na to, że odcinek nie mógł być zbyt długi. I jeśli jest taka potrzeba, możemy zanurkować głębiej lub też poszerzyć w jakiś sposób to, co czujemy, że jest wartościowe pod każdym nurtem. Ale przechodząc do konkretów, jaki pierwszy nurt spoza typowego agile’a widzimy jako wartościową inspirację? Jacek: Pierwszy taki nurt to będzie zarządzanie projektami. I to w zależności od tego, jakie masz doświadczenie, w jakiej firmie jesteś, w jakiej roli funkcjonujesz, no to może Cię albo bardzo zaskakiwać, albo wręcz przeciwnie. Zarządzanie projektami bardzo często pokazywane jest jako pewna taka kontra do podejścia zwinnego. Stąd są osoby, które potrafią tak bardzo na dzień dobry negować wszystko to, co płynie z bardzo szerokiego obszaru związanego z tym, jak sensownie tymi projektami zarządzać. Oboje z Kubą mamy w swoim doświadczeniu bycie w roli czy osoby, która koordynuje projekty, czy osoby, która zarządza projektami. Więc sięganie do wachlarza wynikającego z tej metody było dla nas dosyć naturalne. Jednak obserwując to, co się dzieje na rynku, okazuje się, że wcale nie jest to takie popularne. Stąd nieprzypadkowo umieszczamy właśnie zarządzanie projektem na pierwszym miejscu. Kuba: I dlaczego zarządzanie projektami przyda się w zwinnej organizacji zwinnym zespole czy zwinnym produkcie? Dlatego, że najczęściej wiele inicjatyw, które są realizowanych przez takie zespoły, faktycznie projektem jest. Zwłaszcza od strony czystej teorii. Więc tutaj wiele konkretnych praktyk, sposobów myślenia, sposobów organizowania przedsięwzięcia wynikających z takiej bardzo dobrej filozoficznej podstawy związanej z zarządzaniem projektami jest po prostu potrzebna. Może być wartościowa i wręcz właśnie to, co jest tutaj late motivem naszego odcinka odrzucanie tych koncepcji zarządzania projektami może być po prostu zamknięciem sobie bezsensownie pewnego zestawu narzędzi, które może być przydatne. No i tutaj, żeby być konkretnym, jakie narzędzie z nurtu zarządzania projektami byśmy proponowali jako jedna przykładowa, ale bardzo konkretna inspiracja? Jacek: Tak, no to tutaj wybraliśmy wykres Gantta, który bardzo często jest odrzucany. Na zasadzie, że to jest właśnie ten stary zły project management, a my przecież teraz pracujemy zwinnie. Natomiast uważam, że sama metoda może być pomocna. Przykład użycia wykresu Gantta w praktyce. Mogę opowiedzieć historię z jednego z moich pierwszych zespołów zwinnych, w których pracowałem. Wykorzystywaliśmy planowanie przy użyciu tego wykresu, czyli mocno inspirując się tym wykresem, gdy planowaliśmy sobie pracę na konkretny Sprint. Staraliśmy się dosyć dobrze sobie rozrysować w pewnej określonej kolejności, jak będzie wyglądał nasz plan, kto będzie się czym zajmować. Próbowaliśmy też ustalić, ile praca zajmie. Jakie są zależności, które elementy są krytyczne, co musi zostać zrobione wcześniej, po to, żeby uruchomić jakieś tam dalsze możliwości. I to generalnie bardzo dobrze nam działało. Byliśmy w stanie osiągać Cele Sprintu, w tym wszystkim mieliśmy całkiem sensowną przewidywalność. Natomiast bardzo dobrze pamiętam reakcję jednego ze Scrum Masterów, które kiedyś w ramach, o ile dobrze pamiętam, była taka wymiana firmowa na zasadzie, firma X przyszła do naszej firmy i ludzie z tej firmy po prostu mieli możliwość poobserwowania, jak pracujemy. No i ten Scrum Master był taki cały nabuzowany, ale jak wy tu pracujecie, używacie Scruma, a wy planujecie przy użyciu Gantta, nie można, to jest Waterfall, to jest project management. Pamiętam, że już z Kubą się trochę z tego pośmialiśmy na zasadzie, jeżeli coś jest dobre i działa, no to dlaczego by tego nie używać? Kuba: Ode mnie komentarz do tego, bo faktycznie trochę się z tego pośmialiśmy, a trochę nam dało to do myślenia. No i teraz nieprzypadkowo Jacek w swojej opowieści używał liczby mnogiej, bo wykres Gantta jako narzędzie tak, natomiast ten akcent, jak to połączyć ze zwinnością, no to zespołowo planować pracę. Czyli tutaj jak Słuchaczu Słuchaczko cofniesz się do słów Jacka, no to razem budowali, razem planowali, razem wyceniali, razem układali. Cały zespół rozumie, akurat wykres Gantta jest narzędziem dosyć intuicyjnym, dosyć łatwym do złapania. Często nawet ludzie mogą nawet nie wiedzieć, że to się tak nazywa, a umieć to dobrze rozłożyć na jakiejś wizualizacji czy w jakimś narzędziu elektronicznym? No i zastosować to po prostu całym zespołem sprawnie, wzajemnie się gdzieś tutaj pobawić w to planowanie, harmonogramowanie czy układanie. Ja sobie użył przykładu Sprintu, myślę, że to się rozszerza. To może być też planowanie wdrożenia, planowanie releasu, planowanie jakiejś skomplikowanej migracji, czy na przykład planowanie pracy między kilkoma zespołami, że tak lekko nawiążę do poprzedniego naszego nagrania, gdzie na przykład trzeba zsynchronizować pracę, na przykład marketingu, sprzedaży, jakieś zmiany w zasadach obsługi i jednocześnie sprawy związane z wdrożeniem technologicznym. Więc tutaj to budowanie wykresu wspólnie razem może być fajnym sposobem na połączenie klasycznego zarządzania projektami zwinnym zespołem. Kuba: Kolejny nurt zarządzania, przechodzimy już do drugiego punktu, to zarządzanie finansami. Często zwinne zespoły, takie za mocno zapatrzone w konkretne frameworki dystansują się mocno od takiego twardego świata finansów. Rozliczenia, budżetowania, zaplanowania, cash flow i wszystkich tych słów, które być może nawet po prostu niektórym w ogóle nie są znane albo są kojarzone raczej z tą sferą taką klasycznego starego managementu, może osobnych działów, może osobnych specjalistów, którzy żądają jakiejś templatki, zakładają jakieś założenia, które są w świecie zwinnym dosyć obce. Mocno chcemy to zanegować, zwłaszcza osoby, które jednak wejdą w ten nurt takiego zarządzania średniego i wyższego stopnia, już nie mogą od tego uciekać. No i jesteśmy zaniepokojeni takim trendem widzenia agile’a jako sposobu na to, żeby było lepiej w zespole, a niekoniecznie na to, żeby był lepszy, na przykład rezultat finansowy. Jacek: To, co Kuba mówisz, to jest dokładnie to, co może być takim dławikiem, jeżeli masz poczucie, że zwinność w Twojej organizacji nie kwitnie tak, jak powinna. Być może te działania są zbyt oderwane od rzeczywistości, która tak jak Kuba wspomniał, od pewnego momentu w strukturze będzie spore zainteresowanie dotyczące tego, jakie są koszty, jak to zabudżetować, w jaki sposób cała ta praca jest rozliczana. Jeżeli będziemy reagować, jak pies do jeża, na każde zapytanie, czy sformułowanie związane z finansami, to bardzo łatwo możemy się wypozycjonować takim działaniem, że nie do końca rozumiemy realia biznesowe, bo tak naprawdę nie działamy w próżni, wszystko kosztuje, a firma robi pewne rzeczy i inwestuje po to, żeby zarobić. Zamykanie oczu na tę rzeczywistość, myślę, że tak naprawdę może po prostu być sporym błędem. Kuba: No i można te oczy zamykać albo można dbać o to, żeby osoby w naszej strukturze na te kwestie oczy otwierały. Konkretna praktyka, którą proponujemy, to monitorowanie i kontroling kosztów per Sprint. To się zamienia na dosyć proste pytanie, ile kosztuje firmę sprint danego zespołu? Nie po to, żeby zespoły do siebie porównywać, bo wystarczy, że mają różny skład osobowy, już te koszty będą inne, ale żeby czy to samemu zespołowi uświadomić, czy osobom zarządzającym procesem to pokazać, czy żeby też wyciągać się większe decyzje managerskie na temat tego, jaki jest koszt pracy, ile kosztuje Sprint zespołu wytwórczego i też, żeby to może zaraz szybko zestawić obok siebie z wartością uzyskaną czy wartością dodaną, który ten zespół generuje? To często w praktyce oznacza co najmniej dwa kawałki ćwiczenia. Jeden to uświadomienie sobie, jakie są w ogóle czynniki kosztów. To nie będą tylko koszty osobowe, ale też różnego rodzaju dodatkowe koszty, ale też może nić porozumienia ze stroną właśnie jakiegoś innego być może pionu w firmie, właśnie jakiegoś departamentu finansów czy osoby odpowiedzialne za kontroling, by porozmawiać o tym, jak to w ogóle jest liczone, co to oznacza, jakie są typy kosztów i wszystkie takie, być może dla niektórych osób dosyć nowe wiadomości, które dla zarządzania całą organizacją mają znaczenie, mają też znaczenie, chociażby dla kontrolowania i poprawiania efektywności pracy zespołu.  Jacek: I pamiętam taką bardzo żywą reakcję zespołu, kiedy dowiedzieli się, że Sprint kosztuje, nie pamiętam dokładnie ile to było, około kilkadziesiąt tysięcy złotych i komentarz był taki, a my przecież w tym jednym konkretnym Sprincie dowozimy jakiś tam drop down list czy coś takiego super prostego, jakąś opcję widoczną w interfejsie, którą gdzieś tam tylko zaznaczamy, odznaczamy. No i było takie poczucie, że kurczę, to jednak faktycznie kosztuje. I myślę, że to był taki przełomowy moment dla tego zespołu, żeby zacząć się zastanawiać nad tym, czy na pewno pewne rzeczy musimy robić, czy na pewno musimy te rzeczy robić tak szeroko, jak planowaliśmy? No i zdecydowanie, myślę, pomogły im to myśleć o tym, że ta praca to jest pewnego rodzaju inwestycja, ale tak na koniec dnia, no to, żebyśmy tu wszyscy sobie mogli funkcjonować, mieć owocowe czwartki i tak dalej, no to jednak jest potrzebny pieniądz, który do firmy musi jakoś spłynąć. Jacek: Kolejny obszar to przywództwo. Jest cała masa teorii zarządzania, które mówią nam na przykład o tym, że w zależności od tego, jakie są sytuacje, w jakim jesteśmy kontekście, no to powinniśmy postępować w różny sposób. Natomiast rozpoczynamy w ogóle rozmowę o tym punkcie, dlatego że obserwacja jest taka, że przeniesienie odpowiedzialności na zespół i cała koncepcja samorganizacji, samozarządzania źle zrozumiana może osłabić pozycję lidera i spowodować, że w sytuacjach, kiedy byśmy się spodziewali jakichś konkretnych reakcji, to one jednak nie występują. Sam wielokrotnie miałem wiele rozmów z managerami, którzy najnormalniej w świecie mieli obawy, czy inspirowanie się podejściem zwinnym nie spowoduje, że stracą pracę. Więc myślę, że jest taki troszeczkę, takie uogólnione przekonanie, że w podejściu zwinnym tych liderów wyraźnych i managerów nie ma, no bo przecież cała odpowiedzialność idzie na zespół i to zespół teraz jako takie jedno ciało będzie podejmował decyzję. Kuba: I à propos tych teorii zarządzania, no to zwinne metody bardzo często premiują i preferują takie podejście właśnie doświadczony zespół, zaangażowany, zmotywowany. Zespół, który wie, jak się zachować w odpowiednich momentach, zespół, który sprawnie podejmie pewne decyzje albo szybko skoryguje, jeśli trzeba coś skorygować. To są według różnych modeli całkiem dobre postawy, natomiast będą też momenty, gdy to nie jest najlepszy wybór. I dwa konkretne przypadki, czy dwie konkretne teorie, z którymi operuję często. Jedna być może znana i dosyć popularna, związana z zarządzaniem to Situational Leadership, wiele osób też kojarzy to pod koncepcją Blancharda, gdzie jednak bardzo jasno jest powiedziane, że metody takie, gdzie przekazuje się dużą odpowiedzialność, gdzie daje się dużą swobodę, gdzie wyznacza się cele i w zasadzie czeka na efekty i ewentualnie koryguje te efekty, no to to jest za adekwatne, ale wyłącznie dla wyższych poziomów zaawansowania, jeśli chodzi o doświadczenie i dojrzałość. Nie zawsze mamy takie zespoły, czasem są zespoły początkujące, czasem są osoby w zespole, które są początkujące, albo cały zespół na razie do tej pory nie miał do czynienia z daną sytuacją, z którą się mierzą. I wtedy danie pełnej swobody może być proszeniem się o kłopoty, zgodnie właśnie z tym Situational Leadership. Zespół będzie po prostu stał w miejscu i się zastanawiał albo szkodził. Podobną koncepcją, która też mówi o tym, żeby dobierać metody do sytuacji, jest Cynefin. Jeśli nie kojarzysz koncepcji, może znasz wzrokowo, bo niektórzy też nie umieją tego do końca przeczytać po walijsku, więc niektórzy mówią to Cynefin, choć jest to niepoprawna wymowa. Gdzie też tutaj konkretnie Snowden, twórca tej metody, mówi wprost, będą sytuacje, gdy w złożonych sytuacjach zespół może sobie fajnie podejmować decyzje o eksperymentach, ale będą też sytuacje, chociażby chaotyczne, które wymagają sprawnego działania, szybkiego reagowania, podjęcia odpowiedzialności za po prostu rozpoczęcie pewnych działań, by z tego chaosu wybrnąć lub sobie w nim poradzić. Więc tutaj znane dwie koncepcje mówią – niekoniecznie zawsze ten taki domyślny tryb zwinny zespołowy wspólny współodpowiedzialności będzie zawsze poprawny. Jacek: Przykładem tutaj może być sytuacja, kiedy na przykład zespół nie ma odpowiednich umiejętności, odpowiedniej wiedzy, próbuje podjąć jakąś decyzję, gdzieś tam eksploruje, szuka, ale po prostu nie ma szans, żeby z tego coś mądrego wyszło. W takiej sytuacji odważne wkroczenie lidera, podjęcie decyzji, która spowoduje, że tematy ruszą się do przodu, to jest przykład działania takiego kontekstowego. Czyli nie czekamy, aż wydarzy się magia, która może nigdy się nie wydarzy, tylko jeśli trzeba, to po prostu wkraczamy. Oczywiście tu jest pewna pułapka taka, że jeżeli sobie nałożymy filtr w głowie jako liderzy, że ja muszę zawsze wkraczać i zawsze pomagać, to oczywiście jest tego konsekwencja, że zespół być może zawsze będzie na tym poziomie, no bo przyzwyczai się, że to lider podejmuje decyzję, a może też po prostu tak będzie wygodnie. Więc to oczywiście też musi być stosowane z głową. No niemniej jakby wydźwięk całego tego punktu z naszej perspektywy, to jest taka zachęta do tego, żeby nie wykluczać wyraźnego i mocnego przywództwa. Jednocześnie mam takie poczucie, obserwując wybrane firmy, że takiego przywództwa po prostu brakuje. No i dlatego pewne rzeczy są, że tak potocznie powiem, takie trochę rozmemłane, takie niekonkretne. No i myślę, że w tym samym czasie z dobrym przywództwem można byłoby uzyskać o wiele lepsze efekty. Kuba: Podsumowując jednym zdaniem to, co Jacek powiedział, jaką praktykę związaną z przywództwem, rekomendujemy rozważenie odważnego podejmowania decyzji przez lidera w sytuacji, która faktycznie tego wymaga. Kuba: Zanim przejdziemy do kolejnego punktu, wspomnijmy, że jesteśmy już po pierwszych konsultacjach, które Jacek zachwalał w poprzednim nagraniu. Rozmowa tego typu trwa 45 minut i możesz ją wykorzystać na skonsultowanie dowolnego tematu związanego z budowaniem efektywnej, zdolnej do szybkiego działania organizacji. Wynikiem tych rozmów, które już się odbyły, były konkretne porady, konkretne nasze rekomendacje na temat tego, co można zrobić, żeby sobie poradzić z danym wyzwaniem, z którym się te wybrane osoby do nas zgłosiły. Możesz to wdrożyć samodzielnie. Jeśli masz taką potrzebę albo czujesz, że ma to sens, możemy spróbować też zorganizować coś wspólnie z naszym udziałem. Zapisy na te bezpłatne konsultacje znajdziesz 202procent.pl. W prawym górnym rogu znajduje się bardzo wyraźny przycisk bezpłatna konsultacja. Kuba: Przechodząc do czwartego punktu, kolejną inspiracją, którą uważamy zawartą rozważenia, jest koncepcja zarządzania Lean. Lean Management znany z fabryk, z optymalizacji procesów w firmach, składa się z wielu bardzo konkretnych praktyk, z też całej filozofii, którą w jakimś stopniu oddaje polskie tłumaczenie, którego nie lubimy, czyli szczupłe zarządzanie, ale jest to koncepcja szukania okazji za tego, żeby optymalizować proces, obniżać koszty i maksymalizować wartość dodaną, zwłaszcza tę wartość dodaną z perspektywy czy do klienta końcowego, czy klienta procesu, czy wartości uzyskanej z danego procesu. Praktyk jest tu wiele, ale zanim przejdziemy do jednej naszej konkretnej, wybranej i rekomendowanej, to jeszcze ważny komentarz na temat twórcy Scruma. Jacek: Wiele lat temu mieliśmy okazję z Kubą być na szkoleniu u Jeffa Sutherlanda. Jest to jeden ze współtwórców Scruma. To szkolenie miało w nazwie też na pewno coś związanego ze Scrumem. Natomiast to, co nas bardzo zaskoczyło, to to, jak sporo na tym szkoleniu było o Leanie. Całe duże bloki, całe duże ćwiczenia dotyczące np. marnotrawstwa, jak jej identyfikować, jak w ogóle podejść do mierzenia procesu, było dla nas sporym zaskoczeniem. No bo jednak spodziewaliśmy się czegoś bardziej, nazwijmy to scrumowego, a tu się okazało, że zostaliśmy nakarmieni bardzo smaczną porcją mocnej wiedzy na temat tego, jak wykorzystać Lean w pracy z zespołami. Kuba: I konkretną praktyką, którą byśmy dorzucili do tego, co już Jacek wymienił i którą mocno rekomendujemy, to jest koncepcja czy narzędzie raportu A3. Jest to taki klasyczny leanowy koncept budowania, usprawniania się poprzez przejście przez pewnego rodzaju schemat, może nawet aż bym powiedział szablon, ale nie chodzi o to, żeby wypełnić tę kartkę A3, tylko żeby jednak pomyśleć, co jest problemem, co jest blokerem, jaki jest kontekst tej sytuacji, w której w danej momencie się znajdujemy, jakie są przede wszystkim źródłowe przyczyny tego, co aktualnie jest problemem i jakie są pomysły na to, jak można to usprawnić. Jacek wspomniał o szkoleniu z Sutherlandem, ja sam też pamiętam, że byłem na takim szkoleniu parę ładnych lat temu z właśnie takiego klasycznego Leana. I to było niesamowite, to było jedno z lepszych wydarzeń, które w tamtym roku się u mnie działy, bo szkolenie było w cenie jednej trzeciej kosztu szkolenia takiego typowego agile’owego czy managerskiego, w sensie, było mega tanie, na wtedy chyba z półtora tysiące złotych, co mówię, było naprawdę niedużym kosztem i było szkolenie przepakowane takimi bardzo dużymi konkretami. Odwiedziliśmy też taką działającą firmę w pełni zgodnie z Leanem i właśnie między innymi te raporty A3 były pokazane jako coś, co w zasadzie w każdym miejscu, gdzie siedzi jakiś zespół, to była bardziej firma usługowa, znajduje się pewna przegródka, do której można zajrzeć i w tych przegródkach znajdują się wypełnione raporty A3 na temat usprawnień, które albo zrealizowane zostały, albo są w trakcie realizacji przez dany zespół. I to jest praktyka, którą warto spróbować, co najmniej się zainspirować, a najlepiej przeszczepić po prostu do pracy w zespołach wytwórczych, zespołach tworzących produkty technologiczne, jako pokazanie pewnego schematu myślenia, dochodzenia do źródłowych przyczyn i eksperymentowania z usprawnieniem procesu w duchu Kaizen. Jacek: W szczególności, jeśli czujesz, że Twoje zespoły dużo spędzają czasu na usprawnieniach, na rozmowach o tym, jak pewne rzeczy robić lepiej, a Ty patrząc z boku masz poczucie, że nie ma efektów, albo nie ma rezultatów, albo że właściwie te rozmowy są cały czas o tym samym. Użycie takiego uporządkowanego podejścia, gdzie się faktycznie zastanowimy, gdzie jesteśmy, dokąd zmierzamy, w ogóle jakiego efektu, jak się spodziewamy, jak będziemy to mierzyć, kiedy będziemy to mierzyć i tak dalej. Cała masa takich porządkujących informacji może być bardzo pomocna, żeby wprowadzić proces usprawniania się, czy to w zespole, czy na poziomie organizacji, na wyższy poziom. Jacek: Kolejna super istotna dziedzina, obszar, który warto znać i którym warto się zainspirować, jest inżynieria oprogramowania. Tak sobie myślę teraz, że może to powinno wylądować trochę wyżej na naszej liście, te koncepcje są na tyle różne, że tutaj nie ma jakiejś ukrytej kolejności, natomiast zwinność w realiach wielu firm nieodłącznie łączy się z procesem wytwarzania oprogramowania. Inżynieria oprogramowania generalnie jest taką dosyć szeroką dziedziną, która pokrywa właściwie wszystko od pozbierania tego, co chcemy zrealizować przez zaprojektowanie, implementację, aż do procesu przetestowania i do wdrożenia. No i niestety taką trochę mamy z Kubą takie poczucie, że jest przypięta do tej inżynierii taka łatka czegoś, co wydarzyło się dawno kiedyś tam i nie powinniśmy do tego sięgać, no a zdecydowanie tak nie powinno być. Jedną z dużych inspiracji, którą można sobie wziąć z inżynierii oprogramowania, jest wszechobecna automatyzacja, czyli zadbanie o to, żeby na właściwie dowolnym momencie naszego procesu, żeby zadbać o to, żeby rzeczy były automatyzowane, czy to w kwestii programowania, czy to w kwestii sprawdzania jakości, czy to w kwestii automatyzacji procesów wdrożeniowych, wszelkiego rodzaju monitorowania tego, jak funkcjonuje system, jak funkcjonuje infrastruktura. Nie jest to nic innego, jak dobre praktyki płynące z inżynierii oprogramowania, no, a jednak mam poczucie, że nie jest w szczególności automatyzacja czymś, po co firmy sięgają. Raczej często widzę sytuacje, w której rzeczy, które mogłyby być automatyzowane, są po prostu realizowane ręcznie. Kuba: I Ci z naszych Słuchaczy i Słuchaczek, którzy mają background inżynierski z tej sfery oprogramowania, już to wiedzą. Natomiast jeśli nie jesteś tym przypadkiem, no to bardzo mocny komunikat nie daj sobie wmówić, że pewne rzeczy muszą być realizowane ręcznie, że testy, regresji, przed wdrożeniem muszą trwać tyle tygodni. Absolutnie nie, to być może jest jakaś zaszłość, być może są jakieś powody, że tak się nie dzieje, ale tutaj zdecydowanie zachęcamy wszystkie osoby w funkcjach liderskich, by zmierzały do tej automatyzacji, wspierały jej stworzenie, zapewniały budżety na to, dawały zespołom czas, ale jednak też domagały się, żeby ta automatyzacja na wszystkich możliwych poziomach i we wszystkich możliwych miejscach się wydarzyła. Jeśli ten przypadek, czyli właśnie brak backgroundu technicznego, to Twoja sytuacja tutaj mocno zachęcamy do rozwoju, chociaż bardzo podstawowego zorientowania się w temacie nowoczesnej, zdrowo rozumianej inżynierii oprogramowania, i akurat Jacek ma jedną konkretną rekomendowaną lekturę. Jacek: Tak, zdecydowanie. To jest książka w szczególności dla tych, którzy oglądają nasze nagranie na YouTube. To jest książka „Pragmatyczny programista”. Książka, która mnie osobiście dosyć mocno ukształtowała w czasie, gdy jeszcze programowałem. Jak widzicie, ona jest sygnowana takim wielkim nagłówkiem inżynieria oprogramowania, natomiast metody czy techniki, które znajdziecie tutaj w środku, one są zdecydowanie rzeczami, które wsadziłbym do worka takiego dobrego, pragmatycznego, zdroworozsądkowego wykorzystania zwinności właśnie w procesie wytwarzania oprogramowania. Nazwę książki oraz autorów umieścimy w notatkach do tego nagrania. Kuba: I ostatni, ale wcale nie najmniej ważny nurt, który rekomendujemy, to koncepcje zarządzania zmianą. Wiele zespołów zwinnych realnie wiąże się ze zmianą. Same się zmieniają, zmieniają swoją firmę, zmieniają swój rynek, zmieniają produkt, nad którym pracują, ale widzimy, że wiele zespołów niestety nie wykorzystuje gotowych narzędzi, gotowych koncepcji, gotowych strategii związanych z zarządzaniem zmianą, z którymi świat mierzy się już od lat i już dawno sobie poukładał to w pewne propozycje, rozwiązań. A wiele zespołów niestety metodą prób i błędów próbuje odkryć pewną rzeczywistość na nowo.  Jacek: Temat zarządzania zmianą może być szczególnie istotny, jeżeli faktycznie wykorzystujesz podejście zwinne w swojej organizacji. No i częścią tego jest poszukiwanie lepszych rozwiązań. Żeby te rozwiązania, na które czy Ty wpadniesz, czy Twoje zespoły, żeby one miały szansę wejść w życie, no to trzeba do tego podejść w sposób uporządkowany. No bo mówimy tutaj o tym, że będzie się pewna zmiana działać. I tutaj zarządzanie zmianą wjeżdża na białym koniu, no bo pomaga nam zaplanować pewne działania, zrobić też pewne działania wyprzedzające, zadbać o to, żeby wszyscy ludzie byli na pokładzie, rozumieli po co, dlaczego pewne rzeczy robimy. No i jak również zadbać o to, żeby wiedza, która jest potrzebna do przeprowadzenia zmiany, żeby została dostarczona, no i żeby ludzie też nabrali umiejętności wykorzystania tej wiedzy w praktyce. Kuba: I tu akurat zarządzanie zmianą jest nam bardzo bliskie z uwagi na to, że bardzo często firmy wspieramy w zmianie, pomagamy im przejść przez zmianę. Natomiast to konkretne narzędzie, które już od lat mocno rekomendujemy i które jest też tłem wielu naszych nagrań, nie zawsze wprost wymienionym, to koncepcja zarządzania zmianą według modelu ADKAR. ADKAR to skrótowiec w odpięciu słów angielskich Awareness, Desire, Knowledge, Ability, Reinforcement. Nie będziemy w tym nagraniu mocno rozszerzać tego, co to oznacza, ale jest to model zarządzania zmianą osobistą, który zakłada, że każda osoba musi rozumieć zmianę, chcieć jej, znać ją tę zmianę od strony podstawowych założeń czy teorii, umieć wykonać to w praktyce i też dostać wzmocnienie, jeśli zmiana dała pozytywne rezultaty. I to na poziomie ogólnym ta koncepcja jest do pojedynczej osoby, ale widzimy też ją w praktyce, w działaniu w zespołach czy całych częściach, czy całych firmach. Przykład życia, żeby pokazać, jak ADKAR może funkcjonować w życiu Twojego zespołu. Wyobraźmy sobie, że odkrywasz, że temat niskiej przewidywalności pracy to jest jednak pewien problem, więc warto najpierw zbudować świadomość w członkach zespołu, że to jest problem, że to nie jest bez znaczenia, że mówimy, że będzie, a potem nie ma i że to właściwie zawsze tak jest, wytłumaczyć, po co i dlaczego. Następnym etapem jest popracowanie z poszczególnymi osobami, upewnienie się, że są z nami na pokładzie, że rozumieją, że chcą. To jest też moment, żeby popracować trochę z obawami, z rzeczami, które mogą być stoperami takiej zmiany, więc to jest trochę takiej pracy indywidualnej. Następnie trzeba zastrzyk wiedzy dostarczyć, czyli jeżeli mówimy o tym, że będziemy pracować nad przewidywalnością, to może należałoby wprowadzić taką wiedzę jak planowanie zespołowe, może trzeba by było wprowadzić jakieś podstawowe miary, które pomogą nam patrzeć na tę przewidywalność, no, a następnie pomóc zespołowi wykorzystać te rzeczy w praktyce. Czyli samo wysłanie na szkolenie, czy podesłanie odcinka podcastu, czy wpisu na blogu, czy książki, to może być za mało, no bo trzeba pomóc ludziom przejść przez tę zmianę na zasadzie, aha, to są te nowe narzędzia, to teraz ja chciałbym się jako lider upewnić, że moi ludzie wiedzą, jak je wykorzystać w praktyce. No i na koniec ta zmiana będzie się toczyć, no i chcielibyśmy z Kubą świata, w którym liderzy wzmacniają pozytywne efekty, są w stanie pokazać tę deltę na zasadzie, zobaczcie, tak było, a tak jest, takie uzyskaliśmy rezultaty, ale oczywiście te wzmocnienia powinny występować tylko wtedy, kiedy faktycznie jest poprawa, żeby pomóc ludziom zobaczyć, że ten wysiłek i te wszystkie kroki, które trzeba było zrobić, żeby dojść do tych rezultatów to, że one miały sens i prowadzą nas do jakiegoś fajnego efektu. Jacek: Przedstawiliśmy z Kubą sześć koncepcji, które na bazie naszych doświadczeń nie zawsze są wykorzystywane, nie zawsze są uwzględniane w organizacjach, które inspirują się podejściem zwinnym. No i tutaj bardzo łatwo jest zanegować wszystko to, co powiedzieliśmy, bardzo łatwo jest wejść w myślenie stereotypami, albo używać takiego przerysowania na zasadzie krytyki bardzo łatwej, płynnej tego wszystkiego, o czym wspomnieliśmy. Chcielibyśmy z Kubą teraz narysować trochę, o jakiej krytyce mówimy, żebyś mógł czy mogła ocenić, czy w Twojej organizacji spotykasz się z podobnymi głosami.  Kuba: Dobra, to jakie mogą być kontrowersje, co może być nie tak z zarządzaniem projektami? Jacek: Na pewno, że to jest takie bardzo predykcyjne patrzenie na świat i że daje złudne poczucie kontroli. Kuba: Co jest nie tak z zarządzaniem finansami? Jacek: Nie, no wielka biurokracja, która nam nie daje wartości. Kuba: To może przywództwo, tu jest jakaś kontrowersja? Jacek: No przywództwo, to mikromanagement, to zabija sam organizację, trzeba unikać. Kuba: Zarządzanie Lean? Jacek: Nie, no software development to przecież nie fabryka. Kuba: No to może inżynieria oprogramowania, przecież to software development. Jacek: Nie, nie, to z Waterfalla, to nie używamy tego. Kuba: Co jest nie tak z zarządzaniem zmianą? Jacek: Przecież chcemy odpowiadać na zmianę, a nie podążać za jakimś planem, no to jak? Kuba: No i tutaj jak słyszysz, Jacek specjalnie pobawił się trochę stereotypami albo uogólnieniami, ale we wszystkim tym jest pewna ziarnko prawdy. Natomiast my tym nagraniem jednak chcemy zachęcić do tego, żeby się inspirować, przełamywać te schematy, nie odrzucać tych konceptów, nawet jeśli Twoje osobiste doświadczenie jednak jest bliższe tym odpowiedziom sprzed chwili, które wymienił Jacek. Jacek: Tak, uważamy z Kubą, że świat nie jest czarno-biały. To nie jest tak, że możemy sobie kategorycznie pewne rzeczy brać, inne kategorycznie odrzucać. Myślę, że przyszłość jest w tym, żebyśmy nie szufladkowali, a pragmatycznie myśleli, co daje nam dobre rezultaty i z tych źródeł, które uważamy za wartościowe, żebyśmy czerpali. Kuba: Ale też dla równowagi, bo tutaj teraz przechodzimy do takiej puli przestróg czy jakichś takich myśli końcowych, dla równowagi jednak bądźmy ostrożni zmieszaniem konceptów. Wybrane te praktyki się fajnie łączą, wybrane koncepty mają punkty wspólne, które się ładnie wspierają, ale też bądźmy ostrożni przed takim łączeniem wszystkiego na siłę i bezmyślnie. Ja użyję swojej metafory czy analogii, Jacek za chwilę dorzuci swoje, i moja jest mocno związana z moim hobby. Więc tutaj pokażę na wideo coś, co być może niektórzy rozpoznają. Ja pokazuję dla słuchaczy, opowiem co pokazuję, pokazuję paletkę do farb. Moim hobby jest m.in. modelarstwo, gdzie mocno w teorię kolorów wchodzę. No i jak połączę kolory czerwone, zielone, żółty, niebieski, jakiejś brązowy, no to niestety nie wyjdzie żaden fajny kolor łączący zalety wszystkich pięciu, tylko wyjdzie jakiś taki szarobury bez nazwy. No i niestety może być podobnie z tymi inspiracjami. Czyli tutaj zaczerpnięcie naraz zza wielu źródeł i próba połączenia wszystkich możliwych światów i wszystkich praktyk jednocześnie może wcale nie dać aż tak dobrych rezultatów. Więc głos ode mnie, inspirujmy się, czerpmy z praktyk, ale róbmy to z głową, żeby czasami nie łączyć elementów, które się wzajemnie znoszą albo psują sobie zalety wybranych konkretnych nurtów. Jacek: No i zdecydowanie trzeba dać sobie szansę na sprawdzenie. Tutaj moja analogia z kolei, no, jeżeli z jakiegoś powodu stwierdzę, że bieganie może być fajne, przebiegnę na pełnej prędkości swoje pierwsze 100 metrów i stwierdzę, że się zmęczyłem i że w ogóle jestem spocony i że to nie jest dla mnie, no to to może być zbyt szybka, zbyt pochopna refleksja. Dłuższe pobieganie, powiedziałbym, pobiegaj tydzień, pobiegaj miesiąc, zastanów się, spójrz holistycznie, co się zmieniło, łatwiej ci się biega, gorzej biega, lepiej się czujesz, gorzej się czujesz, waga poszła w górę, w dół, cała masa parametrów, które można sobie śledzić. No to świadczy jednak o tym, że żeby sobie mieszać, żeby inspirować się narzędziami, technikami czy pewnymi koncepcjami, które mogą nam się wydawać niewłaściwe, może takie, które w ogóle nie powinniśmy korzystać, to jest fajna przygoda, do której trzeba podejść z głową. I taki zdrowy rozsądek w tym podejściu chcielibyśmy z Kubą w tym odcinku zaakcentować. Kuba: I tak zbierając obie te nasze analogie, takie nasze porady, jak można by właśnie z głową podejść do tego inspirowania się, to na pewno warto mieć punkt odniesienia, żebyś wiedział lub wiedziała, czy faktycznie to bieganie ci pomaga. Spróbuj do tego podejść rzetelnie. Przygotuj się, poczytaj, doradź się kogoś, kto już to robił, żeby tutaj czasami nie dać się ponieść swojej intuicji i zrobić to zbyt słabo, żeby zobaczyć rezultaty. No i daj sobie minimalny czas potrzebny, żeby zauważyć efekt. Te przykładowe Jacka 100 metrów i zadyszka, to może być jeszcze za wcześnie i jak patrzymy na zarządzanie, czy sposób funkcjonowania zespołów, to też to widzimy. Jedno nieudane spotkanie planistyczne jeszcze nie mówi, że planowanie jest bez sensu, ale może nam dać sygnał, że musimy w to zainwestować na przykład jednak trochę więcej doradztwa albo znaleźć kogoś, kto może nam powiedzieć, żeby to zrobić jeszcze lepiej. I całe nagranie świadomie zakończymy pewną inspiracją bardzo konkretną od Alistair’a Cockburn’a, który jest niezmiennie naszym guru w tematach. Alistair mocno propaguje coś, co też kiedyś już wspomnieliśmy w jednym z nagrań. Coś, co się nazywa, przepraszam za mój angielski, The Oath of Non Allegiance. Polskiego tłumaczenia nie ma, ale spróbuję tak przez analogię przetłumaczyć. To przysięga niewierności, niewierności, niewierności, gdzie tutaj bardzo konkretnie Alistair zachęca do takiego sposobu myślenia. Teraz będę na żywo tłumaczył z angielskiego. Przysięgam nie wykluczać rozważenia idei w zależności od źródła, z której ta idea pochodzi. Niezależnie od tego, z jakiej szkoły, z jakiego dziedzictwa, będę szukał tych, które najlepiej pasują do mojej sytuacji. Tak przenosząc się z tej przysięgi na taki język zrozumiały, zwykły. Nieważne, że to pochodzi ze świata, który jest mi dzisiaj obcy. Jeśli to jest dobry narzędzie, jeśli to jest dobry koncept, jeśli on mi pomaga, to warto go rozważyć, spróbować i wyciągnąć sobie wnioski samodzielnie, a nie szufladkować się, że to jest zwinne, a to jest niezwinne, więc muszę to odrzucić. Jacek: Generalnie jest to zachęta do tego, żeby podchodzić zarówno z ciekawością, ale też z ostrożnością do tego, co słyszysz. Może być tak, że osoby, eksperci będą mieć bardzo super wyraźne zdanie na jakiś temat i wręcz dyskredytować pewne inne koncepcje. No i tutaj zachęcamy z Kubą do tego, żeby jednak wysłuchać, zastanowić się i jednak na koniec dnia samodzielnie podjąć decyzję na temat tego, czy na pewno świat jest tak czarno-biały, jak się wydaje, czy może jednak możemy wskutek zmieszania tych kolorów uzyskać coś lepszego, niż opowiedział Kuba, czy może niekoniecznie szarość, a w jakiś sposób na przykład podbić wyrazistość, na której nam zależy. Jacek: Podsumowując, sześć inspiracji spoza podejścia zwinnego, które warto znać i umieć stosować to – zarządzanie projektami, zarządzanie finansami, przywództwo.  Kuba: Koncepcja zarządzania Lean. Inżynieria oprogramowania i zarządzanie zmianą. Jacek: Na koniec krótkie ogłoszenie. Kończę pisać drugie wydanie książki, która się nazywa „Labirynty Scruma”. Jest to książka dla osób używających Scruma, które napotykają trudności w jego efektywnym wykorzystywaniu. Druga wersja to kompletna rewizja całości. Między innymi uwzględnia pracę zdalną, uwzględnia zmiany w najnowszym przewodniku po Scrumie. Dodane są nowe pułapki oraz dodane są nowe porady, zebrane w trakcie ostatnich moich lat pracy jako konsultant. Dla osób, które lubią liczby, to jest ponad 200 rozwiązań na najczęstsze pułapki występujące w Scrumie oraz też taka nowa rzecz w drugim wydaniu, ponad 100 praktycznych przykładów z życia, które opisują, jak te wskazówki zastosować w praktyce. Jeśli chcesz być na bieżąco w kontekście przedsprzedaży książki pod koniec pierwszego kwartału 2025 roku, zapisz się na mój newsletter na stronie jacekwieczorek.pl Kuba: Notatki do tego odcinka, artykuł napisane na jego bazie, transkrypcję naszej rozmowy oraz zapis wideo, tym razem zapis, na którym coś więcej widać niż tylko nasze gadające głowy, znajdziesz na stronie porzadnyagile.pl/131 Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba. Kuba: Dzięki Jacek. Jacek: I do usłyszenia wkrótce. ——— To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę! Ostatnia aktualizacja: 23 stycznia 2026The post Jedna najlepsza metoda pracy nie istnieje first appeared on Porządny Agile.

Czasem zdarza się, że w organizacji pojawi się projekt, który wymaga działań wielu zespołów zwinnych. Przygotowaliśmy zestawienie pewnych praktyk, z których możesz ułożyć sobie własne rozwiązanie, skrojone do odwagi, dojrzałości i możliwości firmy. Zwróciliśmy też uwagę na ważne przestrogi, które możesz spotkać podczas inicjatyw wielozespołowych. Porządny Agile · Inicjatywy wielozespołowe Założenia do sytuacji, o której powiemy Zakładamy, że w organizacji działają już pewne zespoły zwinne, stanowiące bazę. Funkcjonują one na zadowalającym poziomie, bez wyraźnych patologii oraz z zaufaniem w zakresie realizacji własnych zadań w dobrze znanych im obszarach. Rozpatrywać będziemy przypadek pojawienia się nowego, rozbudowanego i istotnego tematu, którego wdrożenie wymaga współpracy wielu zespołów jednocześnie. Co mamy na myśli, gdy mówimy wspólny temat dla wielu zespołów? Przyjrzyjmy się kilku przykładom, które mogą odnosić się do twojej sytuacji.  Przebudowa lub przepisanie systemu: starsze, rozbudowane systemy często wymagają gruntownej modernizacji lub całkowitego przepisania, aby wspierać konkretny kawałek procesu biznesowego. Proces ten może obejmować prace niemalże wszystkich zespołów technologicznych w organizacji. W wielu organizacjach starsze rozwiązania bywają na tyle rozległe i kluczowe dla całości, że stworzenie nowej wersji wymaga zaangażowania niemal wszystkich zespołów technologicznych, a czasem nawet wszystkich. Radykalne zmiany biznesowe: Innym przykładem jest radykalna zmiana biznesowa, na przykład spowodowana nowymi regulacjami prawnymi, przeobrażeniem wizerunku lub marki czy przejęciem innej firmy. W takiej sytuacji kluczowe elementy, takie jak wizualne czy marketingowe atrybuty, rozproszone są po całej organizacji, we wszystkich systemach i procesach. To z kolei wymusza skoordynowane działania bardzo wielu zespołów, a niekiedy również wszystkich bez wyjątku. Nowa linia biznesowa: wprowadzenie nowej linii biznesowej, wymaga zbudowania komponentów w różnych miejscach w organizacji, technologiach, warstwach i lokalizacjach organizacyjnych. Przykładem może być nowa hurtownia danych, przebudowa kluczowego systemu bazowego, modyfikacje w aplikacji mobilnej czy integracje upsellingowe z już istniejącymi produktami. W takich przypadkach sukces biznesowy zależy od w miarę jednoczesnej realizacji zmian w wielu miejscach organizacji. Nie jesteśmy zwolennikami nadmiernego podejścia do skalowania pracy zwinnej. Mamy takie doświadczenie, że praktykowaliśmy skalowanie jeszcze przed pojawieniem się frameworków, co daje nam przekonanie, że najlepiej podchodzić do tego tematu ewolucyjnie. Oczywiście można inspirować się różnymi metodami, ale wciąż uważamy, że to może być pułapka. Zachęcamy do dopasowywania rozwiązań do konkretnego kontekstu organizacji. Na zakończenie tego rozdziału poniżej wskażemy konkretne praktyki, które sami byśmy zastosowali. Jednak nie traktuj ich jako gotowego zestawu czy procedury, ponieważ każda organizacja ma swoje specyficzne potrzeby. Warto je dopasować do odwagi, możliwości oraz dojrzałości zespołów. Te czynniki mogą sprawić, że w jednej organizacji dane praktyki będą miały sens, a w innej już nie. Proponowane praktyki pracy wielu zespołów nad jedną inicjatywą 1. Jasny i wyraźny cel inicjatywy Jasny i wyraźny cel inicjatywy ma za zadanie spajać myślenie ludzi na temat tego, co tak naprawdę jest do zrealizowania. Rekomendujemy tę praktykę, aby uniknąć rozjazdu priorytetów w organizacji i zapobiec rozszerzaniu budżetu czy zakresu projektu. Jasne określenie celu to nasz absolutny klasyk, punkt wyjścia. Tak jak dla pojedynczego zespołu potrzebujemy sensownego celu, tak samo ta praktyka ma zastosowanie w przypadku współpracy wielozespołowej. Ten cel może stać się mantrą, przypomnieniem, o co wszystkim zespołom chodzi. Tak jak wspomnieliśmy, cele dla zespołów mogą być jasne, ale w przypadku inicjatyw wielozespołowych może się okazać, że dla danego zespołu priorytety się zmieniają. Na przykład zespół rozwijający swój kawałek produktu może mieć swoją road mapę, ale gdy pojawia się większa, ogólnofirmowa inicjatywa, może być konieczne wstrzymanie pracy nad dotychczasowymi zadaniami i skupienie się na wspólnym celu. Ważne jest, żeby ten cel był jasny i zrozumiany przez wszystkich, aby nie powstały sytuacje, w których zespoły realizują równolegle swoje cele, udając, że współpracują nad czymś ogólnofirmowym. Jeśli inicjatywy mają się udać, wszyscy powinni realizować wspólny cel. 2. Budżetowanie przyrostowe Chodzi o uruchamianie budżetu na wczesnym etapie projektu, ale nie na całą inicjatywę, z góry na wiele miesięcy czy lat. Zamiast tego, podobnie jak fundusze inwestycyjne w start-upy, otrzymujecie pierwszą pulę finansowania, która pokrywa początkowe etapy. Takie podejście jest oszczędne i nastawione na szybkie wyniki, a kolejne rundy inwestowania są przyznawane w miarę osiągania celów. Ta praktyka jest istotna, ponieważ wielozespołowe inicjatywy niosą ryzyko przekroczenia budżetów, zakresu czy harmonogramu. Dlatego ważne jest, by jasno zakomunikować wszystkim zespołom, że dostaną tylko fundusze na początek, a dalsze finansowanie zależy od wyników. Należy unikać komfortowego podejścia, które może prowadzić do opóźnień, ponieważ czas jest kosztowny przez cały okres trwania projektu. Ważne jest, aby projekt realizować małymi krokami, zgodnie z uruchamianym finansowaniem.Warto pokazać, że rozumiemy cele biznesowe, że ogarniamy technologię, a co ważne, szczególnie przy skalowaniu, potrafimy ze sobą współpracować. Oczekiwanie, że powstanie coś namacalnego, stanowi doskonały pretekst do sprawdzenia i zarządzania wszystkimi ryzykami. 3. Dedykowany zespół pod inicjatywę Trzecia praktyka, którą rekomendujemy, to stworzenie dedykowanego zespołu pod konkretną inicjatywę. Może to być sprzeczne z tradycyjnym podejściem, w którym zespoły odpowiadają za określone obszary lub produkty. Często pojawia się pokusa, by przypisać część zasobów istniejących zespołów do realizacji wspólnej inicjatywy. Proponujemy jednak odwrotne podejście: zamiast tego, utwórz zespół dedykowany tej inicjatywie, aby uniknąć rywalizacji o czas i zasoby. Takie podejście zapewnia pełne skupienie na zadaniach, które muszą zostać wykonane, eliminując konieczność dzielenia uwagi między konkurujące inicjatywy. W najlepszym przypadku, zamiast angażować wiele zespołów do jednej inicjatywy, wyciągniemy po dwie, trzy osoby z kilku zespołów, które normalnie musiałyby współpracować, i stworzyć dedykowany zespół skoncentrowany wyłącznie na tym przedsięwzięciu.  Wiemy, że może to być sprzeczne z zasadą stałych zespołów, które są skupione na konkretnych produktach lub obszarach, ale w tym przypadku zachęcamy do rozważenia przełamania tej zasady, aby zapewnić pełne skupienie na realizacji danej inicjatywy.Zdajemy sobie sprawę, że ta praktyka może być sprzeczna z zasadą tworzenia stałych zespołów, które są przypisane do konkretnych produktów, obszarów lub systemów. Niemniej jednak, zachęcamy do rozważenia przełamania tej zasady, by stworzyć zespół dedykowany wyłącznie realizacji tej inicjatywy, co pozwoli na pełne skupienie się na jednym celu i zminimalizowanie rozproszenia. 4. Dobór najlepszych ludzi z dostępnych w organizacji Kolejna praktyka, o której mówimy, dotyczy doboru ludzi i polega na wybraniu najlepszych osób dostępnych w organizacji. W przypadku przedsięwzięć wymagających pracy wielu zespołów, które mają szczególne znaczenie biznesowe, warto bardzo starannie przeanalizować dostępne zasoby i wybrać te osoby, które mają największy wpływ na powodzenie projektu. Szczególnie istotne jest, aby wybrać osoby w funkcjach kluczowych, liderskich, Osoba zarządzająca produktem, w tego typu przedsięwzięciach rośnie również potrzeba dobrego architekt, oraz osoby na innych liderskich stanowiskach mogą mieć ogromny wpływ na sukces. Warto, aby osoby odpowiedzialne za tworzenie struktury wielozespołowej w organizacji rozważyły selekcję najbardziej odpowiednich kandydatów do tego przedsięwzięcia, by minimalizować ryzyko i zwiększyć szanse na jego powodzenie. Za tą praktyką doboru najlepszych ludzi kryje się jednak pewne zagrożenie. Jeśli stworzymy zespół z samych „gwiazd”, mogą pojawić się trudności związane z ich współdziałaniem. Może to prowadzić do problemów z ego, rywalizacją o to, czyje pomysły będą dominować, czy które decyzje będą priorytetowe. Przy tworzeniu takiego zespołu, warto szczególną uwagę zwrócić na proces grupowy oraz jego facylitację. Ważne jest, aby zespół, który początkowo może mieć różne interesy, z czasem stał się spójną grupą. Należy działać w krótkich okresach, raczej myśląc w kategoriach tygodni niż miesięcy, by stopniowo budować efektywną współpracę. 5. Jeden lider biznesowy decydujący o priorytetach Kolejną praktyką jest wskazanie jednej osoby, która będzie odpowiedzialna za podejmowanie decyzji i wyznaczanie priorytetów, pełniąc rolę lidera biznesowego. Ta osoba powinna pełnić funkcję kompasu lub latarni morskiej, wskazując właściwą drogę. W zależności od struktury organizacyjnej, może to być Product Owner, Product Manager, Project Manager lub inna rola, ale najważniejsze, żeby była to jedna osoba, która posiada autorytet, wizję i asertywność, oraz jest w stanie skutecznie poprowadzić całą inicjatywę. Podkreślamy, że kluczowe jest, aby była to jedna osoba odpowiedzialna za decyzje, ponieważ w organizacjach z wieloma dobrze działającymi zespołami może być kilka osób liderskich. Jeśli nie zostanie wyraźnie wskazana, namaszczona ta jedna osoba do podejmowania decyzji, istnieje ryzyko, że powstanie komitet produktowy, który podejmie decyzje kompromisowe lub niejednoznaczne, zamiast skupić się na klarownym celu i wartości.  W idealnym scenariuszu, powinna to być jednoznacznie wskazana osoba decyzyjna. Może to być także lider spośród Product Ownerów, który przyjmuje odpowiedzialność za decyzje w trudniejszych sytuacjach, pierwszy wśród równych.  Osoba, która decyduje w sytuacji impasu, albo innych trudniejszych, w których przejmie kierownice. W zależności od kultury organizacyjnej rozwiązanie może być mniej lub bardziej wyraźne, ale kluczowe jest, by nie pozostawić tego obszaru niezaopiekowanego, licząc na to, że wszyscy się dogadają.To może nie mieć miejsca. 6. Kontrakt na współpracę międzyzespołową Kolejna praktyka, którą warto rozważyć, to kontrakt na współpracę międzyzespołową. Kładziemy na tą formę współpracy szczególny nacisk. Zakładając, że bazujemy na zespołach, które już istnieją, mogą one mieć już swoje zasady działania, kontrakty, które są bardziej lub mniej ugruntowane. Jednak w przypadku, gdy tworzymy nową strukturę międzyzespołową, może się okazać, że zespół A ma świetne zasady, zespół B ma inne zasady, również dobre, ale różne, a zespół C stosuje zasady, które mogą być zupełnie sprzeczne z tymi w zespołach A i B. W takim przypadku, tworząc taką strukturę, warto bardzo świadomie podejść do kwestii współpracy. Ważne jest, by wszystkie zespoły biorące udział w wspólnej inicjatywie miały ustalony co najmniej minimalny standard współpracy. Ten standard może dotyczyć trywialnych rzeczy, jak narzędzia do komunikacji, miejsce przechowywania dokumentów, narzędzia do śledzenia zadań, ale również bardziej praktycznych kwestii, jak odpowiedzialność za zakończenie zadań, przypomnienia czy zasady współpracy z konkretnymi procesami wytwórczymi.Taki kontrakt może być narzędziem, które pomoże przyspieszyć współpracę konkretnego zespołu, właśnie dzięki temu, że na początku ustalimy, jak podchodzimy do konkretnych tematów. Jasność i przejrzystość podstawowych zasad mogą działać jako akcelerator współpracy w zespole, co w praktyce sprawi, że procesy będą przebiegać sprawnie. 7. Jedno źródło prawdy o priorytetach Chodzi o to, aby mieć jedno miejsce, które będzie źródłem prawdy, dostępne dla wszystkich, aby uniknąć poczucia, że nie widzimy pełnego obrazu zadań, którymi się będziemy zajmować, lub że część tematów zostanie nam ujawniona dopiero później. To jedno źródło powinno jasno wskazywać, które tematy są do zrealizowania, nad którymi aktualnie pracujemy, a które zostały już zakończone.Ta praktyka jest bardzo zbieżna z dwoma wcześniejszymi. Z jednej strony jasno pokazuje podjęte decyzje, a w źródle prawdy znajduje się informacja o tym, co aktualnie realizujemy. Jest również powiązana z przyrostowością na poziomie budżetowym, ponieważ prawdopodobnie napotkamy ograniczenia. Rzadko zdarza się, aby takie duże przedsięwzięcie nie miało żadnych ograniczeń. Te ograniczenia muszą być bardzo wyraźne. Konkretnie, te rzeczy robimy, a innych nie robimy, nawet jeśli mogłyby być wykonane. Często pojawia się pokusa, by przy okazji zrobić coś dodatkowego, ale im bardziej rozproszona jest wiedza na temat priorytetów, tym łatwiej może dojść do rozbieżności. Rozszerzający się zakres może szybko wymknąć się spod kontroli. Dlatego lepiej mieć jedną, wspólną listę priorytetów. W przypadku Scruma będzie to jeden Backlog Produktu, a w podejściu kanbanowym jedna kolumna jednoznacznie wskazująca zadania do realizacji w pierwszej kolejności. 8. Praca przyrostowa na poziomie całej inicjatywy Przedostatnia porada to praca przyrostowa na poziomie całej inicjatywy. Wspomnieliśmy wcześniej o budżetowaniu przyrostowym, a teraz przenosimy akcent na dostarczanie przyrostowe. Jest to oczywiste w wielu zespołach, gdzie kolejne wersje i części produktu są dostarczane stopniowo. Każdy zespół, zwłaszcza gdy jest rozdzielony systemowo lub komponentowo, robi coraz lepsze wersje swojego kawałka. Chcielibyśmy jednak podkreślić, że nie chodzi tylko o to, by każdy zespół robił swój kawałek przyrostowo, ale by cała inicjatywa była realizowana w sposób przyrostowy. Gdy zespół A, B i C zrobią swoje części, te części muszą być połączone i tworzyć przyrostowy produkt. Na początku może to być bardzo prosty produkt, ale z biegiem czasu, gdy będzie rozwijany, coraz bardziej zbliży się do ostatecznej wersji. Ważne jest, by na poziomie całej inicjatywy, przyrostowość była widoczna od samego początku. Na końcu będziemy mieć już prawie gotowy produkt, z drobnymi poprawkami, ale całość będzie już w pełni funkcjonalna, a nie tylko zbiorem niepowiązanych elementów. Cała zabawa w integrację rozwiązania polega na tym, jak podejdziemy do wersjonowania, czy mamy włączoną ciągłą integrację, jak wygląda cały proces code review i zapewnienia, że wszystkie elementy na koniec dnia będą działały razem. Z perspektywy biznesowej to może być coś, co łatwo zostaje niedoszacowane, jeśli chodzi o całkowity wysiłek potrzebny do zintegrowania takiego projektu. Im wcześniej zaczniemy ten proces i będziemy oczekiwać, że integracja przebiegnie na wszystkich poziomach, tym szybciej dowiemy się, czy napotkamy jakiekolwiek trudności, brakuje nam zasobów lub mamy inne problemy. Będziemy mieli wtedy czas na odpowiednią reakcję. 9. Wspólne sesje usprawnieniowe Ostatnia rekomendacja, którą przygotowaliśmy, brzmi: wspólne sesje usprawnieniowe.  Mocno wierzymy w to, że zawsze można pracować lepiej i zawsze można znaleźć usprawnienia. W szczególności w sytuacji, o której piszemy w tym artykule, że na pewno pojawi się mnóstwo tematów, które można zrobić inaczej, lepiej. Będziemy się potykać o różne trudności. Dlatego niezwykle ważne jest, aby regularnie przeprowadzać sesje usprawnieniowe, które prowadzą do konkretnych usprawnień, wprowadzanych w życie. Zwłaszcza że wymiar współpracy międzyzespołowej sam w sobie będzie generował tematy, które w wielu firmach mogłyby już być dość dogrzane. Jeżeli pójście w model wielozespołowy będzie się różnić w zależności od inicjatywy, to te doświadczenia i sposób współpracy będą się dopiero kształtować. Nie zakładajmy, że jedno rozwiązanie będzie działało za każdym razem. Takie wspólne sesje usprawnieniowe mogą być coraz bardziej skomplikowane w miarę wzrostu skali, więc warto rozważyć scenariusz, w którym te sesje nie będą gromadziły wszystkich uczestników projektu, ale tylko odpowiednich ludzi. Na przykład programiści z różnych zespołów mogą się spotkać, by omówić aspekty ze swojej profesji, albo tylko Product Ownerzy, aby rozmawiać o priorytetach. Takie elastyczne podejście będzie bardziej efektywne, niż sztywne trzymanie się dużych spotkań dla wszystkich, które mogą zabić entuzjazm do usprawniania się. Jeśli czujesz, że temat usprawniania się w twojej organizacji wymaga jeszcze poprawy, zachęcamy Cię do zapoznania się z naszym webinarem, w którym opowiadamy o tym, jak skutecznie wprowadzać usprawnienia. Znajdziesz go na stronie porzadnyagile.pl/retro. Przestrogi oraz przemyślenia przy pracy wielozespołowej 1. Zaakceptuj, że nie będzie idealnie od początku Pierwsza przestroga, już częściowo zasygnalizowana w ostatniej praktyce, to zaakceptowanie, że nie będzie idealnie od początku. Wiele osób, które mierzą się z tym wyzwaniem, ma nadzieję, że dobrze zaplanowane procesy i dobrze zarysowane granice sprawią, że wszystko pójdzie gładko już od pierwszego dnia. W innych przypadkach jest pełna świadomość, że robimy to po raz pierwszy w organizacji, więc może nie będzie idealnie, ale pojawia się szybka frustracja, gdy spotkania są nieefektywne, ktoś coś zgubił, coś się nie zgrało. Nasza przestroga: tak, tak będzie. Niestety, tak to wygląda.  Konstrukcje wielozespołowe, zwłaszcza w organizacjach, które nie mają jeszcze dużego doświadczenia, po prostu nie będą optymalne na początku. Potrzebujemy się usprawniać, uczymy się, stosujemy praktyki, które pomagają szybciej wychwycić problemy. Ważne jest, by docenić postęp w kolejnych krokach i nie oczekiwać, że wszystko będzie idealnie na samym początku. 2. Pozwól na odstępstwa od tego, jak zespoły działają zazwyczaj  Część naszych porad może być sprzeczna z tym, jak funkcjonuje twoja organizacja, dlatego chcemy zachęcić cię, aby nie trzymać się kurczowo tradycyjnych ustaleń czy firmowego kanonu, który narzuca, jak zespoły mają pracować. Sytuacja, o której mówimy, jest wyjątkowa i może się okazać, że to, co jest zapisane w firmowym playbooku lub co robiliście do tej pory, nie będzie odpowiednie w tej konkretnej sytuacji. Czasami trzeba na chwilę odłożyć te przyjęte zasady na bok i zastanowić się, co będzie najlepsze w danym momencie, nie martwiąc się o „dług” decyzji podjętych w przeszłości. 3. Pogódź się z faktem, że współpraca wielu zespołów będzie mniej efektywna Trzecia przestroga to pogódź się z faktem, że współpraca wielu zespołów będzie mniej efektywna. Bez względu na to, jak dobrze wdrożymy praktyki, które rekomendujemy, musimy być świadomi, że przy realizacji dużych przedsięwzięć, w których zaangażowane są setki osób, efektywność per osoba będzie znacznie niższa niż w przypadku mniejszych zespołów, liczących na przykład do dziesięciu osób.  Praca będzie bardziej żmudna, spotkania większe, wymagające więcej uwagi i organizacji. Pojawią się również dodatkowe cykle synchronizacyjne i mechanizmy, które normalnie można by pominąć, ale w przypadku dużych przedsięwzięć będą konieczne. Nie mamy magicznych rozwiązań, to po prostu koszt większych inicjatyw. Warto zrewidować bądź urealnić oczekiwania, ponieważ duże przedsięwzięcia nie zawsze przyspieszają realizację projektów, a ich wartość może nie być tak wysoka, jak wynikałoby to z analiz w Excelu czy PowerPointach. 4. Bazuj na dobrze działających zespołach i procesach  Bałagan w pojedynczych zespołach, nieefektywności w procesach wytwórczych, problemy z komunikacją czy technologią tylko się pogłębi, uwypukli, gdy zaczniemy działać wielozespołowo. Dlatego ważne jest, aby zadbać o to, by procesy, współpraca i działania na poziomie pojedynczych zespołów były jak najbardziej efektywne. gdy zaczniemy angażować wielu ludzi w dużą inicjatywę, problemy sumują się, a ich skala staje się znacznie bardziej widoczna na poziomie całej inicjatywy. A co zrobić, jeśli czujesz, że działające zespoły i procesy są nieoptymalne i rzeczywiście będzie to potęgowanie problemów? Może warto zrewidować, czy konieczne jest realizowanie tak dużej inicjatywy w organizacji. Może lepiej podzielić ją na mniejsze, niezależne zadania dla zespołów, zamiast porywać się z motyką na słońce, jeśli obecne warunki są zbyt trudne. Alternatywnie, jeśli jednak zdecydujesz się kontynuować, musisz być gotowy na to, że będzie jeszcze trudniej – pewne rzeczy mogą się rozjeżdżać, a inne psuć w trakcie pracy. W takim przypadku może okazać się, że będzie potrzebne wsparcie zewnętrzne, dodatkowe inwestycje w czas, uwagę, czy budżet, aby jak najszybciej wyprostować problemy i utrzymać inicjatywę na właściwym kursie. 5. Zapewnij wsparcie merytoryczne dla organizacji i zespołów Praca w konfiguracji wielozespołowej jest trudna,  co wskazujemy w całym artykule. Jeśli twoja firma nie ma jeszcze doświadczeń w tym zakresie, nie wahaj się skorzystać z pomocy osób, które już to robiły. W dzisiejszych czasach są profesjonaliści, którzy mają doświadczenie w pracy z takimi inicjatywami. Może to być Scrum Master, Agile Coach, doświadczony Product Owner lub Product Manager, a także kierownicy projektów, którzy potrafią poprowadzić zespół w sposób zwinny. Nie zamykaj się na żadną z opcji, ale skorzystaj z doświadczeń, które mogą pochodzić spoza naszej organizacji. To może być także doskonały pretekst do współpracy z doradcami,takimi jak my, którzy wspierają tego rodzaju przedsięwzięcia. Jest to dobry punkt startu czy nawet cała orbita, wokół której zapewniamy wsparcie organizacji. W takim przypadku koncentrujemy się na transferze naszych doświadczeń, co znacząco zwiększa szansę na sukces ważnego przedsięwzięcia w organizacji, które sprowokowało koncepcję pracy wielozespołowej.Jakie przestrogi mamy dla liderów, którzy potrzebują zrealizować zwinną inicjatywę wieloma zespołami? Zaakceptuj, że nie będzie idealnie na początku.  Pozwól na odstępstwa od tego, jak zespoły działają zazwyczaj.  Pogódź się z faktem, że współpraca wielu zespołów będzie mniej efektywna. Bazuj na dobrze działających zespołach i procesach.  Zapewnij wsparcie merytoryczne dla organizacji zespołów. Jeżeli mierzysz się z tematem współpracy na poziomie wielu zespołów i chcesz uniknąć typowych problemów związanych ze skalowaniem, odezwij się do nas. Wsparcie mentorskie podniesie szansę na sukces ważnych inicjatyw w twojej firmie. Opisz nam swoją sytuację, używając formularza na stronie porzadnyagile.pl/kontaktDobrze rozumiejąc twoją sytuację, proponujemy kilka opcji współpracy dopasowanych do twojego budżetu. Może to być pomoc w postaci pojedynczych konsultacji, wsparcie przy występowaniu prac, aż po pełne wsparcie mentorskie podczas całych prac wytwórczych czy projektowych. FAQ: Inicjatywy wielozespołowe Dlaczego warto stosować dedykowany zespół do inicjatywy obejmującej wiele zespołów? Dedykowany zespół (stworzony z członków innych zespołów zwinnych) pozwala skupić się na jednym, wspólnym celu bez rozpraszania uwagi innymi priorytetami. Dzięki temu zyskujesz większą elastyczność w zarządzaniu i szybsze podejmowanie decyzji, co jest kluczowe w kontekście pracy wieloma zespołami. Czym jest „budżetowanie przyrostowe” i jak to pomaga w zarządzaniu dużymi inicjatywami? Budżetowanie przyrostowe polega na planowaniu i realizacji inicjatywy w małych, kontrolowanych etapach. Dzięki temu można dostarczać wartościowe przyrosty w krótszych cyklach, co pozwala lepiej reagować na zmieniające się potrzeby i minimalizować ryzyko. Dlaczego jeden lider biznesowy jest kluczowy dla priorytetów w dużej inicjatywie? Jeden lider odpowiedzialny za priorytety całości pozwala na jasną i spójną decyzję o tym, co jest najważniejsze. Unika się wtedy chaosu, który może wynikać z różnych osób decydujących o priorytetach dla poszczególnych zespołów. Czym jest kontrakt na współpracę międzyzespołową i jak go wdrożyć? Kontrakt międzyzespołowy to klarowna umowa, która definiuje zasady współpracy – obejmuje standardy komunikacji, zakres odpowiedzialności oraz ustalone procesy. Tworzony na starcie projektu, pozwala uniknąć nieporozumień i maksymalizuje efektywność współdziałania między zespołami. Jakie są korzyści z posiadania jednego źródła prawdy o priorytetach? Posiadanie jednego, wspólnego dla wszystkich Backlogu Produktu zapewnia, że wszystkie zespoły znają priorytety i pełny zakres prac do wykonania. Pomaga to uniknąć rozbieżności i zapewnia spójność działań. Dlaczego warto pracować przyrostowo na poziomie całej inicjatywy, a nie tylko w obrębie poszczególnych zespołów? Praca przyrostowa na poziomie całej inicjatywy pozwala na stopniowe dostarczanie wartości i monitorowanie postępów, co pozwala na szybsze identyfikowanie problemów oraz dostosowywanie działań do zmieniających się warunków rynkowych i biznesowych. Na czym polegają wspólne sesje usprawnieniowe i dlaczego warto je przeprowadzać? Wspólne sesje usprawnieniowe, takie jak retrospektywy międzyzespołowe, umożliwiają dzielenie się doświadczeniami i identyfikowanie obszarów do poprawy w sposobie współpracy. Pomagają także w bieżącym rozwiązywaniu problemów i usprawnianiu procesów pracy. Jakie praktyki warto stosować przy współpracy z wieloma zespołami zwinnymi? Jasny i wyraźny cel inicjatywy Budżetowanie przyrostowe Dedykowany zespół pod inicjatywę Dobór najlepszych ludzi z dostępnych w organizacji Jeden lider biznesowy decydujący o priorytetach Kontrakt na współpracę międzyzespołową Jedno źródło prawdy o priorytetach Praca przyrostowa na poziomie całej inicjatywy Wspólne sesje usprawnieniowe 📄Transkrypcja podcastu „Inicjatywy wielozespołowe” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Rozmawialiśmy niedawno z Jackiem z pewnym liderem IT, który na krawędzi naszej rozmowy, która była o jakimś innym wątku, zapytał nas właśnie o kwestię współpracy wielu zespołów zwinnych nad jednym większym przedsięwzięciem. Mieliśmy swoją odpowiedź w tamtej rozmowie, ale stwierdziliśmy, że temat jest godny nagrania tego materiału. Jacek: Tym bardziej że uważamy z Kubą, że jest to temat, który dotyczy wielu firm i wiele firm, kiedy opanuje pracę nad konkretnym produktem czy projektem na poziomie pojedynczych zespołów, albo chce, albo staje przed sytuacją, w której będzie trzeba sobie poradzić w sytuacji, gdzie tych zespołów zaangażowanych więcej. Kuba: I taka mała ironia dla naszych wiernych słuchaczy. Naprawdę mamy jeszcze o czym nagrywać, bo to 129. odcinek, a to pierwszy raz, gdy realnie zabierzemy się za coś, co w gronie praktyków zwinności bywa nazywane skalowaniem czy skalowaniem zwinności. Tego tematu jeszcze nie poruszaliśmy, mamy swoje konkretne zdanie no i opowiemy Tobie co można zrobić, jak sobie poradzić, kiedy jest projekt dla wielu zespołów zwinnych do realizacji w jednocześnie. Kuba: Spis treści tego odcinka jest dosyć prosty. Najpierw opowiemy o założeniach do sytuacji, którą chcemy poruszyć, potem podzielimy się proponowanymi praktykami pracy wielu zespołów nad jedną inicjatywą i w ostatniej części przekażemy przestrogi oraz dodatkowe przemyślenia w tym temacie. Jacek: Kilka założeń dotyczących tego odcinka. Zakładamy, że są już jakieś zespoły zwinne, które są pewnego rodzaju bazą. Działają w miarę ok, w zadowalający sposób. Nie ma jakichś wybitnych patologii. Można im zaufać na poziomie dowożenia, dostarczania ich własnych tematów z własnego podwórka. Będziemy rozmawiać o sytuacji, w której pojawia się nowy, duży, ważny temat, który będzie wymagał działań wielu zespołów. Kuba: I co mamy na myśli, gdy mówimy wspólny temat dla wielu zespołów? Spotykamy bardzo różne układanki. Wrzucimy kilkoma przykładami takimi zanonimizowanymi. Zobaczymy, na ile to jest coś, co też dotyczy twojej sytuacji. Popularny przypadek to jest przebudowa czy może nawet kompletne przepisanie jakiegoś większego systemu, który wspiera konkretny kawałek procesu biznesowego. W wielu organizacjach te starsze systemy potrafią być na tyle rozległe i na tyle integrujące całość rozwiązania, że po prostu napisanie czegoś nowego wymaga pracy albo prawie wszystkich zespołów technologicznych, a może nawet w niektórych przypadkach wszystkich. Inny przypadek to jakaś radykalna zmiana biznesowa, na przykład zmiana wynikająca albo sprawa, albo zmiana wizerunku, zmiana brandu, może przy okazji jakiegoś przejęcia też zmiana jakichś takich podstawowych elementów takich, powiedzmy, wizerunkowych, marketingowych, które po prostu są rozsiane po całej organizacji, po wszystkich systemach, po wszystkich procesach i potrzeba skoordynowanego działania całej masy zespołów albo wręcz dosłownie wszystkich zespołów. Może to być też coś bardzo trudnego. Nowa linia biznesowa, która wymaga zbudowania składowych z kilku zespołów, w kilku technologiach, z kilku warstw, w kilku miejscach organizacji, może jakaś hurtownia, może jakiś core system, może zmiana w appce, może podłączenie przy okazji jakiejś upsell z innych już istniejących produktów, gdzie też zaszyte rozwiązanie będzie w kilku miejscach. No i sukces biznesowy zależy od tego, że w miarę jednocześnie w dosyć różnych miejscach organizacji będzie to rozsiane. Jacek: I jak usłyszysz w ciągu tego odcinka, nie jesteśmy jakimiś nadmiernymi fanami konkretnego skalowania pracy zwinnej. Raczej z Kubą mamy takie doświadczenie, że praktykowaliśmy skalowanie, kiedy frameworków skalowania nie było i tak do dzisiaj nam zostało, że to chyba tak na koniec dnia jest najmądrzejszy sposób, żeby ewolucyjnie podchodzić do tematu skalowania. Oczywiście można się inspirować, ale to zawsze będzie pewnego rodzaju pułapka. No i całość tego nagrania będzie zachęcać też do tego, żeby zawsze w takich sytuacjach starać się dopasować rozwiązanie, które pasuje do Twojego kontekstu. Kuba: Już kończąc ten rozdział wstępny, w tym odcinku podajemy za chwilę konkretne praktyki, które sami byśmy zastosowali. Natomiast koniecznie nie traktuj ich jako gotowego zestawu, konkretnej procedury, bo tutaj co organizacja to trzeba to dopasować do pewnej odwagi, możliwości, dojrzałości. To są wszystko składowe, które mogą powodować, że wybrane praktyki mają, a w innych organizacjach jednak nie mają sensu. Jacek: Więc bardziej chińskie menu, a nie jedna konkretna potrawa, gdzie każdą z tych naszych rekomendacji można wykorzystać w zależności od tego, czy czujesz, że ona ma sens w Twoim kontekście. Praktyki te bowiem mogą się wzajemnie wykluczać. Kuba: Ok, to przechodząc do sedna. Jakie to są praktyki? Jeśli potrzebujesz działać wieloma zespołami zwinnymi nad jedną całością, rozważ następujące praktyki. Jasny i wyraźne cel inicjatywy. Budżetowanie przyrostowe. Dedykowany zespół pod inicjatywę. Dobór najlepszych ludzi z dostępnych organizacji. Jacek: Jeden lider biznesowy decydujący o priorytetach. Kontrakt na współpracę międzyzespołową. Jedno źródło prawdy o priorytetach. Praca przyrostowa na poziomie całej inicjatywy oraz wspólne sesje usprawnieniowe. Kuba: Przejdźmy do szczegółów tych zaproponowanych praktyk. Pierwszą rzeczą, jaką wymieniliśmy, był jasny i wyraźny cel inicjatywy. O co tutaj chodzi? Jacek: Zdecydowanie. Jasny i wyraźny cel inicjatywy ma za zadanie być pewnego rodzaju takim kapeluszem czy parasolem spajającym myślenie ludzi na temat tego, co tak naprawdę jest do zrealizowania. Rekomendujemy tę praktykę po to, żeby w jakiś sposób nie rozjechały się priorytety, które gdzieś tam w organizacji funkcjonują. Przy okazji, żeby nie doszło do sytuacji, że puchnie nam budżet projektu, czy puchnie nam zakres projektu. Jasne określenie celu to jest taki nasz z Kubą absolutny klasyk, punkt wyjścia, punkt startowy. Tak jak potrzebujemy sensowny cel dla pojedynczego zespołu, no to tak samo ta praktyka jest prawdziwa w momencie, kiedy mówimy o współpracy wielozespołowej. Kuba: Ten cel może stać się pewną mantrą, pewnym takim przypomnieniem, o co nam wszystkim chodzi, o co chodzi wszystkim zespołom. Zwłaszcza że tak jak Jacek powiedziałeś przed chwilą, cele dla zespołów mogą być jasne, natomiast w przypadku inicjatyw wielozespołowych może się okazać, że dla danego zespołu te cele takie, które zazwyczaj są realizowane, one jednak przez chwilę nie będą najważniejsze. Czyli na przykład jest jakiś zespół, który rozwija swój własny system, czy swój kawałek produktu i normalnie zmierzają w jakimś kierunku, zgodnym z wizją tego produktu, zmierzają w realizacji konkretnych kolejnych kroków na Road mapie. Natomiast gdy jednak jest taka spajająca, większa inicjatywa ogólnofirmowa, to może się okazać, że ten cel jednak nie będzie taki oczywisty i wszyscy muszą czuć, że przez chwilę przestajemy realizować tą naszą normalną Road mapę, bo jednak musimy się podporządkować pod ten cel całości. No i tutaj jesteśmy wielkimi fanami tego, żeby to było bardzo klarowne, żeby wszyscy to rozumieli, wszyscy tak samo to interpretowali, żeby nie było takie, no dobra, dobra, robimy niby coś ogólno-firmowego, ale tak naprawdę dalej robimy swoje, bo nic się nie zmieniło. Jeśli te inicjatywy mają się udać, a często one są bardzo ważne biznesowo, z jakichś konkretnych przyczyn firma jednak chodzi o inne konstrukcje, no to też wszyscy realizujmy wspólnie ten sam cel. Kuba: Druga praktyka to budżetowanie przyrostowe. Co to znaczy budżetować przyrostowo? To znaczy uruchamiać budżet, albo uwalniać ten budżet, nie na całą inicjatywę, z góry na wiele miesięcy, kwartałów, a w wielu przypadkach nawet na wiele lat w przód, tylko raczej przyjąć takie założenie, jak fundusze inwestycyjne inwestują w start-upy. Dostajecie pewną rundę finansowania, na wczesnym etapie dostajecie tylko pewne środki, które z góry można założyć, że w zasadzie są niewystarczające na całą wielką rzecz, która jest szykowana, ale chodzi o to, żeby już na wczesnych etapach pójść w takie rozwiązanie bardzo świadomie oszczędne, bardzo też nastawione na pierwsze wczesne rezultaty, po to, żeby ewentualnie dosypać kolejnego inwestowania. Odwracając trochę to od strony ryzyk, te wielozespołowe inicjatywy niestety mają bardzo dużą korelację też z takim zagrożeniem przekroczenia budżetów, przekroczenia zakresów, przekroczenia harmonogramów. To wszystko jest związane z tym, że po prostu jest to bardzo duże coś, no i trzeba świadomie postawić pewną tamę. Dać jasny komunikat do całej grupy, do tej grupy zespołów. Wykorzystajcie, zróbcie pierwszą wersję, zróbcie jakieś NVP i dopiero potem zdecydujemy o kolejnych rundach finansowania, tak żeby nikt się gdzieś tam nie poczuł zbyt komfortowo albo żeby się nawet, bym powiedział, nie rozleniwił taką optyką. Ok, ok, najbliższe wdrożenie dopiero za rok, możemy mnóstwo czasu nawet zmarnować. Zmarnowany tydzień developmentu jest tak samo drogi w pierwszym tygodniu projektu, jak po roku projektu i od razu nastawiałbym całą ekipę na to, żeby jednak iść z tym takim założeniem, że nie mamy nadmiernego budżetu i nawet przełamać tę zasadę, że to coś, co robimy, jest tak wielkie. To jest wielkie, ale będziemy robić to małymi krokami zgodnymi z uruchamianym finansowaniem. Jacek: I tutaj na pewno odporność psychiczna osoby, która buduje takie oczekiwanie, jest istotna, bo spodziewałbym się, słysząc w wielu organizacjach takie głosy, że nie da się, nie można, nie w naszej firmie, to jest nierealne, zawsze robiliśmy to inaczej. Czyli takie klasyczne argumenty, że się nie da. Mimo wszystko tutaj należy zacisnąć zęby i trzymać się tej wersji, że okej, rozumiem, to nie będzie tak kompletne, tak idealne, tak perfekcyjne, ale udowodnijmy sobie wszyscy, tak jak jesteśmy zaangażowani w ten projekt czy inicjatywę, że jesteśmy w stanie dać jakiś zalążek i tak jak wspominałeś Kuba w tych ryzykach. Pokazać, że rozumiemy, o co chodzi biznesowo, pokazać, że ogarniamy technologię no i co istotne w szczególności w przypadku skalowania, pokażmy, że potrafimy ze sobą współpracować. Oczekiwanie, że powstanie coś namacalnego jest świetnym pretekstem, żeby wszystkie te ryzyka sprawdzić. Jacek: Trzecia praktyka, którą rekomendujemy, dedykowany zespół pod inicjatywę. Jest to praktyka, która może wstać w sprzeczności z klasycznym podejściem, które funkcjonuje w organizacji. Czyli mamy stworzone zespoły, które odpowiadają za jakieś określone obszary, procesy, produkty w zależności od tego, po jakim kluczu organizacja zdecydowała się na podział. No i mogłaby istnieć pokusa, żeby wydzielić jakąś część pojemności zespołów na realizację jakiejś wspólnej inicjatywy. Praktyka, którą proponujemy, jest pewnego rodzaju kontrą, czyli raczej mówimy, stwórzmy dedykowany zespół pod inicjatywę, po to, żeby nie trzeba było rywalizować z innymi tematami, które dzieją się w ramach konkretnych zespołów. W takim przypadku uzyskamy tutaj efekt skupienia, polegający na tym, że doskonale wiemy, co jest do zrobienia. Nic innego nas nie rozprasza. No i nie musimy się zastanawiać, w jaki sposób dokonać podziału czasu pomiędzy wiele konkurujących ze sobą inicjatyw. Kuba: W najszczęśliwszym obrocie spraw może się okazać, że jednak nie będziemy mieli współpracy wielu zespołów nad jedną inicjatywą, bo być może powyciągamy po dwie, trzy osoby z kilku zespołów, które normalnie musiałyby współpracować. Możemy z nich nawet tylko tymczasowo pod daną inicjatywę stworzyć po prostu dedykowany zespół w pełni oddany, w 100% oddany temu przedsięwzięciu. Zdajemy sobie sprawę, że to może być sprzeczne z zasadami. Jeszcze trochę będziemy dzisiaj o tym mówić. Z zasadami związanymi np. ze stałymi zespołami. Czyli gdzieś tam łatwo wchodzi praktyka – miejmy zespoły, które skupione są wokół konkretnego produktu, wokół konkretnego obszaru czy systemu. Natomiast my tutaj zachęcamy wśród możliwych praktyk do rozważenia, czy by nie przełamać tej zasady i jednak dla dobra inicjatywy stworzyć dedykowaną ekipę skupioną wokół konkretnego tematu. Kuba: Następna praktyka też jest o doborze ludzkiej, czy dedykowanym zespole. Praktyka, którą nazywaliśmy dobór najlepszych ludzi z dostępnych w organizacji. Zwłaszcza jeśli to przedsięwzięcie, które wymaga pracy wielu zespołów, wielu osób, jest z jakiegoś powodu krytyczne biznesowo, może być potrzebne, żeby naprawdę przeselekcjonować, kogo mamy do wyboru i wybrać te osoby, które podniosą nam prawdopodobieństwo, że się to uda. Szczególnie myślimy o tym, żeby dobrać takie osoby w funkcjach krytycznych, liderskich. Osoba zarządzająca produktem, na pewno w takich przedsięwzięciach strasznie rośnie potrzeba na dobrego architekta, na pewno też w zależności od tego, jak organizacja to układa, jakieś osoby w funkcjach liderskich, też mogą zrobić dużą różnicę. Więc zwłaszcza gdy jest pewne pole manewru w organizacji, myślę, że grono managerskie, które układa taką strukturę wielozespołową, mogłoby rozważyć też pewną selekcję osób do zadania i zmniejszyć ryzyko poprzez wybranie osób najlepiej dopasowanych do tego przedsięwzięcia. Jacek: I jednocześnie za tą poradą, za tą praktyką kryje się pewne zagrożenie. Czyli jeżeli zbudujemy sobie zespół gwiazd, no to może pojawić się problem związany z ich współdziałaniem, może pojawić się temat związany z ego, z tym, czyj pomysł będzie wyżej, niżej i na jakie rzeczy będziemy się decydować. Więc przy okazji budowania takiego zespołu, zdecydowanie warto zwrócić uwagę na sam proces, jakim konstruujemy zespół, proces grupowy, sensowna facylitacja. Wszystkie takie rzeczy, których ostatecznym celem jest sprawienie, że ta grupa ludzi, być może początkowo nawet z nieco sprzecznymi interesami, za kilka tygodni, lepiej myśleć o tygodniach niż o miesiącach, stanie się faktycznym zespołem. Jacek: Kolejna praktyka. Jeden lider biznesowy decydujący o priorytetach. Mamy tutaj na myśli, żeby wskazać konkretną osobę, która będzie odpowiedzialna za podejmowanie decyzji, będzie osobą wskazującą kierunek, będzie takim trochę kompasem, trochę latarnią morską wskazującą właściwą drogę. W zależności od tego, jak aktualnie wygląda struktura twojej organizacji, czy modele, którymi się inspirujesz, taka osoba może być nazywana czy Product Ownerem, czy Product Managerem, czy Project Managerem i tak naprawdę na koniec dnia ta nazwa nie jest tak istotna, jak to, żeby była to faktycznie jedna wskazana osoba, która ma autorytet, ma wizję, jest osobą asertywną i jest w stanie z sukcesem poprowadzić tego rodzaju inicjatywę. Kuba: Dlatego kładziemy nacisk na to, że ma być to jedna osoba, bo przyjmując założenie, że bazujemy na organizacji, która ma już sporo dobrze działających zespołów, to takich osób liderskich może być w organizacji sporo. Jeśli się tak nie namaści do decydowania o tej inicjatywie konkretnej jednej osoby, to możemy wpaść bardzo popularną pułapkę takiego komitetu produktowego, który będzie podejmował decyzje kompromisowe albo takie niewyraziste zamiast jednak ostrego cięcia, ostrego skupienia na wartości, ciągłego przypominania, gdzie jest cel, a niekoniecznie gdzieś zadowalania po kolei wszystkich, włącznie z tymi, których zadowolić po prostu ta wspólna inicjatywa nie będzie w stanie. Tutaj w idealnym scenariuszu jest to jednoznacznie namaszczony decydent. Może jest też coś pośredniego typu spośród grona istniejących Product Ownerów wskazujemy kogoś, kto jest pierwszy spośród równych. Jednak osoba, która na przykład decyduje w sytuacji impasu albo w sytuacjach trudniejszych jednak przyjmuje tę kierownicę. W zależności oczywiście od kultury organizacyjnej, od dotychczasowych relacji pewnie rozwiązanie będzie mniej lub bardziej takie wyostrzone, ale w szczególności nie zostawiłbym tego zupełnie niezaopiekowanego albo liczył na to, że po prostu się dogadają albo będą sobie przekazywać o to jedną priorytety i zadania. To może nie mieć miejsca. Kuba: Następna praktyka, którą proponujemy rozważyć to kontrakt na współpracę międzyzespołową. Mocno dookreślam to, że międzyzespołową. Zakładam, że zwłaszcza jeśli będziemy bazować na zespołach, które już istnieją, to one pewnie swój kontrakt albo oficjalnie mają, albo po prostu już się dotarły i jakieś reguły działania mają. Ale właśnie jakieś reguły działania może się okazać dosyć szybko, że zespół A ma fajne zasady, zespół B ma też fajne zasady, tylko inne, a zespół C ma bardzo unikalne zasady, które są totalnie sprzeczne z zespołami A i B. Więc tutaj, zwłaszcza gdy tworzona jest taka struktura, trzeba bardzo świadomie zwrócić na to uwagę, oddzielnie to zaznaczyć, oddzielnie to przeprocesować, przypilnować, żeby wszystkie zespoły składowe, wchodzące w przykład takie struktury, realizujące taką wspólną inicjatywę, miały ustalony minimalnie potrzebny standard. Ten standard może być również na poziomie dość trywialnym, w jakich narzędziach się komunikujemy, gdzie trzymamy dokumenty, jak korzystamy z narzędzi do trackowania zadań czy czasu, ale to też mogą być takie rzeczy związane na przykład z odpowiedzialnością. Co to znaczy skończona robota? Kto ma dopilnować, kto ma się przypomnieć? Na co sobie pozwalamy w takich kwestiach międzyzespołowych czy związanych z konkretnymi procesami wytwórczymi. Jacek: I taki kontrakt to może być narzędzie, które pomoże nam, wracając do tego punktu, który mówiliśmy z Kubą wcześniej, sprawić, że współpraca tego konkretnego zespołu przyspieszy, tylko dzięki temu, że na wstępie umówimy się na to, w jaki sposób podchodzimy do konkretnych tematów. Jest to taka jasność i przejrzystość, jeśli chodzi o podstawowe zasady, no jest całkiem dobrym akceleratorem współpracy w zespołach. Jacek: Kolejna praktyka, jedno źródło prawdy o priorytetach. Myślimy tutaj o sytuacji, w której mamy jedno miejsce prawdy, jedno źródło konkretne, wskazane, dostępne dla wszystkich, tak, aby nie było poczucia, że albo nie widzimy całego obszaru i tematów, którymi będziemy się zajmować, albo że jest to tylko jakiś wycinek na teraz i część dopiero zostanie nam odsłonięta w późniejszym czasie. Jak również jedno źródło, którego zadaniem będzie powiedzenie w taki jasny, binarny sposób, te tematy są do zrobienia, nad tymi tematami aktualnie pracujemy, a te konkretne tematy zostały już zrealizowane.  Kuba: I ta praktyka jest bardzo zbieżna już z dwoma wcześniejszymi. Z jednej strony jest tutaj jasne pokazanie, jakie zapadły decyzje, w takim źródle prawdy jest informacja, tak, to właśnie robimy. Jest to też bardzo powiązane z tą przyrostowością na poziomie budżetowym. Prawdopodobnie będziemy mieli ograniczenia. Rzadko się zdarza sytuacja, żeby takie wielkie przedsięwzięcie nie miało ograniczeń. Te ograniczenia niech będą bardzo jednoznaczne. Czyli te konkretne rzeczy robimy, a innych nie robimy, choć może można. I czasami jest taka właśnie pokusa, jeśli już robimy, to przy okazji róbmy jeszcze to. Im bardziej rozproszona jest wiedza na temat tego, co jest ważne, im bardziej rozproszona jest wiedza na temat tego, jaki jest tak naprawdę zakres do realizacji w danym kroku, w konkretnych kilku kolejnych krokach, to się to może niesamowicie prosto rozjechać. Czyli pokus do tego, żeby się ten zakres ciągle zwiększał, będzie pełny. I lepiej zastosować coś, co jest wspólną listą priorytetów. Jeśli korzystać się ze Scruma, to to będzie jeden Backlog Produktu. Jeśli korzysta się z jakiegoś podejścia bardziej kanbanowego, to będzie po prostu jedna kolumna jednoznacznie pasująca, co jest do zrobienia w pierwszej kolejności. Kuba: Przedostatnia porada, którą chcielibyśmy przekazać, to praca przyrostowa na poziomie całej inicjatywy. Wspomniałem już na samym początku o budżetowaniu przyrostowym, a teraz akcent przeniosę na to, żeby również dostarczanie było przyrostowo. Dostarczenie przyrostowe jest takie oczywiste w wielu zespołach. Po prostu będą kolejne wersje, kolejne kawałki. Każdy zespół, zwłaszcza jeśli jest rozdzielony jakoś tak systemowo, albo komponentowo, to po prostu będzie robił coraz lepsze wersje swojego kawałka. Natomiast ja bym akcent położył na to, że to nie tylko chodzi o to, żeby każdy robił swój kawałek przyrostowo, ale żeby na poziomie całej inicjatywy powstawały przyrostowy. Jeśli zespół A, B i C zrobią swoje kawałki, to w dodatku te kawałki też są przyrostem. One są połączone, one albo spełniają w jakiejś prostej wersji cały proces, od początku do jego końca, albo to jest jakaś pierwsza wersja całego produktu. Cokolwiek co jest realizowane, ale żeby było również międzyzespołowo przyrostowe, czyli tworzyło kolejne wersje bardzo prostego produktu, na początku wręcz prymitywnego, ale później rosło, rosło, rosło, rosło, aż w końcu, zwłaszcza w drugiej połowie, czy tak bliżej końca, cokolwiek to jest ten koniec, będzie wręcz widać, że w zasadzie to już prawie wszystko mamy. To są jakieś drobne doróbki. Z perspektywy całego zakresu to wcale nie będą drobne doróbki. No ale już będzie bardzo dosyć wcześnie, najlepiej byłoby jak najwcześniej widać, że to już jest jakaś pierwsza część produktu i on jest całością na poziomie całej inicjatywy, a nie tylko sumą jakichś gotowych puzzli, które jednak na razie zupełnie nie tworzą wspólnego obrazku. Jacek: Moja przeszłość developerska, jak słucham Kuba tej opowieści, pokazuje mi całą masę nieoczywistych problemów, które mogą się pojawić w trakcie implementacji. Cała zabawa w integrację rozwiązania, to w jaki sposób podejdziemy do wersjonowania, to czy mamy zapiętą jakąś ciągłą integrację, pod spodem cały proces code review i zapewniania, że te klocki na koniec dnia połączymy i ze sobą zadziałają. To jest coś, co w szczególności z perspektywy biznesowej może być nieoczywiste i takie trochę bym powiedział niedoszacowane, jeśli chodzi o całościowy wysiłek, który będzie potrzebny, żeby taki projekt zintegrować. Tak więc im wcześniej zrobimy, im wcześniej będziemy oczekiwać też, że zostanie to zintegrowane na wszystkich koniecznych poziomach, to tym wcześniej w najgorszym przypadku dowiemy się, że czegoś nie potrafimy, mamy jakieś problemy, brakuje nam jakichś zasobów. No i będziemy mieć czas, żeby odpowiednio zareagować. Jacek: Ostatnia rekomendacja, którą przygotowaliśmy z Kubą, brzmi wspólne sesje usprawnieniowe. Jeżeli słuchasz naszego podcastu od dłuższego czasu, to na pewno ten punkt nie jest dla Ciebie zaskoczeniem. Mocno z Kubą wierzymy w to, że zawsze można pracować lepiej i zawsze można poszukać usprawnień. No i w szczególności w takiej konfiguracji, o której od początku dzisiejszego odcinka rozmawiamy, tam na pewno będzie cała masa tematów, które będzie można zrobić inaczej, które będzie można zrobić lepiej. Będzie pełno tematów, o które się potkniemy. Stąd niezwykle istotne jest to, żeby zadbać o to, żeby takie sesje usprawnieniowe pojawiały się często i żeby prowadziły do faktycznych, konkretnych usprawnień, które też będą faktycznie wprowadzane w życie.  Kuba: Zwłaszcza że ten wymiar współpracy międzyzespołowej sam w sobie jeszcze będzie generował tematy, które normalnie pewnie już byłyby w wielu firmach dosyć dogrzane. Zwłaszcza jeśli też pójść w ten model, którym mocno rekomendujemy, że być może w danej organizacji co inicjatywa to trochę inaczej się zabierzemy na tę wielozespołowość. Więc również te doświadczenia muszą się dopiero kształtować i też ten sposób zgrania się dopiero się będzie tworzył, więc nie przyjmujmy założenia, że raz w dobrze wymyślony sposób będzie dobrze działał. Tu oczywiście takie wspólne sesje usprawnieniowe mogą wraz z rosnącą skalą być coraz bardziej skomplikowane, więc również rozważmy scenariusz, w którym te sesje usprawnieniowe już nie są zebraniem wszystkich uczestników całego wielkiego przedsięwzięcia. Może to jest coś, co się powinno odbywać w odpowiednich gronach dedykowanych danemu zagadnieniu. Na przykład spotykają się tylko programiści między sobą z różnych zespołów, bo mają coś do przegadania na swojej profesji. Czy na przykład tylko Product Ownerzy, bo rozmawiają o priorytetach lub mapach. To jest w porządku, tutaj fajnie byłoby uruchomić jakąś taką elastyczność, takie dopasowanie rozwiązania do sytuacji, a nie takie podejście sztampowe. Co do zasady wszyscy wszystko na wspólnych wielkich spotkaniach, bo one w którymś momencie mogą, dosyć łatwo zabić entuzjazm do usprawniania się. Jacek: Jeżeli czujesz, że temat usprawniania się w twojej organizacji wymaga jeszcze poprawy, to zachęcamy cię do zapoznania się z naszym webinarem, w którym opowiadamy o tym, jak skutecznie wprowadzać usprawnienia. Znajdziesz go na stronie porzadnyagile.pl/retro Kuba: Jeśli chodzi o listę praktyk, to moglibyśmy jeszcze wymieniać dalej. Postanowiliśmy się zatrzymać na jakimś etapie. Mamy kolejne pomysły, ale też nie mieliśmy ambicji zrobić zamkniętej listy, raczej wyliczyć te, które czujemy, że są tymi najważniejszymi, od których zaczynamy nasze rekomendacje, więc tu się zatrzymamy w tym rozdziale i przejdziemy do drugiej części. Jacek: W drugiej części chcieliśmy podzielić się już nie konkretnymi praktykami, a raczej pewnego rodzaju przestrogami i dodatkowymi przemyśleniami, które uważamy, że mogą być pomocne, jeżeli jest przed Tobą wyzwanie dotyczące pracy wielozespołowej. Kuba: Pierwsza przestroga, już w zasadzie była trochę zasygnalizowana w ostatniej z praktyk, czyli zaakceptuj, że nie będzie idealnie od początku. Wiele osób, z którymi rozmawiam, które właśnie mierzą się z takim wyzwaniem, mają ochotę, mają potrzebę, czasami taką pokusę, że jak dobrze to rozplanujemy, że jak dobrze to poukładamy, dobrze wymyślimy procesy, dobrze granice zarysujemy, to już będzie w zasadzie jak z płatka, już od pierwszego roku będzie dobrze. W innych przypadkach może nawet jest pełna świadomość, że po prostu robimy to pierwszy raz w tej organizacji, może idealnie nie będzie, ale jest też taka dosyć szybka, wczesna frustracja, że kurcze, ale te spotkania są nieefektywne, tu ktoś coś zgubił, coś się nie zagrało. To przemyślenie przestroga od nas, tak, tak będzie. Tak, niestety, tak będzie. Czyli te konstrukcje wielozespołowe, zwłaszcza gdy jest, do tej pory nie ma dużego doświadczenia, one niestety po prostu nie będą optymalne. Po to potrzebujemy się usprawniać, po to się uczymy, po to zastosujmy pewne z tych praktyk, które my podpowiedzieliśmy, żeby to wcześniej wyłapać. Żeby pracując przyrostowo, się wcześniej zorientować, żeby ciągle się doskonalić dzięki usprawnieniom i raczej być zadowolonym z tego, jak będzie to wyglądało w kolejnych krokach rozwoju tej dużej inicjatywy, a nie mieć marzenia o tym, że będzie idealnie dobrze. Jacek: Drugie przemyślenie, pozwól na odstępstwa od tego, jak zespoły działają zazwyczaj. Część naszych porad może stać w sprzeczności z tym, jak funkcjonuje Twoja organizacja i chcemy zachęcić Cię do tego, żebyś nie trzymał/trzymała się zwyczajowych ustaleń czy jakiegoś takiego kanonu firmowego, który nakazuje, że zespoły mają funkcjonować w jakiś konkretny sposób. Sytuacja, o której opowiadamy, jest sytuacją taką, nazwijmy to zwykle nadzwyczajną i może się okazać, że to, co mamy w naszym firmowym playbooku, czy to, jak to robiliśmy od zawsze, czy to, jak to robimy teraz i nam się wydaje, że to jest najlepsze, może ćwiczeniowo będzie trzeba na chwilę te koncepcje odłożyć na bok i zastanowić się, co byłoby najlepsze w tym momencie. Nie ciągnąc za sobą tego, nazwijmy to, długu decyzji, które podjęliśmy w stosunku do tego, jak powinien wyglądać nasz proces pracy. Kuba: Trzecia przestroga, to pogódź się z faktem, że współpraca wielu zespołów będzie mniej efektywna. Jakby się nie starać, ile praktyk, które sami rekomendujemy, by nie wprowadzać, mamy poczucie, że jednak jeśli robimy coś wielkiego, jeśli to w tym przedsięwzięciu zaangażowane będzie kilkanaście albo wręcz kilkadziesiąt czy kilkaset osób, to siłą rzeczy ta efektywność będzie znacznie słabsza per osoba zaangażowana, niż to, do czego może byśmy byli w stanie się przyzwyczaić w sytuacjach, gdy zespoły są takie maks dziesięcioosobowe. No i tutaj nie mamy dobrej odpowiedzi, to jest taka pewna przestroga. Ta praca będzie po prostu trochę bardziej żmudna, te spotkania trochę większe będą wymagały też trochę więcej zachodu, trochę więcej przypilnowania. Być może pojawią się również siłą rzeczy pewne dodatkowe cykle synchronizacyjne, pewne mechanizmy, które normalnie można by żyć bez nich, można by się obyć bez nich. No ale niestety takie duże przedsięwzięcia mogą być po prostu niemożliwe do realizacji bez tego. I tutaj nie mamy sekretów, nie mamy żadnych jakichś magicznych rozwiązań, to po prostu jest pewnego rodzaju koszt, z którego trzeba sobie zdać sprawę, wziąć na niego poprawkę. Może też trzeba tak zrewidować czy urealnić swoje oczekiwania. Po prostu takie bardzo duże przedsięwzięcia wcale nie będą na przykład przyspieszały projektów, albo ta wartość dodana z takich dużych inicjatyw wcale nie będzie aż tak wielka, jak może można by wnioskować na poziomie Excela albo Power Pointu. Jacek: Przedostatnia porada, bazuj na dobrze działających zespołach i procesach. Bałagan na poziomie pojedynczych zespołów, wszelkiego rodzaju nieefektywności, czy to procesów wytwórczych, czy tego, jak ludzie ze sobą się komunikują, wszelkiego rodzaju potykacze technologiczne. Wszystko to tylko się uwypukli i spotęguje, kiedy będziemy musieli zacząć działać wielozespołowo. Więc ta rekomendacja czy przestroga to jest takie wskazanie mówiące o tym, że warto zadbać o to, żeby na poziomie pojedynczych zespołów proces, współpraca, działania wyglądały jak najlepiej. No bo tak jak Kuba mówił w poprzednim punkcie, jeżeli zaczniemy działać wielozespołowo, jeżeli zaczniemy mówić o wielu osobach zaangażowanych w jakieś duże inicjatywy, no to niestety zacznie się to nam sumować i suma tych problemów uwidoczni się jeszcze boleśniej na poziomie jednego dużego zespołu. Kuba: A co zrobić, jeśli jednak czujesz, że te działające zespoły i procesy są nieoptymalne i będzie to potęgowanie, przed którym przestrzega Jacek, to może zrewiduj, czy na pewno musisz w organizacji zrealizować tak dużą inicjatywę. Może trzeba ją skroić, może trzeba ją podzielić na mniejsze cząstki, które można dać jednak niezależnie zespołom i po prostu nie porywać się z motyką na słońce, jeśli jest na razie z tym za ciężko lub alternatywnie można wziąć poprawkę na to, że w takim razie będzie jeszcze trudniej, bo tu się pewne rzeczy będą rozjeżdżały, pewne rzeczy będą się psuły w trakcie, gdy pracujemy. No i na przykład nadnaturalne wsparcie jest potrzebne albo doinwestowanie w jakichś obszarów, czy to uwagą, czy to czasem, czy dosłownie budżetem, żeby pewne rzeczy wyprostować tak szybko jak to możliwe, żeby inicjatywa wycierpiała. Kuba: I ostatnia porada, to zapewnij wsparcie merytoryczne dla organizacji i zespołów. Praca taka wielozespołowa jest po prostu bardzo trudna, o czym chyba mówimy przez cały ten odcinek. Jeśli do tej pory takich doświadczeń w firmie nie masz, nie zawahaj się skorzystać ze wsparcia kogoś, kto już to robi. To nie jest nic nowego. Dzisiaj już istnieją osoby czy profesjonaliści, którzy mają doświadczenia z tego typu sprawami. Być może trzeba zapewnić takie wsparcie. Co to może być? W praktyce to mogą być albo Scrum Masterzy, którzy mają takie doświadczenia, albo Agile Coach’e, którzy mają takie doświadczenia. Może odpowiedni Product Owner, który już był w takiej sytuacji, czy Product Manager? Może również doświadczeni kierownicy projektu, którzy umieją tutaj zwinnie to wyprowadzić? Nie zamykajmy się na żaden ze scenariuszy, ale skorzystajmy po prostu z doświadczeń, które być może są, tylko są na razie poza naszą organizacją. To może być też dobry pretekst do współpracy z takimi doradcami jak my. My też wspieramy takie przedsięwzięcia i to jest czasami dobry punkt startu czy nawet w ogóle cała orbita, wokół której możemy takie wsparcie organizacji zapewnić. My się wtedy skupiamy na transferze naszych doświadczeń. Przy okazji też organizacja podnosi sobie szansę na sukces tego konkretnego, ważnego przedsięwzięcia, które sprowokowało całą koncepcję pracy wielozespołowej. Jacek: Podsumowując drugi rozdział dzisiejszego odcinka. Jakie przestrogi mamy dla liderów, którzy potrzebują zrealizować zwinną inicjatywę wieloma zespołami? Zaakceptuj, że nie będzie idealnie na początku. Pozwól na odstępstwa od tego, jak zespoły działają zazwyczaj.  Kuba: Obudź się z faktem, że współpraca wielu zespołów będzie mniej efektywna. Bazuj na dobrze działających zespołach i procesach. Zapewnij wsparcie merytoryczne dla organizacji zespołów. Jacek: Natomiast jeżeli mierzysz się z tematem współpracy na poziomie wielu zespołów i chcesz uniknąć typowych problemów związanych ze skalowaniem, odezwij się do nas. Wsparcie mentorskie podniesie szansę na sukces ważnych inicjatyw w Twojej firmie. Opisz nam swoją sytuację, używając formularza na stronie porzadnyagile.pl/kontakt. Kuba: Dobrze rozumiejąc Twoją sytuację, zaproponujemy kilka opcji możliwej współpracy dopasowanej do twojego budżetu. Mogą to być pojedyncze konsultacje, to może być też pomoc w występowaniu prac, aż po możliwy wariant maksymalny wsparcie mentorskie podczas całych prac wytwórczych czy projektowych. Jacek: Notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/129 Kuba: To by było wszystko na dzisiaj. Dzięki Jacek. ——— To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę! Ostatnia aktualizacja: 23 stycznia 2026The post Inicjatywy wielozespołowe first appeared on Porządny Agile.

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. Porządny Agile · Czego oczekiwać od Scrum Mastera? Kiedy Scrum Master poprawnie realizuje swoją odpowiedzialność? 1. Inicjuje rozmowę o swojej “ofercie”  To absolutna podstaw pracy! 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ć. Scrum Master powinien wyjaśnić, na czym polega jego funkcja. Umiejętność przedstawienia swojej oferty świadczy o tym, że jest ona dobrze przemyślana. Dobra oferta wykracza poza wsparcie zespołu tylko podczas wydarzeń scrumowych. Pokazanie tego, co faktycznie może zrobić w organizacji, jest czymś, do czego zawsze zachęcamy. 2. Edukuje zespół w temacie zwinności i Scruma Oczekujemy, że Scrum Master potrafi wyjaśnić nie tylko sam framework Scrum, który w wielu firmach stanowi podstawę pracy zespołów. SM musi także rozumieć czym jest zwinność. Popularność Scruma sprawiła, że wiele technik i praktyk jest kategoryzowanych jako scrumowe. Może prowadzić to 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 wielu obszarach. Przykładowo może być to być samozarządzanie — koncept, w którym 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. SM zna też techniki zarządzania Backlogiem Produktu, metody priorytetyzacji czy sposoby opisu elementów Backlogu. Oczekujemy, ż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. Oznacza to aktywną pomoc zespołowi w ich zastosowaniu, doradztwo, jak zrobić to po raz pierwszy i jak udoskonalić docelowy proces. Jeśli Scrum Master mówi: „Nie umiemy tego robić”, to oznacza, że to przede wszystkim SM powinien nadrobić braki w edukacji. 3. Sprawia, że wydarzenia i artefakty scrumowe mają sens Z bólem serca czasami słyszymy od zespołów stwierdzenia typu: „Nasze Daily nie ma sensu”, „Nie warto realizować Retrospektywy„. Czasem spotyka się też stwierdzenie: „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. Wszystkie elementy Scruma – praktykowaliśmy i obserwowaliśmy to – 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. Od Scrum Mastera oczekujemy, że korektami i podpowiedziami sprawi, że poszczególne praktyki w Zespole Scrumowym złożą się w całość. Pierwszym krokiem z perspektywy Scrum Mastera powinno być zrozumienie wszystkich niuansów Scruma. Tylko wtedy będzie w stanie 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. Oznacza to rozmawianie z praktykami, uczestnictwo w szkoleniach prowadzonych przez osoby, które faktycznie to rozumieją. To tylko przykłady działań, które można podjąć, aby uzyskać takie zrozumienie. 4. Zapewnia, że zespół się regularnie usprawnia 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. Każdy uczestnik rozumie jej przebieg i wie, czego się od niego oczekuje podczas tego spotkania. W efekcie cały zespół dochodzi do konkretnych wniosków. Retrospektywa jest spotkaniem z którego Zespół wychodzi z poczuciem: „Tak, od najbliższego Sprintu wprowadzimy jedną, dwie rzeczy, które realnie zmienią naszą pracę”. Jeśli u Ciebie wydarzenie to jest niedoskonałe, sprawdź nasz webinar jak powinna wyglądać porządna Retrospektywa Sprintu. 5. Doprowadza do usuwania przeszkód Przeszkody w Scrumie to pojęcie występujące w sytuacji, w której Zespół spowalnia pracę i ma trudności w realizacji celów. Może to też być ewidentny postój w miejscu, w którym Zespół nie jest w stanie uzyskiwać jakiegokolwiek postępu.  Scrum Master dąży do usuwania tych przeszkód. Może to robić samodzielnie. Może 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. 6. Zwraca uwagę zespołu na jego efektywność 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/ 7. Wyjaśnia intencje swoich działań 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. Co zrobić, jeśli sposób pełnienia roli SM wymaga usprawnienia? 1. Zaproponuj spotkanie 1×1 lub z zespołem 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. 2. Powołaj się na nasz materiał jako punkt odniesienia 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. 3. Wylicz rzeczy których ci brakuje 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: mniej oceniać i unikać wzajemnych pretensji,  nie rób recenzji dotychczasowych działań danego Scrum Mastera, skup się raczej na przyszłości, na tym, co możesz wspólnie zrobić, a nie na tym, co do tej pory nie zadziałało u tej osoby, u poprzedniego Scrum Mastera czy poprzednich członków zespołu. 4. Poproś, żeby nad tym wspólnie popracować z zespołem 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. 5. Ustalcie plan działania, jak usunąć luki, zaczynając od najważniejszej 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:  spotkanie się z określonymi osobami,  zorganizowanie spotkania,  przygotowanie materiałów,  przeprowadzenie analizy.  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. 6. Zaproś Scrum Mastera z innego zespołu, żeby dał feedback 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. 7. Zaangażuj zewnętrznego eksperta, który wesprze rozwój Scrum Mastera Należy ustalić odpowiedni styl współpracy  — może to być coaching, mentoring, konsulting lub szkolenie. 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. 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, które decydują o takiej współpracy i posiadają budżet na takie działania. 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 8. Umówcie się na sprawdzenie efektów – kiedy sprawdzicie, jaki efekt dały ustalone działania usprawnieniowe 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. FAQ: Czego oczekiwać od Scrum Mastera? Co powinno być podstawową „ofertą” Scrum Mastera? Scrum Master powinien jasno komunikować, w jaki sposób może wspierać zespół oraz organizację, inicjując rozmowę o swojej roli i wartościach, które wnosi. Jak Scrum Master pomaga zespołowi w zrozumieniu Scruma? Scrum Master edukuje zespół w zakresie zwinności i Scruma, wspierając w praktycznym stosowaniu zasad, np. w samozarządzaniu czy planowaniu Sprintu. W jaki sposób Scrum Master wspiera zespół w usprawnieniach? Regularnie inicjuje i wspiera procesy usprawnień, np. poprzez retrospektywy, pomagając zespołowi wyciągać wnioski i doskonalić pracę. Jak monitorować postępy w usprawnianiu pracy Scrum Mastera? Umówcie się na regularne sprawdzanie efektów podjętych działań, aby ocenić, jakie usprawnienia przynoszą pożądane rezultaty, a jakie obszary wymagają poprawy. Jakie kroki można podjąć, aby usprawnić pracę Scrum Mastera? Zaproponuj spotkanie 1×1, powołaj się na dostępne materiały edukacyjne lub zaangażuj zewnętrznego eksperta, aby ocenić i wspierać rozwój Scrum Mastera. Dlaczego tłumaczenie intencji działań Scrum Mastera jest ważne? Otwarte i szczere wyjaśnianie motywacji działań przez Scrum Mastera pomaga budować zaufanie i zrozumienie w zespole, unikając poczucia manipulacji i niejasności. 📄Transkrypcja podcastu „Czego oczekiwać od Scrum Mastera?” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. 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. 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 zespół 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. ——— To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę! Ostatnia aktualizacja: 23 stycznia 2026The post Czego oczekiwać od Scrum Mastera? first appeared on Porządny Agile.

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. Porządny Agile · Dlaczego tak trudno ustalić 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. Powody problemów w konstruowaniu celu Sprintu 1. Brak zrozumienia czym jest 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. 2. Założenie, że Cel dotyczy całego zakresu i wszystkich Developerów 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. 3. Poczucie, że jeśli coś nie jest w Celu Sprintu, to nie jest ważne 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. 4. Realizacja Celów jest rozliczana przez management  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. 5. Brak pracy przyrostowej 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. 6. Wiele równoległych wątków realizowanych w Sprincie 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. 7. Produkt nie jest rozwijany poprzez cele 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. 8. Backlog Produktu nie jest uporządkowany 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. 9. Zespół rozwija wiele produktów albo projektów 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.  10. Zespół nie tworzy kompletnego produktu  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ść. 11.  Zespół realizuje głównie zadania utrzymaniowe  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 Jak rozwiązać problemy w zbudowaniu celu Sprintu?  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ć.  1.Uporządkuj i rozbuduj swoją wiedzę na temat Celu Sprintu 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. 2. Wyrównaj wiedzę na temat Celu Sprintu w zespole  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. 3. Eksperymentuj z formułami 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. 4. Usprawnij proces Refinementu Backlogu Produktu 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 5. Rozpocznij dyskusję o konfiguracji zespołów  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? Brak zrozumienia, czym jest Cel Sprintu Założenie, że Cel dotyczy całego zakresu i wszystkich developerów. Poczucie, że jeśli coś nie jest w Celu Sprintu, nie jest ważne. Realizacja celów rozliczana przez management. Brak pracy przyrostowej. Wiele równoległych wątków realizowanych w Sprincie. Produkt nie jest rozwijany poprzez cele. Backlog Produktu nie jest uporządkowany. Zespół rozwija wiele produktów albo projektów. Zespół nie tworzy kompletnego produktu.  Zespół realizuje głównie zadania utrzymaniowe. 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. FAQ: Dlaczego tak trudno ustalić Cel Sprintu? Czym jest Cel Sprintu? Cel Sprintu jest zobowiązaniem wchodzącym w skład Backlogu Sprintu. Wskazuje, co jest do osiągnięcia w ramach Sprintu. Określa, jaki ma mieć kształt Przyrost, który uzyskamy w tym Sprincie. Dlaczego sensownie ustalony Cel Sprintu jest tak istotny? Cel Sprintu jest kluczowy, ponieważ pomaga zespołowi skupić się na najważniejszych zadaniach, eliminując rozproszenie uwagi i ułatwiając podejmowanie decyzji w trakcie pracy. Czy realizujesz wiele równoległych wątków w Sprincie? Brak skupienia na jednym, konkretnym celu sprawia, że zespół traci klarowność co do tego, co naprawdę chce osiągnąć. Warto zatem skupić się na jednym, najważniejszym kierunku działań, aby skuteczniej osiągać zamierzone rezultaty. W innym wypadku możesz mieć trudności z ustaleniem Celu Sprintu. Nieuporządkowany Backlog Produktu = problem z ustaleniem Celu Sprintu? Chaotyczny Backlog Produktu sprawia, że trudno wyłonić najważniejsze zadania, co utrudnia ustalenie klarownego Celu Sprintu. Dobrze zorganizowany Backlog jest kluczem do skupienia się na priorytetach i osiągnięcia zamierzonych rezultatów. Dlaczego warto jest uporządkować i rozbudować swoją wiedzę na temat Celu Sprintu? To, jak rozumiesz i tłumaczysz istotę Celu Sprintu, ma ogromne znaczenie dla efektywności zespołu. Inwestując czas w zgłębianie tej wiedzy, poprawiasz swoje umiejętności jako Scrum Master. Szukaj informacji, pytaj ekspertów, ćwicz i sprawdzaj swoje podejście. Lepsze zrozumienie Celu Sprintu przekłada się na lepsze wyniki zespołu. W czym pomoże wyrównanie wiedzy na temat Celu Sprintu w zespole? Wyrównanie wiedzy na temat Celu Sprintu w zespole daje sporo korzyści. Działanie takie poprawia zrozumienie pracy do wykonania i skupienie całego zespołu na najważniejszych zadaniach. Szkolenia i warsztaty, które wyrównują wiedzę, a także praca na realnych przykładach Celu Sprintu Twojego zespołu, pomagają wszystkim członkom lepiej zrozumieć i realizować wspólne cele. To prowadzi do bardziej efektywnej współpracy i lepszych rezultatów. Jakie korzyści przynosi eksperymentowanie z formułami Celu Sprintu? Próbowanie różnych formatów i podejść do ustalania Celu Sprintu pomaga znaleźć najbardziej efektywne rozwiązanie dla Twojego zespołu. Nie poddawaj się po pierwszym niepowodzeniu – testowanie różnych metod pozwala na lepsze dostosowanie celów do specyfiki pracy zespołu, co prowadzi do większej klarowności, lepszego skupienia i wyższej efektywności. Dodatkowe materiały Cel Sprintu Cel Produktu Kiedy Scrum nie jest odpowiedzią? Dlaczego Cel Sprintu jest kluczem do efektywnego Sprintu? Szybciej, ale pod presją: wpływ przerw na produktywność zespołów Dlaczego nie kładę nacisku na Cele Sprintu? – Mike Cohn artykuł 10 powodów, dla których nie udaje ci się skutecznie ustalić Celu Sprintu 📄Transkrypcja podcastu „Dlaczego tak trudno ustalić Cel Sprintu?„ Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. 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ę. ——— To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę! Ostatnia aktualizacja: 23 stycznia 2026The post Dlaczego tak trudno ustalić Cel Sprintu? first appeared on Porządny Agile.

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. Porządny Agile · Wzmacnianie kompetencji zwinnych w zespołach Jakie są zagrożenia braku dalszej nauki w praktykach zwinnych? 1. Rozbudowa zespołu o osoby bez zwinnego doświadczenia 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.  2. Utrata inicjatorów zwinności Przechodząc do kolejnego przykładu. Grupa pasjonatów wprowadziła w jednej z firm zwinność. 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 zrozumienia i rutynowe praktyki sprawiły, że zespół przestał rozumieć, dlaczego wprowadzili. Mieli trudności z podejściem do naprawy tego, co stworzyli, a tym, co zrealizowali. 3. Zwalnianie Scrum Masterów Jedna z organizacji zwolniła Scrum Masterów. To był kolejny przypadek. Firma ta miała przeświadczenie, że osiągnęła już wszystko, co wiązało się ze zwinnością. 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. 4. Skalowanie Scruma 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 zespół uczył się Scruma. Zespół postrzegał to narzędzie jako sposób na organizację swojej pracy. Słusznie. Jednak na tamtym etapie bardziej ambitne rzeczy pozostawały poza ich zasięgiem. W efekcie zabrakło im wyższego wtajemniczenia i zaawansowania stosowania praktyk zwinnych.  Przyczyny zatrzymania rozwoju kompetencji 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. 1. Przekonanie, że uczymy się tylko raz 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. 2. Transformacja zwinna jako zamknięty projekt 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. 3. Niechęć do zwinności 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 ludzie z nią wiązali. W związku z tym jest przekonanie, że to, co mamy i używamy, jest na tyle istotne, że chcemy to zachować. 4. Wysoki koszt szkoleń 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. 5. Konkurencja wzmacniania kompetencji z nowymi trendami 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. 6. Inne priorytety w firmie 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: obszaru feedbacku, umiejętności twardych programistów, techniki sprzedaży, wzmacniania mocnych stron pracowników 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. 7. Brak spójnego podejścia do edukacji 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 9 sposobów wzmacniania kompetencji zwinnych w zespołach 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.   1. Zastanów się, jak obecny sposób działania zespołów odpowiada na potrzeby organizacji 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ę: gdzie znajdują się mocne strony zespołu,  w jaki sposób zespół pracuje,  gdzie znajdują się obszary do poprawy w zespole bądź w organizacji.  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.  2. Diagnozuj wewnętrzny stan wiedzy 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:   umiejętności profesjonalistów, stopień doświadczenia zespołów,  zdolność zespołów do radzenia sobie z różnymi wyzwaniami,  jakie stosują praktyki.  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. 3. Poproś eksperta zewnętrznego o rekomendacje zmian w procesach 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. 4. Zorganizuj inspiracyjne warsztaty 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 rozwiążą, 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. 5. Dopasuj program rozwoju do potrzeb twoich zespołów 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 wymaga, aby organizacje same tworzyły rozwiązania dopasowane do swoich potrzeb. 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. 6. Uruchom wewnętrzny program wymiany wiedzy 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:  organizację wzajemnych wizyt międzyzespołowych,  zapraszając zespoły do wymiany doświadczeń,  organizując szkolenia, pogadanki,  wewnętrzne gildie, gdzie zespoły mogą wspólnie rozwiązywać trudne problemy. Bardziej zaawansowanym rozwiązaniem są:  wewnętrzne konferencje, spotkania wymiany wiedzy, podczas których zespoły mogą podsumować swoje doświadczenia, omówić eksperymenty procesowe, narzędzia czy sposoby radzenia sobie z trudnymi sytuacjami. 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 pasują 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. 7. Aktywuj istniejących w firmie ekspertów do prowadzenia warsztatów To kolejna porada oparta na tym, co organizacja już faktycznie zbudowała. Wiele firm zapewnia ciągłe odświeżanie wiedzy i inspiruje poprzez wewnętrzne warsztaty lub szkolenia, które prowadzą pracownicy 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: po pierwsze, pasjonaci zwinności mogą być ekspertami w tej dziedzinie, ale niekoniecznie najlepszymi szkoleniowcami. Warto wzmocnić ich umiejętności w zakresie prowadzenia warsztatów, sesji i strukturyzacji zajęć, czyli zapewnić im narzędzia dobrego szkoleniowca. po drugie, istnieje ryzyko, że osoby, które zechcą zaangażować się w te inicjatywy, mogą mieć luki w wiedzy na temat zwinności. Może to prowadzić do przekazywania błędnych zrozumień, utrwalając w firmie niepotrzebne odchylenia od obowiązujących praktyk.  Warto, aby eksperci dobrze się przygotowali, 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ń. 8. Stwórz program mentoringowy 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. 9. Odśwież oczekiwania co do pracy zwinnej przy okazji nowych inicjatyw 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:   Jak się rozwijać w roli Scrum Mastera. Znajdziesz go pod adresem porzadnyagile.pl/2. Wyszkoliliśmy się ze zwinności i co dalej – Dowiesz się jakie kroki może podjąć Scrum Master/grupa Scrum Masterów wewnątrz organizacji, aby pogłębiać swoje zrozumienie zwinności i stosowania innych praktyk. Dostępny pod adresem porzadnyagile.pl/37. Ocena stanu zwinności firmy – To temat oceny i analizy zwinności w organizacji. Znajdziesz go pod adresem porzadnyagile.pl/63. Jak dobrze organizować szkolenia? – Mamy dla Ciebie 10 konkretnych porad, dzięki którym planowane szkolenie przyniesie Ci zaplanowany efekt porzadnyagile.pl/65. Skuteczne retrospektywy zespołów – Jak prowadzić skuteczne retrospektywy, które są kluczowym elementem w procesie ciągłego doskonalenia się zespołów Agile. Znajdziesz go pod adresem porzadnyagile.pl/5. FAQ: Wzmacnianie kompetencji zwinnych w zespołach Dlaczego kompetencje zwinne czasami zanikają po początkowej transformacji? Umiejętności związane ze zwinnością mogą się osłabiać, jeśli taki model pracy nie otrzymuje dalszego wsparcia, zwłaszcza jeśli pierwotnie przeszkolone osoby (developerzy lub Scrum Masterzy) z różnych względów odchodzą z firmy. Co może się stać, gdy brakuje ciągłego doskonalenia umiejętności związanych ze zwinnością w zespole? Z powodu braku ciągłego doskonalenia w zespole nowi członkowie mogą nie rozumieć sensu praktyk zwinnych, co osłabi efektywność pracy. Praktyki mogą nadal być stosowane rutynowo, ale ich istota może zostać zgubiona. Jakie mogą być przyczyny zniechęcenia do dalszego rozwoju kompetencji zwinnych? Jedną z przyczyn może być rozczarowanie zwinnością w organizacji. Jej wprowadzenie w danej firmie mogło okazać się trudne i obiecane korzyści mogły nie nastąpić. W takim scenariuszu management organizacji, zamiast poprawić zarządzanie zmianą, może chcieć się z niej całkowicie wycofać. Jakie rozwiązanie może pomóc w utrzymaniu kompetencji zwinnych w organizacji? Warto regularne diagnozować potrzeby organizacji względem zespołów i sprawdzać dostępne kompetencje w zespołach. Kolejnym krokiem po takiej diagnozie może być dostosowywanie programów rozwojowych i aktywne usprawnienie i wsparcie zespołów we wprowadzaniu potrzebnych zmian w ich praktykach. Co może być skutecznym sposobem na wzmocnienie kompetencji zwinnych w zespole? Zaproś zewnętrznego eksperta, który przeprowadzi diagnozę i zaproponuje adekwatne rekomendacje. Osoba z doświadczeniem z wielu organizacji i niezależnym spojrzeniem na sposób funkcjonowania zespołów może przynieść do firmy szereg inspiracji, które podniosą jakość współpracy i efektywność zespołów. Dodatkowe materiały Zachęcamy Cię do pogłębienia tego tematu i zapoznania się z dodatkowymi materiałami: Jak się rozwijać w roli Scrum Mastera? Wyszkoliliśmy się ze zwinności i co dalej? Ocena stanu zwinności firmy Jak dobrze organizować szkolenia? 📄Transkrypcja podcastu „Wzmacnianie kompetencji zwinnych w zespołach„ Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. 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 z naszych doświadczeń. Pokażemy sytuacje, które pokazują problem zaniechania rozwijania kompetencji w zespołach. Pracowałem jakiś czas temu z zespołem, który szybko się rozrósł. Z kilku osób zrobiła się spora grupa – kilkanaście osób. Zespół zatrudnił sporo nowych ludzi z rynku. Byli tam głównie młodzi stażem. Często była to dla nich pierwsza praca. Wszystkiego o zwinności uczyli się od koleżanek i kolegów. Obserwowali ich codzienną pracę i konkretne praktyki zwinne. W pewnym momencie liderka zespołu zauważyła problem. Szczególnie osoby nowo dołączone nie rozumiały, po co stosujemy praktyki i zasady. Przykład. Nie do końca rozumieli ideę ciągłego usprawniania się. Nie wiedzieli też, dlaczego codziennie rano spotykamy się, ż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órą początkowo zbudowali 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 zewnętrzne. Dla równowagi dorzucimy kolejną poradę. Uruchom wewnętrzny program wymiany wiedzy. Przyjmuję założenie, że wewnątrz organizacji jest kompetencja zwinna. Nadal na minimalnym, akceptowalnym poziomie. Wiele organizacji nie wykorzystuje tego potencjału. Lepsze zespoły albo bardziej doświadczeni specjaliści od zwinności bywają zagubieni. Czasem są źle wykorzystani. To okazja, żeby oprzeć się na tych specjalistach. Można zorganizować program i dać im czas na realizację takich działań. Warto robić wzajemne wizyty międzyzespołowe. Można zapraszać zespoły do wymiany wiedzy. Organizować szkolenia, pogadanki, wewnętrzne gildie. Podnosić tematy trudne, w których zespoły mogą sobie pomagać. Ekstremalną, ale ciekawą wersją są wewnętrzne konferencje. Spotkania wymiany wiedzy. W dużej firmie znajdzie się kilka zespołów, które chętnie podsumują ostatni etap. Opowiedzą o eksperymencie procesowym. O wykorzystaniu narzędzia. O sposobie poradzenia sobie z trudną sytuacją. Takie historie bywają bardzo inspirujące. Wewnętrzne konferencje w odpowiedniej skali mogą być lepszym i rozsądniejszym wydatkiem niż wysłanie połowy firmy na dużą, generyczną konferencję. Tam są fajne wystąpienia, ale rzadko tak dobrze dopasowane do kontekstu, jak historie 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, dość ogólna myśl. Czasami brakuje pretekstu, żeby podnieść kompetencje. Albo żeby się zdopingować. Albo zdyscyplinować do stosowania pewnych praktyk. Tutaj rada dla managementu. Jeśli z wcześniejszych porad wynika diagnoza o brakach. Jeśli inspiracje wskazują, że trzeba się odświeżyć. To być może takie odświeżenie faktycznie musi nastąpić. Pretekstem może być start nowego projektu. Początek kwartału. Budowa nowego zespołu. Każda sytuacja, w której zaczynamy coś od nowa. To też pole do managerskiej inicjatywy. Do mocniejszego zasygnalizowania: wracamy na pewne tory. Oczekujemy konkretnego działania. Stawiamy zespołom jasne wymagania, jak ma przebiegać praca. Taki ruch wspiera wcześniejsze porady. Dzięki niemu łatwiej przełożyć teorię na praktykę. Nawet najlepsze szkolenia — dobrze dopasowane i przemyślane — mogą być trudne do wdrożenia. Jeśli nie ma jasnego oczekiwania, że praca faktycznie ma się zmieniać i usprawniać. Dlatego tak ważne jest managerskie wsparcie. Poprzez wyraźne postawienie oczekiwań. Że praca zespołu ma wyglądać trochę lepiej niż 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. ——— To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę! Ostatnia aktualizacja: 23 stycznia 2026The post Wzmacnianie kompetencji zwinnych w zespołach first appeared on Porządny Agile.

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. Porządny Agile · 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. Czym jest zaufanie? 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ć. Obejrzyj nagranie na YouTube Jak budować zaufanie w software house? 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. 1. Wiarygodność Spełniaj złożone obietnice 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%. Komunikuj w przewidywalny sposób 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. 2. Komunikacja Informuj na bieżąco o ryzykach i problemach 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. Dziel się informacją zwrotną 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.  3. Proces wytwarzania Jak najwcześniej oddawaj działający produkt 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.  Pokazuj efekty pracy częściej niż na Demo 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.  Dostarczaj kompletne przekrojowe funkcje 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. 4. Transparentność Zapewnij przejrzystość procesu wytwórczego 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. Zadbaj o jasny skład zespołu 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. FAQ: Budowanie zaufania jako software house Jak zdefiniować zaufanie klienta? Zaufanie jest przekonaniem, że można polegać na kimś, że będzie postępować zgodnie z oczekiwaniami, wartościami i zobowiązaniami. To też wiara w przewidywalność zachowań osoby, którą darzysz zaufaniem. Bazuje na wiarygodności lub dotychczasowych dobrych doświadczeniach współpracy. Dlaczego ważne jest, żeby spełniać złożone obietnice? Zadbaj o to, żeby dopilnować danego słowa. “Dowieziona” obietnica buduje przeczucie, że można na Tobie i zespole polegać. Częścią zaufania jest składanie obietnic, które później mają pokrycie i robienie wszystkiego tak, żeby to uzyskać. (BTW: jak już jesteśmy przy słowie „dowiezione” – sprawdź nasz nowy projekt “Elegancko Dowiezione”). Jak komunikować się z klientem zewnętrznym? Komunikacja powinna być przeprowadzona w pewnym standardzie jakościowym, jeśli chodzi o zawartość tej komunikacji. Zadbaj o punktualność, responsywność i spójność każdego komunikatu, żeby utrzymać wizerunek rzetelnego partnera. Czy i kiedy informować klienta o ryzykach i problemach? Nie ma nic gorszego niż postawienie klienta w sytuacji, gdy o problemach dotyczących jego projektu dowiaduje się jako ostatni. Nie zatajaj tego, że pojawiła się przeszkoda. Komunikacja o problematycznych sytuacjach to też istotny fundament budowania długofalowego zaufania z klientami. Jak dzielić się z klientem informacją zwrotną? Zaufanie z klientem budujemy też przez informacje zwrotne. O tym, jaką drogę wybrać decyduje to, jak blisko z nim jesteśmy. Czy relacja jest formalna, czy nieformalna? Droga formalna – napisz e-mail i podziel się informacją o tym, jakie zachowania są pozytywne i w jakich miejscach jest potencjał na usprawnienia. Masz relacje nieformalne? Przekaż bezpośredni feedback przy okazji każdej rozmowy. Kiedy oddawać działający produkt? Działający produkt oddawaj jak najwcześniej i jak najczęściej.  Im wcześniej pokażesz, że potrafisz jako dostawca wytworzyć coś namacalnego, tym większa jest szansa, że klient obdarzy Was zaufaniem. Zaczynasz udowadniać jako dostawca, że umiesz dostarczyć rozwiązanie, które ma konkretną działającą postać. 📄Transkrypcja podcastu „Budowanie zaufania jako software house” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. 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. ——— To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę! Ostatnia aktualizacja: 2 czerwca 2026The post Budowanie zaufania jako software house first appeared on Porządny Agile.

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. Porządny Agile · Q&A cz.1 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. Jak monitorować i prezentować zespołowi codziennie Action Pointy z Retro w pracy zdalnej? 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? Poszukaj wygodnej dla zespołu formuły wizualizacji ich w narzędziach online, Uwzględnij akcje usprawniające w Backlogu Produktu i Backlogu Sprintu. Przygotuj je w formie listy i spraw by była wyświetlana podczas Stand-upu, podobnie jak to się robi z listą tematów do wytworzenia, Regularnie wracaj do ustalonych Action pointów i przypominaj o nich Zespołowi, Zadbaj o szybką realizację ustaleń, w ten sposób problem monitorowania może stać się mniej istotny. Oceniaj z całym Zespołem efektywność wdrażanych akcji usprawniających i w razie potrzeby modyfikuj stosowane podejście. Co ważne, zachęcamy, aby nie porzucać spotkań i działań usprawniających, gdyż są one kluczowe dla rozwoju zespołu. Co daje Wam największy napęd („drive”) w szerzeniu zwinności? 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. Jaka jest rola Scrum Mastera w procesie Release w Scrumie? 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 może pomóc w zidentyfikowaniu i usunięciu nieefektywności z procesu. Może też usprawnić komunikację i współpracę między zespołami, a także wspierać w zdefiniowaniu i wdrażaniu najlepszych praktyk. Scrum Master może zapewnić, że proces wdrażania jest ciągle doskonalony. Pomoże zespołowi w zidentyfikowaniu obszarów, które można poprawić, a następnie wprowadzić zmiany i obserwować efekty.  Scrum Master może pomóc zespołowi zrozumieć, że release nie musi odbywać się po zakończeniu Sprintu. Wdrażanie powinno odbywać się wtedy, gdy Przyrost jest gotowy i ma sens, niezależnie od harmonogramu Sprintu. Rolą Scrum Mastera jest ciągłe poprawianie efektywności procesu wytwórczego i dążenie do skracania czasu potrzebnego na dostarczenie wartości do klienta.  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. Co w sytuacji, gdy Product Owner nie chce interesariuszy na Review, „bo nie ma co pokazać”? 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.  poczucie wstydu, że praca nie jest jeszcze gotowa, obawa przed nowymi pomysłami i koniecznością zmiany planu, podejście „na zasadzie: „im mniej ludzie się wtrącają, tym lepiej”, brak zrozumienia w organizacji pracy małymi krokami i dążenie do prezentacji efektu “wow”. 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? rozmowę na osobności z Product Ownerem w celu odkrycia przyczyn tego oporu, wyjaśnienie korzyści płynących z częstego feedbacku, promowanie w organizacji koncepcji pracy iteracyjnej,  rozmowa z managementem i pokazanie korzyści z pracy małymi krokami, wyjaśnienie tego, jak przebiega spotkanie Sprint Review z udziałem zarządzających. Czy obserwujecie, że wielu Scrum Masterów słabo wykonuje swoją pracę? 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ą: etykietka „Scrum Master”, która może sugerować odpowiedzialność za cały Scrum i zwinność w organizacji, a to jest nierealne, duży napływ nowych Scrum Masterów bez odpowiedniego doświadczenia i kwalifikacji. Na rynku pojawiła się ogromna liczba różnego rodzaju szkoleń czy bootcampów zapewniających, że to szybkie wejście do branży IT.  brak dostępnych Scrum Masterów na rynku, co miało miejsce kilka lat temu. Doprowadziło to właśnie do namnożenia się szkół, ale i niskiej selekcji podczas rekrutacji.  brak rozwijających wyzwań, które są spowodowane tym, że w wielu firmach Scrum Masterzy nie mają okazji do współpracy z doświadczonymi mentorami lub konsultantami. Z jakich powodów agile umiera? 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? Głębszego zrozumienia istoty zwinności. Zaangażowania wszystkich interesariuszy, od managerów po deweloperów. Elastyczności we wprowadzaniu zmian i gotowości do ciągłego doskonalenia. 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. Jak przekonać firmę do deskalowania zamiast skalowania, gdy nie ma do tego warunków? 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. Jak pracować z ludźmi posiadającymi waterfall’owy mindset?  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ł.  📄Transkrypcja podcastu „Q&A cz.1” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. 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. ——— To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę! Ostatnia aktualizacja: 2 czerwca 2026The post Q&A cz.1 first appeared on Porządny Agile.

Jesteś osobą odpowiedzialną na zmianę w organizacji i czujesz, że nic więcej nie da się zrobić? Czasami warto odpuścić. Poznaj siedem sygnałów, które naszym zdaniem na to wskazują. Wyjaśniamy też nasz punkt widzenia na temat odpuszczania. Porządny Agile · O tym, kiedy odpuszczać Jak poznać, że pora zmienić organizację, gdyż w obecnej nie da się już nic więcej dokonać bez narażania się na wypalenie? Na co zwracać uwagę i co jest być pomocne w podjęciu tej decyzji? Czym jest odpuszczenie? Można powiedzieć, że o odpuszczaniu mówimy, kiedy wspierasz organizację w procesie zmiany, jednak jest pasmo ciągłych przeszkód i niepowodzeń. Masz poczucie, że nie ma postępu, a wszystkie możliwe sposoby i pomysły na wdrożenie usprawnień zostały wyczerpane. Starasz się z całych sił, brakuje Ci wsparcia, zaczynasz tracić energię i motywację. Pewnego dnia po prostu stwierdzasz, że wachlarz możliwości się wyczerpuje i pojawia się uczucie, że tracisz czas. Czas, który można wykorzystać w innej firmie, której naprawdę zależy na zmianie, a Ty będziesz mieć szansę zrobić wreszcie coś namacalnego. Rezygnujesz, zwyczajnie odpuszczasz starania. Oczywiście, uczucia mogą tutaj pojawić się różne. Powyższy opis dotyczy tego, co sami odczuwaliśmy, kiedy byliśmy w podobnych sytuacjach. Chcieliśmy pokazać Ci, jak to może wyglądać, bazując na realnym przykładzie, prawdziwej sytuacji z życia.  7 oznak, że warto odpuścić Poniższa lista nie jest zamknięta. Jest to pewna synteza tego, co sami doświadczyliśmy i może to być dla Ciebie pewną wskazówką, że znajdujesz się w ślepej uliczce. 1. Działasz z wyraźnie mniejszą energią niż kiedyś Chodzi nam tu o sytuacje, gdy orientujesz się, że potrzebujesz dodatkowej energii i motywacji do działań, które kiedyś były robione z ochotą, napędzało do dalszej pracy. Czujesz, że coraz bardziej nie chcesz tego robić, szukasz wymówek lub zmuszasz się do wykonywania zadań z tego obszaru. To mocny sygnał, że pora odpuścić. I nie ma w tym nic złego. Sami mieliśmy też takie sytuacje, a najlepsze co możesz dla siebie zrobić to zatrzymać się i zastanowić się, co się dzieje i czy warto dalej walczyć. 2. Nie dostrzegasz istotnych sojuszników zmiany Działania z każdą zmianą, czy to w organizacji, w zespole, w produkcie czy w sposobie działania, są pracą zespołową. Zazwyczaj pracujesz z jakimś liderem, może programistą, testerami i analitykami. Osoby te pojawiają się w odpowiednich momentach i Cię wspierają. Jednocześnie wszyscy się wzajemnie nakręcacie i inspirujecie. Jeśli jednak nie ma tych osób, bo np. odsunęły się lub odeszły, to zaczyna się robić niebezpiecznie. Twoje wysiłki mogą przestać być tak skuteczne, jak do tej pory, gdyż trudno jest samodzielnie przeprowadzić jakąś zmianę, zwłaszcza w dużej organizacji. Ważny jest też tu też aspekt ludzki, wspieranie w trudniejszych momentach, odbijanie pomysłów i wspólne świętowanie sukcesów. Przykładowo, Kuba miał nawet taką sytuację, kiedy to zespół tak dobrze zorganizował pracę w agile, że ich lider awansował i przestał wspierać zespół, jak do tej pory. 3. Chęć zmiany w organizacji okazała się wyłącznie fasadowa To chyba jeden ze smutniejszych momentów, gdy osoba zaangażowana w zmianę, zaczyna dostrzegać, że tak naprawdę ta zmiana nie jest oczekiwana. Nie chodzi nam o to, że rzeczy dzieją się powoli, bo to oczywiste, że w większych organizacjach to tempo może być wolniejsze. Jednak, gdy dociera do Ciebie, że tak naprawdę poza bardzo powierzchownymi zmianami, więcej się raczej nie zmieni, jest to mocny sygnał do zastanowienia się, czy na pewno jesteś we właściwym miejscu. Przykładowo musisz z zespołem zaakceptować, że osoby z biznesu nie będą reprezentantami klienta i nie dostarczą bardzo cennego feedbacku. Długofalowo nie wróży to nic dobrego.Przykładem jest sytuacja, która spotkała Kubę i która była jednym z takich kamyczków dorzuconych do puli argumentów za tym, że ta zmiana, nad którą pracują, nie nastąpi, że chęć zmiany jest tylko powierzchowna. Działaliśmy w Scrumie, niby rzeczy jakoś tam się działy. Jednak gdy przyszło do rozmowy z zarządem o potrzebie powiększenia zespołów, gdyż nie byliśmy już w stanie zrealizować wszystkich celów strategicznych, pojawił się opór. Pojawił się on też, gdy chcieliśmy pewne rzeczy zmienić, aby usprawnić pracę i przyspieszyć procesy. Brak wsparcia managementu i prawdziwej chęci zmian jest mocnym sygnałem, że może warto odpuścić. 4. Zmiana nie przynosi widocznych rezultatów Wiele zmian potrzebuje czasu na to, żeby zobaczyć pierwsze rezultaty. Jeśli jednak pomimo podjętych prób, zrealizowania wszystkich założeń i działań zgodnie z planem, zmiana nie następuje, to też jest sygnał, aby się zatrzymać i zastanowić nad sytuacją. Być może coś robisz źle, być może plan był nieidealny, a może w tej konkretnej organizacji nie da się zrealizować tej konkretnej zmiany. Oczywiście nie mówimy o braku zmian po miesiącu od rozpoczęcia działań, raczej chodzi nam tu o roku lub dwóch latach wytężonej pracy z różnymi osobami, na różne sposoby. Wszystko powinno się udać, a jednak jest inaczej. To mocno obniża energię do działania i jest sygnałem, że może warto odpuścić. 5. Zauważasz w sobie narastający pesymizm odnośnie do zmiany Zamiast myślenia: zrobimy to, rozwiążemy problemy, zrealizujemy cele, pojawiają się pesymistyczne myśli, a na każdy pomysł reagujesz niechęcią, zwątpieniem, a nawet brakiem wiary, że to przyniesie oczekiwane rezultaty. Nie jest to wspierające ani dla Ciebie, ani dla reszty zespołu, bo takie nastawienie szybko się przenosi na cały zespół. Trudniej jest to zauważyć u siebie niż u innych, stąd potrzebna jest duża samoświadomość oraz otwartość na feedback, także ten, w którym usłyszymy, że za bardzo narzekamy i demotywujemy zespół. Jeśli ten pesymizm nie znika, tylko narasta, to odpuszczenie, może być najlepszym rozwiązaniem dla Ciebie i dla zespołu. 6. Nie masz już poczucia sensu działania Gdy nie wiesz, po co coś robisz, robi się już bardzo niebezpiecznie. Jeśli nie widzisz, że sensu w swoich działaniach i zaczynasz częściej żartować niż raczej wierzyć, że Twoje starania coś zmienią, to może warto przestać to robić. Trudno jest wówczas zarażać innych do działania, być efektywnym i z przyjemnością podchodzić do pracy.  Spontanicznie zaczyna się raczej jąkać albo ironizować z tego raczej niż w to wierzyć, niż jasno powiedzieć jakąś taką krótką wersję tego, po co to robisz, to jest to sygnał, że czas już przestać. Zwłaszcza jeśli widzisz, że poczucie sensu działania w tym projekcie już nie powróci. 7. Zauważasz, że praca odbija się na twoim życiu prywatnym Myślami jesteś w pracy, zamiast być w pełni obecnym podczas spędzania czasu z rodziną lub przyjaciółmi. Nagromadzają się w Tobie jakieś frustracje związane z problemami w pracy i zaczynają one przenikać do życia prywatnego. Nam podobne uczucia też nie są też obce. Kuba sam kiedyś postanowił odpuścić, gdy zorientował się, że jest przytłoczony pracą, za dużo spędzał w niej czasu i że zjada ona dużo jego energii. Do domu wracał bardzo zmęczony, w dodatku późno i bez chęci na cokolwiek. W końcu przyszła taka refleksja, że balans między życiem prywatnym a zawodowym gdzieś zanikł. Lepiej, aby ta refleksja przyszła wcześniej niż później, aby móc w odpowiednim czasie odpuścić. Ta granica będzie u każdego inna i dużo też zależy od kontekstu, więc nie możemy Ci powiedzieć, ile można pracować, a ile nie. Warto jednak być mocno uważnym, aby w odpowiednim momencie odpuścić. Jeśli chcesz pogłębić temat trudnych sytuacji w pracy i stresu z tym związanego, przesłuchaj odcinek 69 podcastu “Porządny Agile”, w którym opowiadamy, jak radzimy sobie ze stresem i różnymi obciążeniami.  Nie bój się odpuszczać, gdy wszystko idzie nie w tym kierunku, w którym powinno, a Twoja motywacja, energia i przyjemność z działania zaczynają zanikać. FAQ: O tym, kiedy odpuszczać Czy zauważasz brak wsparcia w procesie zmiany organizacji? Kiedy nie ma wystarczającego wsparcia ze strony zespołu lub kluczowych interesariuszy, zastanów się, czy jest sens kontynuować zmiany. Czy masz jeszcze swoich sojuszników zmiany? Jeśli w trakcie implementacji zmian w organizacji zniknęli sojusznicy, może być niebezpiecznie. To sygnał, że przestajesz działać w grupie, która wzajemnie się wspierała. Dalsze wysiłki mogą okazać się nieskuteczne. Masz może wrażenie, że zmiana w Twojej organizacji jest fasadowa? W organizacji są zespoły zwinne, ale brak reprezentacji biznesowej w zespołach deweloperskich utrudnia prawdziwą transformację. Dodatkowo zarządzający stawiają opór i nie wspierają głębszych zmian. To może skłonić do zastanowienia się nad sensem dalszego zaangażowania w proces zmiany, zwłaszcza gdy brak jest perspektywy na poprawę w dającej się przewidzieć przyszłości. Dodatkowe materiały Jak radzimy sobie ze stresem 📄Transkrypcja podcastu „O tym, kiedy odpuszczać” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Ten odcinek to pierwszy, który nagrywamy na początku 2024 roku. Pod koniec poprzedniego roku poprosiliśmy naszych słuchaczy na kanale, na naszych mediach społecznościowych o to, żeby podzielić się z nami informacją zwrotną. Dziękujemy bardzo wszystkim tym osobom, które tę informację nam przekazały. Zapoznaliśmy się z wynikami. Super, dzięki też za pozdrowienia. Dla nas dobre słowo, podpowiedzi co możemy robić lepiej. Wśród rzeczy, o które pytaliśmy, były też wątki związane z tematami, które moglibyśmy jeszcze poruszyć, których jeszcze nie poruszaliśmy. Przejrzeliśmy je i postanowiliśmy jeden z tych tematów wybrać. Jeden z naszych słuchaczy lub słuchaczek, bo tu akurat ankieta była anonimowa, więc nie za bardzo możemy dać konkretną atrybucję, zgłosił temat o tym kiedy odpuszczać. Cały wpis, cała treść tej podpowiedzi była trochę szersza. Zainspirowało nas to do nagrania. No i cały temat brzmi o tym kiedy odpuszczać, kiedy uznać, że w danej organizacji, sytuacji więcej nie da się zrobić bez narażania się na wypalenie.  Jacek: I podzielimy się naszymi przemyśleniami w tym temacie. Jednak zanim to zrobimy, doprecyzujemy, że chcemy poruszyć temat wypalenia, zmęczenia, tematem zmieniania organizacji i na tym aspekcie będziemy się skupiać. Nie mamy na myśli pracy w nadgodzinach, czy pracy pod zbyt silną presją. Także praca na zbyt dużym tempie to też nie jest temat, którego dzisiaj będziemy dotykać. Chodzi nam głównie o ten aspekt zmieniania organizacji. Kuba: Zawartość tego odcinka czy spis treści tego nagrania jest dosyć prosta. Zaczniemy od tego, że podzielimy się naszym zrozumieniem co to znaczy odpuścić i naszymi osobistymi historiami, bo mamy parę takich.  Oraz siedem oznak tego, że naszym zdaniem warto odpuścić. Jacek: Zanim pójdziemy dalej, przypominamy z Kubą, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej niż robimy to w podcaście, to nasze płatne produkty znajdziesz na stronie porzadnyagile.pl/sklep. Kuba: Dobrze, to pierwsza część. Co to dla nas oznacza odpuścić? Jacek: Z mojej perspektywy odpuszczenie to jest moment, kiedy wspieramy organizację w procesie zmiany i oczywiście taka zmiana to jest pasmo pewnych przeszkód, pewnych upadków i wzlotów. Jednak zaczynam odczuwać, że właściwie coraz więcej jest niepowodzeń i zaczyna się rodzić we mnie takie poczucie, że właściwie już nie dostrzegam postępu i co gorsze wyczerpałem wszystkie możliwe sposoby i pomysły, żeby spróbować zrobić to inaczej. Czyli w pewnym sensie czuję taką bezsilność, nie mam już pomysłu na to, jak jeszcze inaczej na świeżo mógłbym podejść do tego tematu. I pewnego dnia po prostu stwierdzam czy odkrywam, że skończył mi się wachlarz możliwości. Nie widzę też wsparcia po stronie organizacji, nie mam za bardzo z kim taką zmianę dalej prowadzić i zaczyna we mnie rodzić takie poczucie, że tracę czas. Tracę czas zarówno organizacji, która być może nie jest tak bardzo zainteresowana zmianą, jak pierwotnie myślałem, a z drugiej strony tracę swój czas, bo tak naprawdę mógłbym być w innej firmie, której faktycznie zależy na zmianie, w której jest szansa, żeby ta zmiana była faktycznie namacalna. Kuba: Temat odpuszczenia zarezonował również ze mną, bo też mi się zdarzyło odpuścić. Tak najwyraźniej mogę zaznaczyć, że co najmniej dwa razy, ale myślę, że to zdarzało się w mniejszej skali również częściej. I to, co powiem, będzie od siebie, nie sile się na kontrę do tego, co Jacek przed chwilą powiedział. W moim przypadku odpuszczanie to zatrzymanie starań. Normalnie te starania daję na maksa, mocno się angażuję, dużo staram się, pomyślę, jak zrobić to inaczej, jak zrobić to lepiej. Mogą być te wzloty i upadki, jak tak Jacek opowiedziałeś, natomiast nawet gdy się nie udaje, to jest ze spokojem zazwyczaj przeze mnie przyjmowane, że dobra, nie tak, to inaczej, nie drzwiami, to oknem. No ale jednak przychodzi taki moment, że mimo że się staram bardzo mocno, wkładam swoje dotychczasowe doświadczenia, które oczywiście z czasem rośnie, ale nie mam rezultatów, nie widać, żeby była jakakolwiek różnica lub te rezultaty czy te różnice jest mikroskopijne. No i nie mam nikogo z kim mógłbym się jeszcze starać. Czy tu był ktoś może, ale tej osoby już nie ma, albo to grono jest super nieliczne i niestety nie ma wpływu na to, jak sprawy się mają w danej organizacji czy w danej części organizacji? Przestaję mieć ochotę dalej ciągnąć sprawy, przestaję mieć ochotę wkładać z siebie jeszcze dalej wysiłek, zużywać energię, zużywać ją i nie mieć żadnych miejsc, w których tę energię mogę podładować, czy jakby sobie samemu obiecać, że chyba idą sprawy w dobrą stronę. Więc wolę nie robić już nic więcej, bo wszystko to co robię do tej pory jest bezskuteczne i po prostu odpuszczam, rezygnuję. Realnie w tych przypadkach, w których byłem po prostu wybieram pewne inne alternatywy i kończę wsparcie czy współpracę w tym konkretnym obszarze. Jacek: I te nasze dwie historie z Kubą przedstawiamy po to, żeby dać mniej więcej obraz, o jakim stanie emocjonalnym mówimy, jak to może wyglądać. Twoje odczucia mogą być oczywiście zupełnie inne, to może zupełnie inaczej w Tobie pracować, ale uznaliśmy, że taka opowieść z naszej strony może być interesującym wprowadzeniem, gdybyś wahał się bądź wahała czy słuchać dalej ten odcinek. Jacek: Przedstawimy teraz siedem oznak, które na bazie naszego doświadczenia z Kubą zidentyfikowaliśmy. Na zasadzie, jeżeli większość z tych elementów potwierdzisz pozytywnie, że jest faktycznie tak, jak mówimy, no to może to być jakaś wskazówka, że znajdujesz się w ślepej uliczce. Natomiast definitywnie nie jest to jakaś zamknięta check-lista. Nie jest to jest to te siedem punktów, które należy sobie sprawdzić, jedynych. Jest to po prostu pewna synteza tego, czego doświadczyliśmy z Kubą i na tym się mocno oparliśmy. I pierwszy punkt na naszej liście brzmi następująco. Działasz z wyraźnie mniejszą energią niż kiedyś. Jak słuchałem Kuba twojej opowieści, to mówiłeś o tym jak pracujesz, że tam jest sporo energii, jak nie oknem, to drzwiami. Tutaj zdecydowanie mam coś podobnego. Praca potrafi mnie dosyć mocno wciągnąć, zaangażować. I tak domyślnie mi się chce. Zdarzało mi się czasem, kiedy jeszcze pracowałem na etacie, dojeżdżając do pracy spotykać ludzi w środkach komunikacji miejskiej i zawsze mnie dziwiły takie komentarze, na zasadzie był poniedziałek i ktoś zaczynał opowieść: „Jezu, ale mi się nie chce znowu do roboty”. Jakieś takie smuty. I już wtedy to kompletnie do mnie nie trafiało, no bo jednak domyślnie, domyślnie zawsze mi się chciało. I wszelkiego rodzaju oznaki, że wstaję rano i nie mam tych chęci do działania, które miałem wcześniej, są na mnie bardzo wyraźnymi sygnałami, że być może coś się dzieje w tym temacie takiego, nazwijmy to, czy wypalenia, czy sytuacji, w której mogę zacząć się zastanawiać, co się zmieniło i co się dzieje, że moje nastawienie uległo zmianie.  Kuba: Ta kwestia energii, to tutaj chyba musimy mocno podkreślić, że chodzi o sytuacje, w które się nam wcześniej trafiały, uwielbialiśmy je robić, a jednak gdzieś tam w którymś momencie się łapiemy, że kurczę, jeszcze jedno szkolenie, bo jeszcze jedna warsztaty, kurczę, znowu z nimi. Nie będę się wyrażał na antenie. Więc jeśli czuję, że coś kiedyś robiłem z wielką ochotą, chciało mi się, nabierałem energii i to nie było, że może gorzej się wyspałem jednego dnia, więc mam gorszą energię, tylko bardziej myślę, że odpuszczanie się musi pojawić właśnie wtedy, gdy mam takie poczucie, że już przestaję chcieć robić coś, co kiedyś naprawdę bardzo chciałem robić, lubiłem to robić, nikt nie musiał mnie dodatkowo motywować, bo lubię pracować z ludźmi, lubię zmieniać świat, robić lepiej, więc tutaj ta energia się sama budowała i to się wszystko samo nakręcało. Dzisiaj również łapię się na tym, że są takie czynności, są takie działania, które nie wzbudzają we mnie tej energii i zaczyna być niebezpiecznie, jeśli na przykład to jest właśnie na przykład szkolenie, które wymieniłem, bo wiem, że tak jest, że na przykład w niektórych organizacjach mogło mi się trafić mniejsza chęć na pewne szkolenia, no i to były takie wczesne sygnały ostrzegające o tym, że może czas odpuścić, bo coś, co mi sprawia normalnie przyjemność, tutaj zaczyna być z jakiegoś powodu niebezpieczne. Kuba: Kolejna oznaka, że warto odpuścić, to nie dostrzegasz istotnych sojuszników zmiany. No to jest coś takiego, co ja sam w swojej tej części mocniej zaznaczyłem. Działamy nad zmianą, czy pracujemy nad zmianą organizacji, zmianą zespołu, zmianą produktu, zmianą sposobu działania jakiejś części organizacji z ludźmi. To zazwyczaj nie jest wysiłek indywidualny. Tam będą jacyś liderzy organizacji, może jakieś osoby z produktu, może jacyś istotni tacy influencerzy wewnątrzorganizacyjni, czyli może jacyś programiści, jacyś testerzy, jacyś analitycy, którzy gdzieś tam w odpowiednich momentach nas wspierają, pomagają nam gdzieś, wszyscy się wzajemnie mocno nakręcamy, inspirujemy i to jest super. Ale jeśli ten fragment, który prawdopodobnie nawet na trochę lepszej emocji powiedziałem teraz, jednak jest nieprawdą, czyli nie ma tych osób, albo były, ale zniknęły, albo były, ale już im się odechciało, patrz, punkt pierwszy z naszej listy, no to może być już niebezpiecznie. Trafiałem na różne przypadki, różne kombinacje, być może, i to jest trochę powtarzalny schemat. Na przykład, management, który mocno wspiera zmiany, być może odchodzi, być może zmienia swój zakres obowiązków i przestaje wspierać zmiany, albo najnieszczęśliwsza historia, tak fajnie zrobiliśmy tego agile’a, że nasz tam lider zmiany awansował i już go z nami nie ma i już nie wspiera tak bardzo zmiany jak do tej pory to robił. To wszystko może być sygnał, że przestajemy działać w jakiejś takiej grupie, która do tej pory nas bardzo fajnie nakręcała, wzajemnie inspirowała, być może się tak wspierała, no i to wszystko powoduje, że być może nasze dotychczasowe wysiłki przestaną być tak skuteczne, bo przestały być już odpowiednie osoby w grze. Jacek: Rezonuje ze mną to, co mówisz na takiej zasadzie tej takiej gry zespołowej. Możesz być najlepszy w swoim fachu, znać wszystkie narzędzia dostępne, modele. Natomiast nie ma moim zdaniem możliwości, żeby zmianę, którą mamy na myśli, czyli zwykle jakąś taką zmianę w okolicach inspirowania się podejściem zwinnym, żeby to przeprowadzić samodzielnie. Ta ekipa, o której mówiłeś, wspierająca, ona musi być z bardzo prozaicznych powodów. Zwykle organizacje są duże i w wielu różnych miejscach spodziewałbym się symultanicznych, skoordynowanych, zaplanowanych działań, których po prostu nie zrobimy w pojedynkę, ale też myślę o takim aspekcie bardzo ludzkim, czyli w szczególności w tych gorszych momentach, o których już trochę z Kubą powiedzieliśmy, bycie samemu po prostu jest trudne. Nie ma od kogo się odbić, nie ma z kim pogadać, nie ma osoby, która może akurat jest w stanie opowiedzieć o jakiś sukcesach w innym obszarze organizacji, czy w innym zespole. No i tak naprawdę zostajemy trochę bezsilni, a co gorsza, po prostu sami z tym problemem. Jacek: Kolejny, trzeci punkt na naszej liście. Chęć zmiany w organizacji okazała się wyłącznie fasadowa. Chyba jest to jeden z takich smutniejszych momentów osoby, która jest zaangażowana w zmianę, przynajmniej ja zwykle reagowałem pewnego rodzaju smutkiem, kiedy pewne kropki mi się łączyły w taki układ, że zaczynałem dostrzegać, że chyba tak naprawdę zmiana, taka prawdziwa zmiana nie jest do końca oczekiwana. Na takiej zasadzie, że problemem nie jest to, że to wszystko dzieje się powoli, bo oczywiście każda organizacja ma swoje tempo. Inaczej będzie się zmieniać mała organizacja, inaczej będzie się zmieniała duża korporacja i to jest oczywiste. Natomiast moment, kiedy dociera do mnie, że tak naprawdę poza takimi bardzo powierzchownymi zmianami niewiele się zmieni, jest takim czynnikiem, który uruchamia we mnie proces myślenia, czy aby na pewno jestem we właściwym miejscu. Czyli przykładowo pojawiają się jakieś zespoły. Zaczynamy nazywać te zespoły, powiedzmy zespołami zwinnymi. Pojawiają się jakieś osoby w różnych rolach, które również brzmią zwinnie. Jak tak zmrużymy oczy, to wydaje nam się, że wszystko jest dobrze, ale zaczyna do nas docierać, że pewne rzeczy są nie do ruszenia. Czyli na przykład musimy zaakceptować to, że ze strony biznesowej nie zostaną wystawione osoby, które będą takimi faktycznymi reprezentantami klienta czy biznesu do pracy z zespołami deweloperskimi. Co z mojego punktu widzenia jest bardzo dużym spowalniaczem zmiany, bardzo dużym uproszczeniem. No i jakby długofalowo nie wróży to niczego dobrego.  Kuba: I tutaj jasno sobie powiedzmy, że nie chodzi o sytuacje, gdy są zmiany, ale one są błędne albo jest jakiś taki trochę klimat koziołka-matołka, trzy kroki w przód, dwa w tył. To jest naturalna sprawa, że pewne rzeczy mogą być mylne, że też ludzie, którzy na początku deklarują zmianę, być może nie zdają sobie sprawy z głębokości tych zmian, jakie są potrzebne. Ja do puli dorzucę przypadek ilości inicjatyw, które dzieją się w firmie jednocześnie. To taki przypadek, który mnie spotkał, który faktycznie był jednym z takich kamyczków dorzucających do puli argumentów, że jednak kompletnie ta zmiana nie nastąpi i że jest fasadowa, czyli jest tylko i wyłącznie powierzchowna. Niby jest inaczej, niby są te wszystkie Scrumy i jest fajnie, ale gdy przyszło, co do czego i chciałem porozmawiać z zarządzającymi organizacji o tym, że trzeba się skupić, że nie ma tyle zespołów, nie ma możliwości, żeby te istniejące zespoły robiły tyle rzeczy, które zostaje im gdzieś tam zasugerowane, narzucone, wskazane jako cele, wskazane jako jakieś strategiczne inicjatywy, że to się nie da aż tak bardzo, że trzeba trochę się przylimitować. I wspiąłem się na swoje wyżyny i tutaj przekonywania i pokazywania przykładów, i jakby pokazania dotychczasowych rezultatów. Był po prostu opór, mur, nie ma szans. To jest nie do ruszenia, tego nie wolno zmienić. No to się nie zmieni i to jest też dla mnie sygnał. Jeśli organizacja nie chce się zmienić, jeśli te zmiany w organizacji, te głębsze, potrzebne, nie są wspierane przez management i nic nie wskazuje na to, żeby się miało cokolwiek zmienić w zauważalnym, skończonym, przewidywalnym czasie, no to jest jeden z punktów do rozpatrzenia, że być może te zmiany nie nastąpią. Oczywiście zmiany mogą nastąpić też na takim poziomie lokalnym, czyli na przykład pojedynczy zespół, pojedynczy produkt w ramach organizacji, która zmieniać się nie chce, jednak będzie pracował trochę inaczej, ale zwłaszcza jeśli mamy apetyt na głębszą zmianę firmy, większe ambicje na coś więcej, no to takie zderzenie się z tą ścianą, braku chęci zmiany, może być bardzo ważnym sygnałem. Kuba: Czwarta oznaka sugerująca, że może warto odpuścić, to fakt, że zmiana nie przynosi widocznych rezultatów. Wiele zmian oczywiście potrzebuje chwili czasu na to, żeby jakieś rezultaty były widoczne. Często te rezultaty uwidocznią się dopiero po jakimś czasie, gdy opadnie taki kurz zmiany, gdy ludzie się do pewnych rzeczy przyzwyczają, gdy nowe sposoby działania wejdą w pewne nawyki, ale jeśli mimo podjętych sensownych prób, mimo że zrobiliśmy wszystko, jak trzeba. Że dałem z siebie wszystko, wszyscy moi sojusznicy też zrobili to tak, jak trzeba i zmiana nie następuje. Zdefiniowane przez nas na początku zmiany jakieś konkretne wskazówki czy jakieś takie objawy, zarówno te miękkie, takie międzyludzkie, jak i te bardzo konkretne, biznesowe, widoczne w jakichś miernikach tak zwanych KPI-ach czy cokolwiek co tam sobie wybierzemy i jeśli w żadnym z tych obszarów nie widać różnicy, to robimy coś źle. Być może ja robię coś źle, ale jeśli nie ma żadnych rezultatów tego, co robimy, no to też może być sygnał, żeby odpuścić. Może nie robię tego wystarczająco dobrze, może to nie jest właściwy moment, albo może ta zmiana, którą chcę forsować, niestety nie jest właściwą zmianą i organizacja tego albo nie potrzebuje, albo wręcz, jeśli jednak mi się uda, to w firmie to zaszkodzi i, zwłaszcza jeśli mam alternatywę, to może być podpowiedź, że tutaj po prostu rezultatów nie mam. I ten taki fajny efekt, czyli zmiana, która nakręca się, ponieważ ma fajne rezultaty i się bardzo łatwo rozprasza czy jakby rozszerza na kolejne części organizacji i sama tak też się udowadnia, nie ma prawa zaistnieć, no bo nie mamy w ogóle żadnych rezultatów i za chwilę w ogóle stracimy cały zapał czy jakiekolwiek resztki zapału.  Jacek: Te rezultaty, o których mówisz, one generalnie wchodząc na taką ścieżkę, gdzie chcemy zmieniać organizację, no to myślę, że trzeba się wyposażyć w grubą skórę i taką pewną pokorę, że to się nie wydarzy w jakimś takim, nazwijmy to, szybkim okresie. Więc jak mówimy, że zmiana nie przynosi rezultatów, to nie chodzi nam o to, że to jest coś w stylu, nie wiem: „No już miesiąc nad tym pracuję i czemu jeszcze się nie zmieniło tak jak bym chciał”. Raczej tutaj z mojej perspektywy mówimy o horyzoncie, nie wiem, rok, dwa, pracujemy na różne sposoby z różnymi osobami w różnych obszarach no i po prostu te rezultaty, których się spodziewaliśmy, też pewnie rezultaty, które zdefiniowaliśmy sobie gdzieś na początku, one się po prostu nie pojawiają. Trochę jest taka natura zmiany, ale jeżeli ich w ogóle nie ma, no to może to być bardzo demotywujące. Ja pamiętam, jak pracowałem w jednej z organizacji i miałem akurat ogród na takim świeżym etapie założenia i też taką miałem świeżą zajawkę, no to bardzo lubiłem wrócić i skosić trawę. Dlatego że jak wykonałem swoją pracę, 45 minut jeżdżenia kosiarką, no to patrzyłem na trawnik i mówiłem, to jest efekt mojej pracy. Wykonałem pracę, jest rezultat i zestawiałem to sobie z ilomaś tam miesiącami pracy w pewnej organizacji, no i zdałem sobie sprawę, że to nawet nie jest tak, że ten rezultat jest oddalony w czasie, tylko go po prostu nie ma. No i to potrafi dosyć mocno podciąć skrzydła.  Jacek: Kolejna oznaka wskazująca, że być może warto rozważać odpuszczenie, to fakt, że zauważasz w sobie narastający pesymizm odnośnie zmiany. Czyli trochę przeciwieństwo tej energii, trochę przeciwieństwo wiatru w żaglach, trochę przeciwieństwo takiego myślenia, da się, można, zrobimy, pokonamy przeciwności. Zaczynasz zauważać, że coraz bardziej jesteś pesymistą, czyli właściwie na każdy pomysł reagujesz, nie uda się, nie ma sensu, próbowaliśmy, wielokrotnie robiliśmy coś tam i to nie przyniosło rezultatów. Właściwie wszędzie, na każdą okazję zakładasz czapkę krytyka, czyli nie po to, żeby spojrzeć na pewien na przykład pomysł z różnych perspektyw, tylko to jest taka krytyka na zasadzie bezlitosnego chłostania pomysłu. No tak po prostu, bo tak czuję, bo tak po prostu uważam, że fajnie będzie, jeśli w ten sposób się wypowiem. I to oczywiście nie jest zwykle, a w szczególności na dłuższą metę wspierające. Więc tak parafrazując, jeżeli w zmianie wszędzie zaczynasz dostrzegać problem i – co gorsza – zaczynasz tym pesymizmem zarażać te osoby, które jeszcze nie są być może na tej ścieżce odpuszczenia, no to na pewno dostrzeżenie tego, tych symptomów może być istotnym krokiem na drodze do zastanowienia się, co tak naprawdę się ze mną dzieje w kontekście tej zmiany, w której uczestniczę. Kuba: I nie mamy na myśli tutaj jakiegoś na przykład sarkazmu albo okazjonalnego żartu, czy takiego rozładowania sobie może na jakiegoś napięcia poprzez rzucenie czegoś frywolnego. Tylko jednak jakieś takie zjawisko, które chyba trochę łatwiej zauważyć u innych niż u samego siebie, że kurczę, ta osoba kiedyś zarażała optymizmem, a teraz zaraża pesymizmem. I tak naprawdę już coraz mniej się ma ochotę do tej osoby pójść, to nie jest osoba, która gdzieś tam podnosi na duchu, gdzieś tam się wzajemnie nakręca, czy też nakręca pozostałych, tylko po prostu już zaczynamy zbyt często bardzo źle myśleć o tym, jakie są szanse powodzenia w temacie, nad którym pracujemy. Więc tutaj tak jak mówię, to w sobie można trochę trudniej zauważyć, wymaga oczywiście bardzo dużej samoświadomości, jak się ją ma to super, natomiast bądźmy też uważni, jeśli to ludzie z naszego otoczenia nam mówią, że już może za dużo stękamy albo za dużo tego narzekania. Czy na przykład też jakieś krytyki, bo to też może być taki objaw, że tak nam się bardzo łatwo gdzieś się ulewa na innych, z którymi współpracujemy, że tam coś jest nie tak, że coś jest nie w porządku. No i jeśli ten pesymizm odnośnie zmiany narasta, jeśli tak byśmy stanęli przed lustrem i sobie powiedzieli, czy nam się uda i parę dni z rzędu, parę tygodni z rzędu nam się to będzie powtarzało, że nie masz szans, więcej umiemy zażartować na temat tego, jak to wszystko jest beznadziejne, no to możemy właśnie odhaczyć tą naszą nieoficjalną, czy nieformalną listę, że tutaj być może to odpuszczenie to może być najlepsze, co może nas spotkać, jeśli faktycznie byliśmy osobami, które wcześniej miały sporo optymizmu. Kuba: Przedostatni punkt, oznak tego, że może warto odpuścić, to punkt – Nie masz już poczucia sensu działania. No i tu już jest gruba rura, jeśli nie wiem po co to robię, co robię, jeśli przestałem mieć motywację, jeśli nie widzę tego, że to wszystko, co robimy ma sens, że to co ja robię już nie ma sensu dla mnie samego, nie ma to sensu dla mojej grupy, z którą działam, nie ma to sensu dla mojej firmy, nie umiem tego nazwać. Spontanicznie zaczyna się raczej jąkać albo żartować z tego raczej niż w to wierzyć, niż jasno powiedzieć jakąś taką krótką wersję tego, po co to robię, no to to może być sygnał, że czas już przestać. Jacek: Tutaj przeszliśmy bardzo długą drogę od pierwszej oznaki, gdzie mówiliśmy tylko, że jest jakaś mniejsza energia, że jakieś tam lekkie kłucie zaczynamy czuć, no to tutaj to jest coś zupełnie innego, na zasadzie kompletnie stracone poczucie, że warto. Dla mnie, dla osoby, która potrzebuje rezultatów jako pewnego rodzaju paliwa, to to stracenie sensu działania kompletnie odcina mi zapłon, kompletnie podcina mi skrzydła. No bo jeżeli ja nie wierzę osobiście, personalnie w to, co robię, no to jak ja mogę w ogóle próbować zarażać innych, włączać innych w zmianę, czy być osobą, która jest wiarygodna w tym, że dzisiaj jesteśmy w punkcie A, ale tak naprawdę z pełną energią idziemy do punktu B. Tak więc strata poczucia sensu działania jest nieprzypadkowo na końcu tej listy, no bo to już są takie właściwie sygnały, które bardzo późno odczytaliśmy, ale to są już takie sygnały naprawdę, nie wiem, czy jest droga powrotna, kiedy straciliśmy poczucie sensu działania. Jacek: Ostatnia oznaka, która wskazuje, że być może warto odpuścić, to fakt, że zauważasz, że praca odbija się na twoim życiu prywatnym. No i tutaj konsekwencje oczywiście mogą być różnorodne. To może być, bycie cały czas myślami gdzieś tam w pracy, zamiast spędzać czas w domu z rodziną, czy ze znajomymi. Ale to może przybrać też jakieś gorsze warianty na zasadzie, moje poddenerwowanie też może się udzielać innym. Mogę być burkliwy, markotliwy. Nie wiem, jakoś tam zdawkowo kogoś potraktować. Po prostu nagromadzenie jakichś nerwów, jakichś frustracji z pracy może w niebezpieczny sposób przenikać na to, co mamy poza pracą. Jeżeli ta nasza taka oaza spokoju, pewna kontra do tego, co robimy na co dzień w pracy, jeżeli zaczynamy ją zatruwać, no to to też jest, myślę, sygnał podobnie silny jak ten poprzedni, że już jest generalnie bardzo, bardzo źle. Kuba: Ta oznaka to coś, co mnie osobiście spotkało za pierwszym razem, gdy tak świadomie dzisiaj z perspektywy powiem, że odpuściłem, gdzie po prostu to przytłoczenie pracą, sporo takich innych negatywnych oznak, które też miały miejsce z tej listy, którą wcześniej wymieniliśmy, to się wszystko rzutowało na to, że trochę za długo spędzałem czasu w pracy, trochę za bardzo mnie to wszystko zjadało energetycznie. No i tak naprawdę wracałem do domu z pracy, to jeszcze czasy przedpandemiczne, czasy jeszcze pracy etatowej, no już absolutnie wymęczony. Zero energii, bardzo późno, w zasadzie przestałem mieć życie prywatne, bo mimo wszystko gdzieś tamta moja energia, chęć starania się, jakieś takie poczucie obowiązkowości, to wszystko generowało we mnie jeszcze chęć próbowania dalej. I to właśnie taka refleksja, jak teraz w tej chwili wygląda suma mojego życia zawodowego i prywatnego, jak bardzo ten balans się zupełnie gdzieś tam zgubił. No to był taki sygnał, że może już przesadziłem, że w zasadzie nie za dobrze to wróży na przyszłość. Więc tutaj każdy ma oczywiście swój poziom, standard, gdzieś tam swoje oczekiwania, więc tutaj musimy być oczywiście, gdy o tym mówimy, bardzo delikatni i bardzo czujni na to, że te konteksty będą różne, no ale warto sobie zadać pytanie, czy czasami na przykład zmiana nad którą pracujemy czasami nie odbija się za mocno na naszym życiu i czy czasami akurat dopiero po tym nie poznamy, że to odpuszczenie powinno mieć miejsca. Nie oceniam, jeśli tak jest, ja sam po sobie mogę powiedzieć, trochę żałuję, że tak późno to zauważyłem, bo szczerze mówiąc były też objawy wcześniejsze i może można było to przerwać, zanim poszło w dość złą stronę. Obyło się bez tragedii, więc też nie dramatyzuję, tutaj nie musicie mnie jakoś pocieszać albo zadawać się ciężkich pytań na privie, ale nie musiało tak być, mogło się skończyć o wiele gorzej. Kuba: I jeśli temat tego typu objaw to jest coś, co chcesz pogłębić, to tutaj już sporo czasu temu, to 3 lata będzie, nagraliśmy odcinek „Jak radzimy sobie ze stresem”. On był z podobnego rejestru, takiego poważnego podejścia do tematu, tam też troszkę podpowiadamy na temat tego jak sobie radzimy ze stresem czy z tymi obciążeniami. Bo tutaj, no temat, można go spokojnie opowiedzieć, ale temat nie jest do kompletnego zignorowania, więc tutaj polecam odcinek 69 „Jak radzimy sobie ze stresem”, do znalezienia pod adresem porzadnyagile.pl/69 Kuba: Podsumowując, kiedy naszym zdaniem warto odpuścić? Działasz z wyraźnie mniejszą energią niż kiedyś. Nie dostrzegasz istotnych sojuszników zmiany. Chęć zmiany w organizacji okazała się wyłącznie fasadowa.  Jacek: Zmiana nie przynosi widocznych rezultatów. Zauważasz w sobie narastający pesymizm odnośnie zmiany. Nie masz już poczucia sensu działania. Czujesz, że odbija się to na twoim życiu prywatnym. Kuba: Na koniec zaproszę na prawdziwe Przypadki Scrumowe. 19 i 20 marca w Warszawie zbieram kolejną grupę na kolejną edycję autorskich warsztatów. Prawdziwe Przypadki Scrumowe to formuła oparta o case studies. Przynoszę na ten warsztat historię z prawdziwych zespołów, zespołów, które spotkały się z jakimiś problemami, najczęściej dosyć złożonymi, i razem z grupą obecnych tam osób – najczęściej są to Scrum Masterzy, praktykujący Agile Coach’e, Czasami zdarzy się też product ownerka albo jakiś kierownik projektu – i wspólnie rozmawiamy na temat tego, jak można było postąpić w takiej sytuacji. Rozmawiamy też z chętnymi osobami, które w podobnej sytuacji były w przeszłości, jak one sobie poradziły i wspólnie całą grupą budujemy możliwe rozwiązania na trudne sytuacje. Też dzielimy się praktykami i konkretnymi historiami, jak w takiej sytuacji się zachować jako Scrum Master, co może zrobić management, jak mógłby się zachować lepiej zespół. Jeśli taka formuła pracy brzmi dla Ciebie interesująco, to zapraszam do zapisów na 202procent.pl/przypadki-scrumowe Jacek: Natomiast notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/117 Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek. Jacek: Dzięki Kuba. I do usłyszenia wkrótce. ——— To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę! Ostatnia aktualizacja: 23 stycznia 2026The post O tym, kiedy odpuszczać first appeared on Porządny Agile.