Co jest groźnego w zespołach wsparcia i koordynacji?

W organizacjach, w których pracowałem i w tych, z którymi współpracuję jako konsultant, od czasu do czasu napotykam wzorzec organizacyjny zespołów wsparcia i koordynacji projektu. Zespół taki budowany jest w przypadku, gdy realizowane jest jakieś większe przedsięwzięcie (projekt, program), zaangażowanych jest co najmniej kilka zespołów i oczywiste jest dla kierownictwa firmy, że w takiej sytuacji „musi” być ktoś, kto „ogarnie całość” przedsięwzięcia. Mam tu na myśli organizacje, które są jeszcze w trakcie uczenia się podejścia zwinnego i nie ma w nich jeszcze zaufania albo kompetencji w skalowanym podejściu do zwinności. Powstaje funkcja albo grupa funkcji w stylu koordynatora czy kierownika projektu, jakieś role dodatkowego wsparcia zespołów (zapewnienia jakości, utrzymania architektury, spójności biznesowej). Z perspektywy zwinnego podejścia i konkretnych metod skalowania automatyczna reakcja niejednego agile coacha to sugestia, żeby kompletnie usunąć te dodatkowe funkcje. Sam też mam takie preferencje, ale w codziennej pracy z zespołami i menedżerami nie zawsze uda się przekonać do rozwiązań, które uznają za zbyt ryzykowne i niezgodne z ich intuicją. W tym wpisie zahaczę kilka powodów, dla których uważam takie pomysły za niebezpieczne z perspektywy zwinności i podpowiem kilka kierunków, jakimi można takie struktury usprawnić (metodą małych kroków i ewoluowania tych struktur we właściwszą stronę).

Co jest pułapką w wydzielonych zespołach koordynacyjnych?

  • Pośrednictwo w przepływie informacji – Najzwyczajniej w świecie przy każdym kolejnym przekazaniu informacji gubi się jakiś fragment oryginalnego komunikatu przez zjawisko „głuchego telefonu”. I nie ma znaczenia, czy postaramy się, żeby komunikacja była jednoznacznie spisana, przekazana bezpośrednio, zebrana w jakieś schematy czy modele – koordynator ma w zamierzeniu często poprawić komunikację między zespołami, ale przez fakt swojego istnienia tę komunikację również bezwiednie pogarsza. A w realiach dużych organizacji niestety ten efekt trzeba przemnożyć przez filtrowanie informacji takie jak w uproszczeniu poniżej:
    1. zespół do PMa – nie zdążymy na termin
    2. PM do dyrektora – być może nie zdążą na termin
    3. dyrektor do zarządu – jest zagrożenie, że nie zdążą, ale postaramy się
      Brzmi idiotycznie? To czemu ciągle to spotykam?
  • Podział odpowiedzialności – Stworzone struktury wsparciowo-koordynacyjne mają w zamierzeniu poprawić odpowiedzialność za jakieś ważne aspekty realizacji projektu (np. jakość rozwiązania, architekturę, zarządzenie zależnościami). Rozpatrując pracę wyłącznie osób wchodzących w te role możemy dojść do wniosku, że jest lepiej – w projekcie pojawiają się osoby, które się przejmują, wykonują świadomie wyłącznie te prace, do których zostały powołane, czyli obszar jest zadbany. Czy to jest cały obraz sytuacji? Oczywiście, że nie. Bo na każdego mocno przejmującego się PMa w projekcie znajdziemy w zespołach 10 developerów, którzy przestają się przejmować kompletnie. Zjawisko się spotęguje szczególnie wtedy, gdy osoby ze specjalnie wyznaczonymi odgórnie zadaniami mają postawy monopolistyczne – nie pozwalają innym wykonywać podobnych zadań (w imię czystości podziału obowiązków) a w niektórych przypadkach niestety nawet nie pozwalają mieć innych opinii i stawiają się względem innych w pozycji wyższej – „o architekturze decyduję ja, wy macie wykonać bez szemrania”. I mamy w efekcie podobny paradoks jak w pierwszej pułapce – by zapobiec obojętności członków zespołu na jakiś ważny aspekt powołujemy specjalną funkcję, która źle zrealizowana powoduje… jeszcze większą obojętność członków zespołu na ten ważny aspekt!
  • Plastrowanie braku decyzyjności – Gdy z zaciekawieniem drążę konieczność powoływania odrębnych struktur koordynacyjnych, częstym argumentem, jaki spotykam, jest to, że w ramach istniejących zespołów i ról czysto-scrumowych mamy niewystarczającą decyzyjność. Product Owner nie ma wizji, członkowie zespołu nie patrzą wystarczająco szeroko, więc potrzebne jest powołanie osób do uzupełnienia tych braków. Czujny czytelnik przewidzi co zaraz napiszę – znowu wywołany jest paradoks, ponieważ na braki w decyzyjności na pewno nie pomogą kolejne warstwy komunikacyjne i kolejne osoby po trochu odpowiedzialne za elementy całego projektu. Jak definiujemy braki decyzyjne to zróbmy coś z tymi rolami, które już mamy, a nie dokładajmy kolejne warstwy plastrów przykrywających oryginalne problemy.
  • Kopiowanie starych rozwiązań – (pułapka z trochę innego poziomu logicznego, niż trzy poprzednie) Kierownictwo firmy skonfrontowane z  takimi samymi problemami jak w przeszłości (przed wykorzystaniem zwinnego podejścia nawet na poziomie zespołu wytwórczego) uruchamia te same rozwiązania, jak zawsze – powołanie PMa, PMO, zespołu wsparcia, głównego architekta, Komitetu Sterującego itd. Zamiast bezrefleksyjnego skopiowania takich podejść (które swoją drogą doprowadziły przecież do sformułowania Manifestu Zwinnego Wytwarzania Oprogramowania ze swoją samoorganizacją, bezpośrednią komunikacją między developerem a biznesem, przyrostowym dostarczeniem rozwiązania itd. itp.) należałoby chociaż w minimalnej wersji zastanowić się, co jest w realiach danego przedsięwzięcia potrzebne, jakie problemy danym rozwiązaniem chcemy usunąć, jakie są ryzyka istnienia danych ról czy struktur. Nie każę od razu wskakiwać w jakieś nexusy czy lessy (czyli z perspektywy początkujących w zwinności metody kompletnie szalone i nierealne w danej firmie), ale zastanówmy się choć w minimalnym stopniu po co jakieś struktury, role czy procesy powołujemy i czy to nie jest skrót myślowy „zawsze tak robiliśmy”, bo ktoś wtedy może czujnie skwitować „i ten projekt też nam wyjdzie jak zawsze”.

