Q&A cz.1

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

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

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, hipote