Improwizacja dla zespołów IT i agile – czym jest i kiedy działa?

Improwizacja dla zespołów IT trenuje zachowania, od których zależy, czy agile działa na ludziach, a nie tylko na tablicy: mówienie na głos, że czegoś nie wiemy lub nie zdążymy, przyjmowanie cudzego pomysłu zanim go ocenimy, reagowanie na zmianę planu. Najmocniejsze dowody dotyczą bezpieczeństwa psychologicznego w zespołach i pracy zdalnej, a nie samej improwizacji. Czy warsztaty impro zmieniają metryki zespołów IT (prędkość, liczbę defektów), nie zostało zbadane. Nie znalazłem takiego badania.

autor: Michał Mącznik

Czas czytania: 18 min

Zaktualizowano: październik 2026

SPIS TREŚCI

Zespół złożony z samych kompetentnych ludzi potrafi przez pół roku nie powiedzieć na głos jednego zdania: „nie rozumiem tego”. Retrospektywa kończy się listą „co poszło dobrze”. Estymata na planningu ląduje gdzieś pomiędzy tym, co ktoś naprawdę myśli, a tym, co wypada powiedzieć przy seniorze.

Agile zakłada rozmowę: planning, daily, review, retrospektywa. To cztery regularne okazje, żeby powiedzieć coś na głos. Ktoś, kto pisze świetny kod, nie zawsze ma równie dobry sposób, żeby w rozmowie powiedzieć „to nie zadziała”. Ten tekst sprawdza, czy improwizacja w tym pomaga i co o tym naprawdę wiadomo.

DEFINICJA

Improwizacja dla zespołów IT i agile to warsztaty, na których zespół ćwiczy zachowania komunikacyjne z improwizacji teatralnej (przyjmowanie cudzej propozycji i budowanie na niej, mówienie o niepewności, reagowanie na to, czego nie dało się przewidzieć) na materiale z codziennych sytuacji w pracy: planningu, code review, retrospektywy, demo. To nie jest team building ani szkolenie z metodyki. Nie uczy procesu, tylko rozmowy w procesie.

Pierwsza odpowiedź jest prosta: praca w IT odbywa się w ciągłej niepewności. Wymagania się zmieniają, szacunki bywają zgadywaniem, a najważniejsze informacje o ryzyku mają zwykle osoby, które najmniej głośno mówią. Do tego zespoły często pracują rozproszone i przez kamerę.

Druga odpowiedź jest mniej wygodna. Badań nad improwizacją w zespołach IT właściwie nie ma. Największy przegląd badań o applied improv na uczelniach (54 prace z lat 1999–2024) pokazuje, że 85,2% z nich dotyczyło studentów, a 61,1% edukacji medycznej. Zespoły programistyczne tam po prostu nie występują. Dowody, które tu zbieram, pochodzą z dwóch miejsc: z badań nad zespołami w ogóle (głównie nad bezpieczeństwem psychologicznym) oraz z badań nad samym treningiem improwizacji na dorosłych i studentach.

To nie jest powód, żeby odpuścić temat. To powód, żeby czytać dalej ostrożnie i oddzielać to, co udowodnione, od tego, co rozsądne.

Zanim zapytasz, czy warsztat działa, odpowiedz na pytanie „na co”. W zespołach IT warto wskazać trzy zachowania.

Ktoś widzi, że termin jest nierealny, że architektura ma dziurę albo że nie rozumie zadania. Wie o tym od tygodnia. Nie mówi. To nie jest brak odwagi w sensie charakteru. To rachunek: co mnie to kosztuje, a co zyskam. Zmiana polega na tym, żeby koszt mówienia był niski.

W design review i code review pierwszą reakcją bywa „tak, ale” albo „to się nie sprawdzi”. Improwizatorzy ćwiczą odwrotną kolejność: najpierw „tak, i…”, czyli zbudowanie na tym, co ktoś zaproponował, a potem ocena. Nie chodzi o to, żeby przestać krytykować, tylko o to, żeby krytyka przychodziła po zrozumieniu.

Sprint idzie jednym torem, w środku pojawia się incydent albo klient zmienia priorytet. Zespół, który ćwiczy reagowanie na niespodziankę, ma szansę zrobić to szybciej niż zespół, który ćwiczy tylko plan.

