8 grudnia 2021Agile, Techniki zwinne

Dlaczego zespoły nie planują zespołowo?

Podczas planowania bardzo często zauważamy, że zespoły są zespołami tylko z nazwy. Każdy robi to co ma przydzielone, nie angażuje się i nie wychodzi poza szereg. Mamy kilka hipotez na to, dlaczego zespoły nie planują. Chcemy dać Ci też inspiracje do tego, żeby planować zespołowo. To, co odkryjesz w zespole podczas planowania, może okazać się największą wartością z tego procesu (a nie sam plan, który się szybko dezaktualizuje).

Porządny Agile · #077 – Dlaczego zespoły nie planują zespołowo?

Praca zespołowa dotyczy nie tylko wykonywania zadań, ale także etapu planowania. Dlaczego jednak ten drugi element jest często pomijany? Jak zacząć planować działania wspólnie, zamiast robić plany indywidualne?

Podczas pracy z zespołami często widzimy, że mimo wdrażania praktyk zwinnych to gdy przychodzi do czynności planowania iteracji, sprintu czy wdrażania jakiegoś projektu to tak naprawdę brak tam planowania zespołowego. Jest to dużym błędem, bo to, co odkryjemy w zespole podczas planowania, może okazać się największą wartością z tego procesu. Sam plan ma mniejszą wartość, gdyż szybko się dezaktualizuje.

W tym artykule odpowiemy sobie na pytanie, dlaczego zespoły nie planują zespołowo i podpowiemy Ci jak zmienić ten stan rzeczy w Twoim zespole.

Nim jednak przejdziemy do przyczyn i rozwiązań przytoczymy Ci przykłady planowania w zespole, które ma niewiele wspólnego z planowaniem zespołowym. Zwykle jest tak, że zespół omawia konkretny zakres (zadań, wymagań, ficzerów), który zostanie wykonany. I na tym całe planowanie się kończy. Czasem zachodzi jeszcze indywidualny przydział zadań do członków zespołu. Nie jest to jednak planowanie zespołowe, nie powstaje również żaden faktyczny plan. W konsekwencji każdy martwi się o swój kawałek projektu, nie ma tu współpracy, a członkowie zespołu pracują obok siebie. Jednocześnie bardzo często okazuje się, że to, co w strukturze organizacji określane jest zespołem to tylko taki formalny kontener, składający się z jednostek.

Oczywiście, łatwo nam powiedzieć, że coś nie działa, wskazać co dokładnie, a następnie wyliczyć listę praktyk, które mogą zapobiec lub usunąć jakiś problem. Dlatego najpierw warto poznać przyczyny takiego stanu rzeczy.

Dlaczego zespoły nie planują zespołowo?

Bazując na naszych obserwacjach zebraliśmy 8 przyczyn problemów związanych z planowaniem zespołowym:

Przyzwyczajenie do takiego trybu pracy. Możliwe, że członkowie zespołu nigdy w swojej karierze zawodowej nie mieli okazji poznania perspektywy prawdziwej pracy zespołowej i jest to dla nich całkowicie normalny stan.
Narzędzia elektroniczne, z których korzystają zespoły w pracy, zupełnie nie wspierają aktu planowania. Mamy tu na myśli takie narzędzia jak Trello czy Jira. Pozwalają one na wizualizację Backlogu Produktu czy listy zadań, jednak nie mają funkcjonalności wspierających planowanie zespołowe.
Wyróżnianie poziomów specjalizacji i podział na wyraźnie stanowiska pracy. Jest to zrozumiałe i potrzebne m.in. jeśli chodzi o proces rekrutacji czy ustalanie ścieżek rozwoju pracowników. To jednak może utrudniać pracę w zespole, gdyż pracownicy mają świadomość odpowiedzialności, za swoją działkę, do której zostali zatrudnieni i z czego są też rozliczani.
Utylizacja stanowisk pracy, czyli oczekiwanie, że skoro zatrudniamy developera, to spędza on swój czas na programowaniu, natomiast zatrudniony tester zajmuje się tylko testowaniem. Powoduje to, że po prostu robimy to, co się od nas oczekuje, a takie wychodzenie poza nasz zakres, nie jest mile widziany. To z kolei stoi w sprzeczności ze współpracą zespołową.
Maksymalizacja wyników pracy, czyli oczekiwanie, że wszyscy w zespole będą 100% czasu zajęci. Taka optyka, żebyśmy nie mieli żadnego przestoju i żebyśmy wciąż dążyli do tworzenia kolejnych ficzerów, bardzo utrudnia wspólną pracę. Przez to przykładowo tester nie jest w stanie przetestować wszystkiego, co do niego spływa od programistów i jest coraz bardziej przytłoczony, a to w rezultacie oddala zespół od realizacji kolejnych elementów projektu.
Szkolenia ze zwinności czy ze Scruma rzadko obejmują też rzeczy związane z planowaniem. Bardzo łatwo tu wpaść w pułapkę własnych doświadczeń. Gdy trener na szkoleniu mówi “Na planowaniu Sprintu zespół planuje”, to każdy z inaczej może to odczytać. Jeden zrozumie, że po prostu ktoś przypisuje mu zadania, inny, że wybieramy sobie sami zadania itd. Dlatego warto zadbać, aby na szkoleniu uczestnicy mogli faktycznie doświadczyć właściwego planowania i zobaczyć jak powinno wyglądać.
Przekonanie, że planowanie nie jest zwinne. Często firmy przechodząc transformację ze świata bardziej projektowego, poukładanego, z mocną rolą kierownika projektu, mogą mieć poczucie, że należy porzucić planowanie, bo w Manifeście jest zanegowane podążanie za planem, więc pewnie plan jest niepotrzebny. Jest to niestety bardzo popularny, a jednocześnie niebezpieczny mit. Transformacja organizacji nie oznacza absolutne zanegowanie wszystkich praktyk, które mogą być korzystne dla osiągania sukcesu przez zespół.
Poczucie, że plan jest zwykle zbyt optymistyczny i na pewno się nie uda, więc nie ma sensu planować. W zespole jest przekonanie, że szkoda na to czasu i lepiej zająć się od razu pracą.

Po krótkim omówieniu potencjalnych przyczyn, które mogą przeszkadzać w planowaniu zespołowym, pora przejść do rozwiązań. Pamiętaj jednak, że tak jak przytoczone przez nas przyczyny, tak i rekomendacje jak rozwiązać problem, opierają się na naszych obserwacjach. Dlatego zawsze przeanalizuj, jak w Twoim przypadku wygląda sytuacja, co u Ciebie w zespole zakłóca planowanie zespołowe i które z naszych rekomendacji mogą się sprawdzić. Traktuj je jako inspirację, a nie jako gotowe rozwiązania.

Jak wdrożyć planowanie zespołowe w organizacji?

