Scrum Master na urlopie

Każdy Scrum Master zasługuje na urlop. Problem zaczyna się wtedy, gdy sam zespół uważa, że razem z wyjazdem Scrum Mastera wyjeżdża też porządek, rytm Sprintu, jakość rozmów i zdrowy rozsądek procesowy. To właśnie w takich momentach widać, czy Scrum w zespole naprawdę żyje, czy tylko był obsługiwany przez jedną osobę.

Temat nieobecności Scrum Mastera jest znacznie ważniejszy, niż na pierwszy rzut oka mogłoby się wydawać. Dla jednych zespołów będzie to zwykły, spokojny tydzień pracy. Dla innych może to być pierwszy prawdziwy test dojrzałości, samoorganizacji i odpowiedzialności za proces. W praktyce urlop Scrum Mastera działa trochę jak odstawienie stabilizatorów z roweru: jeśli zespół nauczył się utrzymywać równowagę, pojedzie dalej. Jeśli nie – chwiejność ujawni się bardzo szybko.

Dlatego dobrze przygotowany Scrum Master nie znika po prostu z kalendarza. Zanim wyjedzie, powinien świadomie przygotować zespół, ustalić zasady działania, zadbać o odpowiednie wsparcie i zostawić po sobie nie tylko plan spotkań, ale przede wszystkim warunki do dalszego uczenia się. Po powrocie zaś nie powinien pytać wyłącznie, „czy wszystko działało”, lecz raczej: „czego dowiedzieliśmy się o naszym zespole?”.

Ten wpis został napisany z myślą o publikacji blogowej i praktycznym wykorzystaniu przez Scrum Masterów, Agile Coachów, liderów zespołów oraz Product Ownerów. Znajdziesz tu rozróżnienie poziomów dojrzałości, konkretne zalecenia przed urlopem, sposób działania zespołu pod nieobecność Scrum Mastera, listę rzeczy do sprawdzenia po powrocie i zestaw checklist do skopiowania. Raz wspomnę też o RetroAppSuite.pl jako naturalnym miejscu do prowadzenia retrospektyw i zbierania obserwacji z takiego okresu.

Dlaczego urlop Scrum Mastera to ważny test

W wielu organizacjach Scrum Master pełni rolę znacznie szerszą, niż sugeruje sam framework. Facylituje wydarzenia, dba o przejrzystość, wspiera Product Ownera, pomaga rozwiązywać konflikty, pilnuje dyscypliny procesowej, a czasem nawet łagodzi napięcia między zespołem a interesariuszami. Jeśli przez dłuższy czas robi to za zespół, a nie z zespołem, jego chwilowa nieobecność zaczyna być odczuwana jak wyjęcie centralnego bezpiecznika.

Tymczasem zdrowy Scrum nie powinien działać wyłącznie dzięki jednej osobie. Scrum Master buduje zdolność zespołu do samodzielnego funkcjonowania. Uczy, facylituje, wzmacnia nawyki, redukuje zależności i wspiera samoorganizację. Z tej perspektywy urlop nie jest problemem operacyjnym. Jest lustrem. Pokazuje, ile z tych kompetencji zostało naprawdę w zespole.

To właśnie dlatego dobrze jest potraktować urlop Scrum Mastera nie jako ryzyko, lecz jako kontrolowany eksperyment. Eksperyment zaufania, odpowiedzialności i przejęcia procesu przez zespół. Im lepiej taki eksperyment zostanie przygotowany, tym większa wartość z niego wyniknie.

Dojrzałość zespołu ma znaczenie

Nie ma jednej uniwersalnej instrukcji dla wszystkich zespołów. To, co sprawdzi się przy zespole samoorganizującym się, może kompletnie nie zadziałać w zespole świeżo po wdrożeniu Scruma. Dlatego sensowne planowanie urlopu Scrum Mastera powinno być oparte na realnej dojrzałości zespołu, a nie na życzeniowym przekonaniu, że „już jakoś sobie poradzą”.

Zespół początkujący

To często zespół nowy, świeżo sformowany albo taki, który formalnie pracuje w Scrumie, ale w praktyce wciąż myśli kategoriami projektu, zadań przekazywanych odgórnie i statusowania. W takim zespole Scrum Master zwykle jest przewodnikiem po podstawach. Pilnuje, żeby Daily nie zamieniło się w raportowanie do menedżera, żeby Retrospektywa miała sens, żeby Sprint Goal nie był pustym sloganem, a Product Backlog nie stał się listą przypadkowych pomysłów.

