Jak angażować zespół w rozwiązywanie problemów?

Co można zrobić, by zaangażować zespół w rozwiązywanie problemów? Jedną z metod jest „Take it to the team”, którą polecamy nawet osobom zaczynającym pracę w rolach zwinnych – kiedy są w tak zwanej tranzycji. Dodatkowo mamy pięć innych porad, które pozwolą zaangażować zespół by wspólnie rozwiązać powstałe problemy. Pomocne będą też aspekty,  aspekty, które bierzemy pod uwagę, kiedy zastosować daną metodę, a kiedy nie.

Take it to the team

Tego rodzaju wskazówka jest szczególnie pomocna dla osób, które dopiero rozpoczynają pracę w rolach zwinnych i znajdują się w procesie przejścia z bardziej klasycznych modeli zarządzania. Osoby z doświadczeniem w klasycznym zarządzaniu np. Project Managerowie, często przenoszą nawyk samodzielnego rozwiązywania problemów do pracy z zespołem zwinnym. Działa też obawa, że zespół może nie do końca brać odpowiedzialność, więc lider bierze sprawy w swoje ręce. Dlatego warto budować nawyk: przedstawiać problem zespołowi, wspólnie go definiować i szukać rozwiązań razem. 

Czasem zespół potrafi zaproponować coś, na co lider czy Scrum Master sam by nie wpadł i to bywa naprawdę odkrywcze. Co więcej, zespół chętniej wdraża rozwiązanie, które sam wypracował, właśnie dlatego, że to jest ich pomysł. Technika „Take it to the team” nie jest uniwersalnym rozwiązaniem, które zawsze działa. Przerysowanym przykładem byłoby odbijanie każdego pytania z powrotem do zespołu, niezależnie od kontekstu. Nawet jeśli zespół prosi o opinię, sugestię lub radę, odpowiadamy pytaniem. To pułapka opisana w „Labiryntach Scruma” jako postawa „Scrum Mastera, który zachowuje się jak coach”. Dlatego chcemy podkreślić: to nie technika, która sprawdzi się w każdej sytuacji. Przyjrzymy się, kiedy ta technika ma sens, a kiedy niekoniecznie. Podzielimy się też tym, jakie czynniki warto rozważyć, decydując o jej zastosowaniu i w jakim zakresie. Nie jest to jedyna możliwa droga w pracy z zespołem, ale mamy kilka sensownych alternatyw. 

Zobacz wersję wideo

Alternatywy do Take it to the team

1. Rozwiązanie problemu poza zespołem

Choć zaczęliśmy od pozytywnego obrazu zespołu samodzielnie rozwiązującego problemy, to nie znaczy, że każde działanie poza zespołem jest z góry błędem. W praktyce wiele decyzji faktycznie zapada poza zespołem. Przykładem są decyzje o przejściu na zwinne podejście, wyborze narzędzi, technik czy frameworków. Takie decyzje zwykle zapadają na poziomie organizacji, nie zespołu. Często zespoły nie uczestniczą w tym procesie ani nie są o niego pytane. To ma swoje zalety i wady. Warto uważać na pułapkę myślenia, idąc tropem pułapki z „Labiryntów Scruma” że tylko to, co powstaje w zespole, jest wartościowe. Są decyzje, które muszą zapaść poza nim i to nie czyni ich gorszymi. W niektórych sytuacjach to liderzy organizacji muszą wziąć odpowiedzialność i spojrzeć na całość. To oni inicjują zmianę, a zespoły podejmują decyzje na dalszych etapach. Czasem ten pierwszy impuls, decyzja o zmianie musi pojawić się poza zespołem. Kiedy zatem to podejście jest zasadne? Wtedy, gdy w grę wchodzi duża zmiana organizacyjna, wymagająca decyzji lidera z szeroką perspektywą, który otwiera drogę do dalszych, kolejnych decyzji w zespołach niższego szczebla. 

Warto też wspomnieć o sytuacji, w której zespół otrzymuje do rozwiązania konkretny problem. Jednak decyzje dotyczące poziomu ryzyka i granic, których nie można przekroczyć, zapadają poza zespołem. Przykładem może być środowisko regulowane, w którym kierunek działań wyznaczany jest przez osoby zarządzające organizacją, a nie przez sam zespół.

Decyzje podejmowane poza zespołem nie muszą być złe, stają się problematyczne dopiero wtedy, gdy zespół nie rozumie, skąd się wzięły. Dotyczy to np. ograniczeń procesowych, architektonicznych, regulacyjnych czy organizacyjnych przekazywanych zespołowi z zewnątrz. Tego typu decyzje nawet podjęte poza zespołem są łatwiejsze do przyjęcia, jeśli znany jest ich kontekst. Pomaga wtedy zrozumienie ryzyk, ograniczeń i rozważanych wcześniej alternatyw.

2. Rozwiązują problem tylko z częścią zespołu

To podejście pośrednie zespół bierze udział w decyzji, ale nie w pełnym składzie. To podejście pośrednie, zespół bierze udział w decyzji, ale nie w pełnym składzie. Dobór osób zależy od kontekstu. Najczęściej są to osoby z większym doświadczeniem ogólnym lub związanym z danym produktem czy systemem.

Zwykle nie jest to formalnie nazwane, ale naturalnie przyjmowane. Czasem decyzja wynika z chęci oszczędzenia czasu całego zespołu, innym razem z przekonania, że mniej doświadczone osoby nie są jeszcze gotowe na przykład do decyzji architektonicznych, podczas gdy osoby z wieloletnim stażem potrafią spojrzeć szerzej i przewidzieć potencjalne ryzyka. Z drugiej strony, dobrą praktyką może być wspólna zgoda zespołu na to, że dany problem zostanie rozwiązany przez wybraną grupę. Przykładowo: podczas Retrospektywy cały zespół uzgadnia, że dwóch najbardziej doświadczonych deweloperów zajmie się reorganizacją narzędzi wspierających pracę. Pozostali mają zaufanie, że zrobią to dobrze i wiedzą, że w tym przypadku nie ma potrzeby angażowania wszystkich. Ryzyko pojawia się wtedy, gdy grupa rozwiązująca problem jest zbyt jednorodna, może zabraknąć szerszej perspektywy. Problem zostanie rozwiązany po ich myśli, ale w innym składzie mógłby zostać ujęty lepiej, szerzej. To sytuacja, w której warto znaleźć balans, brak pełnego udziału zespołu nie oznacza od razu, że problem został źle rozwiązany, ale też nie każda decyzja w wąskim gronie będzie najlepsza.

Z jednej strony bywa to najlepsze rozwiązanie, ale istnieje ryzyko, że automatycznie pomijane są osoby oceniane jako mniej wartościowe w dyskusji. Tymczasem osoby początkowo niedoceniane potrafią zadawać trafne pytania, np. prosząc o wyjaśnienie niezrozumiałego zagadnienia, które wnoszą świeżą perspektywę i ożywiają dyskusję. Zdarza się też, że osoby nowe, choć bez lokalnego kontekstu, wnoszą cenne doświadczenia z innych organizacji. Często okazuje się, że ich udział pozytywnie wpływa na przebieg rozmowy mimo początkowych wątpliwości. Dlatego warto pamiętać, że decyzja o zawężeniu grupy powinna być kontekstowa i dobrze przemyślana.

3. Świadome pozostawienie problemu w zespole

Inną alternatywą jest świadome pozostawienie problemu w zespole, nawet jeśli z zewnątrz widać, że nic się z nim nie dzieje. Zespół nie widzi problemu lub nie traktuje go poważnie.

Jesteśmy na przykład Agile Coachem z zewnątrz, jako osoba wspierająca zespół, widać wyraźnie, że coś nie działa. Można ten problem nazwać, znać sposoby jego rozwiązania, ale zespół mimo sygnałów, nie rozpoznaje go lub nie podejmuje próby rozwiązania. W efekcie zespół uznaje, że problem nie istnieje. To trudny moment, pułapka  świadomości,  problem jest widoczny z zewnątrz, ale nie wewnątrz zespołu. Kluczowe są tu konsekwencje, one mogą przesądzić o tym, czy warto reagować, czy lepiej zostawić sprawę w zespole. Można wtedy podjąć świadomą decyzję: problem został zasygnalizowany, jeśli nie został podjęty widocznie, nie jest jeszcze istotny z perspektywy zespołu. Taka postawa ma sens, jeśli skala problemu i jego skutki są ograniczone i możliwe do zaakceptowania. Jeśli to drobna nieefektywność komunikacyjna można pozwolić zespołowi dojrzeć do zmiany. Natomiast w przypadku poważnych ryzyk, jak zagrożone wdrożenie lub porażka projektu, pozostawienie problemu bez reakcji może być błędem. Jeśli zignorowanie problemu grozi poważnymi konsekwencjami niczym jechanie wprost na czołówkę z tirem, lepiej sięgnąć po inne dostępne opcje. Jeśli jednak problem ma czas, by dojrzeć, a zespół potrzebuje przestrzeni, by go samodzielnie odkryć. Świadome nieinterweniowanie może być trafną decyzją, szczególnie z perspektywy osób spoza zespołu. Zbyt duże zaangażowanie może działać przeciwskutecznie, próba „naprawiania świata”, może nie przynieść efektu. Zbyt duże zaangażowanie może zrobić więcej krzywdy,  próba „naprawiania świata” może nie przynieść efektu. Zespół musi być gotowy, by problem dostrzec i chcieć go rozwiązać. Czasami potrzebny jest czas i przestrzeń na zbudowanie tej świadomości i zrozumienie problemu. Dojrzeć do tego, że ten problem należy rozwiązać. 