Wszystkie trzy mają wspólny mianownik: małe ryzyko interpersonalne wykonane publicznie i bez kary. To właśnie nazywa się bezpieczeństwem psychologicznym.

Wniosek: to najlepiej udokumentowany fragment całej układanki. Zastrzeżenie: badania nie dotyczą specjalnie zespołów IT, a Edmondson badała zespoły w firmie produkcyjnej. Nie ma powodu sądzić, że programiści będą działać inaczej, ale trzeba pamiętać, że to przeniesienie.

Ten wynik ma konsekwencję dla code review. Zespół, który mówi „bądźmy bardziej bezpośredni w review”, bez zadbania o bezpieczeństwo, może dostać nie lepszą krytykę, tylko gorszy klimat. Dodatkowo eksperymenty Foulk i współpracowników (2016) pokazują, że nawet drobna nieuprzejmość „zaraża”: jedno doświadczenie niegrzeczności sprawia, że odbiorca częściej widzi ją u innych i sam jest mniej uprzejmy wobec następnych osób. Wyniki pochodzą z eksperymentów i badań laboratoryjnych, nie z zespołów programistycznych, a jedna grupa badawcza stoi za całą serią. Porath i współautorzy (2015) w artykule przeglądowym dla praktyków opisują mechanizm: rozpamiętywanie przykrych uwag zajmuje pamięć roboczą. Ta praca to synteza własnych badań autorów, nie samodzielny dowód.

Co z tego wynika: hipoteza, że sposób formułowania uwag w review wpływa na to, czy ludzie w ogóle będą się odzywać, jest rozsądna i ma oparcie. Bezpośrednich badań na zespołach IT nie znalazłem.

Przełożenie na zespół programistyczny to hipoteza: różnica między seniorem a juniorem albo między architektem a resztą zespołu działa podobnie jak różnica między lekarzem a pielęgniarką. Brzmi sensownie, ale jej nie zmierzono.

Jest też wynik dotyczący liderów, który warto znać. W badaniu Granta, Gino i Hofmanna (2011) (dwa eksperymenty laboratoryjne i badanie 130 zespołów franczyzy pizzerii) introwertyczni liderzy osiągali około 20% lepsze wyniki niż ekstrawertyczni, gdy członkowie zespołu byli proaktywni. To nie badanie o IT, ale pokazuje, że styl prowadzenia i aktywność zespołu zależą od siebie. Zob. też improwizacja dla introwertyków.

Uwaga, bo ten wynik łatwo źle zrozumieć. Vera i Crossan piszą o improwizacji jako sposobie pracy zespołu (działanie bez gotowego scenariusza), nie o szkoleniu z improwizacji teatralnej. Wniosek dla nas: ćwiczenie impro może pomóc, ale nie zastępuje wiedzy, bezpieczeństwa i regularnej praktyki.

Dwa eksperymenty z losowym przydziałem (74 i 131 osób, głównie studenci; Felsman i in. 2020) pokazały, że po sesji improwizacji uczestnicy lepiej wypadali w myśleniu dywergentnym i mieli wyższą tolerancję niepewności oraz lepszy nastrój. W sześciotygodniowym badaniu z losowaniem na 58 dorosłych (Schwenke i in. 2020) trening podniósł kreatywność i poczucie własnej skuteczności, ale nie podniósł akceptacji emocjonalnej ani uważności.

Wniosek: wiemy coś o efekcie, który można zmierzyć w tygodnie. Nie wiemy, jak długo trwa, i czy przekłada się na pracę w zespole.

To jedyny obszar, w którym dowody są mocne i bezpośrednio dotyczą codzienności zespołów IT.

Co z tego wynika: zespół rozproszony powinien projektować rozmowę inaczej niż zespół w jednym biurze. Burza mózgów na kamerze daje mniej pomysłów, a przy decyzjach różnica jest mniejsza. Polityka „kamery zawsze włączone” brzmi neutralnie, ale w badaniu systematycznie wyciszała część zespołu.