Bez Scrum Mastera taki zespół ma skłonność do wracania do dawnych nawyków. Spotkania stają się krótsze, ale mniej wartościowe. Niewygodne tematy są odkładane. Trudniejsze decyzje czekają na czyjś powrót. Konflikty bywają zamiatane pod dywan, a impedimenty – ignorowane, bo nikt nie czuje się odpowiedzialny za ich nazwanie i eskalację.

Zespół rozwijający się

Taki zespół rozumie już ogólne zasady i potrafi je zastosować, ale nie zawsze robi to konsekwentnie. Gdy pracuje się spokojnie, proces działa dobrze. Problemy pojawiają się wtedy, gdy rośnie presja, pojawia się chaos priorytetów albo zewnętrzny nacisk na „szybsze dowiezienie”. Wtedy łatwo wrócić do skrótów, uproszczeń i starych schematów.

W takim zespole nieobecność Scrum Mastera może być bardzo wartościowa. To dobry moment, by sprawdzić, na ile zespół naprawdę potrafi przejąć odpowiedzialność za rytm pracy, facylitację spotkań i dbanie o jakość procesu, a na ile tylko dobrze funkcjonuje pod opieką doświadczonego Scrum Mastera.

Zespół dojrzały

Dojrzały zespół nie traktuje Scruma jako ceremonii wykonywanych dlatego, że ktoś o nich przypomniał. Rozumie sens wydarzeń, potrafi prowadzić rozmowy o procesie, wyciąga wnioski i wprowadza usprawnienia. W takim środowisku Scrum Master nie jest niezbędnym „operatorem Scruma”, tylko partnerem rozwojowym, który wzmacnia zespół i pomaga mu rosnąć.

Nieobecność Scrum Mastera nie powinna tu być dramatem. Może wręcz przynieść dodatkową wartość: wzmocnić wewnętrzne liderstwo, pokazać, że zespół potrafi sam się facylitować, i potwierdzić, że samoorganizacja nie kończy się wraz z opuszczeniem biura przez jedną osobę.

Co Scrum Master powinien zostawić przed urlopem

Największy błąd polega na założeniu, że skoro zespół jest „ogarnięty”, to nie trzeba nic ustalać. Nawet dojrzałe zespoły korzystają na jasności. Dobra praktyka polega nie na mikro-zarządzaniu nieobecnością, ale na świadomym ustawieniu warunków, w jakich zespół będzie działał bez Scrum Mastera.

Przed urlopem w zespole początkującym

Tutaj Scrum Master powinien zostawić konkret. Nie ogólne hasła typu „poradzicie sobie”, ale praktyczne, zrozumiałe punkty odniesienia. Chodzi nie o to, aby zespół działał jak robot według instrukcji, lecz o to, aby nie musiał tracić energii na zgadywanie podstaw.

• Harmonogram wydarzeń Scrumowych na cały okres urlopu.
• Jasną informację, kto facylituje Daily, Refinement, Review i Retrospektywę.
• Przypomnienie celu każdego wydarzenia, żeby spotkania nie zamieniły się w puste rytuały.
• Listę kontaktów awaryjnych oraz sposób eskalacji problemów.
• Krótki opis tego, czego zespół nie powinien robić pod nieobecność Scrum Mastera, np. rezygnować z Retrospektywy bez ważnego powodu.

Warto też przygotować prostą checklistę operacyjną. Taki dokument często działa lepiej niż wielostronicowy poradnik. Zespół początkujący potrzebuje punktów zaczepienia, nie elaboratu.

Przed urlopem w zespole rozwijającym się

W zespole rozwijającym się nacisk powinien być położony nie na instrukcję, ale na ramy i intencję. Scrum Master może świadomie powiedzieć: „to jest okazja, żebyście zobaczyli, jak prowadzicie proces bez mojego bieżącego wsparcia”. Takie postawienie sprawy buduje odpowiedzialność i poczucie partnerstwa.

• Ustal zasady minimalne: spotkania odbywają się, cel sprintu jest widoczny, impedimenty są nazywane.
• Wskaż, jakie eksperymenty zespół może zrobić samodzielnie, a jakich lepiej teraz nie zaczynać.
• Ustal, w jaki sposób zespół będzie zapisywać obserwacje z okresu nieobecności Scrum Mastera.
• Porozmawiaj z Product Ownerem o jego roli w utrzymaniu przejrzystości i decyzyjności.