Poniżej podajemy 11 rekomendacji ułatwiających rozwiązanie problemu z brakiem planowania zespołowego, ale oczywiście raczej nie będzie potrzeby, aby zastosować je wszystkie na raz. Część z nich może nie sprawdzić się w Twojej organizacji. To jest dosyć złożona sfera, a my nie mamy tutaj monopolu na prawdę. Wszystko, co wymieniamy poniżej traktuj, przetwarzaj i adoptuj do swojej organizacji, według swojego uznania.

Nazwij problem braku współpracy – na początku warto zrobić krok do tyłu i zastanowić co u nas nie działa, jakie elementy warto poprawić. Czasem wystarczy zacząć o pewnych rzeczach mówić, aby zaczęła dziać się zmiana, w myśl stwierdzenia, że “zmiana zaczyna się od momentu, kiedy zaczynamy o niej mówić”. Stąd też ważnym punktem startowym jest rozmowa o tym, jak to nasze planowanie w zespole wygląda i jak mogłoby wyglądać.
Usprawniaj ewolucyjnie, czyli nie rób rewolucyjnych zmian, tylko zastosuj metodę małych kroków. Niezależnie od wielkości problemu i nakładających się zagadnień, zacznij od czegoś drobnego, od pojedynczej rzeczy. Następnie krok po kroku, upewniając się, że idziecie we właściwą stronę, pogłębiaj tę zmianę w swoim zespole. Oczywiście, że pojawi się pokusa, aby wszystko zmienić od razu i zobaczyć spektakularną przemianę, czy wdrożyć rewolucyjną ideę. To może jednak się nie udać, bo będzie zbyt dużo elementów do zmiany na jeden raz i członkowie zespołu zaczną się w tym gubić. Pamiętaj, że pewne rzeczy muszą dojrzeć, pewne rzeczy zespół musi oswoić i lepiej poznać.
Zdefiniuj, jak konkretnie rozumiecie współpracę w zespole. Jest to powiązanie z punktem pierwszym, czyli nazwaniem problemu z planowaniem. Dobrą praktyką jest umówienie się w ramach kontraktu zespołu, według jakich reguł pracujemy i co rozumiemy poprzez współpracę. Warto omówić to na konkretnych przykładach, poprzez wskazanie konkretnych zachowań, poprzez opisanie prostym językiem czego spodziewamy się po współpracy w zespole.
Zachęcaj osoby do wychodzenia poza swoje role, co pozwoli też na uniknięcie wąskich gardeł i zwolnienie szybkości pracy, bo np. tester nie wyrabia się ze swoimi zadaniami, gdyż otrzymuje elementy do testowania od 6 developerów. W takiej sytuacji, zamiast zgłaszać zapotrzebowanie na dodatkowego testera i czekać na rekrutację, developerzy mogą pomóc w testach. Zapożyczając z metodologii Kanban, “zacznij kończyć, przestań zaczynać”. Jednak, aby to było możliwe, developerzy muszą być mentalnie gotowi na wychodzenie ze swojej roli i zajmowanie się zadaniami innych osób w zespole.
Stosuj planowanie wizualne, czyli w pewien wizualny sposób przedstawiaj plan, który macie przed sobą na najbliższy okres pracy. Najistotniejsze w tej praktyce jest to, żeby faktycznie pojawiła się jakaś forma wizualizacji. Może to być zwykła lista w dokumencie tekstowym, gdzie rozpiszemy kto, kiedy i czym będzie się zajmował, kiedy to mniej więcej się skończy, kto następnie przejmie pracę itd. Uwzględniamy tu zależności zewnętrzne, a poszczególne elementy możemy łatwo przesunąć lub dopytać o niezrozumiałe kwestie. Zrzucamy cały ciężar trzymania w głowie tych wszystkich informacji, a cały zespół ma dostęp do tego samego planu.
Poznaj klasyczne praktyki planowania i wykorzystaj ich elementy w swoim zespole. Nie chodzi o to, aby wdrażać je 1:1, gdyż prawdopodobnie będzie to nieadekwatne do Twoich potrzeb. Jednak przez dziesiątki lat ludzie dochodzili do coraz lepszych podejść, coraz lepszego trybu pracy, stąd warto z tego skorzystać, dostosowując je do złożonej natury naszych przedsięwzięć.Jakie są zależności między zadaniami? Jakie mamy dostępności? Gdzie widzimy ryzyka? Gdzie jest ścieżka krytyczna? Jak układa się plan w kolejnych dniach? To są wszystko elementy klasycznych metod.
Zaplanuj scenariusze alternatywne, czyli zastanówcie się, co może pójść nie tak. Sytuacji tego typu może być wiele, np. będziemy dłużej czekać, aż inny zespół dostarczy nam jakiś kawałek funkcjonalności albo zewnętrzna usługa, z którą się integrujemy, nie zadziała. Może też być tak, że osoba, od której wszystko zależy, zachoruje i nie pojawi się w pracy. W takich przypadkach budowanie alternatywnych scenariuszy może uratować projekt.
Potraktuj Daily jako planowanie krótkoterminowe. Tą rekomendacją chcemy zwrócić Twoją uwagę na fakt, że planowanie zespołowe nie dotyczy tylko na przykład scrumowego planowania Sprintu czy początku projektu. Wykorzystujmy je także do planowania codziennej pracy. Jaki będzie plan na najbliższy dzień? Jak będziemy sobie wzajemnie pomagać? Jak razem będziemy realizować nasz cel, do którego zmierzamy? Nie marnujmy Daily na robienie rundki, gdzie każdy musi się spowiadać i odklepać jakąś krótką wypowiedź. Daily to idealny czas na praktykowanie planowania zespołowego.
Poproś losową osobę o sparafrazowanie planu, zarówno na spotkaniu typu Daily, jak i podczas długoterminowego planowania. Pomoże to upewnić się, że dowolna osoba z zespołu rozumie plan i jest w stanie przedstawić tę zespołową perspektywę.
Wymyślaj własne praktyki planowania, opierając się na własnym doświadczeniu i patrząc jak w Twoim zespole, funkcjonują pewne procesy. Zadaj sobie nieoczywiste pytania, podejdź do tematu od innej strony. Nawet jeśli to na początku wydaje się dziwne, inni tak nie robią, nikt o tym nie pisze w książkach. Jeśli u Was się to sprawdza i przynosi efekty, to znaczy, że warto to rozwijać i testować dalej. Być może za kilka lat będzie to praktyka powszechnie stosowana, o której będziecie pisać artykuły i uczyć jej innych.
Zastanów się zespołowo, jak Wam działa planowanie. Pozwólcie sobie na regularną refleksję dotyczącą tego czy eksperymenty, na które się umówiliście, coś zmieniają? Czy jest lepiej, czy może gorzej? Dlaczego nam się nie udało? Pomocne przy tym mogą być jakieś mierniki KPI oraz otwartość na optymalizację.

