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.

Zobacz wersję wideo

TRANSKRYPCJA

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.