To także dobry moment, żeby oddać część odpowiedzialności rotacyjnie. Niech jedna osoba facylituje Daily, inna zadba o zebranie wniosków z Retrospektywy, a ktoś jeszcze inny pilnuje przejrzystości tablicy i blokad. Taka rotacja rozwija zespół szerzej niż wyznaczenie jednego tymczasowego „zastępcy Scrum Mastera”.

Przed urlopem w zespole dojrzałym

W dojrzałym zespole lista rzeczy do zostawienia będzie najkrótsza, ale nie zerowa. Scrum Master powinien jasno zakomunikować termin nieobecności, sposób kontaktu w razie sytuacji krytycznej oraz wspólnie z zespołem ustalić, co chcecie sprawdzić w tym czasie. Taki zespół nie potrzebuje instrukcji. Potrzebuje świadomego uznania swojej sprawczości.

Można też zawczasu umówić się, że pierwsza Retrospektywa po powrocie będzie dotyczyła między innymi tego, jak wyglądała praca bez Scrum Mastera. Dzięki temu zespół wie, że obserwacje z tego czasu są ważne i że wrócicie do nich nie po to, by kogokolwiek rozliczać, ale by się uczyć.

Czy trzeba kogoś namaścić?

To jedno z częstszych pytań. Odpowiedź brzmi: czasem tak, ale nie zawsze. Największym ryzykiem nie jest brak formalnego zastępcy, tylko niejasność. Jeśli zespół nie wie, kto ma zadbać o ramy procesu, łatwo o rozmycie odpowiedzialności. Z drugiej strony zbyt szybkie namaszczanie jednej osoby może niechcący wytworzyć nową zależność i mini-hierarchię.

W zespole początkującym

Najczęściej warto wskazać jedną osobę odpowiedzialną za pilnowanie podstaw procesu. Nie jako pełnoprawnego zastępcę Scrum Mastera, ale raczej jako opiekuna rytmu. To może być senior developer, analityk z autorytetem, ktoś z naturalną skłonnością do porządkowania dyskusji. Taka osoba nie ma „rządzić”, tylko wspierać zespół w utrzymaniu ustaleń.

W zespole rozwijającym się

Lepiej zwykle sprawdza się odpowiedzialność współdzielona. Jedna osoba pilnuje kalendarza wydarzeń, inna facylituje Review, kolejna zbiera obserwacje z okresu urlopu. To buduje wieloosobową odpowiedzialność i zapobiega sytuacji, w której cały proces znowu zaczyna zależeć od jednej jednostki.

W zespole dojrzałym

Formalne namaszczenie często nie jest potrzebne. Zespół sam wie, kto naturalnie przejmie facylitację konkretnego spotkania lub kto sprawniej uporządkuje dyskusję, jeśli rozmowa zacznie się rozjeżdżać. Tutaj ważniejsze od wyznaczania lidera jest danie jasnego sygnału: „ufam wam, że potraficie to utrzymać”.

Jak zespół powinien działać bez Scrum Mastera

Nieobecność Scrum Mastera nie oznacza wakacji od Scruma. Jeśli zespół od razu rezygnuje z Daily, odkłada Retrospektywę albo zaczyna traktować Sprint Backlog jak luźną listę pomysłów, to znaczy, że nie zrozumiał sensu własnego procesu. Rolą Scrum Mastera nie jest bycie jedynym powodem, dla którego Scrum istnieje.

Zespół początkujący bez Scrum Mastera

Powinien przede wszystkim trzymać się ustalonego rytmu i nie komplikować sobie życia. To nie jest dobry moment na rewolucję, zmianę wszystkich praktyk czy spontaniczne skracanie wydarzeń, bo „i tak wiemy, o co chodzi”. Dla mniej dojrzałego zespołu stabilność jest wartością samą w sobie.

• Daily powinno odbywać się regularnie i służyć synchronizacji.
• Review powinno nadal pokazywać realny przyrost, a nie tylko opowiadać o wykonanych zadaniach.
• Retrospektywa powinna się odbyć nawet wtedy, gdy zespół czuje opór lub niepewność.
• Blokady i konflikty powinny być zapisywane, a nie przemilczane.

