Q&A cz.1

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.

Spis treści

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

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”

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.

The post Q&A cz.1 first appeared on Porządny Agile.