Przyczyn, dlaczego zespoły nie planują zespołowo, jest wiele. Wiele jednak jest też sposobów, aby to zmienić. Osobiście uważamy, że warto planować wspólnie z zespołem, choć wiemy, że idealny plan nie istnieje. Plany zawsze ulegają zmianie, często już w pierwszych dniach projektu. Jednakże cała intencja stojąca za planowaniem jest taka, że proces planowania pozwala zespołowi dowiedzieć się więcej o wykonywanej pracy, umówić się dokładniej na pewne elementy, a także ustalić jak będzie przebiegać współpraca wewnątrz zespołu. Można powiedzieć, że plan jest takim produktem ubocznym planowania, ale to, co odkryjecie w zespole w trakcie planowania, stanowi największą wartość.

Transkrypcja podcastu „Dlaczego zespoły nie planują zespołowo?”

Kuba: Dzisiejszy odcinek ma trochę przewrotny tytuł. „Dlaczego zespoły nie planują zespołowo”. Wynika to z naszej obserwacji i naszej pracy z zespołami z różnych organizacji w przeszłości i teraźniejszości, gdzie trochę nas szokuje, trochę nas uderza taka wizja zespołów, które teoretycznie korzystają z metod zwinnych, z praktyk zwinnych. Teoretycznie tworzą jakiś rodzaj zespołu, czy to projektowego, czy produktowego, czy jakiegoś organizacyjnego. Ale gdy przychodzi do tych czynności planowania, iteracji, planowania Sprintu, planowania kolejnej porcji pracy jakiegoś projektu, ficzera, to de facto tak naprawdę, nie odbywa się planowanie zespołowe. Ten plan, to nie jest plan zespołu, tylko plan jakiś inny. Najczęściej plan indywidualny.

Jacek: I, zanim pogłębimy z Kubą co mamy na myśli, chcielibyśmy podziękować Ci za udział w ankiecie. Zakończyło się duże badanie słuchaczy podcastu Porządny Agile. Otrzymaliśmy masę odpowiedzi. Usiądziemy na spokojnie do analizy wyników z Kubą. Na pewno też podzielimy się rezultatami w social mediach. Już teraz wiemy, że na pewno pojawią się w kolejnych odcinkach tematy, którymi słuchacze podzielili się z nami w ankiecie. Tak więc jeszcze raz bardzo dziękujemy za spędzony czas i za ten wsad, który możemy przeanalizować.

Kuba: A na zachętę. Jakie wnioski z ankiety już mamy? Możesz to sprawdzić na naszych mediach społecznościowych. Podzieliliśmy się już pierwszą taką informacją na temat wniosków, wyników badań z wybranych pytań, wybranych jakichś tutaj analiz – takich demograficznych trochę. Jest też kilka ciekawostek. Poszukaj na naszych profilach, na tej stronie, czy tej appce społecznościowej, z której korzystasz, profilu podcastu Porządny Agile i zobacz już pierwsze wyniki na infografice.

Kuba: A wracając do merytoryki odcinka i zespołowego planowania przez zespoły. Co tutaj mamy na myśli? Jakie zjawiska obserwujemy?

Jacek: Kiedy dochodzi do faktycznego planowania zespołu, to co się dzieje, to to, że tak naprawdę zespół omawia konkretny zakres, który zostanie zrealizowany. Czyli generalnie najczęściej w praktyce oznacza to, że jakieś konkretne zadania, wymagania, ficzery, elementy Backlogu Produktu są w jakiś sposób oznaczane, że to nimi zajmiemy się w tej konkretnej iteracji. No i właściwie na tym ten akt planowania się kończy. Czyli to jest tylko wybranie zakresu. Natomiast ta właściwa czynność planowania po prostu nie zachodzi.

Kuba: Czasami jest kroczek dalej, ale dalej nie doskonale, że następuje indywidualny przydział zadań do osoby. Czyli spośród całego zespołu ustala się, kto z tego zespołu zrobi którą cząstkę pracy lub którą cząstkę produktu, i koniec. Ani to nie jest zespołowe, ani nie powstaje jednak żaden faktyczny plan, oprócz tego, że ktoś tam się czymś ma martwić.

Jacek: I konsekwencją tego, co mówi Kuba jest to, że na koniec dnia każdy martwi się i każdy odpowiada po prostu za swoją pracę, którą na tym etapie rozdawania poszczególnych elementów do wykonania, no po prostu przyjął/przyjęła. No ta optyka patrzenia na nadchodzący tydzień, czy dwa tygodnie wspólnej pracy, no zwykle ma po prostu charakter tego, że patrzę na moje podwórko, na status mojej pracy. No i na tym po prostu skupiam swoją uwagę.

Kuba: No i to niestety ma taką dalszą konsekwencję tego, że tak naprawdę ze sobą nie współpracujemy, albo na etapie planowania nie zakładamy, że ta współpraca będzie następowała. Tak troszkę przerysowując, no jesteśmy teoretycznie w zespole, a tak naprawdę obok siebie jesteśmy w zespole. No i trzymamy kciuki, żeby się udało. Znaczy ja zrobię swoje, ktoś inny zrobi swoje i oby te cząstki się połączyły w większy plan i żebyśmy się wszyscy spotkali we właściwym miejscu i we właściwym czasie. Co niestety z doświadczenia obserwujemy, że potrafi zawieść.

Jacek: No i bardzo często okazuje się, że zespół to jest taki formalny kontener, składający się z jednostek – coś, co w strukturze organizacyjnej jest nazywane zespołem. Natomiast kiedy patrzę na taki zespół ze swojej perspektywy, to widzę grupę osób pracujących pod jakimś, często nawet wspólnym szyldem. Natomiast ta faktyczna zespołowość, tak jak z Kubą rozumiemy, po prostu nie zachodzi. Planowanie jest takim szczególnym momentem, kiedy jesteśmy w stanie to zaobserwować.

Kuba: I, zanim przejdziemy do konkretnych podpowiedzi, jak można wyjść naprzeciw takiemu problemowi braku zespołowego planowania i jak to planowanie uzyskać, to chcemy tutaj bardzo wyraźnie zaznaczyć, że łatwo powiedzieć co nie działa i łatwo wyliczyć całkiem sporą pokaźną listę praktyk, które mogą zapobiec lub wyjść naprzeciw, czy usunąć jakiś kłopot. Natomiast chcemy Ciebie tutaj teraz uczulić w tym, żeby zanim się wskoczy w te rozwiązania, nawet jeśli wyglądają na przekonujące i wydaje się, że nasz autorytet podpowiada, że tutaj powinno to zadziałać. To przede wszystkim zrozumiemy, dlaczego jest jak jest. Czyli jeśli zgadzasz się lub w swoim zespole obserwujesz właśnie te zjawiska, o których teraz przed chwilą wymieniliśmy, nie mając twojego zespołu na myśli, to zanim powiesz – Dobra to naprawiam, bo Kuba i Jacek mi tak każe, to wejdziemy głębiej w to, z czego mogą wynikać takie zjawiska.