Największym błędem tego poziomu dojrzałości jest udawanie, że wszystko idzie świetnie, tylko po to, by „nie zrobić problemu” po powrocie Scrum Mastera. Dojrzałość zaczyna się tam, gdzie zespół potrafi nazwać trudność.

Zespół rozwijający się bez Scrum Mastera

Tu zespół powinien nie tylko utrzymać rytm, ale też uważnie obserwować, które elementy procesu działają lepiej lub gorzej bez stałej obecności Scrum Mastera. To może być znakomita okazja do sprawdzenia, czy Daily naprawdę służy zespołowi, jak wygląda wspólne podejmowanie decyzji i czy Product Owner jest wystarczająco dostępny.

Warto, by zespół w tym czasie prowadził krótkie notatki obserwacyjne. Co działało dobrze? Gdzie pojawiła się niepewność? Jakie zachowania pojawiły się naturalnie, a jakie zanikły bez facylitacji? Takie dane są znacznie cenniejsze niż ogólne stwierdzenie „było okej”.

Zespół dojrzały bez Scrum Mastera

Dojrzały zespół powinien działać normalnie, z jednym dodatkiem: świadomą autorefleksją. Taki zespół potrafi sam poprowadzić wydarzenia, sam zadbać o jakość rozmów, sam rozpoznać, że zaczyna skręcać w stronę nieproduktywnego zachowania. W praktyce oznacza to nie tylko dowożenie pracy, ale także pilnowanie jakości współpracy.

To także dobry czas na rozwijanie wewnętrznego przywództwa. Ktoś może lepiej facylitować Review, ktoś inny świetnie porządkuje rozmowę wokół celu Sprintu, jeszcze ktoś lepiej wyciąga wnioski z Retrospektywy. Nieobecność Scrum Mastera pomaga te role zobaczyć wyraźniej.

Typowe zagrożenia podczas urlopu Scrum Mastera

Nawet dobrze przygotowane zespoły wpadają czasem w przewidywalne pułapki. Warto nazwać je wcześniej, bo sama świadomość ryzyka zmniejsza prawdopodobieństwo, że w nie wpadniecie.

1. Daily zamienia się w status. Ludzie raportują, co robili, ale przestają planować wspólny dzień pracy.
2. Retrospektywa zostaje odwołana. Bo „nie ma kto poprowadzić” albo „mamy teraz za dużo roboty”.
3. Sprint Goal przestaje być ważny. Zespół skupia się na zamykaniu ticketów zamiast na realizacji celu.
4. Blokady nie są eskalowane. Każdy liczy, że sprawa „sama się rozwiąże”.
5. Product Owner zostaje osamotniony. Zespół nie dba o przejrzystość komunikacji i rośnie frustracja po obu stronach.
6. Nikt nie zapisuje obserwacji. Po powrocie wszyscy mają wrażenie, że coś się działo, ale brakuje konkretów.

Każde z tych zjawisk mówi coś ważnego o zespole. Nie po to, żeby kogoś zawstydzać, ale po to, żeby zobaczyć, gdzie proces opiera się jeszcze na zewnętrznym wsparciu, zamiast na nawykach i odpowiedzialności zespołowej.

Co Scrum Master powinien zweryfikować po powrocie

Powrót z urlopu nie powinien zaczynać się od próby szybkiego „odzyskania kontroli”. To bardzo kuszące, ale zwykle nieproduktywne. Znacznie lepiej rozpocząć od słuchania i obserwacji. Scrum Master wraca nie po to, by natychmiast poprawiać, tylko po to, by zrozumieć, jak zespół funkcjonował bez niego.

1. Jak zespół utrzymał rytm pracy

Czy odbyły się wszystkie wydarzenia? Czy miały sens? Czy zespół pamiętał o celu sprintu? Czy tablica była aktualna? To podstawowe pytania, które od razu pokażą, czy nieobecność Scrum Mastera zachwiała codzienną dyscypliną pracy.

2. Jak wyglądała jakość rozmów

Samo to, że Daily się odbyło, nie oznacza jeszcze, że było wartościowe. Scrum Master powinien sprawdzić, czy zespół rozmawiał o planie i współpracy, czy raczej odtwarzał suchy status. Warto też zapytać, jak przebiegały trudniejsze rozmowy: o zależnościach, zmianach zakresu, napięciach czy niedostępności decyzji.