Ryzykiem tego podejścia jest skrajność: pozostawianie wszystkiego zespołowi z hasłem „upadaj często, ucz się na błędach”. Sama idea nie jest błędna pod warunkiem, że faktycznie prowadzi do nauki. Te podejścia mają sens tylko wtedy, gdy zespół rzeczywiście wyciąga wnioski i rozwija się dzięki błędom. W przeciwnym razie pozostawianie problemów i liczenie na to, że zespół sam podejmie rekawice, może być naiwna. Zwłaszcza gdy wyraźnie widać, że zespół nie podejmuje tematu z braku motywacji, zrozumienia czy poczucia odpowiedzialności. Sama bierność nie jest tu skuteczną strategią. Może być postrzegana jako brak działania ze strony lidera. Podsumowując, zobacz Rzym płonie, a Ty stoisz. Nie pomaga także stwierdzenie: „od dwóch miesięcy widzę, że będzie pożar”.

Tego typu reakcja może zostać odebrana negatywnie. Każda z omawianych alternatyw wymaga uwzględnienia kontekstu, nie ma rozwiązań uniwersalnych. Każda z tych strategii wymaga osobnego przemyślenia, co w danym zespole i sytuacji może zadziałać, a co nie.

4. Doprowadzenie do sytuacji, w której zespół uzyskuje zdolność dostrzeżenia problemu

Inną możliwością jest stworzenie warunków, w których zespół sam dostrzega problem. Przykładowo: przekazujemy dane, analizy czy statystyki, które prowokują refleksję – „chyba mamy problem, może warto coś zmienić”. Klasyczna sytuacja: zespół regularnie nie dowozi zaplanowanego zakresu Sprintu. Sprint kończy się z dużą liczbą zadań w toku rozgrzebanych, zablokowanych lub niedokończonych. Zamiast nazywać problem wprost, można pokazać dane: np. analizę pięciu ostatnich Sprintów i wynikającą z niej przewidywalność. Można wskazać konkretne wskaźniki: ile zadań zostaje rozgrzebanych, ile przypada średnio na osobę i przedstawić to zespołowi. Czasem reakcja zespołu jest szybka „tak, widzimy problem”. Innym razem zespół nie reaguje, dane nie wywołują żadnego efektu. Efekt zależy od kultury organizacyjnej, dojrzałości zespołu i sposobu jego prowadzenia. Mimo wszystko to skuteczna metoda rozwijająca zespół w kierunku refleksji nie tylko nad tym, co robi, ale też jak pracuje.

Warto podkreślić, czym to podejście różni się od klasycznego przekazania problemu zespołowi. Załóżmy, że zespół ma trudność z realizacją własnych prognoz. Można wtedy podejść wprost i powiedzieć: „nie realizujecie prognoz, to psuje Sprint i dalsze plany”. Można też podejść inaczej tak, jak to zostało wcześniej opisane pokazać dane i obserwacje. Jeśli po prostu „przyklejamy etykietę” z problemem, zespół może ją odrzucić. Gdy jednak pokażemy twarde dane, które trudno podważyć, szansa na realną reakcję jest większa. Czasami dysponujemy już konkretnymi danymi lub analizą zjawiska, a innym razem trzeba zacząć od zbudowania procesu zbierania takich danych. Warto, jeśli organizacja wspiera takie podejście i jeśli zespół ma nawyk przyglądania się faktom. Wtedy naturalne staje się rozpoczęcie od analizy stanu obecnego. W innych sytuacjach może to być rola bardziej zakulisowa, pełniona przez Scrum Mastera, lidera czy Agile Coacha. Wtedy warto wcześniej zebrać dane, by późniejsze rozmowy z zespołem były bardziej skuteczne. Warto dodać, że budowanie świadomości zespołu to inwestycja, na którą nie zawsze jest czas. Jeśli np. środowisko produkcyjne przestaje działać albo napływa lawina zgłoszeń od Klientów, to nie jest moment na rozwijanie refleksyjności zespołu. W takiej sytuacji konieczne jest szybkie działanie. Dlatego ten aspekt, pilność sytuacji, warto wziąć pod uwagę przy wyborze strategii.

5. Chińskie menu na rozwiązania 

Zdarzają się sytuacje, w których zespół nie jest w stanie samodzielnie rozwiązać problemu, bo po prostu nie zna odpowiednich rozwiązań. Niezależnie od tego, czy uznamy, że rozwiązanie „jest w zespole, tylko trzeba je wydobyć”, czy spojrzymy na to praktycznie, np. w przypadku zespołu, który dopiero zaczyna pracę w Scrumie. Taki zespół prowadzi Codzienny Scrum zgodnie z tym, co usłyszał na szkoleniu, ale wydarzenie nie przynosi realnej wartości, jest mechaniczne i mało angażujące. Zespół może dostrzegać, że coś nie działa, ale nie ma pomysłu, jak to zmienić brakuje wiedzy o alternatywach. Niektóre zespoły eksperymentują, inne, mniej doświadczone lub mniej odważne, czekają na wskazówki. Brakuje im też często odwagi do testowania nowych rozwiązań. W takich przypadkach można sięgnąć po alternatywę znaną z kursów coachingowych, podejście nazwane „chińskim menu”. Jeśli już proponujemy rozwiązania, warto zaproponować ich kilka. Tak jak karta dań w restauracji chińskiej wiele opcji, różnorodne warianty. Przykładowo: jeśli Daily nie działa, można zaproponować trzy do pięciu różnych sposobów jego poprowadzenia. Żadne z nich nie jest narzucane jako jedyne słuszne. Dzięki temu zespół nie odrzuca jednego dominującego rozwiązania, tylko ma możliwość wyboru lub łączenia różnych podejść. Z czasem wypracowuje własne, hybrydowe rozwiązanie. 

Dzięki takiemu podejściu nie ponosimy pełnej odpowiedzialności za wybór konkretnego rozwiązania, a jednocześnie zmniejsza się ryzyko odrzucenia całego pomysłu.Im więcej realnych opcji, tym większa szansa, że zespół coś wybierze. I unikamy reakcji: „to już było”, „to nie działa”, „to nie dla nas”. Jeśli opcji jest kilka, prawdopodobieństwo trafienia w coś użytecznego rośnie.

Warto zauważyć, że w niektórych kontekstach „chińskie menu” może być celowo ograniczone. Przekazujemy zespołowi dostępne warianty, pomijając te, które z różnych względów nie wchodzą w grę. Tym samym eliminujemy rozwiązania, na które organizacja nie jest gotowa, ale nadal angażujemy zespół w podejmowanie decyzji w ramach dostępnych możliwości. To nadal działanie wspierające budowanie świadomości zespołu i poczucia odpowiedzialności za podejmowane decyzje. Taka postawa sprzyja zaangażowaniu i przejmowaniu odpowiedzialności. W przeciwieństwie do podejścia pasywnego, gdzie decyzje są oczekiwane z zewnątrz. Gdzie efekt, czy decyzja zapadnie, czy nie – nie ma dla zespołu większego znaczenia.

W tym podejściu zespół traktowany jest jako jednostka odpowiedzialna za produkt, dążąca do jego jakości pod wieloma względami. Warto dopowiedzieć, czym „chińskie menu” różni się od podejścia „Take it to the team”. Różnica tkwi w tym, że osoba przedstawiająca „chińskie menu” zachowuje kontrolę nad zakresem prezentowanych opcji. To nie jest sytuacja, w której zespół sam wymyśla rozwiązanie na zadany problem. To raczej podejście: „zespoły w podobnej sytuacji stosują następujące praktyki”. Przykładowe rozwiązania to: ograniczanie pracy w toku, zmiana formatu Daily, drobniejsze planowanie itp. Prezentowane spektrum jest szerokie, ale nie nieograniczone zostało celowo wybrane i ustrukturyzowane. To nie jest pełna dowolność, zespół nie tworzy wszystkiego od zera. Prezentujący zachowuje kontrolę, co wiąże się również z odpowiedzialnością. Warto więc, by osoby prowadzące znały możliwe opcje i miały je gotowe. To ciągłe poszukiwanie alternatyw i wariantów dla codziennych praktyk zespołu. Zamiast trzymać się jednego, niezmiennego sposobu na Daily, retro czy Backlog, Choć to naturalne na początku pracy w zwinnych rolach, nawet bardziej doświadczone osoby powinny stale poszerzać repertuar możliwych rozwiązań. Nie po to, by je eksponować, ale by świadomie wiedzieć, że są dostępne. Tak, by w odpowiednim momencie móc “Chińskie menu “  przedstawić.