Jak ewolucyjnie usprawnić zespoły wsparciowo-koordynacyjne?

Gdy wchodzę do projektu, który już biegnie albo kierownictwo decydujące o strukturach projektu nie jest chętne do odejścia od utartych ścieżek, mam w praktyce kilka kierunków, w których staram się ewoluować takie grupy:

  • Eksploracja różnych opcji organizacyjnych – Warto przemyśleć jakie są możliwe rozwiązania na dane zagadnienia: jak ten temat załatwia „czysty Scrum”, co proponuje Nexus, LeSS, jak sobie z tym radzą w modelu Spotify czy nawet SAFe. Warto mieć przed oczami wiele praktyk, by nie wpadać w jedyną słuszną dla danej organizacji, zwłaszcza jeśli inne modele podpowiadają alternatywy, które lepiej oddają ducha zwinności. Gdy poszerzymy sobie paletę rozwiązań, możemy też spróbować świadomych eksperymentów – zaczerpnięcia praktyk i uważnego obserwowania efektów pożądanych i niepożądanych, ze szczególną czujnością na efekty niespodziewane. Obawiamy się, że mamy niedecyzyjnego PO – spróbujmy mu dać władzę do decydowania i zaobserwujmy jakie da to efekty. Boimy się, że bez centralnego architekta poza zespołami nie powstanie architektura – stwórzmy community albo forum kodujących architektów z zespołów i obserwujmy ich współdziałanie i rezultaty ich pracy w powstającym produkcie.
  • Eliminacja pośrednictwa – Jak najwięcej działań powinna być realizowana bezpośrednio między zainteresowanymi stronami. Nawet jeśli mamy jakieś dedykowane role, niech ich zadaniem będzie organizowanie okazji do wymiany informacji i dbanie o to, że ona się faktycznie dzieje a nie proste pobieranie i przekazywanie komunikatów (niektórzy zgryźliwie takie funkcje nazywają forward manager). Wielkim wyzwaniem dla takich ról koordynacyjnych będzie zorganizowanie swoich działań efektywnie, zwłaszcza łatwo wpaść w pułapkę nudnych spotkań, które nie prowadzą do niczego konstruktywnego. Jest spora szansa, że jeśli mamy do czynienia z projektem realizowanym zwinnie, znajdziemy gdzieś Scrum Mastera albo Agile Coacha, który powinien wspomóc swoim warsztatem facylitacyjnym. Inna sprawa, czy faktycznie wymiana wiedzy poprzez spotkania to jest konieczne rozwiązanie – można również stosować radiatory informacji (jakieś tablice, dashboardy elektroniczne czy plakaty, które dostarczają te same komunikaty),  czy przebudować zespoły tak, by jak najwięcej komunikacji odbywało się wewnątrz danego zespołu w ramach daily i pracy w sprincie.
  • Dobre wspólne Review – Wiele argumentów o konieczności koordynacji zespołów podpartych jest argumentem „bo nie ma wiedzy między zespołami co robią inni”. Zachęcam do eksperymentowania z formułą międzyzespołowego Review – prezentowania w jakiejś bardzo sprawnej formie efektów pracy wszystkich zespołów zaangażowanych w dane przedsięwzięcie i wzajemnego komentowania sobie postępów w pracy. Jest to świetny moment, by propagować informację o nowych priorytetach biznesowych, zwracać uwagę na problemy technologiczne, konkretnie pokazać jakieś mierniki istotne dla sukcesu całego projektu (efekty biznesowe pierwszych etapów, budżet, postęp pracy związanych z przygotowaniem wdrożenia itd.). Takie dobre review może być dobrą motywacją dla wszystkich zespołów (nikt nie chce wypaść źle przed kolegami z innych ekip), może też być miejscem, na które warto zaprosić interesariuszy, by z pierwszej ręki dowiedzieli się jaki jest faktyczny postęp prac. Z doświadczenia wiem, że pierwsze próby takie Review będą słabe – ale jeśli się dobrze wczuć w konieczność jego usprawnienia, to szybko pojawią się dodatkowe potrzebne zmiany w sposobie pracy, które poprawią zarówno samo Review jak i ogólnie pracę wszystkich zespołów (np. stworzenie lub poprawienie Continuous Integration, zbudowanie wspólnych standardów jakości, UX, dokumentacji itd.).
  • Prostota struktur – Łatwo zagubić się w koncepcji dokładania kolejnych specjalistów, ekspertów i kierowników odpowiedzialnych za jakiś ważny obszar dużego przedsięwzięcia, trudniej pomyśleć w stronę przeciwną – jak możemy to rozwiązać najprostszym środkiem. Kierownik projektu nie wyrabia się ze spotkaniami – zamiast dokładać drugiego może poszukajmy takiego odchudzenia procesów zespołowych czy ogólnofirmowych, żeby tych spotkań tyle nie było.
  • Zespół jako podstawowa jednostka – Warto dążyć do tego, by podstawową jednostką organizacji był zespół i zdać się na samoorganizację wewnątrz niego (i w drugim kroku – pomiędzy zespołami). Zamiast tworzenia osobnych ról, zachęcam do eksperymentu polegania w tych sprawach na zespole, ewentualnie motywowania zespołu do brania większej odpowiedzialności za całość efektu.Jeśli zespół nie ma chęci odpowiadać za jakieś działania, warto sprawdzić czy ma potrzebne kompetencje – może trzeba je wzmocnić w istniejących osobach, a może jakiegoś członka zespołu trzeba dołożyć. Jako Agile Coach nie widzę problemu w tym, żeby w ramach samoorganizacji jednym z członków zespołu wytwórczego był Kierownik Projektu, Architekt Korporacyjny czy inny rzadki specjalista. Zespół w naturalny sposób będzie oddawał takiej osobie zadania z jej specjalizacji. Przy założeniu, że będzie na równych prawach względem pozostałych członków – jest szansa, że ten rzadki specjalista wykona również działania spoza swojej specjalizacji albo zostanie wsparty w swoich prostszych działaniach przez innych. Klasyczny przykład T-Shaped Skills, jaki łatwo propagować pomiędzy programistami i specjalistami QA, a moim zdaniem działa również przy kolejnych specjalizacjach, nawet tych najrzadszych w organizacji.
  • Wzmacnianie Product Ownera – wiele powodów, dla których organizacje tworzą struktury wsparciowo-koordynacyjne prowadzi po lekkim śledztwie do stwierdzeń, że przy danym Właścicielu Produktu kierownictwo nie ma zaufania, nie wierzy, że dana osoba (/grupa osób) sobie poradzi z całością przedsięwzięcia. Temat można rozwiązać co najmniej na trzy sposoby inne, niż dokładanie do takiej osoby Project Managera czy Lidera Technicznego:

    • dać więcej zaufania tej osobie, pozwolić jej rozwijać się w trakcie projektu. Ten konkretny projekt pewnie będzie z tego powodu trochę cierpiał, ale długofalowo budujemy sobie w firmie kompetentnych liderów biznesowych, z szerokim horyzontem i umiejętnościami. Jeśli w ramach rozwoju dana osoba zauważy braki teoretyczne – warto też zainwestować w profesjonalne kształcenie takiej osoby (niestety często widzę, że od osób biznesowych oczekuje się rozwoju bez dania przestrzeni na to w codziennej pracy…)
    • wstawić w rolę PO osobę o lepszych kompetencjach czy decyzyjności – być może Product Owner w tym momencie odpowiadający za pojedynczy zespół nie jest jeszcze zupełnie gotowy do wzięcia odpowiedzialności za wielozespołowe przedsięwzięcie i wtedy warto się zastanowić, czy w rolę PO nie może wejść osoba z wyższego poziomu organizacji (przykładowo kierownik czy dyrektor ze strony biznesu)
    • zbudować grupę wspierającą Product Ownera – zamiast duplikowania struktur obok PO, może można go odciążyć i wzmocnić jego pozycję poprzez oddelegowanie mu osób podległych (dodatkowi eksperci biznesowi, doradcy). Wielu POsów narzeka na obowiązki projectmanagerskie i im się nie dziwię, ale wolę rozwiązania w których ew. PM w projekcie jest przyporządkowany do Właściciela Produktu, a nie jest ustawiony obok niego w strukturze lub nad nim.
  • Retrospektywy całego przedsięwzięcia – Ostatnia praktyka, ale możliwe, że z tych wszystkich dla mnie najważniejsza, to realizowanie retrospektywy całego projektu, a nie tylko zamykanie się z nimi na poziomie poszczególnych zespołów. Jeśli struktury przedsięwzięcia realizowanego zwinnie mają swoje niedoskonałości, idealną okazją ku temu będzie porozmawianie o tym w grupie wszystkich zespołów (albo przedstawicieli wszystkich zespołów) i świadome ewoluowanie podejścia, poprzez drobne usprawnienia operacyjne, jak i śmiałe rewolucje wynikające z jakichś kryzysów w projekcie. Retrospektywę warto zrealizować też po zakończeniu całego przedsięwzięcia, by na przyszłość umieć wystartować podobne struktury lepiej, bez ślepego kopiowania ciągle tych samych błędów.

