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 rozw