Omówiliśmy różne alternatywy i sytuacje, w których dana strategia może, ale nie musi mieć zastosowania. Teraz chcemy uporządkować tę wiedzę i podzielić się zestawem kryteriów, które pomagają określić, w jakim stopniu angażować zespół w rozwiązywanie problemów. Od czego warto zacząć? 

Kryteria, które pomagają określić, w jakim stopniu angażować zespół w rozwiązywanie problemów

1. Dojrzałość zespołu w procesie grupowym

Rozumianą jako poziom zgrania i zaawansowania w procesie grupowym. Czy potrafimy otwarcie rozmawiać, udzielać sobie informacji zwrotnej i działać jako zgrany zespół? Im zespół dojrzalszy, tym więcej można z nim wspólnie wypracować. Zespół mniej dojrzały, będący na początku wspólnej pracy, naturalnie napotyka trudności wynikające z niedoskonałości relacyjnych, które utrudniają zastosowanie klasycznych metod współpracy. To zespół, który jeszcze potrzebuje czasu, by dojrzeć do pełniejszego zaangażowania. Na tym etapie decyzje mogą być podejmowane w podgrupach lub przekazywane z zewnątrz, pod warunkiem, że towarzyszy im odpowiednie wyjaśnienie. Ważne, by zespół rozumiał powody podejmowanych decyzji. 

Warto dodać praktyczną obserwację: zespołom na początku często brakuje dwóch kluczowych aspektów. Po pierwsze, otwartości na inne pomysły, połączonej z odwagą ich wypowiadania. Chodzi o gotowość, by podzielić się pomysłem i zaakceptować, że może on zostać odrzucony. Jeśli te dwa elementy nie są obecne, co w nowej grupie jest raczej naturalne, to trudno oczekiwać otwartej, konstruktywnej rozmowy. Członkowie grupy będą ostrożni, niepewni, co wolno powiedzieć, a co może zostać źle odebrane. Pojawia się też obawa przed reakcją innych. Dlatego im większa dojrzałość zespołu, tym większa otwartość w rozmowie i wymianie pomysłów. Nawet jeśli wiele propozycji zostaje odrzuconych, zespół przyjmuje to naturalnie.

Warto uważać, by nie pójść za daleko w interpretacji wcześniejszych wniosków. Dojrzałość zespołu kształtuje się właśnie w trudnych sytuacjach. Często poruszamy się na granicy między niedojrzałością a gotowością do mierzenia się z wyzwaniami. Problem pojawia się, gdy liderzy zakładają, że zespół jest niedojrzały, i nie dopuszczają go do sytuacji, które mogłyby tę dojrzałość rozwijać. Nie da się sformułować uniwersalnej zasady, że w przypadku niedojrzałego zespołu decyzje zawsze powinien podejmować ktoś za nich. Taka praktyka może utrwalić niedojrzałość zespołu, bo zespół pozostaje w strefie komfortu i nie angażuje się w trudniejsze wyzwania.

2. Pilność inicjatywy

Jeśli zespół działa pod presją czasu, ma konkretne zobowiązania lub znajduje się w sytuacji awaryjnej, to lepszym rozwiązaniem może być szybkie działanie, wskazanie kierunku lub wsparcie, niż czekanie na samodzielną inicjatywę zespołu. W sytuacjach chaosu, jak to opisuje model Cynefin, najważniejsze jest szybkie działanie. Gdy sytuacja się stabilizuje, można zacząć tworzyć przestrzeń do szerszego zaangażowania zespołu. Być może konieczne będzie, by ktoś zdecydował i poprowadził zespół w określonym kierunku, bo zbyt długie wahanie może wiązać się z poważnymi konsekwencjami. Czasami problem jest ignorowany, a Klienci w tym czasie nie mogą korzystać z produktu. 

3. Umiejscowienie w organizacji

Kolejnym ważnym wymiarem jest umiejscowienie w strukturze organizacji, tego, co do tej pory nieco pominięte. W szczególności chodzi o ryzyko, że osoby z dalszych warstw organizacji zaczynają rozwiązywać problemy za zespół, zamiast wspierać go w samodzielności. Problem polega na tym, że nasza perspektywa, wynikająca z pozycji w strukturze. może znacząco różnić się od perspektywy zespołu. Dotyczy to szczególnie dużych organizacji o rozbudowanej hierarchii, gdzie branie odpowiedzialności „za zespół” może prowadzić do oderwania się od jego realiów a w skrajnych przypadkach do utraty zaangażowania zespołu. Dlatego warto regularnie konfrontować własną wizję organizacji z tym, jak postrzegają ją zespoły. W przeciwnym razie trudno się dziwić, że zespoły nie angażują się w decyzje, które zostały narzucone z góry. Szczególnie jeśli decyzje pochodzą z najwyższych poziomów organizacji, z pominięciem codziennego kontekstu pracy zespołu.

Kolejnym ważnym, choć pośrednim wymiarem jest kultura organizacyjna.Przykładowo: w niektórych kulturach organizacyjnych dominuje obraz menedżera jako odważnego lidera, który samodzielnie podejmuje decyzje. Taka kultura, nie sprzyja rozwijaniu w zespole kompetencji związanych z odpowiedzialnością i samodzielnym rozwiązywaniem problemów. W efekcie świadomie lub nie podtrzymujemy model, w którym to zarządzający zawsze rozwiązują problemy za zespół. W niektórych kulturach zakłada się, że menedżer zawsze podejmuje decyzje, nawet jeśli się myli. Warto więc zdiagnozować, czy funkcjonujemy w takiej kulturze przywództwa, a następnie zdecydować, czy chcemy ten model utrzymać, czy jednak zależy nam na przesunięciu odpowiedzialności bliżej zespołów.

4. Doświadczenie członków zespołu

Zdarza się, że członkowie zespołu nie mają jeszcze wystarczającego doświadczenia, by podejmować decyzje o strategicznym znaczeniu. W zespole o niskim poziomie doświadczenia nie należy oczekiwać, że zostaną rozpoznane i rozwiązane bardziej złożone problemy. Po prostu brakuje im zawodowej ekspozycji na tego typu sytuacje. To problemy, które trzeba najpierw przeżyć, by nauczyć się je rozpoznawać i rozwiązywać. Z drugiej strony w doświadczonym zespole ekspertów, podejmowanie decyzji przez zespół jest naturalne i oczekiwane. Właśnie po to buduje się zespoły z odpowiednio dobranymi kompetencjami, by mogły samodzielnie rozwiązywać problemy bez potrzeby zewnętrznego sterowania. Dobrym przykładem jest popularny mit, że podejście zwinne nie uwzględnia architektury,  że wszystko powstaje iteracyjnie, bez planu. Stereotyp mówi, że z każdą iteracją tworzymy coś nowego, bez przemyślanej koncepcji. To jednak przykład tematu, który wymaga zarówno umiejętności, jak i doświadczenia, również z porażkami. Dopiero z czasem zaczynamy doceniać wartość spójnej wizji architektonicznej oraz świadomych wyborów technologicznych, bibliotek, narzędzi czy stylów. 

W efekcie głos niektórych osób w zespole będzie naturalnie ważniejszy. Doświadczeni członkowie zespołu zostaną wysłuchani z większą uwagą, a mniej doświadczeni mogą nawet nie mieć gotowości, by zabrać głos i nie należy tego sztucznie wymuszać. Nie chodzi o tworzenie fałszywego wrażenia równości kompetencyjnej. Samoorganizacja to także uznanie, że ktoś z zespołu ma kompetencje, by poprowadzić innych w określonym obszarze.

5. W jakim stopniu zespół widzi problem