3. Jak zespół radził sobie z impedimentami

Czy problemy były zauważane odpowiednio wcześnie? Czy ktoś je eskalował? Czy blokady zalegały na tablicy? To jeden z najmocniejszych wskaźników dojrzałości. Zespół może działać pozornie spokojnie, a jednocześnie tolerować problemy, które normalnie Scrum Master pomógłby szybciej ujawnić.

4. Jak wyglądała relacja z Product Ownerem

Bardzo często podczas nieobecności Scrum Mastera widać, czy współpraca z Product Ownerem jest zdrowa sama z siebie, czy była stabilizowana przez trzecią osobę. Warto zweryfikować, czy decyzje były podejmowane sprawnie, czy zespół miał jasność priorytetów i czy nie pojawiły się napięcia komunikacyjne.

5. Jakie nowe zachowania pojawiły się naturalnie

To nie tylko polowanie na problemy. Po powrocie trzeba też zauważyć to, co zadziałało dobrze. Może ktoś świetnie poprowadził Review. Może Daily stało się bardziej zwięzłe i konkretne. Może zespół sam zaczął lepiej dokumentować decyzje. Warto takie rzeczy nazwać i wzmocnić.

Jak poprowadzić rozmowę po powrocie

Najlepiej nie robić z tego przesłuchania. Zamiast pytać „co poszło nie tak?”, lepiej zacząć od pytań otwartych i neutralnych. Na przykład:

• Co działało dobrze podczas mojej nieobecności?
• Co było dla was trudniejsze niż zwykle?
• W których momentach brakowało wam wsparcia Scrum Mastera?
• Co zrobiliście samodzielnie lepiej niż przypuszczaliście?
• Jakie zachowanie warto zostawić na stałe?

Taka rozmowa daje znacznie lepsze rezultaty niż próba szybkiego wystawienia oceny. W centrum nie powinna być teza „poradziliście sobie” lub „nie poradziliście sobie”, tylko refleksja: czego nauczył nas ten okres o naszej dojrzałości.

Retrospektywa po urlopie Scrum Mastera

To jeden z najlepszych tematów na Retrospektywę po powrocie. Można potraktować cały okres nieobecności jako eksperyment procesowy i przeanalizować go na spokojnie. Taka retrospektywa może być bardzo konkretna, bo dotyczy ograniczonego czasu i realnych zachowań, a nie abstrakcyjnych opinii o tym, „jak nam się pracuje”.

Dobry układ takiej retrospektywy:

• Co działało bez zmian?
• Co zadziałało lepiej bez Scrum Mastera niż zwykle?
• Co osłabło lub zniknęło?
• Jakie zależności od Scrum Mastera chcemy świadomie zmniejszyć?
• Jakie praktyki chcemy utrzymać lub dopracować przed kolejną nieobecnością?

Jeżeli zespół używa narzędzi do retrospektyw online, łatwo zebrać takie obserwacje jeszcze w trakcie urlopu, a potem połączyć je w jedną analizę. To szczególnie przydatne wtedy, gdy nieobecność trwa dłużej i obejmuje więcej niż jeden Sprint.

Jak zachowuje się dobry zespół bez Scrum Mastera

W zależności od dojrzałości odpowiedź będzie trochę inna, ale można wskazać pewne wspólne elementy. Dobry zespół bez Scrum Mastera nie udaje, że nic się nie zmieniło, tylko świadomie bierze odpowiedzialność za to, co do tej pory częściej inicjowała jedna osoba. Nie chodzi o perfekcję. Chodzi o postawę.

• Zespół utrzymuje rytm wydarzeń i rozumie ich cel.
• Zespół nazywa problemy zamiast je ukrywać.
• Zespół nie czeka biernie na powrót Scrum Mastera z każdą trudniejszą decyzją.
• Zespół dba o przejrzystość pracy i komunikacji.
• Zespół umie powiedzieć po czasie, czego się nauczył.

To ważne, bo czasem organizacje błędnie uznają, że brak problemów oznacza dojrzałość. Tymczasem brak sygnałów może oznaczać równie dobrze bierność, unikanie napięć albo zamiatanie tematów pod dywan. Prawdziwa dojrzałość objawia się nie brakiem trudności, tylko sposobem reagowania na nie.

Jak zachowuje się dobry Scrum Master przed urlopem

