Siła retrospektywy – narzędzia - OKDP 111

Siła retrospektywy to jedno z najbardziej użytecznych narzędzi dla usprawnień w zespole.

Monika Chutnik
Siła retrospektywy – narzędzia

Dzisiaj rozmawiamy o narzędziach. Pomyślałam, że ciekawe będą takie odcinki, w których możemy naświetlić poszczególne sposoby i metody pracy. A po co? Właśnie po to, żeby wiedzieć, na czym to polega i móc zastosować je w swoim własnym zespole wtedy, kiedy jest to potrzebne — albo nawet zupełnie regularnie.

Dzisiaj mowa o takim narzędziu: retrospektywie. Moim gościem jest Dawid Wacławski.

 

Czego dowiesz się z tego odcinka:

  • Czym jest retrospektywa i po co zespoły ją stosują
  • Jak bezpieczeństwo psychologiczne wpływa na otwartość rozmów
  • Dlaczego rola menedżera w retrospektywie jest ograniczona
  • Jak ustalać priorytety, gdy tematów jest więcej niż czasu
  • Jaką rolę pełni facylitator i kiedy warto zaprosić kogoś z zewnątrz
  • Jakie metody retrospektyw możesz zastosować, aby spotkania były ciekawsze
  • Dlaczego regularność retrospektyw jest kluczem do usprawnień
  • Jak zmiana kontekstu, np. wyjście poza biuro, wpływa na efektywność spotkania

 

Gdy będziesz słuchać tego odcinka, pomyśl o osobie, która też wysłuchałaby go z korzyścią dla siebie lub swojego zespołu i podziel się linkiem do nagrania.

 

Podziel się swoimi przemyśleniami – tutaj na portalu, lub na naszym profilu na LinkedIn.

Zapraszam Cię do zapisania się na newsletter i obserwowania profilu na LinkedIn. Subskrybuj też kanał O Krok Do Przodu na wybranej platformie i dziel się ze znajomymi.

 


Materiały i źródła wymienione w odcinku


 

O gościu

Mam na imię Dawid i chciałbym opowiedzieć o retrospektywie. To bardzo fajne narzędzie z IT. Pracowałem w tej branży przez ponad 20 lat, większość czasu jako menedżer w różnych rolach. Właściwie w każdym zespole i w każdym obszarze, w którym pracowałem, stosowaliśmy retrospektywę — w takiej czy innej formie.

Jeżeli miałbym wybrać jedno narzędzie z IT, które warto przenieść do innych branż, to właśnie retrospektywa znalazłaby się absolutnie na pierwszym miejscu. To naprawdę bardzo potężne narzędzie. Cieszę się więc, że dzisiaj będziemy mogli opowiedzieć o nim coś więcej.

 

Retrospektywa – co to jest i dlaczego warto jej używać

Tak jednym zdaniem: retrospektywa jest po to, aby usprawnić pracę zespołu. Po prostu zespół rozmawia o tym, jak pracować lepiej i co zrobić, aby wszystkim pracowało się łatwiej.

Ta metoda jest znana od lat. Sama nazwa może brzmieć trochę tajemniczo — „retrospektywa” kojarzy się z powrotem do przeszłości — ale w praktyce chodzi po prostu o to, by wspominać i analizować pewne rzeczy, tyle że w kontekście zawodowym, biznesowym. W projektach, szczególnie tam, gdzie pracuje się projektowo, istnieje praktyka podsumowania na końcu — tzw. lessons learned. Wyciągamy wnioski: co poszło dobrze, co poszło źle, i przenosimy te doświadczenia do kolejnych projektów, żeby usprawnić pracę.

W największym skrócie o to właśnie chodzi: żeby praca była bardziej efektywna i żeby zespołowi pracowało się lepiej.

 

Bezpieczeństwo psychologiczne a retrospektywa