Ostatni wymiar, który warto dodać to, czy zespół w ogóle dostrzega problem i jak głęboko go rozumie. Problemy bywają złożone i wielowarstwowe. Czasem widoczny jest tylko objaw np. zespół odbiera Daily jako nudne. Tymczasem przyczyny mogą sięgać głębiej: nudne Daily może wynikać ze słabego planowania, a to z kolei z niskiego zaangażowania Product Ownera. Łańcuch przyczyn może być znacznie dłuższy. Zespół może dostrzegać jedynie objawy, nie docierając do źródła problemu. W takiej sytuacji pełne przekazanie odpowiedzialności zespołowi może być ryzykowne, bo zajmie się wyłącznie powierzchownymi symptomami. Przykładowo może dojść do wniosku, że trzeba porzucić Scruma, bo Daily „nie działa”. To skrajny przykład, ale pokazuje, że bez właściwego rozpoznania źródła, zespół może długo błądzić i nie rozumieć, czemu problemy się powtarzają. Nawet jeśli usprawnią sam przebieg Daily, problemy nie znikną, jeśli brakuje czasu i zaangażowania po stronie Product Ownera. 

W takich przypadkach zbyt duża wiara w samoorganizację może nas zaprowadzić w ślepą uliczkę. Zamiast rozwiązywać problem za zespół, lepiej doprowadzić do sytuacji, w której sam dostrzeże on jego głębsze przyczyny. Nie oznacza to jednak, że zespół powinien być wyręczany w każdej sytuacji.

📄Transkrypcja podcastu „Jak angażować zespół w rozwiązywanie problemów?”

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.

Jacek: W dzisiejszym odcinku porozmawiamy o poradzie, która po angielsku najczęściej jest przedstawiana jako „Take it to the team”. Jest to porada, która polega na tym, że w przypadku gdy stajemy przed jakimś konkretnym problemem pracując z zespołem, no to, zamiast próbować ten problem rozwiązać samodzielnie przekazujemy ten problem do zespołu, bądź co najmniej włączamy zespół w jego rozwiązanie.

Kuba: Ta porada jest szczególnie dobra dla osób, które dopiero zaczynają pracować w rolach zwinnych. Są w tak zwanej tranzycji. Na przykład wcześniej byłem Project Managerem i byłem przyzwyczajony do tego, że jedno z moich zadań to jest rozwiązywanie problemów no i mogę nieświadomie lub świadomie przenieść ten nawyk do pracy z zespołem zwinnym i dalej konsekwentnie rozwiązywać problemy, plastrować, dostrzegać problemy i je samemu bohatersko jakby rozwalać. Taki nawyk często też ujawnia się u osób, które martwią się, że zespół nie bierze odpowiedzialności, więc na wszelki wypadek to ja tak trochę czując się odpowiedzialny bardziej niż pozostali spróbuję coś z tym zrobić. No i wtedy porada o tym, żeby jednak budować sobie nawyk – zabieraj ten problem do zespołu, zdefiniuj go z zespołem, szukaj rozwiązań z zespole, a nie samemu. No jest z zasady dobrym pomysłem. Niektórym to otwiera oczy. Szczególnie ciekawe są te momenty, w którym zespół znajduje jakieś fajne rozwiązania, które tej danej osobie – czy to liderowi zespołu, czy Scrum Masterowi w ogóle by do głowy nie przyszły. A zespół nie dość, że ma pomysł lepszy, to ten pomysł jest jeszcze w ogóle lepszy tylko dlatego, że to jest po prostu ich pomysł. Sami go wypracowali. Dzięki czemu z większym zaangażowaniem próbują go zrealizować. Planujemy, że ten odcinek będzie analizą tego tematu jak rozwiązywać problemy z zespołem i chcemy świadomie, żeby ten odcinek był trochę bardziej uniwersalny niż tylko te dwa przykłady, które użyłem. Więc zakładam, że odcinek jest skierowany do Scrum Masterów, do Agile Coachów, do Project Managerów, ale też do liderów zespołów zwinnych lub Product Ownerów. Nawet jeśli wprost nie użyjemy danego przykładu to ja zakładam, że cała treść tego odcinka może być wartościową inspiracją. Warto poszukać, czy nie zaczerpnąć czegoś dla siebie.

Jacek: Taka uwaga, którą chcielibyśmy głośno wypowiedzieć, zanim rozpoczniemy dyskusję jest taka, że ta technika – „Take it to the team” ona może zabrzmieć jak taka uniwersalna porada, podejście, które zawsze działa. Taki skrajnie przerysowany przykład to jest, że na każde pytanie i problem zespołu, no to my reagujemy jakby odbiciem piłeczki, przekazaniem tego problemu z powrotem do teamu. Pomimo iż zespół zapytał nas – co my o tym myślimy, co my byśmy z tym zrobili, czy generalnie po prostu zapytał o poradę. Jest to pułapka, którą opisałem w swojej książce w „Labiryntach Scruma„. Ja tę poradę nazwałem akurat konkretnie „Scrum Master zachowuje się jak coach”. Czyli właściwie na każde pytanie zespołu odpowiada pytaniem. Tak więc wyraźnie chcemy z Kubą zaznaczyć to, że to nie jest uniwersalna technika, która działa zawsze. To nie jest też jakaś taka sprytna technika, że ktoś teraz zacznie ją stosować i będzie mądrze wyglądał. Tylko tak naprawdę chcielibyśmy dziś pochylić się nad zagadnieniem, kiedy ta technika ma sens, kiedy może niekoniecznie. I chcielibyśmy też pokazać pewne takie wymiary, które z Kubą byśmy wzięli pod uwagę podejmując decyzję czy ją zastosować czy nie i w jakim stopniu. Nie jest to też tak, że to jest jedyny sposób rozwiązywania problemów z zespołem. Widzimy z Kubą co najmniej kilka alternatyw. Gdybyś miał Kuba wskazać pierwszą z nich to co by to było?

Kuba: Pierwsze wydaje mi się jest najbardziej oczywista, czyli takie przeciwieństwo zabrania tego problemu do zespołu, czy zabrania rozwiązania problemu do zespołu, tylko po prostu zrobienie tego poza zespołem. Tak jak rozpoczynaliśmy w takim dosyć optymistycznym świecie taką optymistyczną historię, że zespół zaangażowany rozwiązuje problem, to wydaje się, że nie – poczekajcie, to jest akurat zły pomysł, żeby w takim razie nie pozwalać zespołowi rozwiązywać jakiegoś problemu. Natomiast przychodzi mi do głowy wiele przykładów, gdzie decyzje są jednak realizowane poza zespołem. No i chociażby same takie już najgrubszego kalibru decyzje czy w ogóle pracujemy w sposób zwinny, że decydujemy się jako firma na jakąś transformację zwinną czy decydujemy się na jakiś zestaw narzędzi, technik, frameworków. To zazwyczaj są decyzje jednak podjęte poza zespołem. Zazwyczaj też zespoły ani nie są pytane, ani nie są jakoś wciągane w ten proces decyzyjny. To ma swoje plusy i minusy. W szczególności też idąc tym tropem tej Twojej pułapki z „Labiryntów Scruma” są takie momenty i są takie decyzje, które po prostu podejmowane są poza zespołem i nie dajmy się tutaj ponieść fantazji takiej coachingowej czy takiemu nastawieniu, że wszystko, co jest dobre to musi powstać w zespole. Wszystko, co poza zespołem powstało to jest na pewno z gruntu złe. Można by długo dyskutować, a mam nadzieję, że dorzucisz jeszcze coś poza tym, co ja zaraz powiem. Przede wszystkim mi się wydaje, że są takie decyzje, w których odpowiedzialność i takie widzenie całości muszą podjąć na przykład liderzy organizacji. Wziąć na siebie ten ciężar. Pozwolić wykonywać już dalsze decyzje w zespołach. No ale jakiś start, jakiś taki sygnał do startu jednak musi nastąpić poza zespołami. Ten taki pierwszy płomyk, czy pierwsza iskra musi padać w niektórych przypadkach poza zespołem. Czyli zamieniając to na taką ogólniejszą wiedzę, kiedy to może mieć miejsce? Wtedy, gdy decydujemy o jakiejś naprawdę najgrubszego kalibru zmianie w organizacji i kiedy potrzebny jest lider, który widzi obraz całej organizacji i też podejmuje – być może odważną, ryzykowną decyzję, która umożliwia kolejne decyzje już niższego szczebla.

Jacek: Ja bym tutaj dołożył od siebie też z doświadczenia taką sytuację, kiedy zespół ma do rozwiązania pewien problem. Natomiast decyzja dotycząca ryzyka, w sensie – jak daleko mogą pójść w rozwiązaniu oraz decyzja jakie są ograniczenia rzeczy, które są stałe, których nie mogą zmienić, nie mogą ruszyć – pozostaje poza zespołem i to akurat jest taki mój przykład z rynku bardzo regulowanego, gdzie po prostu pewne decyzje dokąd możemy pójść nie są zostawiane zespołowi, tylko są – tak jak wspomniałeś – kreowane przez liderów firmy i osoby, które tą firmą zarządzają.