PS. Dziękuję Asi za sprowokowanie rozmowy na temat tego wpisu.

Jedna odpowiedź do “Co jest groźnego w zespołach wsparcia i koordynacji?”

  1. Kubo, jak zwykle dobry wpis, choć trochę na niego czekaliśmy 😉

    Ja widzę jeszcze dodał dwie pułapki:
    1. połączenie podziału odpowiedzialności i plastrowania braku decyzyjności z Twojej listy. Efektem jest zwyczajne rozmycie odpowiedzialności. Tutaj możliwe rozwiązanie to wzmacnianie roli PO.
    2. Podział na fazy eksperckie, w które zaangażowani są zupełnie inni ludzie – przez co brak ciągłości przekazu informacji. Przykład: architekt czy też ich grupa zbiera wymagania i projektuje rozwiązanie, a zupełnie inna grupa zaangażowana jest w jego implementację. Efekt? Ci drudzy mogą nie wiedzieć co ci pierwsi mieli na myśli, dlaczego podjęli akurat takie, a nie inne decyzje. Możliwe rozwiązanie: multidyscyplinarny zespół zaangażowany przez cały cykl życia, nie tylko jego wycinek. Oprócz jaśniejszej sytuacji dochodzi kilka innych efektów, jak to, że bardziej jesteśmy zaangażowani w wykonanie tego, co wymyśliliśmy niż ktoś inny nam narzucił. Plus to co napisałeś w punkcie o zespole, jako podstawowej jednostce.

    Jeszcze jedna kwestia chodzi mi po głowie. Takie zespoły wsparcia i koordynacji bardziej kojarzą mi się z podejściem projektowym, aniżeli produktowym. A tu pułapki: przeładowanie wymaganiami od biznesu (bo później mogą już ich nigdy nie dostać) i podejście na zasadzie: a po nas choćby i potop (skutkiem czego może być np. nadmierny dług technologiczny).

    Dzięki za fajne przemyślenia w poście!

Skomentuj Bartek Juszczak Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.