Kuba: I pierwsza myśl prosta. Zawsze tak pracowaliśmy. Czyli po prostu zespoły są do tego przyzwyczajone. Wiele osób w swojej karierze nigdy w życiu nie spotkało takiej zespołowej perspektywy, nie poczuło się fajnie częścią większego projektowego zespołu, czy produktowego. Nie traktowałbym tego jako coś bardzo negatywnego. To jest po prostu obiektywny neutralny fakt, że ten zespół tak działał. Jakieś tam sukcesy w organizacji do tej pory odnosił i nie zna innego świata. Nie zna innych praktyk i być może tu jest jedna ze sfer, w której trzeba się przyjrzeć i szukać możliwych rozwiązań.

Jacek: Kolejnym powodem jest to, że te najbardziej popularne narzędzia elektroniczne, które obserwujemy, z których korzystają zespoły, czy Trello czy TFS czy Jira, one nie wspierają aktu planowania. Są tak skonstruowane, że ten Backlog Produktu czy tę listę zadań do zrobienia w jakiś sposób wizualizują. Pozwalają nawet przenosić te konkretne zadania w jakieś tam kontenery, obszary, które wskazują, że to jest ta praca, którą będziemy się zajmować w Sprincie, iteracji czy tygodniu. Natomiast zwykle to jest tyle. Nic więcej, co by pomagało zaplanować, albo w ogóle wskazywało, że można to zrobić inaczej, niż jakimś tam drag and dropem, czy innym sposobem przenieść zadanie z Backlogu do Sprintu, czy iteracji powoduje, że po prostu idziemy w pewnym sensie za tym takim flow, który proponuje nam aplikacja. No ale to, co proponuje, jest niestety bardzo uproszczone.

Kuba: Następna kwestia, która jest też neutralna, obiektywna, taka jest, to wyraźne stanowiska pracy. Wiele organizacji, z konkretnych bardzo uzasadnionych powodów, bardzo mocno wyróżnia poziomy specjalizacji. Bardzo wyróżnia konkretne technologie, w których dana osoba się znajduje. Bardzo wyróżnia też te takie specjalizacje z takiego klasycznego kaskadowego modelu wytwarzania oprogramowania. Więc mamy analityków biznesowych, systemowych, projektantów, programistów back-end’u, front-edn’u, testerów takich i innych. I nagle się okazuje, że to wspiera zatrudnianie, wspiera być może rozwój merytoryczny tych osób, w tej swojej ścisłej profesji, czy specjalizacji. Ale akurat może to stać w sprzeczności i może to utrudniać współpracę w zespole. Wspólne podejście, wspólne planowanie i też takie wspólne niesienie pewnego ciężaru, a nie rozejścia się do swoich przegródek i taka perspektywa – ja robię dokładnie od A do B swoją cząstkę pracy, po którą zostałem zatrudniony, którą mam w zakresie obowiązków czy za którą jestem rozliczany jako profesjonalista.

Jacek: I, gdy już to sobie wszystko ładnie zaszufladkujemy, no to pojawia się taka pokusa, żeby zmaksymalizować utylizację tych konkretnych stanowisk. Czyli, jeżeli zatrudniam developera, no to oczekuję, że on spędzi swój czas developując. Jeżeli zatrudniam testera, no to oczekuję, że ten tester spędzi swój czas testując. No i to niestety stoi w sprzeczności ze współpracą. Czyli powoduje, że po prostu robimy to, co się od nas oczekuje i to takie wychodzenie poza to od A do B, nie jest mile widziane. No bo dlaczego, jako tester robisz analizę, albo czemu jako developer testujesz? Tak więc narzut korporacyjny, taki jakby historyczny czy takie oczekiwania, które są budowane przez management, często powodują, że no jednak ta utylizacja i wykorzystanie w tej specjalizacji, którą mamy no powoduje, że nie jest to coś, co wspiera planowanie, jako i bycie po prostu takim team playerem.

Kuba: Uwielbiam słowo utylizacja i regularnie używam jej, żeby patrollować trochę rzeczywistość. Utylizacja ma też drugi smak. To też oczekiwanie, że wszyscy w zespole będą sto procent czasu zajęci. I to jest ciekawy paradoks, który akurat znam z podejścia zarządzania lean, że są procesy i są momenty w danym procesie, że większą korzyścią dla procesu jest to, że nic nie robisz, niż to, że generujesz jeszcze dodatkową pracę. Wyobraźmy sobie prosty przykład. Jest trzech programistów, jeden tester i ci programiści generują rzeczy, które tester ma później przetestować. To dla całego procesu, dla flow, dla wydajności, lepiej byłoby, żeby być może ten jeden z programistów sobie odpuścił developowanie kolejnego kawałka, niż generował jakąś górkę pracy, która jeszcze bardziej tego testera przytłacza, jeszcze bardziej utrudnia, jeszcze bardziej oddala w czasie skończenie całego ficzera. Więc oprócz tego co Ty powiedziałeś, czyli maksymalizacja pracy danej profesji, to rzeczą, która bardzo obiektywnie utrudnia wspólną pracę, wspólne podejście, to taka optyka, żebyśmy byli zajęci, żebyśmy nie mieli żadnego przestoju, albo żebyśmy też może taka jeszcze inna odmiana tej utylizacji, żebyśmy non stop dążyli do kolejnych ficzerów, do kolejnych projektów. Zamiast na przykład popatrzeć na produkt jako całość i zrobić jakieś usprawnienie, jakiś refaktoring. Uporządkować pewne rzeczy, uporządkować narzędzia, nadgonić starą nigdy niezrobioną dokumentację i szereg tego typu rzeczy.

Jacek: Kolejnym powodem, jeszcze trzy takie powody chcemy wymienić, to jest to, że szkolenia ze zwinności czy szkolenia ze Scruma, rzadko z naszej perspektywy dotykają istoty rzeczy związanych z planowaniem. Czyli bardzo łatwo możemy wpaść w pułapkę, że trener mówi – Na planowaniu Sprintu zespół planuje. No i każdy sobie w głowie na bazie swoich doświadczeń mówi – Aha, planuję. Czyli ktoś przypisuje mi zadanie. Albo planuje. Aha, czyli mówię, że to ja zrobię zadanie X czy zadanie Y. I to powoduje, że wszyscy się pięknie zgadzamy, natomiast potencjalnie w najlepszej wersji czy wariancie trener ma coś innego na myśli. Natomiast słuchacze, uczestnicy szkolenia myślą o czymś innym. Tak więc potencjalnym obszarem do usprawnienia jest to, żeby zapewnić, że podczas takich szkoleń, żeby osoby uczestniczące faktycznie doświadczyły tego właściwego planowania, a nie tylko, żebyśmy się zgodzili na poziomie jakichś tam ogólników.