Od tego w sumie trzeba zacząć: absolutnie kluczowym elementem retrospektywy jest bezpieczeństwo psychologiczne zespołu. Musi być poczucie, że nikt nie będzie tutaj „bity” ani obwiniany. Nie chodzi o szukanie winnych błędów czy porażek. Absolutnie nie.

Retrospektywa to po prostu spotkanie zespołu. Najlepiej bez menedżera. W moim doświadczeniu zawsze odbywało się to właśnie w ten sposób. Jako menedżer nie angażowałem się w retrospektywę, żeby nie zaburzać procesu. To jest pełen empowerment — narzędzie stworzone dla zespołu, aby to jemu pracowało się lepiej.

Celem retrospektywy jest usprawnienie pracy. Zespół sam identyfikuje problemy, które napotyka, i generuje pomysły, jak je rozwiązać. To najważniejszy aspekt.

Po co to robimy? Zespół powinien się rozwijać. Nawet drobne zmiany, regularnie wdrażane, prowadzą w stronę metody kaizen: krok po kroku do coraz większej perfekcji. Być może nigdy nie osiągniemy ideału, bo problemów zawsze będzie więcej niż czasu na ich rozwiązanie — ale właśnie dlatego trzeba wybierać, nad czym pracować.

Dlaczego retrospektywa powinna odbywać się bez menedżera?

Bo wtedy zespół wzmacnia swoją sprawczość i odpowiedzialność. Decyzje zapadają oddolnie, a nie są narzucane z góry. To zupełnie zmienia perspektywę i sposób patrzenia na problemy: co jest ważne, co chcemy rozwiązać i w jakiej kolejności.

 

Inna perspektywa na retrospektywę

Dorzucę tutaj inną perspektywę z naszego doświadczenia. W projektach często występuję w podwójnej roli: z jednej strony jestem współtrenerką czy współfacylitatorką, a z drugiej — właścicielką firmy, która zatrudnia tę osobę jako zleceniodawcę. „Pracodawca” to może zbyt mocne słowo, bo przecież współpracujemy projektowo, ale ta rola jest podwójna.

Nie odmawiam sobie przyjemności uczestniczenia w naszych spotkaniach podsumowujących projekt, choć zwracam uwagę, żeby nie wyrywać się pierwsza do zabierania głosu. To przychodzi mi z trudem, ale staram się dawać innym więcej przestrzeni.

Zauważyłam też, że kiedy pracujemy z osobami nowymi i robimy takie podsumowanie, na początku patrzą na to nieufnie: zastanawiają się, co z tego wyniknie i czy to nie będzie jakieś rozliczanie — zresztą często nie do końca wiadomo z czego. Taka obawa się pojawia.

Dopiero gdy zobaczą pierwszą czy drugą rundę i zrozumieją intencję — że chodzi o uczenie się na przyszłość — to zaczynają wchodzić w ten proces dużo swobodniej. Z czasem staje się to fajnym nawykiem. Przynajmniej w niektórych konfiguracjach, bo u nas przy każdym projekcie pracuje trochę inny zespół.

 

Cel retrospektywy

Tutaj warto powiedzieć, po co właściwie robimy retrospektywę, czyli jaki jest jej cel. Szczególnie gdy w zespole pojawia się nowa osoba, która wchodzi z rozpędem — wtedy potrzeba trochę czasu, by złapać sens tego spotkania. Bo czy chodzi tylko o wymianę dobrych praktyk albo wskazanie, co się nie udało? A może o coś więcej? Naturalne jest, że na początku pojawia się obawa: „czy ktoś mnie nie będzie sprawdzał albo testował?”.

Bezpieczeństwo psychologiczne — o którym już mówiliśmy — to fundament. Trzeba je wypracować i zapewnić, a to zajmuje chwilę.

Warto też zrobić krok wstecz i zaznaczyć, że retrospektywa ma sens przede wszystkim wtedy, gdy zespół regularnie współpracuje i jest współzależny. Jeśli każdy pracuje osobno, wykonując niezależne zadania, retrospektywa nie wniesie takiej wartości. Ale kiedy członkowie zespołu są od siebie mocno zależni i muszą ściśle współpracować — wtedy retrospektywa staje się naprawdę potrzebna.