Kuba: Ja myślę, że ten moment, gdy są decyzje poza zespołem tak mocno dokreśla to, że one nie muszą być złe, ale mogą być złe wtedy, gdy zespół nie rozumie, dlaczego takie są jakie są. Jeśli na przykład zespół otrzymuje informuje informację o jakimś ograniczeniu, na przykład procesowym, czy architektonicznym, albo ograniczenie takie jak mówisz rynkowe, regulacyjne, czy nawet takie jakieś decyzje organizacyjne. To jeśli podejmiemy je poza zespołem, to moim zdaniem nie będą tak złe, jeśli będzie wyjaśnione, dlaczego te decyzje są jakie są. Jakie ryzyka, jakie aspekty, jakie być może alternatywne opcje zostały rozważone.

Jacek: Drugim takim alternatywnym sposobem podejścia do rozwiązywania problemów jest sytuacja w której rozwiązujemy problem tylko z częścią zespołu. Czyli jest to taki pewien stan pośredni, w którym włączamy zespół w proces decyzyjny, jednak nie dotyczy to włączenie literalnie każdej osoby w zespole. Czyli przykładowo jak mamy dziesięcioosobowy zespół no to my włączamy z tego zespołu jakąś reprezentację. Oczywiście tutaj sposób doboru tej reprezentacji zwykle jest dosyć kontekstowy. Natomiast z mojego doświadczenia najczęściej włączane są osoby, które mają większe doświadczenie, często zarówno większe doświadczenie zawodowe, ale w szczególności większe doświadczenie dotyczące na przykład konkretnego produktu czy konkretnego systemu, którym ten konkretny zespół się zajmuje. No i tak to zwykle gdzieś to między wierszami pada. Natomiast no zwykle ta decyzja jest podyktowana tym, że albo nie chcemy angażować całego zespołu i niektórzy wprost to nazywają – tracić ich czasu, ale też często pojawia się taki argument, że po prostu pewne osoby są jeszcze są zbyt świeże i zbyt mało doświadczone, żeby mogły podejmować na przykład jakieś decyzje architektoniczne w przypadku software’u, gdzie ktoś, kto ma piętnaście lat stażu w rozwoju jakiegoś konkretnego produktu jest w stanie spojrzeć z lotu ptaka i też wie gdzie można się potknąć, gdzie są pułapki i na co zwrócić uwagę.

Kuba: Wymieniamy tę opcję dlatego, żeby też jakby uczulić na to, że takie absolutne pojmowanie tego rozwiązania problemu całym zespołem nie przerodziło się właśnie w jakieś takie rozwiązywanie problemów na przykład architektonicznych przez analityka biznesowego, który po prostu już tak do końca merytorycznie nie wniesie do tego problemu nic, albo próba rozwiązywania problemów przez osoby, które za bardzo nie mają do tego serca i też nie czują, że dużo wniosą. Ale dla kontry jak już mówimy o tym, że rozwiązujemy problem z częścią zespołu to ja myślę, że takim pogodzeniem ognia z wodą może być zgoda całego zespołu, że rozwiązywany problem jest częścią zespołu. Czyli na przykład jak mówimy o perspektywie zespołu scrumowego to na przykład zgodzenie się na Retrospektywie, że tam dwóch najstarszych developerów spróbuje przeorganizować narzędziówkę w naszym procesie wytwarzania. No bo cała reszta ufa, że zrobią to dobrze, ale też wiedzą, że być może szóstej kucharki do tej potrawy nie potrzeba i sobie poradzą. Co możemy stracić, jeśli rozwiązujemy problem z częścią zespołu? Rozwiązujący są zbyt wąsko dobrani, zbyt wąsko postrzegają też ten problem. Rozwiążą go po swojemu, a może się okazać, że problem jeśli byśmy dorzucili jeszcze trochę różnorodności, rozwiązywany byłby trochę lepiej. I to jest ten pierwszy przypadek, gdy tak świadomie stawiam się gdzieś tam pośrodku, ale warto na pewno nie wpaść w żadną ze skrajności, szczególnie jak problem jest rozwiązywany nie całym zespołem, to znaczy, że to jest błędnie rozwiązywany problem.

Jacek: Ja bym tu jeszcze skomentował tak, bo z jednej strony faktycznie czasem to jest najmądrzejsze rozwiązanie, ale też tu kryje się pewna pułapka, że domyślnie odcinamy od podejmowania decyzji osoby, które nam się wydaje, że niewiele wnoszą. Też dla kontry wielokrotnie widziałem sytuację, kiedy te osoby potencjalnie zaklasyfikowane jako te osoby, które nic nie wnoszą, albo zadawały bardzo dobre pytania na zasadzie – nie rozumiem, więc mi wytłumaczcie, i nagle się okazywało, że te pytania są bardzo ożywcze w stosunku do dyskusji, albo osoby niedoświadczone konkretnie, na przykład w pracy z produktem w danej firmie przynosiły bardzo fajne doświadczenie z poprzednich organizacji. Nagle też się okazywało, że no w sumie fajnie, że ktoś tam dołączył, chociaż początkowo nie spodziewaliśmy się, że to przyniesie efekt. Tak więc jakby, no też ta sytuacja może być taka kontekstowa – no i na to warto zwrócić uwagę.

Kuba: Kolejną alternatywą do rozwiązywania problemów z całym zespołem jest taka świadoma decyzja, żeby pozostawić problem w zespole, mimo, że widzimy gołym okiem, albo mamy już doświadczenie, że zespół nic z tym nie robi. Nie rozwiązuje, nie widzi, nie traktuje jako poważny problem. Załóżmy, że jesteśmy na przykład Agile Coachem. Widzimy, że w zespole, któremu pomagamy, czy który wspieramy coś nie gra. Dla nas jest to ewidentne. Możemy, czy umiemy to nazwać. Może nawet znamy konkretne techniki, praktyki, które rozwiążą ten problem, a zespół delikatnie jakoś tak naprowadzany na problem tak naprawdę problemu nie widzi, odrzuca, albo po prostu nie wpada na żaden pomysł, że zna jakieś rozwiązania. Czyli w efekcie próba przekazania problemu do zespołu kończy się na tym, że zespół stwierdza, że problemu w ogóle nie ma. No i to jest bolesny moment, bo to jest taka trochę pułapka świadomości. Ja widzę, że problem jest, ale nikt inny go nie widzi. I teraz jakie są konsekwencje? Myślę, że konsekwencje tego to jest jeden z tych wymiarów, w których bym decydował, czy robię z tym coś więcej czy jednak decyduję się na tę alternatywę. Dobra świadomie zostawiam ten problem u Was, zgłosiłem go Wam, dałem Wam sygnał. Jeśli uznajecie, że ten problem nie jest istotny to znaczy, że macie rację. Myślę, że to jest możliwe wtedy, gdy czujemy jakie są takie reperkusje czy jaki jest skutek kontynuacji funkcjonowania tego problemu. Czy to jest jakaś drobna niedoskonałość komunikacyjna w zespole, to może nie ma żadnego kłopotu, ale jeśli to jest na przykład jakiś wielki case, który spowoduje, że ten projekt czy jakieś przedsięwzięcie, które ten zespół realizuje, albo kolejne wdrożenie kolejnej wersji produktu jest naprawdę super zagrożone. No idziemy wprost na czołówkę z rozpędzonym tirem, no to może to nie jest najszczęśliwsza opcja i może trzeba szukać innych spośród tych, które wymieniliśmy albo za chwilę jeszcze dopowiemy. Natomiast jeśli to są takie rzeczy i mamy czas na to, żeby te rzeczy sobie spokojnie dojrzewały, być może zespół jeszcze musi dojrzeć i odkryć, że problem jest to świadomie nie robienie nic, że zespół tego problemu nie widzi może być alternatywą – zwłaszcza z perspektywy osób, które są poza zespołem, na przykład Agile Coach, na przykład lider tego zespołu. Możemy wręcz robić krzywdę sobie, że mamy takie za duże zaangażowanie i za dużą chęć naprawiania świata. A ten świat jeszcze musi chcieć być naprawiony. W tym przypadku zespół być może musi na spokojnie dojrzeć i zrozumieć problem. I też może dojrzeć do tego, że trzeba go rozwiązywać.

Jacek: Ryzyko jakie widzę tutaj w tym wariancie jest takie, że znów w skrajnie przerysowanym przypadku, no to wszystko zostawiamy i mówimy – upadaj często, uczmy się na błędach. Jakby co do zasady bliskie mi są, powiedzmy strategie – tak to nazwijmy. Natomiast one działają, jeśli faktycznie się uczymy, jeśli faktycznie wyciągamy wnioski. Więc w skrajnym przypadku zostawianie problemów będąc w pozycji liderskiej i taka ślepa wiara w to, że zespół podejmie rękawice. Gdzie na przykład widać jak na dłoni, że zespoły nie podejmują tematu z różnych powodów. Nie dostrzegają, nie chcą, systemowo nie są do tego motywowani. Co najmniej myślę parę kolejnych opcji byśmy mogli dorzucić. No to też nie jest dobra strategia. Z boku ta strategia może być odebrana, że nic nie robimy będąc liderem nic nie robimy. Zobacz Rzym płonie, a Ty stoisz.