Równie ważne jak zachowanie zespołu jest zachowanie samego Scrum Mastera. Urlop nie może być emocjonalnym testem lojalności ani sprawdzianem „czy beze mnie dacie radę”. Jeśli Scrum Master myśli o nieobecności głównie w kategorii zagrożenia dla własnej roli, to najpewniej zespół rzeczywiście jest od niego zbyt zależny.

Dobry Scrum Master przed urlopem:

• komunikuje urlop odpowiednio wcześniej,
• nie zostawia chaosu do posprzątania na cudzych barkach,
• dostosowuje poziom wsparcia do dojrzałości zespołu,
• nie tworzy nadmiernej kontroli na czas swojej nieobecności,
• po powrocie wraca z ciekawością, a nie z odruchem naprawiania wszystkiego.

To bardzo ważne. Scrum Master, który przed wyjazdem rozpisuje zespołowi każdy ruch, może niechcący zabić samodzielność. Scrum Master, który nie zostawia nic, bo „trzeba się nauczyć”, może z kolei wrzucić zespół w niepotrzebny chaos. Mądrość leży pośrodku: przygotować tyle, ile trzeba – ani mniej, ani więcej.

Przykładowe scenariusze według dojrzałości

Scenariusz 1: nowy zespół produktowy

Scrum Master wyjeżdża na dwa tygodnie. Zespół pracuje w nowym składzie od trzech miesięcy, dopiero uczy się facylitacji, a Daily często zbacza w szczegóły techniczne. W takim przypadku rozsądne będzie wyznaczenie jednej osoby pilnującej rytmu, pozostawienie checklisty wydarzeń i przygotowanie krótkiego dokumentu „co robimy, gdy pojawia się blokada”. Po powrocie Scrum Master powinien sprawdzić nie tylko, czy spotkania się odbyły, ale też czy cokolwiek z nich wynikało.

Scenariusz 2: stabilny zespół rozwijający się

Zespół pracuje razem od roku, rozumie role, ale pod presją czasem gubi sens Retrospektywy i wraca do zadaniowego myślenia. Tutaj warto ustalić minimalne ramy, wprowadzić rotacyjne facylitowanie wydarzeń i poprosić zespół o zapisanie wniosków z okresu nieobecności. Po powrocie świetnym ruchem będzie retrospektywa skupiona na pytaniu: „w których momentach nadal byliśmy zależni od Scrum Mastera?”.

Scenariusz 3: dojrzały zespół platformowy

Zespół pracuje stabilnie, sam dba o jakość rozmów, potrafi korygować kurs i prowadzić Retrospektywy. W tym przypadku Scrum Master może ograniczyć przygotowanie do jasnego zakomunikowania nieobecności i umowy, że po powrocie zespół podzieli się obserwacjami. Taki urlop bywa wręcz potwierdzeniem, że rola Scrum Mastera dobrze wspiera samoorganizację zamiast ją zastępować.

Checklisty do skopiowania

Wnioski dla praktyki Scrumowej

Im bardziej zespół dojrzewa, tym mniej urlop Scrum Mastera powinien być wydarzeniem krytycznym, a tym bardziej naturalnym elementem pracy. To nie znaczy, że rola Scrum Mastera staje się nieważna. Przeciwnie – staje się bardziej strategiczna. Zamiast podtrzymywać proces własną obecnością, Scrum Master buduje zdolność zespołu do utrzymania jakości i kierunku także wtedy, gdy go nie ma.

Dobrze przygotowany urlop może więc dać bardzo cenną informację zwrotną. Pokazuje, gdzie zespół jest już naprawdę samodzielny, a gdzie potrzebuje jeszcze rozwoju. Odsłania niewidoczne zależności. Wzmacnia liderstwo wewnętrzne. A czasem pozwala Scrum Masterowi zobaczyć, że pewne obszary można spokojnie oddać zespołowi na stałe.

Najlepsza sytuacja nie polega na tym, że podczas urlopu „nic się nie wydarzyło”. Najlepsza sytuacja to taka, w której po powrocie zespół potrafi powiedzieć: utrzymaliśmy rytm, zauważyliśmy kilka słabości, wyciągnęliśmy konkretne wnioski i wiemy, co poprawić następnym razem. To właśnie brzmi jak samoorganizacja. I to właśnie jest jeden z najlepszych dowodów dojrzałości zespołu Scrumowego.