Oczywiście zespół musi też mieć chęć rozwoju: ludzie powinni być otwarci, gotowi do rozmowy, uczenia się od siebie nawzajem. Przestrzeń na autorefleksję jest tu niezbędna. Bez tych elementów trudno o dobrą retrospektywę.

 

Sposoby prowadzenia retrospektywy

W IT istnieje mnóstwo sposobów na przeprowadzenie retrospektywy. Schematów są dosłownie dziesiątki.

Najczęściej retrospektywa odbywa się regularnie — jeśli zespół pracuje w trybie zadaniowym, to raz na tydzień albo raz na dwa tygodnie. Spotkania są więc dość częste. I kiedy po roku mamy już kilkadziesiąt retrospektyw za sobą, pytania typu „co poszło dobrze?” i „co mogło pójść lepiej?” zaczynają się powtarzać i trochę nudzić.

Dlatego facylitatorzy w IT wymyślili dziesiątki sposobów, jak uatrakcyjnić retrospektywę, żeby nie popaść w rutynę i schematy. Chodzi o to, by naprawdę dotrzeć głębiej — do tego, co jest pod spodem — a nie tylko odhaczać kolejne spotkanie.

 

Start, Stop, Change, Continue

Na początek warto skorzystać z bardzo prostej metody Start–Stop–Continue. Polega ona na tym, że zastanawiamy się:

  • czego nam brakuje i co powinniśmy zacząć robić (start),
  • co robimy źle albo czego w ogóle nie powinniśmy robić i trzeba to zakończyć lub zmienić (stop),
  • oraz co robimy dobrze — czyli takie poklepanie się po plecach, wzmocnienie tego, co już działa (continue).

Czasem używa się też wariantu Start–Stop–Change–Continue — istnieje wiele odmian tej matrycy.

Gdy zespół nabierze wprawy, warto urozmaicić formę, żeby się nie znudziła. Można sięgnąć po analogie. Na przykład: spotykamy się w sali albo online na tablicy Miro i rysujemy żaglowiec. Potem zastanawiamy się:

  • co było wiatrem w żagle i wypisujemy to na karteczkach,
  • co było kotwicą, która nas hamowała,
  • co było balastem, którego trzeba się pozbyć, bo przeszkadza,
  • a czego zabrakło w naszej misji.

Takie obrazy i metafory bardzo ożywiają retrospektywę.

 

Technika rakiety z paliwem

Możemy pytać: co było moim paliwem, że leciałem szybko? Co było tym tarciem, które sprawiało, że się nagrzewałem, denerwowałem i miałem silne emocje? Czego zabrakło mi na mojej „misji na Marsa”? Co bym zabrał następnym razem? Pomysłów i wariantów jest naprawdę mnóstwo.

Bardzo ciekawa jest też metoda, która pozwala wyjść poza procesy, usprawnienia i narzędzia. Bo to jest pierwszy, najłatwiejszy aspekt do omówienia. Ale jest też drugi, miękki — dotyczący relacji, współpracy i emocji. O tym mówi się trudniej, zwłaszcza w zespołach technicznych.

Żeby to ułatwić, stosuje się np. metodę Mad–Sad–Glad. Polega ona na tym, że zespół omawia emocje związane z zakończeniem cyklu pracy czy projektu, odpowiadając na pytania:

  • co sprawiło, że czułem się wściekły (mad),
  • co sprawiło, że byłem smutny (sad),
  • a co sprawiło, że byłem zadowolony i miałem poczucie satysfakcji (glad).

Czyli ta technika pozwala nie tylko identyfikować obszary do poprawy, ale też rozpocząć rozmowę o emocjach, a to wcale nie jest łatwe.

 

Retrospektywa jako game changer – case study

Oczywiście istnieje też całkiem sporo problemów, których zespół nie jest w stanie rozwiązać samodzielnie. Po prostu nie ma takiej siły przebicia w organizacji — szczególnie w dużych korporacjach.

Udało nam się jednak przeprowadzić jedną naprawdę dużą zmianę, która była prawdziwym game changerem. Problem dotyczył współpracy z innym zespołem, który musiał akceptować nasze rozwiązania. Moi programiści tworzyli oprogramowanie, fragment kodu, ale musiało ono zostać zatwierdzone w innym zespole — pod kątem zgodności z architekturą, normami i standardami.

Te akceptacje trwały wieki: drobne rzeczy leżały tygodniami, a większe — miesiącami. W IT to prawdziwa tragedia. Zamiast dostarczać wartość regularnie, co kilka tygodni, a najlepiej codziennie (bo są firmy, które mają taki proces i codziennie wdrażają coś nowego), u nas wszystko potrafiło utknąć na długie miesiące. To było niezwykle frustrujące.

Oczywiście, kiedy ktoś patrzył z boku — od strony biznesu — to widział tylko tyle, że „zespół nie dostarcza”, więc całe ciśnienie spadało właśnie na nas.

 

Identyfikacja problemu

Zespół jednak bardzo dobrze zidentyfikował problem. Przygotował twarde dane i konkrety: opisał trudności we współpracy, pokazał, jak wpływają one na efektywność, dodał zrzuty ekranu z systemu, na których było widać przesuwające się zadania i miejsca przestojów. Mieliśmy naprawdę solidny materiał merytoryczny.

Z tym pakietem poszedłem wyżej — właściwie na poziom zarządu, do osoby, która tymczasowo w nim zasiadała. Firma była wtedy w zmianie, a ta osoba miała dużą siłę oddziaływania. Gdy zobaczyła dane, dosłownie zrobiła duże oczy. Omówiliśmy propozycje i udało się przeprowadzić znaczącą zmianę.

Firma przez kilkanaście lat działała według schematu „zawsze tak pracujemy”. Tymczasem my doprowadziliśmy do tego, że mogliśmy wydelegować jedną osobę z naszego zespołu do współpracującego działu. Ta osoba została przeszkolona w sprawdzaniu zmian w oprogramowaniu i mogła je akceptować. Innymi słowy: ktoś od nas, po odpowiednim przygotowaniu, zatwierdzał zmiany naszego zespołu. To ogromnie usprawniło pracę.

Ale — i to warto podkreślić — retrospektywa polega na tym, że nieustannie coś usprawniamy. Bo im większa firma, tym więcej problemów. A w dużych korporacjach naprawdę ich nie brakuje.

Okazało się jednak, że ta jedna osoba szybko się „zakorkowała”, bo wszystkie zmiany trafiały właśnie do niej. Na kolejnych retrospektywach najpierw było zadowolenie, że udało się przeprowadzić zmianę, ale zaraz pojawił się nowy problem — nadmiar pracy skoncentrowany w jednym miejscu.

 

Rozwiązanie

Rozwiązaliśmy to tak, że poszliśmy za ciosem i kolejne osoby w zespole również dostały możliwość akceptacji zmian w oprogramowaniu. Docelowo prawie połowa zespołu miała już takie uprawnienia i mogła nawzajem zatwierdzać swoje prace.

Dzięki temu problem został rozwiązany:

  • nie było już długiego czekania,

  • jakość została zachowana, bo osoby te były jednocześnie włączone w prace zespołu akceptującego i znały techniki, sposoby oraz standardy.

Oczywiście wymagało to od nas dodatkowego wysiłku. Trzeba było nauczyć się nowych rzeczy i wziąć na siebie większą odpowiedzialność.

Ten przykład pokazuje, że z jednej strony menedżer może pomóc tam, gdzie rzeczywiście jest taka potrzeba, a z drugiej — że potrzebny jest również wysiłek samego zespołu.