Nie mamy badania, które sprawdziłoby warsztaty improwizacji na zespołach IT, ale pośrednio widać, że elementy, z których korzysta improwizacja, mogą pomagać. Bezpieczeństwo psychologiczne, czyli możliwość zgłoszenia wątpliwości bez kary, wiąże się z uczeniem się zespołu i jego wynikami. Spór o treść poprawia wyniki tylko tam, gdzie jest bezpiecznie. Status tłumi głos, a włączający lider go odblokowuje. Krótkie treningi improwizacji podnosiły u dorosłych kreatywność i tolerancję niepewności. Wszystko to dotyczy zachowań, które improwizacja ćwiczy: robienia małego ryzyka publicznie i bez kary, budowania na cudzym pomyśle przed jego oceną i wyrównywania głosów w grupie. Improwizacja zespołowa sprzyja też innowacji, ale pod warunkami: bezpieczeństwie, wiedzy i treningu (Vera i Crossan 2005).

To jednak cegiełki, nie gotowy dowód. Żadne z tych badań nie sprawdzało, czy warsztat poprawia pracę zespołu programistów, więc traktuj ten wniosek jako dobrze uzasadnioną hipotezę, nie wynik pomiaru.

Pełny opis mechanizmów (małe ryzyko, akceptacja propozycji, uwaga na zewnątrz, wyrównanie statusu) jest w tekście Team building z improwizacją. Tu tylko to, co dotyczy IT.

Warsztat daje zespołowi okazję, żeby wspólnie popełnić drobną pomyłkę i zobaczyć, że nic się nie stało. W improwizacji pomyłka jest regułą, a nie wypadkiem. Na moich zajęciach obowiązuje ukłon cyrkowy: kto się pomyli, podnosi ręce i woła „Teee-Reeee!”, cała grupa odpowiada tym samym. Odruch wstydu dostaje inne zachowanie do wykonania. Czy to przekłada się na wyższe bezpieczeństwo w zespole, nie wiem. Wiem, że zaczyna się od zmiany tego, co ludzie robią po pomyłce.

Ćwiczenie „Tak, i…” zmusza do zbudowania na cudzym pomyśle, zanim się go oceni. To prosty trik na odruch „tak, ale”. Zob. Zasada Tak, i… i Blokowanie.

Z kolei uwaga skierowana na partnera, a nie na własny występ, to mechanizm, który ćwiczysz w każdym ćwiczeniu. Przekłada się na daily, w którym ktoś rzeczywiście słucha, co powiedział kolega, zamiast przygotowywać własne „wczoraj zrobiłem”. Zob. Uptime.

Poniżej propozycje projektowe, jak ćwiczenie przekłada się na ceremonię. Nie są wynikami badań. To sposób, w jaki sam bym zaczynał rozmowę o warsztacie.

Tu ćwiczy się tolerancję niepewności: szacowanie bez pewności, że szacunek będzie dobry. Siedem Rzeczy (siedem elementów kategorii w mniej niż dziesięć sekund) uczy, że pierwsza odpowiedź jest wystarczająca jako punkt wyjścia. Ćwiczenie „Tak, i…” na rozwijaniu historyjki użytkownika uczy budować, zanim się wytnie.

Ćwiczy się uwagę. Zamiast czekać na swoją kolej, słuchasz, co zgłasza kolega. Jeden z możliwych wariantów: każdy zaczyna od nawiązania do jednego słowa z wypowiedzi poprzednika.

Przeformułowanie reakcji: „tak, i…” przed „ale”. Przykład: zamiast „To się nie skaluje” powiedzieć „Tak, i zastanawiam się, co się stanie przy dziesięciokrotnie większym ruchu”. Różnica nie jest kosmetyczna. Pierwsze zdanie zamyka, drugie otwiera.

To tu bezpieczeństwo psychologiczne jest najbardziej widoczne i najłatwiej je zepsuć. Ukłon cyrkowy i Fail Celebration (każdy opowiada o swojej największej „wtopie” tygodnia, a grupa świętuje) zmieniają to, co ludzie robią z pomyłką, zanim zaczną o niej mówić na retro.

Trzeba umieć powiedzieć coś zrozumiale na żywo, kiedy ktoś zadaje pytanie spoza scenariusza. Ćwiczy się pauzę i opowiadanie prostym językiem. Zob. Jak brzmi status? Co badania mówią o głosie, tempie i pauzach.

Poniższe opinie pochodzą od osób z IT, które przeszły Warsztaty Praktycznej Improwizacji (kurs otwarty, nie warsztat zespołowy). To nie dowód skuteczności, tylko to, co ludzie sami opisują.

„Nauczyłem się nie tylko podstaw improwizacji, ale też większego luzu, spontaniczności i przyciszenia Wewnętrznego Cenzora.” — Piotrek Drabicki, informatyk, WPI-51

„Pomagają wyzwolić się z wewnętrznych blokad, otwierają na nowe rzeczy, uczą akceptować błędy.” — Dawid, manager w IT, WPI-40

Więcej w tekście Improwizacja dla programistów na blogu.

Z badań o bezpieczeństwie wynika jedna praktyczna rzecz: to, co robi lider, znaczy więcej niż to, co robi warsztat. Nembhard i Edmondson (2006) pokazały, że „włączający” lider, który słowem i gestem zaprasza cudzy głos, rozbraja bariery statusu. W zespole IT liderem w tym sensie bywa nie tylko menedżer, ale też tech lead, senior albo architekt, czyli osoba, której zdanie waży najwięcej.

Trzy zachowania, które można ćwiczyć. Pierwsze ma bezpośrednie oparcie w tym badaniu: zaproszenie cudzego głosu, na przykład pytaniem „co widzisz, czego ja nie widzę?”. Dwa kolejne to moje propozycje wynikające z logiki tego wyniku, nie zmierzone w nim: senior, który mówi „nie wiem, sprawdźmy”, oraz reakcja na złą wiadomość od podziękowania za zgłoszenie, zanim padnie pytanie, kto zawinił.

Wniosek dla warsztatu: jeśli liderzy nie ćwiczą razem z zespołem, a po warsztacie zachowują się jak przed nim, to reszta uczy się, że ryzyko dotyczy tylko jej.

Dowody z sekcji 3 prowadzą do kilku praktycznych wniosków, niezależnie od tego, czy zespół zrobi kiedykolwiek warsztat improwizacji.

Do generowania pomysłów warto spotkać się fizycznie albo wyłączyć kamery, a do wyboru najlepszego z nich wystarczy wideo (Brucks i Levav 2022). Opóźnienie przejęcia głosu przez Zoom jest ponad trzykrotnie dłuższe niż lokalnie (Boland i in. 2022), więc cisza po pytaniu na wideo nie znaczy tego samego co w biurze: przy dłuższym przejściu między osobami łatwo przerwać komuś albo uznać, że nikt nie ma nic do dodania. Wymuszanie włączonej kamery kosztuje zmęczenie i mniej głosu, i to nierównomiernie (Shockley i in. 2021). To argument, żeby polityka kamery była wyborem, a nie obowiązkiem.

Improwizacja online jest możliwa: w badaniu na studentach medycyny trening przez Zoom poprawił empatię (Amjadi i in. 2024), ale tam efekt mierzono u studentów, nie w zespołach pracujących.

Nie każdy moment jest równie dobry na warsztat. Dwa badania dają wskazówki, ale to wskazówki, nie reguła.

Gersick (1988) obserwowała osiem zespołów projektowych przez cały cykl życia i pokazała, że zespoły nie idą liniowo przez „etapy rozwoju”. Trwają w ustalonym sposobie pracy, a potem gwałtownie przeorganizowują się mniej więcej w połowie drogi do terminu. Zmianę napędza świadomość czasu, nie „dojrzałość” grupy. To badanie jakościowe na ośmiu zespołach, nie tylko z IT, więc nie przenosi się wprost na sprinty.

Harrison i współpracownicy (2003) porównywali w cotygodniowych sesjach różne typy zespołów. Zespoły złożone z początkowo obcych sobie osób, ale kontynuujące ten sam skład, dogoniły zespoły znajomych, a zespoły jednorazowe, z innym składem za każdym razem, były konsekwentnie wolniejsze i słabszej jakości. Stały skład okazał się ważniejszy niż częstotliwość spotkań.

Z tego wyprowadzam trzy hipotezy, żadnej nie sprawdzono w badaniu warsztatów. Po pierwsze, warsztat dla zespołu w stałym składzie ma więcej sensu niż jednorazowa integracja ludzi, którzy za miesiąc będą w innych zespołach. Po drugie, moment bliski połowie projektu, kiedy zespół i tak ocenia, co robi, może być dobry na refleksję nad sposobem pracy. Po trzecie, warsztat na starcie projektu nie zastąpi czasu, którego zespół potrzebuje, żeby się poznać.

Ogólne pytania do dostawcy warsztatu są w tekście Team building z improwizacją. Dla zespołów IT dodatkowo:

1. Czy ćwiczenia odnoszą się do naszych ceremonii? Warsztat, który nie dotyka planningu, review i retro, zostaje w sali.
2. Czy prowadzący rozmawia z zespołem przed warsztatem? Bez trzech konkretnych sytuacji z waszej pracy warsztat jest ogólny.
3. Czy ktoś w zespole będzie musiał występować przed resztą? Dobrowolność ma znaczenie. Osoby z IT często wybierają mniej widoczne role i wymuszanie tego to zła pierwsza lekcja.
4. Jak wygląda sprawa z liderami? Jeśli lider nie weźmie udziału albo ocenia uczestników, bezpieczeństwo nie wzrośnie (Nembhard 2006).
5. Co po warsztacie? Jedno spotkanie nic nie utrwali. Zapytaj o plan na kolejne tygodnie.
6. Jak sprawdzimy, czy coś się zmieniło? Ankieta „czy się podobało” mierzy nastrój w piątek, nie zachowanie w poniedziałek.

• Warsztat jako nagroda lub kara. Zespół, który dostaje improwizację po kryzysie jako „ratunek”, odbiera ją inaczej niż zespół, który wybiera ją sam.

• Brak liderów w sali. Jeśli prowadzący zespołu nie ćwiczy razem z innymi, uczestnicy wnioskują, że ryzyko dotyczy tylko ich.

• Przełożenie jeden do jednego. „Tak, i…” nie znaczy „zgódź się na wszystko w review”. Znaczy: zrozum, zanim ocenisz.

• Mylenie bezpieczeństwa z miłą atmosferą. Bradley (2012) pokazuje, że bezpieczeństwo ma służyć sporowi o treść, a nie go zastępować.

• Obiecywanie wskaźników. „Zwiększy prędkość zespołu o 20%” to hasło, nie wynik badania.

• Ignorowanie kontekstu zdalnego. Ćwiczenia ruchowe w sali nie przenoszą się 1:1 na wideo.

Programy w badaniach nad improwizacją trwały od sześciu do dziesięciu tygodni. W IT nikt takiego programu nie przetestował, więc poniżej tylko moja propozycja, od której mógłbym zacząć rozmowę z zespołem.

• Tydzień 1: warsztat wprowadzający na materiale z waszych ceremonii. Ukłon cyrkowy jako reguła zespołu, „Tak, i…” w parach, jedna sytuacja z code review.
• Tygodnie 2–6: piętnaście minut na początku wybranej ceremonii, na przykład „Tak, i…” w refinemencie albo Fail Celebration na retro. Jedno ćwiczenie na tydzień.
• Tydzień 6: pomiar skali bezpieczeństwa psychologicznego i krótka rozmowa o tym, co zmieniło się w zachowaniach.
• Tygodnie 8–12: drugi warsztat na sytuacjach trudnych (zła wiadomość, incydent, spór o rozwiązanie), potem pomiar końcowy.

Zmierz przed i po. Dwie rzeczy są realistyczne.

• Ankieta bezpieczeństwa psychologicznego. Edmondson (1999) stworzyła krótką skalę siedmiu pozycji, która jest szeroko używana. Zrób ją przed warsztatem, po trzech tygodniach i po dwóch miesiącach.

• Zachowania. Policz, ile razy na planningu ktoś zgłosił ryzyko lub „nie wiem”. Sprawdź, czy w retro pojawiają się tematy, o których wcześniej nie mówiono. Zwróć uwagę, czy zmienił się ton uwag w review.

Jeśli możesz, porównaj z zespołem, który warsztatu jeszcze nie miał. Bez takiego porównania nie odróżnisz efektu zajęć od upływu czasu i od zmiany projektu.

Badania i źródła