Kuba: Kolejna rzecz, która też wygląda mi na całkiem prawdopodobną hipotezę to to, że w niektórych organizacjach ta czynność planowania, te efekty planowania, kojarzą się z czymś, co nie jest zwinne. Niektóre firmy przechodzą transformację, przechodząc z takiego świata bardziej projektowego, poukładanego, z mocną rolą kierownika projektu. I fakt, że te osoby na przykład korzystały, budowały plany, korzystały z konkretnych narzędzi, które zresztą jeszcze nawet wspomnimy w tym odcinku powoduje, że w ramach transformacji wyobrażamy sobie, że no trzeba porzucić to planowanie, bo przecież zwinność tego nie zakłada, nie przewiduje. W Manifeście jest zanegowane podążanie za planem, więc pewnie plan jest niepotrzebny. No i to jest niestety bardzo niebezpieczny mit, ale on jest też bardzo popularny i z tego co widzę, może robić zawieruchę w tym temacie zespołowego planowania. No bo Ty chcesz zaproponować jakieś praktyki planowania, a się nagle okazuje, że zespół mówi – Nie, no stary, ale to już nie te czasy. My teraz już nie planujemy projektów. I to może być czasami tak w złym tonie w tej organizacji, tej konkretnej organizacji, która przechodzi pewną zmianę, żeby pomimo tego, że faktycznie transformacja w stronę zwinności następuje. To nie oznacza absolutne zanegowanie wszystkich praktyk, które mogą być korzystne dla osiągania sukcesu przez ten zespół.

Jacek: I ostatnim powodem, który zdiagnozowaliśmy jest takie poczucie, że ten plan, który założyliśmy, taki zwykle optymistyczny, że on się po prostu uda. Więc tak naprawdę pojawia się pytanie, po co mamy tyle planować? Czyli takie poczucie, że tak naprawdę szkoda czasu, zajmijmy się już pracą. Wróćmy już do tej prawdziwej pracy, czyli do kodowania, no i wtedy oczywiście to planowanie jest traktowane jako pewne marnotrawstwo. Jest to ostatni powód, który nam wydaje się, że jest tutaj przyczyną takiego postrzegania planowania.

Kuba: Dobra to wspomnieliśmy o tych niedoskonałych planowaniach, które osobiście obserwujemy. Wymieniliśmy kilka hipotez, które warto rozważyć czy warto się zastanowić, czy one czasami nie powodują, że w konkretnie w Twoim zespole, w konkretnie w twojej firmie wpływają na to jak jest. Bo może być tak, że są tylko wybrane z tych, które wymieniliśmy adekwatne dla Ciebie. Może być też tak, że jakaś zupełnie jeszcze inna sfera, którą my akurat nie wymieniliśmy, jest u Ciebie prawdziwa. To jest dobry wstęp do tego, żeby też po prostu pomyśleć o tym, jakie inspiracje proponujemy. Mamy ich jedenaście, więc pokrótce ją mówimy. Ale bardzo ważne zastrzeżenie. Traktuj to jako inspirację, a nie jako kompletną gotową regułę. W szczególności wątpię, że trzeba zastosować od razu natychmiast wszystkie jedenaście i może się okazać, że któraś z tych praktyk, akurat w Twoim zespole, akurat Twojej firmie z tych, czy innych powodów się nie sprawdzi. I to jest OK. Bo to jest jednak sfera dosyć złożona. Nie mamy tutaj monopolu na prawdę. I tak to wszystko, co teraz wymieniamy traktuj i przetwarzaj i adoptuj do swojej organizacji, według swojego uznania.

Jacek: Pierwsza taka rekomendacja, którą chcemy się podzielić brzmi – Nazwij problem braku współpracy. Czyli zanim rzucimy się w konkretne techniki i praktyki, no to warto zrobić krok do tyłu i w ogóle powiedzieć sobie głośno, że być może to, jak realizujemy dzisiaj planowanie, to nie do końca jest takie planowanie, jakie by to mogło być. Tym bardziej że bardzo często to takie planowanie po łebkach prowadzi po prostu do kiepskich wyników. Tak więc to jest takie podejście, które stosuję w praktyce. Między innymi dlatego, że lata temu zainspirowałem się jedną z prezentacji na jakiejś konferencji, gdzie padło coś takiego, że zmiana zaczyna się od momentu, kiedy zaczynamy o niej mówić. I tę myśl sobie wziąłem do serca i dosyć długo gdzieś tam we mnie pracowała, ale zrozumiałem i zobaczyłem w praktyce, że faktycznie wystarczy zacząć o pewnych rzeczach mówić i zaczyna się dziać zmiana, oczywiście nie sama. Trzeba to pielęgnować i tak dalej. Natomiast tym punktem startowym jest to, że w ogóle powiemy sobie – Słuchajcie można pracować inaczej. Tak więc jest to taki ważny punkt startowy, w ogóle do rozpoczęcia dyskusji o tym, jak to nasze planowanie w zespole mogłoby wyglądać.

Kuba: Drugą poradę jaką mamy, to usprawniaj się ewolucyjnie. Zastosuj metodę małych kroków. Niezależnie od tego, że problem być może jest wielki, być może nabrzmiały, być może jest szereg kolejnych nawarstwiających się zagadnień, które jest do zmiany. To i tak zacznij od czegoś drobnego. Dosłownie pojedynczej rzeczy. I krok po kroku, tak trochę upewniając się, że idziemy we właściwą stronę, pogłębiaj tę zmianę w swoim zespole. To jest duża obawa czy duży kłopot dla wielu osób, które mają trochę większą świadomość. Czy to jest Agile Coach, Scrum Master, lider zespołu, czy deweloper, który na przykład już widział trochę lepsze funkcjonujące zespoły na przykład w poprzedniej firmie albo w poprzednim projekcie, że spala ich wewnętrznie ochota zmienienia od razu całego świata? Wszystko tutaj, robimy to tak i tu zacznijmy, to skończmy, tu zróbmy w tym narzędziu. I nagle się okazuje, że ta osoba po prostu jest niesłuchana też dlatego, że ma za rewolucyjną ideę. Zbyt dużo chce zmienić jednocześnie. Wszyscy się zaczynają trochę gubić, o co chodzi. Gubi się też ten sens. Więc tutaj niezależnie od tego, że mamy ochotę i być może autentycznie potrzeba jest na to, że zmiana byłaby głębsza, to i tak zróbmy ją metodą małych kroków, a nie dużymi. Być może nawet też powolnymi zmianami. Bo pewne rzeczy muszą dojrzeć. Pewne rzeczy zespół musi je tutaj oswoić, jakby może nawet musi dojść do pewnych większych kryzysów, żeby pewne uzasadnienia albo zmiany też były przez wszystkich współodczuwane.