Kuba: Szczególnie nie pomoże, że powiesz – nie ja już od dwóch miesięcy widzę, że będzie pożar.

Jacek: Tak, to może to nie być odebrane pozytywnie. Tak więc tutaj też znów, to tak mówimy o alternatywach, a jednocześnie każda z tych alternatyw jest mocno kontekstowa. No ale tak to najczęściej to wygląda w praktyce. I też sobie też myślę, że każda z tych strategii wymaga indywidualnego przemyślenia i zastanowienia się co w tym naszym konkretnym kontekście ma sens szansę zadziałać, a co nie. Kolejną alternatywą do strategii takiej, gdzie włączamy zespół w rozwiązanie jest świadome doprowadzenie do sytuacji, w której zespół zaczyna dostrzegać problem. Czyli przykładowo, dostarczamy do zespołu jakieś konkretne dane, statystyki czy opcje i na bazie tego zespół stwierdza, że chyba mamy problem, chyba moglibyśmy coś poprawić. Taki absolutny klasyk, z którym się spotykamy bardzo często to jest sytuacja, w której prognozy zespołu, jeśli chodzi co zrealizują w trakcie Sprintu są nierealizowane. Na koniec Sprintu się okazuje, że zrobiliśmy tylko połowę tego co planowaliśmy, albo odkrywamy, że cała masa pracy jest w toku. Mamy pełno tematów rozgrzebanych, nieskończonych, poblokowanych. No i wtedy zamiast konkretnie nazywać ten problem możemy przedstawić zespołowi – zobaczcie, przeanalizowałem ostatnie pięć Sprintów, nasza przewidywalność wygląda tak, a nie inaczej. Średnio kończymy z ilomaś tam tematami rozgrzebanymi. Zwróćcie uwagę, że średnio trzy tematy na głowę ma każda osoba w zespole i tak dalej. Pokazujemy to. Zwykle to na bazie moich doświadczeń wywiązuje się jakaś dyskusja. Czasem to jest podchwytywane automatycznie, szybko, na zasadzie tak, to jest problem. Czasem mam wrażenie, że te dane nie robią na zespole wrażenia. No i to znów oczywiście jest mocno kontekstowe, zależy od kultury organizacji, od dojrzałości zespołu, od tego, kto tym zespołom przewodzi. Natomiast jest to uważam bardzo fajny sposób, że też taki na meta poziomie sposób, który rozwija zespół w kontekście takiego dostrzegania pewnych rzeczy, nie tylko co robimy, ale też jak pracujemy.

Kuba: No i ja uwypuklę czym to co teraz proponujesz różni się od zabrania problemu do zespołu. Załóżmy, że zespół – ciągnąc dalej Twój przykład, że zespół ma problem z dowożeniem, może nie dowożeniem, bo to nie było to, realizowaniem swoich planów czy jakichś tam prognoz, to można do zespołu przyjść i powiedzieć – słuchajcie, nie realizujecie prognoz, i rozwala nam się z tego powodu Sprint i rozwala nam się z tego powodu też jakiś tam większy plan. No a może można od razu przyjść do zespołu i pokazać to, jak Ty o tym opowiedziałeś, czyli jest zagrożenie, że jeśli tak po prostu spróbujemy do zespołu podejść i przykleić karteczkę na koszulkę – masz ten problem, to karteczka może spaść. Prawdopodobieństwo, że karteczka spadnie jest trochę mniejsze, jeśli podeprzemy się konkretami, faktami i to takimi faktami, z którymi trudno dyskutować, czy trudno jakoś inaczej interpretować. I czasami my te statystyki, dane czy jakieś takie opisanie pewnego zjawiska mamy, a czasami takim powiedzmy w pierwszym kroku, jeśli byśmy chcieli regularnie stosować tę alternatywę no to będzie po prostu uruchamianie pewnego procesu mierzenia. Fajnie jeśli to firma wspiera, fajnie, jeśli zespół ma też tego typu nawyki, więc wtedy to będzie dosyć naturalne, że zanim zaczniemy rozwiązywać problem, to się przyjrzymy jaki jest stan aktualny, no a czasami to może będzie rola taka powiem – zakulisowa, czy to Scrum Mastera, czy Agile Coacha, czy lidera zespołu, żeby sobie troszkę nazbierać pewnych faktów i żeby potem przyjść do zespołu, żeby też ta skuteczność rozwiązywania problemów była trochę wyższa.

Jacek: Chyba też tak kontekstowo dodam, że czasem może nie być czasu na to, żeby – no bo ja to postrzegam jako taka inwestycja w świadomość zespołu, no, jeżeli nie wiem, płonie środowisko produkcyjne, albo Klienci nas zasypują zgłoszeniami, że coś nie tak jest z naszym produktem, no to może to nie jest ten czas, kiedy będziemy inwestować w rozwój samoświadomości, no bo wtedy musimy szybko reagować. Tak więc na ten aspekt zwróciłbym uwagę.

Kuba: Zdecydowanie się zgadzam. Mogą też być takie sytuacje, że rozwiązywanie problemów przez sam zespół nie jest do końca możliwe, dlatego, że nie znają rozwiązań na taki problem. I to już nie istotne czy to tak bardziej tak bardziej coachingowo na to spojrzymy, że w środku ten problem mają tylko trzeba go wygrzebać, czy tak autentycznie po prostu prosty dla mnie przykład, którego teraz użyję to jest zespół, który dopiero startuje z wykorzystaniem Scruma. Codzienny Scrum stosują tak jak go usłyszeli na szkoleniu, albo tak jak zrozumieli, że trener przekazywał. No i to wydarzenie tak nie za bardzo spełnia swoją funkcję, jest takie sztuczne i nie za bardzo widzi zespół, że to wnosi wartość. Nawet może i umieją czy zgodzą się z problemem, że tak trochę marnujemy czas i nie za bardzo mają pomysł jak to zrobić inaczej, nie znają alternatyw już takich, merytorycznie nie umieją sobie spróbować inaczej. No i niektóre zespoły po prostu pójdą na żywioł, po prostu sobie coś wymyślą, ale inne zespoły nie będą miały w sobie tyle dojrzałości. Być może nie będą miały w sobie tyle odwagi. Wtedy ja proponuję taką alternatywę, którą sam poznałem w czasie kursu coachingu, który zresztą z Jackiem razem przechodziliśmy. Coś, co nasza mentorka nazwała „chińskim menu”. Czyli jak już musimy dawać komuś rozwiązania to dajmy ich wiele. Tak jak chińskie menu, czy menu w chińskiej restauracji czy jakiejś azjatyckiej kuchni, no po prostu jest pełno tego. Trudno odróżnić co się różni jedno od drugiego. Natomiast na przykład wracając do tego konkretnego case’a z Daily zespół średnio realizuje Daily no to zaproponujmy trzy rozwiązania albo pięć rozwiązań na to jak Daily mogłoby wyglądać inaczej. Siłą rzeczy żadne z tych rozwiązań nie jest tak przez nas mocno preferowane czy podsuwane. Więc unikamy tego problemu, że zespół nie przyjmie tej jednej jedynej słusznej sugestii, którą my im dajemy, a spośród tych opcji pokazujemy, że jest możliwość kombinowania, że jest kilka alternatyw. Być może zespół uruchomi jakiś tam proces hybrydowego łączenia różnych pojęć. I dlaczego takie chińskie menu? My wtedy nie ponosimy odpowiedzialności za proponowane rozwiązanie i też troszkę zmniejszamy prawdopodobieństwo, że zespół odrzuci to jedno jedyne, które mamy, a jeśli jeszcze zadbamy o to, żeby ta szerokość tego menu była naprawdę duża, mamy naprawdę dużo różnych rozwiązań no to tak naprawdę też być może unikamy też tej opcji, że to mi się nie podoba, to już próbowaliśmy. No a jak tych rozwiązań jest pięć to jest spora szansa, że coś spośród tego, co wymienimy będzie się podobało.