Właśnie takie połączenie realnie usprawniło pracę naszego działu, a w konsekwencji całej firmy. Był to jeden z naszych większych sukcesów. Retrospektywa, inicjatywa oddolna, doprowadziła do zmiany, która wcześniej wydawała się wręcz niemożliwa. Inne zespoły patrzyły na nas z zazdrością i pytały: „Jak wam się to udało? My próbowaliśmy od lat!”. A my zaczęliśmy po prostu od retrospektywy. Z czasem zmiana rozprzestrzeniła się dalej w organizacji.

 

Co zrobić, żeby retrospektywa się udała?

 

Ustalić tematy

Dobrze jest ustalić tematy do omówienia jeszcze przed spotkaniem. My zbieraliśmy je na bieżąco, w trakcie pracy. Pracowaliśmy w dwutygodniowych cyklach i jeśli pojawiał się jakiś temat, to nie rozmawialiśmy o nim od razu — oczywiście wyjątkiem były kwestie naprawdę pilne.

Trzeba pamiętać, że retrospektywa to czas na refleksję. To moment, żeby się zatrzymać, a nie załatwiać coś w biegu. Dzięki temu możemy spokojnie się zastanowić, zamiast potraktować temat powierzchownie.

Żeby nic nie umknęło, a jednocześnie żeby nie odkładać wszystkiego na później, mieliśmy wyznaczone miejsce, w którym każdy mógł zapisać sprawę, jaką chciałby poruszyć na retrospektywie. W ten sposób, w ciągu dwóch tygodni, lista tematów sama się zbierała. Kiedy przychodził czas retrospektywy, mieliśmy już gotowy zestaw do przegadania.

Standardowy problem, który pewnie pojawi się w wielu zespołach, to zbyt duża liczba tematów. Tych zagadnień jest zawsze dużo, a czasu wiadomo — nie poświęcimy całego dnia na rozmowę o tym, jak nam poszło. Jeden dzień w tygodniu tylko na retrospektywę to stanowczo za dużo.

 

Określić priorytety

Drugi element to więc ustalenie priorytetów. Skoro mamy listę tematów, trzeba zdecydować, które są najważniejsze. Tyle że mnie boli jedno, kogoś innego coś zupełnie innego. Jak więc ustalić, co jest priorytetem — dla zespołu i dla firmy?

Istnieje kilka metod:

  • każdy członek zespołu dostaje 3–5 punktów i rozdziela je według uznania na dowolne tematy czy problemy,
  • można wprowadzić zasadę, że nie głosujemy na własny problem, żeby uniknąć sytuacji „każdy głosuje na swoje”,
  • można też poprosić o wsparcie facylitatora, który pomoże ustalić priorytety,
  • a w niektórych przypadkach warto zasięgnąć opinii menedżera — nie po to, by on decydował, ale by wskazał, co z perspektywy firmy czy szerszej strategii jest najważniejsze do rozwiązania.

Menedżer nie jest więc „wyłączony” z procesu. Może nas wspierać, podpowiadając, co jest istotne z punktu widzenia całej organizacji.

 

Ustalić limity

Trzecia rzecz to ustalenie, ile tematów jesteśmy w stanie omówić podczas jednej retrospektywy.

Jeśli na liście mamy np. 15 punktów, to wiadomo, że nie wszystkie da się „przemielić”. Realnie jesteśmy w stanie dogłębnie przepracować 2–3 tematy, a jeśli pojawi się naprawdę duży wątek, to czasem tylko jeden. Dlatego trzeba wybierać mądrze.

Pozostałe sprawy przechodzą na kolejną retrospektywę. Zdarza się jednak, że lista takich „ogonów” zaczyna rosnąć. Jeśli przez 3–4 spotkania z rzędu jakiś temat w ogóle nie zostaje poruszony, warto zadać sobie pytanie: czy on naprawdę jest istotny? Być może problem istnieje, ale mamy ważniejsze i pilniejsze kwestie, a tamtym nie opłaca się już zajmować.

Tak powstaje lista spraw odkładanych na „święte nigdy”.

 

Mastermindy vs. retrospektywa

Coraz częściej widzę punkty wspólne między retrospektywą a mastermindem. Oczywiście są różnice: w retrospektywie zespół, który na co dzień ze sobą pracuje, robi przegląd swoich działań. W mastermindzie częściej spotyka się grupa osób bardziej od siebie niezależnych, ale także z pewną regularnością.

W obu przypadkach kluczowe są regularność i nawyk rozmowy o swoich wyzwaniach oraz wspólne poszukiwanie rozwiązań — takim „zbiorowym umysłem”. To spotkania oparte na dużej otwartości i zorientowaniu na rozwiązania (solution focus). Oba formaty kończą się również konkretnymi action itemami, z których na kolejnym spotkaniu znowu trzeba się rozliczyć.

Jest tu naprawdę wiele podobnych mechanizmów. Choćby ten, o którym mówiliśmy wcześniej: że jedni mówią za dużo i dominują rozmowę, a inni za mało — dlatego trzeba to jakoś moderować. Nasi klienci często pytają, jak prowadzimy mastermindy, bo sami nie chcą wchodzić w bezpośrednie konfrontacje, w których jedna osoba zabiera cały „czas antenowy”, a inni nie dostają przestrzeni. To dokładnie ten sam mechanizm, który działa na retrospektywie.

Świetnie widać tu także empowerment uczestników oraz uczenie się przez praktykę — postawę reflective practitioner. To bardzo mi się podoba, bo prowadzi nas w stronę, w której sami uczymy się zakasać rękawy, pomyśleć o swojej pracy i zrobić kolejne kroki do przodu.

 

Retro o retro i rola facylitatora

Na koniec chciałbym wspomnieć jeszcze o jednym elemencie: retro o retro. Warto poświęcić ostatnie 5 minut spotkania na krótką refleksję: co w tej retrospektywie poszło dobrze, a co chcielibyśmy zmienić w samej strukturze pracy nad retrospektywą.

To prosty sposób, by stale udoskonalać także ten proces.

Rola facylitatora jest tutaj szczególnie istotna. Na początku retrospektywa wymaga facylitacji — po to, żeby zespół nauczył się, jak pracować w tej formule, zrozumiał, o co w niej chodzi, przyswoił pewne schematy i wyrobił praktykę.

Jeśli w organizacji brakuje takich doświadczeń, warto zaprosić facylitatora z zewnątrz, przynajmniej na kilka pierwszych spotkań. Osoba, która prowadzi mastermindy, będzie świetnym facylitatorem również w retrospektywie, bo rozumie, jak moderować dyskusję i zapewnić wszystkim głos w procesie.

Wszystkie problemy związane z prowadzeniem otwartej dyskusji w zespole powtarzają się niezależnie od formatu — czy to mastermind, retrospektywa, burza mózgów czy jakiekolwiek inne spotkanie. Dlatego kompetencje facylitacyjne są naprawdę potrzebne.

Kiedy jednak zespół się już „rozgrzeje”, przeprowadzi kilka czy kilkanaście retrospektyw i wie, o co w nich chodzi, można radzić sobie samodzielnie. Wtedy dobrze jest, aby retrospektywę prowadziła osoba neutralna.

Może to być ktoś z zespołu — osoba ciesząca się szacunkiem, często senior, który potrafi zbalansować różne głosy i perspektywy. Dobrym rozwiązaniem jest także „pożyczenie” facylitatora z innego zespołu. Taka osoba nie jest uwikłana w wewnętrzne zależności („z tym się bardziej trzymam, tego bardziej przyciszę”), więc łatwiej jej zachować neutralność.

Można się też odwdzięczyć: ktoś z naszego zespołu w zamian pójdzie i poprowadzi retrospektywę u kolegów. To proste, a jednocześnie bardzo skuteczne rozwiązanie.

 

Samodzielna retrospektywa

Może być też tak, że zespół zdecyduje się samodzielnie prowadzić retrospektywę, ustalając na początku, kto tym razem pełni rolę facylitatora. Takie rozwiązanie praktykowaliśmy w moich zespołach. Najczęściej prowadziła ta sama osoba, ale jeśli pojawiał się poważny temat mocno związany z facylitatorem, mógł on powiedzieć: „Dziś nie prowadzę, bo jestem zbyt zaangażowany w ten problem i mogę być nieobiektywny”. Wtedy ktoś inny z zespołu przejmował prowadzenie.

Dzięki temu osoba, która miała „swój temat na stole”, mogła uczestniczyć w spotkaniu w pełni jako członek zespołu, bez konieczności łączenia dwóch ról naraz. To ważne, bo bycie jednocześnie facylitatorem i aktywnym uczestnikiem dyskusji jest trudne i wymaga noszenia „dwóch kapeluszy”.

Dlatego dobrze jest pamiętać, że facylitator w pewnym sensie jest wyłączony z pracy zespołu podczas retrospektywy. Z tego powodu warto mieć kogoś neutralnego — chociażby osobę z innego zespołu — aby każdy mógł skupić się na uczestniczeniu w rozmowie.

 

Jednorazowe czy cykliczne spotkanie podczas retrospektywy

Bardzo ważne jest, aby retrospektywa była cykliczna i regularna. To nie jest jednorazowe wydarzenie.

Jeżeli pracujemy w trybie ciągłym, zadaniowym, retrospektywa powinna odbywać się raz w tygodniu albo raz na dwa tygodnie. Najrzadziej raz w miesiącu, ale to już bywa zbyt rzadko. Miesięczne spotkanie potrafi wtedy trwać nawet pół dnia, bo gromadzi się zbyt wiele tematów. Lepiej więc krócej, a częściej.

Przy pracy, w której dzieje się naprawdę dużo, wystarczy godzina lub dwie w piątek — po lunchu, na zakończenie tygodnia. To działa jak podsumowanie i klamra spinająca cały cykl.

Oczywiście zawsze będzie nas gonić „bieżączka”. Czujemy presję realizacji zadań, ale — jak mówisz — żeby nie biegać z pustymi taczkami, trzeba się zastanowić, jak je sprytniej załadować i pracować efektywniej. Temu właśnie służy retrospektywa.

To moment, by odpowiedzieć sobie na pytania:

  • jak mogę zwiększyć efektywność swojej pracy i pracy zespołu,
  • co mi przeszkadza,
  • co mnie wstrzymuje przed wejściem na wyższy poziom.

To absolutnie niezbędny element. Trzeba na niego znaleźć czas — dosłownie wyrąbać go w kalendarzu i konsekwentnie się go trzymać.

 

Retrospektywa poza biurem

Na zakończenie jeszcze jedna podpowiedź: gdy zespół jest już dobrze zgrany i ma wprawę w retrospektywach, świetnie działa wyjście poza biuro.

Retrospektywa nie musi odbywać się przy tablicy w sali konferencyjnej. Można pójść razem na lunch, w piątek skończyć pracę trochę wcześniej i wyjść całą ekipą na piwo, żeby tam porozmawiać o tym, co działało, a co nie. Struktura spotkania pozostaje, ale zmienia się kontekst — a to robi różnicę.

Poza biurem łatwiej otworzyć się na tematy interpersonalne. Często właśnie przy piwie udaje się rozwiązać konflikty, które w biurze wydają się nierozwiązywalne.

 

 

Dziękuję!

 

 

Photo by Priscilla Du Preez 🇨🇦 on Unsplash

Img
Nie przegap nowych treści! Bądź zawsze O Krok Do Przodu
Zapisz się na mój newsletter i otrzymuj powiadomienia o nowych artykułach i podcastach. Nie zapomnij potwierdzić subskrypcji klikając w maila, którego ode mnie dostaniesz - dopiero wtedy naprawdę znajdziesz się wśród odbiorców :-)

Skomentuj podcast

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*