Kuba: Trzecią praktyką, którą proponujemy to zdefiniuj, jak konkretnie rozumiecie współpracę w zespole. To jest powiązane z tym nazwaniem problemu. To samo nazwanie OK – Mamy problem braku współpracy, mamy problem z planowaniem, chcemy planować inaczej, to może być trochę mało. Dobrze, żebyśmy w ramach kontraktu zespołu, w ramach umówienia się według jakich reguł pracujemy, w ogóle jako zespół. Zawarli też w tym, co rozumiemy pod współpracą. Współpraca jest jedną z tych wielu słów kluczy takich pułapek, że współpraca. Oczywiście, że współpraca. Współpraca, komunikacja, szacunek. Dajemy sobie informację zwrotną. Wszyscy fajnie, to łatwo się zgodzą. Takie oczywiste, politycznie poprawne jest, żeby powiedzieć, że tak to właśnie rozumiemy. Po czym się okazuje, że dla jednego współpraca to jest, że do zobaczenia za dwa tygodnie. Przyniosę swoją część. No i to jest dokładnie sprzeczne z tym, co mamy tu na myśli. Więc dobrze poprzez pewne przykłady, poprzez konkretne takie prostym językiem powiedziane zachowania, wymienić to, czego się spodziewamy po współpracy. Że będziemy sobie pomagać, że będziemy się trochę więcej komunikować, że będziemy się wzajemnie – w dobrym rozumieniu tego słowa – sprawdzać, że będziemy się wymieniać robotą, że będziemy się wzajemnie od siebie uczyć. Tego typu zachowania, nie mówię, że wszystkie, które wymieniłem po przecinku, tylko te, które w tym zespole konkretnym są potrzebne i uznane i jakby nazwane jako te jak chcemy, żeby było. Czyli na etapie kontraktu zespołu, gdy zespół powołujemy, gdy zespół jakoś reformujemy, reorganizujemy, dokonujemy jakiejś refleksji, że czas może się umówić na coś nowego. Zdefiniujemy sobie, co konkretnie, z akcentem na konkretnie, praktycznie, rozumiemy jako współpracę.

Jacek: Kolejną inspiracją, którą chcemy się podzielić jest inspiracja, w której zachęcamy osoby do wychodzenia poza swoje role. Najczęściej jest tak, że organizacje rekrutują osobę na konkretne stanowiska. Programista, Product Owner, Developer front-end’owy, UX, analityk. No i to powoduje, że potem, pomimo iż jesteśmy wkładani do pojemnika o nazwie Zespół X, no to każdy ma swoją rolę. I to niestety powoduje, że w szczególności, gdy pojawia się w zespole jakieś wąskie gardła, no to zespół czuje, że ma związane ręce. Najbardziej klasyczny przykład, który właściwie non stop obserwuje w różnych organizacjach jest taki, że tester się nie wyrabia. Jest jeden tester, sześciu developerów. No i co by tutaj zrobić? Zespół dochodzi do refleksji, że brakuje testera. No i oczywiście możemy zgłosić zapotrzebowanie, że brakuje testera, możemy pożyczyć testera z innego zespołu i tak dalej. Natomiast prostą techniką, która działa jest to, że się umówimy, że po prostu pomożemy tej osobie, Kasi, Tomkowi w testach. W momencie, kiedy się okaże, że jest tego za dużo, no to po prostu jestem developerem, ale na chwilę przestaje developować nowe rzeczy, tylko domykam to, co rozpoczęliśmy. Tak trochę z Kanbanu – zacznij kończyć, przestań zaczynać. No ale, żeby to zrobić, no to ja muszę mentalnie być gotowy, czy gotowa na to, że wychodzę z tej swojej roli i po prostu robię coś innego. Dałem przykład testów, ale to może być dopytanie stakeholdera o jakieś detale, rozwinięcie jakiegoś tam kawałka Backlogu Produktu. Bardzo różne rzeczy. Natomiast na koniec dnia chodzi o to, żeby mieć taką elastyczność w tym, żeby pomagać zespołowi osiągać cel. No i to czasem będzie się wiązało z tym, że to moje takie bazowe narzędzie, na którym operuje będę musiał odłożyć i wziąć do ręki inne, w którym być może też nie jestem tak biegły, biegła. No ale wystarczająco dobry, bądź dobra, żeby jednak na koniec dnia zespołowi pomóc.

Jacek: Kolejna inspiracja brzmi stosy planowanie wizualne. Bardzo dużo zespołów planuje w sposób taki, że opowiadają sobie, co wykonają. Jak wspominaliśmy jakaś praca ląduje w jakichś tam miejscach w aplikacji. Przesuwa się do jakiegoś Sprintu czy iteracji. Natomiast to, co obserwuję na bazie własnych doświadczeń, co jest bardzo pomocne i co w ogóle pokazuje, czym jest istota planowania jest planowanie wizualne, które polega po prostu na tym, że w pewien wizualny sposób przedstawiamy ten plan, który mamy przed sobą na najbliższy okres pracy. Ten plan wizualny może przybrać różną formę. Tutaj jakby to, co jest najistotniejsze w tej w tej praktyce to jest to, żeby faktycznie pojawiła się jakaś forma wizualizacji. To może być zwykła lista w jakimś tam dokumencie tekstowym, w którym sobie zaplanujemy kto, czym się będzie zajmował. Kiedy? Kiedy to się mniej więcej skończy? Kto tę pracę przejmie? Które rzeczy mogą się zacząć, dopiero gdy coś innego zostanie zrealizowane? Uwzględniamy sobie jakieś zależności zewnętrzne i tak dalej. Efektem jest to, że ten plan, kiedy już go przygotujemy, to możemy na niego spojrzeć. Możemy łatwo przesunąć jakieś elementy. Możemy dopytać o konkretną rzecz, która jest nazwana wspomniana. Tam może być ktoś dopisany, kto to realizuje. Możemy go zapytać, ją zapytać. Tak więc rzucamy sobie cały ten ciężar trzymania tego w głowie i liczenia, że od godziny każdy tak samo zapamiętał to, co ustaliliśmy. Po prostu na papier to może być dokument tekstowy, to może być Excel, to może być Mural, Miro, cokolwiek. W każdym razie jakby przerzucamy to na papier klasyczny bądź elektroniczny.

Kuba: Następna praktyka bardzo podobna do tego, co Jacek powiedziałeś, to poznaj klasyczne praktyki planowania. Tak jak wspomniałem o tym micie, że planowanie jest nie zwinne, więc należy je całkowicie porzucić. No faktycznie podejście do planowania, czy praktyki planowania, takie klasyczne tradycyjne, są związane z zarządzaniem pracą zespołami, zarządzaniem na przykład logistyką w czasie wojny. To ma długą historię, to nie ma nic wspólnego z Waterfallem, albo PMO w Twojej korporacji. Te metody planowania były potrzebne do tego, żeby efektywnie zarządzać jakąś sytuacją, czy jakimś projektem, czy jakąś inicjatywą, przedsięwzięciem. I przez te dziesiątki lat ludzie dochodzili do coraz lepszych podejść, coraz lepszego trybu pracy, do jakichś pewnych praktyk, które się po prostu w tym konkretnym scenariuszu sprawdzają. I coś, co w ramach tej inspiracji sugeruję, to to, żeby poświęcić na to czas. Może sobie zrobić jakiś kurs z planowania pracy? Może podyplomówkę z zarządzania projektami? Może zapytać o jakieś kursy czy jakieś krótkie szkolenia, żeby poznać te klasyczne metody. Niekoniecznie po to, żeby je 1:1 wprowadzić w swoim zespole, albo uwierzyć, że faktycznie tu kuloodporny plan stworzymy w jakimś dobrym MS Project, bo to prawdopodobnie będzie nieadekwatne. Ale już te wszystkie reguły, które Jacek przed chwilą wymienił przy planowaniu wizualnym, tak naprawdę one są elementem klasycznym. Jakie są zależności między zadaniami? Jakie mamy dostępności? Gdzie widzimy ryzyka? Gdzie jest ścieżka krytyczna? Jak układa się plan w kolejnych dniach? Kiedy to się wszystko gdzieś zbiega kończy? To są wszystko elementy klasycznych metod. I naprawdę szkodzimy sobie sami, jeśli do tych metod nie sięgniemy jako inspiracja. Warto je sobie oczywiście zaaplikować do siebie w taki sposób przetworzony, nowoczesny, uwzględniający również złożoność natury naszych przedsięwzięć. Większość z naszych Słuchaczy – wiemy to z ankiety, że jednak konsekwentnie działa w tej domenie IT. Ale nawet Ci z Was, którzy są w innym świecie, też prawdopodobnie mierzą się ze złożonymi projektami. I to powoduje, że te plany nie sprawdzą się w stu procentach. Ale to nie znaczy, że nie należy zaczerpnąć tej inspiracji z klasycznych metod i spróbować je po swojemu tak zaaplikować do swojej codziennej pracy zespołowej

Jacek: Rozszerzając rozmowę o planie, warto zaplanować scenariusze alternatywne. Czyli zastanowić się, co może pójść nie tak. Być może czekamy na to, żeby zespół X dostarczył nam jakiś kawałek funkcjonalności. Być może łączymy się z jakąś zewnętrzną usługą, która również może zadziałać – nie musi. Być może generalnie w trakcie naszej iteracji w trakcie Sprintu, czekamy na jakieś wydarzenie, czekamy na jakiś sygnał, czekamy na dostarczenie czegokolwiek. Z innej strony patrząc, możemy się zastanowić, co się stanie, kiedy osoba, od której wszystko zależy, nie przyjdzie do pracy. W czasach takich jesteśmy, ja właściwie niemal codziennie, kiedy pracuję z różnymi klientami słyszę, że ktoś miał przyjść, ale dzieci na kwarantannie. Nie może, albo właśnie, że jest pozytywny, zdiagnozowany. Tak więc te takie rzeczy, które zawsze podawałem jako przykład, to mam wrażenie, że w tych dzisiejszych czasach one się częściej materializują, więc naprawdę warto się zastanowić, czy taki pojedynczy silos kompetencyjny, czy nadal chcemy go utrzymywać w czasach, kiedy faktycznie ta niepewność trochę wzrasta. W takich sytuacjach, to budowanie alternatywnych scenariuszy, oczywiście to może być po prostu plan B, to nie musi być dziesięć alternatywnych scenariuszy, ale chociażby zastanówmy się, jakie jest największe ryzyko, jeśli chodzi o nasz plan i jeśli się zmaterializuje, to w jaki sposób do niego podejdziemy.

Kuba: Ósmą praktyką, którą w ramach tej całej serii proponujemy, to potraktowanie również Daily, jako planowania zespołowego, ale jako planowania krótkoterminowego. I specjalnie podkreślam to Daily, bo do tej pory mocno te praktyki, które wymieniliśmy mogły się kojarzyć, czy mogły sugerować ten moment planowania, taki na przykład scrumowego planowania Sprintu czy początku jakiejś iteracji, początku projektu. Ale tutaj miejmy z tyłu głowy to zwinne planowanie również takie codzienne, gdzie całym zespołem wykorzystujemy ten moment codziennego spotkania do tego, żeby stworzyć sobie plan krótkoterminowy. Plan na najbliższy dzień. Jak będziemy działać jako zespół? Jak będziemy sobie wzajemnie pomagać? Jak razem będziemy realizować nasz cel, do którego zmierzamy? I też przez odwrotność – nie planujemy tego Daily jako statusu, gdzie przed kimś się spowiadamy, gdzie robimy jakąś rundkę, gdzie każdy musi coś powiedzieć, odklepać jakąś krótką wypowiedź. Wytłumaczyć się. Marnować sobie wzajemnie czas. Daily jest idealną okazją do tego, żebyśmy całym zespołem powiedzieli sobie, jaki mamy plan. Jak będziemy ze sobą współdziałać, a niekoniecznie traktujemy to jako te negatywne zjawiska, które przed chwilą wymieniłem.

Jacek: Kolejną praktyką, którą chcemy się podzielić, jest proszenie losowej osoby o sparafrazowanie planu. Ta praktyka może być zarówno użyta w kontekście tego, co mówił przed chwilą Kuba, czyli na spotkaniu typu Daily, jak również na takim normalnym planowaniu, kiedy po prostu planujemy sobie na trochę więcej, tydzień, dwa, trzy do przodu w zależności, jak długi mamy ten okres. Właściwie nie ma tutaj żadnej filozofii. Polega to na tym, żeby upewnić się, że dowolna osoba z zespołu jest w stanie przedstawić tę perspektywę zespołową. Czyli nie tylko co ja zrobię, tylko właśnie takie spojrzenie, ok, to umówiliśmy się właśnie, że celem naszym jest X no i zrobimy to tak, że osoba Y i Z zajmie się tym. Mniej więcej po trzech dniach wydarzy się coś tam. No i oczywiście tutaj jakby ten poziom detali jest do ustalenia. Natomiast powinno być jakby w pozostałych członkach zespołu, powinno się zrodzić takie przekonanie, albo OK, ten plan właśnie tak sobie wyobrażałem czy wyobrażałam w głowie. Albo, i to jest bardzo częste w momencie, kiedy ktoś opowiada, dostaje takie kontrkomentarze na zasadzie – Chwila, chwila, wcale nie jest tak, że Tomek robi to, a Kasia zrobi tamto, tylko dokładnie odwrotnie. I się zaczyna dyskusja. Tak więc bardzo fajne, taki empiryczny sposób na sprawdzenie, czy jesteśmy na tej samej stronie.

Kuba: Przedostatnia porada. Już trochę z innego poziomu abstrakcji to, wymyślaj własne praktyki planowania. Niezależnie od tych, które wymieniliśmy przed chwilą, my mamy osobiste doświadczenie i osobiste poczucie, że one są fajne, ale jeszcze fajniejsze są te, które wymyślimy sami. Czyli zwłaszcza czerpiąc pewne inspiracje, czerpiąc jakieś przemyślenia. Patrząc też, jak pewne rzeczy u nas funkcjonują. Zastanówmy się, czy po prostu nie wystarczy, jak sami coś wymyślimy. Wykorzystamy kreatywnie istniejące narzędzia, zadamy sobie jakieś nieoczywiste pytania. Zrobimy to w jakiejś innej, może nawet trochę na początku wydawałoby się głupkowatej konwencji, i może się okazać, że idealnie tak kliknie, że tak nam się połączą praktyki i sobie wymyślimy coś, czego w zasadzie inni nie stosują. Nigdzie nie czytaliśmy o tym. Nie wiemy, że to ma jakąś nazwę. Tylko po prostu nam się to sprawdza. I nawet nie chcę konkretnych rzeczy wymieniać, bo wtedy już naprawdę wszyscy z tych zespołów będą wiedzieć, że się na nich powołuję, ale czasami widzę bardzo nieoczywiste rzeczy stosowane przez pewne zespoły. Na początku wydaje mi się to dziwne, albo głupie, albo nie do końca rozumiem. Ale jeśli tylko odpowiednio wyczekam i zrozumiem i zauważę, że w sumie u nich działa, to może się okazać, że albo właśnie wymyślili nową metodę, o której za 20 czy 30 lat będzie się uczyć, albo będą z tego robić certyfikację, albo przynajmniej tu lokalnie doszli do jakiejś bardzo, bardzo fajnej, unikalnej praktyki. I coś, do czego Ciebie zachęcam Słuchaczu, to też to, żeby po prostu zobaczyć, czy czasami może zamiast oglądania się na innych, na inne praktyki, na jakieś podręczniki czy jakieś playbooki, czy filmiki jak inni to robią, może masz wystarczający potencjał, żeby sobie swoje własne podejście wytworzyć. Poeksperymentować z nim i je doskonalić, pod warunkiem, że u Was działa. Pod warunkiem, że to faktycznie pomaga.

Jacek: I ostatnia inspiracja, też taka na meta poziomie. Zastanów się zespołowo, jak wam działa planowanie. No to taki myślę nasz klasyk z Kubą porządnoagile’owy. Czyli zachęta do tego, żeby regularnie odbywała się refleksja dotycząca tego, czy planowania działa. Czy te eksperymenty, na które się umówiliśmy, coś zmieniają? Czy jest lepiej? Czy jest gorzej? Co sprawia, że się udało? Dlaczego nam się nie udało? Fajnie jakby w tym wszystkim pojawił się jakiś miernik KPI, jakaś taka miara, na którą moglibyśmy spojrzeć. No bo tak naprawdę nie ma jednego sposobu usprawnienia się. Natomiast to, co zwykle pomaga to dane oraz otwartość na to, żeby zastanowić się, co można zrobić lepiej. No i do tego zdecydowanie Cię zachęcamy.

Jacek: Taka dodatkowa refleksja na koniec. Uważamy, że warto planować, pomimo iż doskonale z Kubą wiemy, że idealny plan nie istnieje. Ten plan, który przygotuje cię na początku iteracji, on na pewno się zmieni i to już w pierwszych dniach. Natomiast jakby cała ta intencja stojąca za planowaniem jest taka, że sam proces planowania pozwala zespołowi dowiedzieć się wielu rzeczy, umówić się dokładniej na pewne elementy. I jakby ten plan, co do zasady z takim produktem ubocznym. On będzie ulegał zmianie, ale to, co odkryjecie w zespole w trakcie planowania, to z mojej perspektywy jest ta największa wartość.

Kuba: Podsumowując cały odcinek. Jakie praktyki warto rozważyć, by planować zespołowo?

Jacek: Nazwij problem braku współpracy. Usprawniaj się ewolucyjnie. Zdefiniuj, jak rozumiecie współpracę w zespole. Zachęcaj osoby do wychodzenia poza swoją rolę. Stosuj planowanie wizualne. Poznaj klasyczne praktyki planowania.

Kuba: Zaplanuj scenariusze alternatywne. Potraktuje Daily jako planowanie krótkoterminowe. Poproś losową osobę o sparafrazowanie planu. Wymyślaj własne praktyki planowania i zastanów się zespołowo, jak wam działa planowanie.

Jacek: Notatki do tego odcinka, transkrypcję, zapis wideo, a po kilku dniach również artykuł, znajdziesz na stronie porządnyagile.pl/77.

Kuba: Zazwyczaj na końcu odcinka mamy jakieś albo ogłoszenie, albo jakąś zachętę. Tym razem będzie trochę inaczej, bo jest to ostatni odcinek, który planujemy zrealizować w tym roku. Ostatni odcinek przed Świętami. Czyli wyskoczymy tym razem trochę z tego cyklu dwutygodniowego i następny odcinek będzie dopiero w styczniu. Chcemy skorzystać z tej okazji, żeby na koniec życzyć Tobie Wesołych Świąt. Miłego zakończenia roku, zabawy na Sylwestra – oczywiście z uwzględnieniem aktualnie panujących warunków. Wszyscy wiemy jak jest, ale też chwili odpoczynku po to, żeby wejść z nową energią w Nowy Rok. Zaplanować sobie nowe rzeczy. Może przyjąć pomysły na Nowy Rok i zrealizować je lub nie, ale na pewno sobie wybaczyć za to wszystko, co się dzieje.

Jacek: Z mojej strony przede wszystkim wyhamowania. Żyjemy w dosyć dużym pędzie, rzeczywistość wokół nas jest jaka jest. Tak więc życzę Ci Słuchaczu spokoju, odpoczynku, refleksji w tym takim świątecznym, grudniowym okresie. Tak, żebyśmy mogli wrócić do Nowego Roku na świeżo i z nową energią.

Kuba: Ja sobie też pozwolę podziękować i życzyć wszystkiego dobrego całej ekipie, która stoi za podcastem, bo oprócz tego, że możesz nas usłyszeć lub zobaczyć, też jestem pewien, oraz sam składam życzenia: Marcinowi, Agacie, Monice. Bo jest więcej niż nasza dwójka, która stoi za tym, żeby ten podcast powstawał. No i myślę, że również w imieniu nas wszystkich Tobie życzymy wszystkiego dobrego.

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

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.