Jacek: No jak tak o tym mówisz to tak sobie pomyślałem, że to chińskie menu może w jakiejś określonych kontekstach być ograniczone chińskim menu. W sensie takim, że prezentujemy zespołowi możliwe opcje, jednocześnie nie prezentujemy opcji, które nie są w ogóle możliwe. Tak więc możemy jednocześnie wykluczać opcje, na które jesteśmy jako organizacja gotowi, albo chętni, a z drugiej strony nadal wciągać zespół w proces podejmowania decyzji, co również bym zaliczył jako takie działanie, które ma na celu podniesienie świadomości zespołu, czy budowę takiej odpowiedzialności zespołowej za podejmowane decyzje, bo to ma też wpływ na postawę taką zwykle bardziej proaktywną, gdzie zespół zaczyna się angażować, przejmować i brać odpowiedzialność. W kontrze do stanowiska w którym po prostu czekają, aż ktoś podejmie decyzję no i tyle. No i tak naprawdę będzie decyzja – dobrze, nie będzie decyzji też dobrze. Tak więc raczej tutaj z Kubą mamy podobne patrzenie na zespół jako taka jednostka, która bierze odpowiedzialność za produkt no i stara się, żeby ten produkt pod wieloma aspektami po prostu wypadał jak najlepiej.

Kuba: Ja może jeszcze dopowiem jedną rzecz, dlaczego to „chińskie menu” różni się od „Take it to the team”? Bo mimo wszystko i to zwłaszcza w tej Twojej kontrze czy dopowiedzeniu to wybrzmiało – mimo wszystko osoba, która to „Chińskie menu” prezentuje ma kontrolę nad tym, co prezentuje. Czyli to już nie jest ten przypadek – słuchajcie, wrócę do Twojego przykładu, słuchajcie macie problem z realizowaniem prognozowanego planu i powiedzcie jakie macie rozwiązania tylko raczej słuchajcie, zespoły, które mają problemy z realizowaniem prognoz rozwiązują to w następujący sposób. Limitują sobie pracę, przebudowują Daily, robią to, robią tamto, drobniej planują zadania i jeszcze z trzy inne wymyślę teraz na poczekaniu, ale nie będę ich teraz produkował. Czyli pokazujemy dosyć szerokie spektrum, ale tak jak mówiłeś to spektrum już jest dookreślone, czyli tu nie ma takiej dużej dowolności. Czyli znowu to takie absolutne, że zespół sobie wymyślił problem i rozwiązanie nie następuje. Mimo wszystko mamy tu pewną kontrolę. Kontrola, która jest też odpowiedzialnością. Czyli po pierwsze fajnie byłoby, żebyśmy sami w ogóle znali takie „Chińskie menu”. To jest taki niekończący się wyścig o szukanie różnych alternatyw i opcji na te wszystkie podstawowe rzeczy, a nie takie podejście „One-trick pony”, że jak robię Daily to zawsze tak. Retro to zawsze tak. Backlog to musi mieć taką formę. To jest naturalny odruch u osób, które dopiero zaczynają, ale nawet jeśli już się czujemy komfortowo z tym, co znamy to dalej bym szukał różnych alternatyw. Nie po to, żeby nimi błyszczeć, albo na siłę używać różnych, ale żeby w ogóle zdawać sobie sprawę, że są. Gdy przyjdzie taka sytuacja, o której tu mówimy i musimy to „Chińskie menu” zaprezentować.

Jacek: Mówiliśmy o bardzo różnych alternatywach z Kubą przed chwilą i też trochę wybrzmiewały takie aspekty, kiedy byśmy konkretną strategię zastosowali, a kiedy nie. No i teraz chcielibyśmy uporządkować trochę tę wiedzę, czyli podzielić się z Tobą taką skalą pewną, czy wymiarami, czy aspektami, które bierzemy pod uwagę, kiedy podejmujemy decyzję w jakim stopniu zespół angażować, albo nie angażować. Co byś Kuba wymienił na pierwszym miejscu.

Kuba: Ja myślę, że na pierwszym miejscu najbardziej się przejawiał temat dojrzałości zespołu. Dojrzałości zespołu rozumianego jako, jak dojrzałym zespołem jako ekipa, jako drużyna jesteśmy. Jak daleko jesteśmy w procesie grupowym. Czy już umiemy ze sobą rozmawiać? Czy się zżyliśmy? I czy umiemy sobie szczerze dawać feedback? Im bardziej dojrzały zespół tym czuję, że dużo da się z zespołem zrealizować. Ten mniej dojrzały zespół, zespół, który dopiero się związuje – on po prostu jakby w naturalny sposób ma problemy, czy takie powiedzmy jeszcze swoje niedoskonałości, które utrudniają te najbardziej przekazywane metody do zespołu i być może jest jeszcze czas, żeby dojść z tym zespołem do tego momentu, ale te niedojrzałe zespoły być może mogą podejmować decyzje, mogą jakimiś podgrupami, a może nawet mogą mieć narzucane mieć te decyzje przy tej podpórce, o której wspominałem z wyjaśnieniem, ale jednak ze wskazaniem, dlaczego jest jak jest.

Jacek: Komentując i może tak rozszerzając jakieś taki praktyczny przykład czy taką moją obserwację, którą mam to bardzo często na początku zespołom brakuje dwóch aspektów, tak myślę sobie. Pierwszy to jest otwartość. Otwartość na inne pomysły i to jest połączone z odwagą. Czy ja jestem gotowy podzielić się pomysłem i ewentualnie usłyszeć, że ten pomysł jest nie ok. Tak, więc jeżeli te dwa aspekty nie są zaopiekowane, a nie spodziewałbym się, że w grupie osób, która jeszcze nie jest zespołem, że one będą zaopiekowane, no to nie wypłynie z tego jakaś niesamowita dyskusja, no bo ludzie na początku będą trochę poblokowani, trochę jeszcze niepewni co mogą powiedzieć, czego nie mogą, co jest akceptowalne w zespole, co nie. Też trochę lęk jak zostaną potraktowani przez resztę osób w zespole. Tak więc ta dojrzałość, tu się absolutnie zgadzam – ona ma, jakby im bardziej zespół jest dojrzały, tym te dyskusje są bardziej otwarte, nawet jeśli masę rozwiązań odrzucamy, no to to jest po prostu dla nas OK.

Kuba: Ale można pójść za daleko w tym naszym zrozumieniu tego, co do tej pory powiedzieliśmy. Bo dojrzałość zespołu też się buduje na takich sytuacjach. Więc tutaj jesteśmy tak naprawdę na takiej powiedzmy granicy pomiędzy niedojrzałością, a dojrzałością, albo gotowością lub nie gotowością do rozwiązywania trudnych problemów. Coś, co mnie czasem niepokoi to to, że są liderzy albo Scrum Masterzy w zespołach, którzy zakładają, że zespół jest niedojrzały, więc nie dopuszczają do tych trudnych sytuacji, które tę dojrzałość trochę przesuwają. To też znowu nie jest takie absolutne, czy nie ma miejsca na taką radę, że skoro masz niedojrzały zespół to zawsze podejmuj za nich decyzję, bo może się okazać, że dzięki zastosowaniu tej porady wyrwanej z kontekstu już zawsze będziesz mieć niedojrzały zespół, bo zespół się czuje komfortowo, wtedy gdy nie podejmuje czy nie angażuje się w żadne trudniejsze rzeczy.

Jacek: Swoją drogą ten odcinek dobrze pokazuje temat złożoności, to ile kontekstu dzisiaj wymieniliśmy pokazuje tylko na przykładzie tylko na przykładzie podejmowania decyzji w zespole w jak zwykle złożonym środowisku przychodzi nam pracować. Drugi taki wymiar, który też już wymieniliśmy i tak dla podsumowania chcielibyśmy, żeby wybrzmiał to jest pilność konkretnej inicjatywy, którą realizujemy. Czyli tak jak wspomniałem, jeżeli mamy nóż na gardle, jeżeli mamy jakieś takie konkretne terminy, zobowiązania, albo sytuacja jest awaryjna w stylu pożar w budynku. No to wtedy być może sensowniej byłoby zastosować jakieś konkretne rozwiązanie, wskazać, pomóc, wesprzeć niż spokojnie sobie narysować sytuację przed zespołem i milcząco siedzieć i czekać na reakcję. Tak więc w sytuacjach takich kiedy – to nawet zahaczę o Cynefin’a, o taką sytuację, kiedy mamy do czynienia z chaosem, no to wtedy potrzebne jest przede wszystkim działanie, a dopiero kiedy sytuacja się uspokoi, w sensie ta złożoność się zmniejszy no to wtedy możemy sobie tę przestrzeń na angażowanie kształtować. Natomiast też jasno warto sobie to  powiedzieć czasem będzie potrzeba, żeby ktoś wszedł, podjął decyzję, popchnął zespół w jakimś konkretnym kierunku, no bo alternatywnym scenariuszu zbyt długie podejmowanie decyzji może doprowadzić do sporych strat.

Kuba: Albo wręcz ignorowanie, że problem istnieje, a w tym czasie Klienci nie mogą skorzystać z naszego produktu. Z technik, następnym takim wymiarem jest umiejscowienie w organizacji tego do tej pory za mocno nie zaakcentowaliśmy. Tutaj z Jackiem zaraz to dopowiemy jeszcze mocniej o co nam chodzi, ale tutaj między innymi jest taka przestroga, czy jest taka obawa, że jeśli jesteśmy w organizacji daleko od zespołów, to pojawia się takie zagrożenie rozwiązujemy problemy za zespół, zamiast pozwolić, żeby coraz częściej zespoły te problemy rozwiązywały. Dlaczego tu jest zagrożenie? Bo może się okazać, że ta rzeczywistość, którą my widzimy, naszą optyką miejsca w organizacji nie jest tym, co podzielają zespoły. Zwłaszcza w organizacjach wypiętrzonych, takich większych – jeśli chodzi o struktury, ale też w organizacjach, które mają więcej warstw w hierarchii może się okazać, że taki naturalny odruch do brania odpowiedzialności za pewne decyzje na siebie mogą powodować, że konsekwentnie odlepiamy się  od rzeczywistości, ale też nawet tracimy po prostu zespoły. Więc wraca jednak koncepcja, że bądźmy na to czuli czy to jak widzimy firmę jest tym jak widzą tę firmę zespoły i nie dziwmy się, że jeśli my podejmujemy decyzję naszą. Zespoły później się niestety nie do końca angażują w te pomysły, które my sobie sami wymyślamy. Na przykład z samego szczytu centrali, z najwyższego piętra naszego biurowca.

Jacek: I tutaj takim pośrednim wymiarem, który mi przyszedł do głowy jest też wymiar kultury organizacyjnej. Czyli przykładowo – możemy pracować w kulturze, w której wizerunek managera to jest taki manager, gdzie on podejmuje decyzje odważnie, zawsze tym jest takim absolutnym liderem. Taka kultura jakby domyślnie nie wspiera tego, żeby te kompetencje takie brania odpowiedzialności rozwiązywania problemów budować w zespole. Tak więc chcąc nie chcąc bardziej świadomie lub mniej świadomie możemy kultywować kulturę, w której twardy management rozwiązuje problemy.

Kuba: Rozwiązuje je nieomylnie.

Jacek: Nieomylnie, albo nawet jak się myli no to tak ma być. W sensie managerowie podejmują decyzje. Tak więc na to też warto zwrócić uwagę, czy pracujemy w takiej kulturze, a po diagnozie warto też się zastanowić czy chcemy utrzymać ten wymiar kultury w stanie niezmienionym, czy być może mamy apetyt na przekazanie nieco większej odpowiedzialności zwykle w dół hierarchii. Kolejnym aspektem jest doświadczenie członków zespołu. O tym sporo mówiliśmy. Taki przykład z mojego doświadczenia jest taki, że czasem osoby, które pracują w zespole mają niedostatecznie duże doświadczenie, żeby podejmować decyzje, które mają strategiczny wpływ na nasz produkt. No i tutaj jakby pracując – tak przerysowując – pracując z zespołem osób o bardzo małym doświadczeniu no też nie możemy się spodziewać, że pewne problemy dostrzegą czy rozwiążą, bo po prostu mogą mieć niedostatecznie duże doświadczenie zawodowe. Po prostu z pewnymi problemami się jeszcze nie spotkali i to jest ta grupa problemów, których trzeba doświadczyć, żeby móc potem wykorzystać tę wiedzę w praktyce. Z drugiej strony im bardziej  doświadczony zespół ekspertów, tym bardziej ja osobiście nie miałbym problemu, no to, żeby to eksperci, których mamy w zespole podejmowali decyzje. No bo de facto po to taki zespół sobie konstruujemy z wszystkimi potrzebnymi kompetencjami, no, żeby rozwiązywali problemy i nie potrzebowali osoby, która będzie te problemy rozwiązywać za nich.

Kuba: I w tym obszarze akurat dobrym przykładem jest jedna z rzeczy, która jest czasami kojarzona jako mit podejścia zwinnego, że architektura jest niewskazana w podejściu zwinnym. Co iteracje ma powstawać kolejna wersja i będziemy robić sobie kolejne wersje zupełnie bez głowy. Po pierwsze to jest mit, ale tego nie będę rozszerzał. Natomiast to jest przykład takiego zagadnienia, w którym naprawdę trzeba mieć – w ogóle głowę do takich rzeczy, ale też pewien bagaż. Pewien bagaż również niepowodzeń, żeby zacząć doceniać pewną wizję architektoniczną rozwiązania, pewne decyzje co do konkretnie zastosowanych podejść, narzędzi, bibliotek, jakichś styli. I to wszystko powoduje, że być może głos różnych osób w zespole będzie po prostu różnie słyszany i prawdopodobnie te doświadczone osoby no będą wysłuchane trochę mocniej, a niedoświadczone może nawet nie będą miały opinii i nie ma co się silić. Nie ma co tutaj robić jakiejś fałszywej demokracji. Częścią samoorganizacji również będzie decyzja w zespole, że autentycznie jeden z nas się na tym świetnie zna i po prostu poprowadzi nas dalej w tym kierunku. Natomiast ostatni w tej skali, którą tutaj produkujemy od ostatnich kilku minut to też jest taki wymiar – czy zespół widzi problem, albo w jakim stopniu zespół widzi problem. Czasami będzie tak, że często będzie tak – mówiłeś o złożoności, że problem ma wiele warstw, to znaczy widzimy pewien symptom, pewną taką oznakę zewnętrzną, na przykład jest nudne Daily. No ale wewnątrz tego będzie więcej problemów, bo może Daily jest tylko pokłosiem tego, że źle planujemy pracę, bo nie mamy dobrego Backlogu Produktu. Nie mamy dobrego Backlogu Produktu, bo mamy kiepsko zaangażowanego Product Ownera. Mógłbym ciągnąć ten łańcuszek o wiele dalej. Czasami zespół będzie widział tylko te powierzchowne rzeczy. I wtedy takie przerzucenie odpowiedzialności całkowicie na zespół może być taką pułapką, że zespół tylko te powierzchowne rzeczy będzie sobie rozwiązywał. Może porzucał Scruma, bo mamy słabe Daily? To jest akurat radykalny przykład, ale też jakoś kombinował nie na tej warstwie z rozwiązaniem problemu i się ciągle dziwił, że im to nie wychodzi. Bo nawet jak znajdą dobre rozwiązanie na trochę lepsze, fajniejsze Daily, no to dalej nie będą dowozić, bo Product Owner nie ma czasu na to, żeby autentycznie zarządzić produktem. I wtedy może się okazać, że taka wiara w to, że zespół sam rozwiąże problem – wprowadzi nas w pułapkę. No oczywiście są w tym momencie pewnie są wtedy dobre te alternatywy, żeby doprowadzić do sytuacji, że zespół problem dostrzeże na tym głębszym poziomie. A niekoniecznie wtedy za nich całkowicie rozwiązywać jakieś zagadnienia.

Jacek: Na koniec odcinka chcielibyśmy zaprosić Cię do wypełnienia ankiety, którą od jakiegoś czasu już udostępniliśmy dla naszych słuchaczy. Jest to ankieta, w której chcemy poznać Twoją opinię dotyczącą podcastu i chcemy też usłyszeć od Ciebie czego potrzebujesz, jakie tematy są dla Ciebie bardziej interesujące, jakie mniej, żebyś mógł mieć lub mogła mieć realny wpływ na kształt merytoryczny naszych audycji. Jednocześnie chciałbym w Kubą podziękować osobom, które już wypełniły ankietę. Spłynęło kilkadziesiąt już ankiet. Bardzo dziękujemy, a jednocześnie zachęcić osoby które tego jeszcze nie zrobiły do odwiedzenia strony porzadnyagile.pl/ankieta. Deadline na wypełnienia ankiety do 8 lipca. Tak więc zapraszamy z Kubą do podzielenia się swoimi przemyśleniami odnośnie podcastu na porzadnyagile.pl/ankieta.

Kuba: A jak jesteśmy w takiej sekcji mikro ogłoszeń parafialnych to też zachęcam do rzucenia okiem na nagranie wideo z tego nagrania odcinka. Kolejny przyrost lub iteracja, w zależności, w którą wersję wierzymy, jakości tego materiału. Ja mam trochę lepszą kamerkę, Jacek ma trochę lepsze oświetlenie. Staramy się, żeby również ta wersja wideo była dla Was atrakcyjna, więc jeśli możesz to rzuć okiem, czy czasami taka forma nie jest dla Ciebie lepsza. A jeśli masz jakieś uwagi to również to jest dokładnie temat na ankietę.

Jacek: Wideo oczywiście można zobaczyć na YouTube. I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.

———

To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę!