Rebelsi · model dojrzałości tribe'u

Mapa dojrzałości
tribe'u

Pięć etapów, przez które przechodzi organizacja budująca tribe'y wokół wartości i produktu. Każdy etap rozwiązuje problem poprzedniego. Model oparty na obserwacjach z organizacji produktowych w sektorze finansowym i technologicznym.

!

Zanim ocenisz etap

  • Model nie jest oceną — każdy etap to właściwa odpowiedź na swój moment organizacyjny. Problem pojawia się dopiero, gdy tribe utknął: ma sygnały etapu 3, ale nawyki etapu 1.
  • Większość tribe'ów ma elementy kilku etapów naraz, a różne squady w tym samym tribie bywają na różnych etapach — to normalny stan, nie błąd.
  • Częsty wzorzec: dojrzałość wartościowa wyprzedza procesową — tribe wie, co ważne, ale nie potrafi tego jeszcze przewidywalnie dostarczyć.

PS. jeśli w Waszym tribie to wygląda inaczej — o to właśnie chcemy usłyszeć.

Rozwiązuje →Oderwanie IT od biznesu — tworzenie zespołów, które mogą dostarczać wartość bez ciągłych transferów między silosami funkcjonalnymi.
  • Tribe istnieje, ale granice odpowiedzialności nie są jasne — członkowie mają kłopot z rozróżnieniem odpowiedzialności produktowej od liniowej
  • „Transformacja agile” oznacza głównie nową strukturę, nie nowy sposób pracy

Tribe dopiero powstał. IT i biznes działają razem w ramach struktury, ale kompetencje end-to-end dopiero się budują. To try & buy — sprawdzamy, czy ten model zwinności w ogóle u nas zadziała.

Po czym rozpoznać ten etap

  • Tribe istnieje, ale granice odpowiedzialności nie są jasne — członkowie zespołu mają kłopoty z rozróżnieniem odpowiedzialności produktowej od liniowej
  • Kluczowe kompetencje end-to-end brakujące lub pożyczone z zewnątrz squadu
  • Poszczególne squady działają inaczej — brak wspólnych standardów, narzędzi, zdarzeń
  • „Transformacja agile” oznacza głównie nową strukturę, nie nowy sposób pracy
  • Zidentyfikowane problemy zrzucane są na karb zmiany (np. narzędzia)
  • Praca i priorytety napływają z zewnątrz tribe'u, decyzje zapadają poza nim
  • Zależności między squadami wychodzą w trakcie pracy, nie wcześniej
  • Dług techniczny i architektura są dziedziczone sprzed podziału na tribe'y — część squadów „boi się” dotykać niektórych systemów
  • Usprawnienia pojawiają się adhocowo, zwykle po większej awarii lub porażce — brak regularnego rytmu wyciągania wniosków

Co zazwyczaj boli

Tribe dostarcza, ale „wolno” i nieprzewidywalnie. Zmiana struktury nie wpłynęła znacząco na sposób pracy. „Agile theatre” — mamy nazwy, zespoły, spotkania i tablice. Brakuje rozumienia intencji i głębokości zmiany. Brak wspólnego rozumienia odpowiedzialności za wyniki i procesy.

Co się zazwyczaj dzieje dalej

Tribe dostarcza na tyle, że jest sens kontynuować, ale brak wspólnego rytmu i języka między squadami zaczyna go ograniczać. Wchodzi etap 2.

Gdzie to widzisz

Organizacje krótko po uruchomieniu pierwszych tribe'ów — zwykle w ciągu pierwszego roku, najczęściej w sektorach z historycznie silnym podziałem IT/biznes (bankowość, ubezpieczenia), zanim wejdą szersze programy transformacyjne.

  1. Czy członkowie tribe'u potrafią jasno rozróżnić, za co odpowiadają produktowo, a za co liniowo (organizacyjnie)?

    1powszechna konfuzja, nikt nie wie kto za co odpowiada
    3część ról jest jasna, część wciąż budzi wątpliwości
    5odpowiedzialności są jasne i szeroko rozumiane

  2. Ile kluczowych kompetencji end-to-end (np. testowanie, analiza, UX, DevOps) squad ma u siebie, a ile pożycza z zewnątrz albo nie ma wcale?

    1większość kompetencji brakuje lub jest pożyczana z zewnątrz
    3część kompetencji jest wewnątrz squadu, część wciąż pożyczana
    5squad ma większość kluczowych kompetencji end-to-end u siebie

  3. Czy sposób pracy realnie się zmienił (nowe zdarzenia, decyzje, priorytetyzacja), czy zmieniła się głównie struktura i nazewnictwo?

    1zmieniła się głównie struktura/nazwy, praca wygląda jak przed transformacją
    3część praktyk się zmieniła, część to stare nawyki pod nową nazwą
    5sposób pracy realnie się zmienił, nie tylko struktura

  4. Kiedy pojawia się problem, czy pierwszą wskazywaną przyczyną jest „zmiana” (nowa struktura, nowe narzędzia), czy realna analiza źródła?

    1„to przez zmianę” jest standardową odpowiedzią, brak dalszej analizy
    3czasem szuka się głębiej, czasem poprzestaje na wygodnym wytłumaczeniu
    5problemy są analizowane do faktycznej przyczyny, niezależnie od tego czy to wygodne

  5. Ile bieżącej pracy i priorytetów tribe ustala sam, a ile napływa z zewnątrz jako gotowa decyzja?

    1priorytety niemal wyłącznie napływają z zewnątrz, tribe wykonuje
    3część priorytetów tribe ustala sam, część nadal napływa z zewnątrz
    5tribe ma realny wpływ na własne priorytety w większości przypadków

  6. Czy są systemy albo obszary kodu, których squady unikają lub boją się dotykać, bo są dziedziczone sprzed podziału na tribe'y i nikt ich dobrze nie rozumie?

    1takie obszary istnieją i są powszechnie unikane
    3istnieją, ale squady sobie z nimi jakoś radzą
    5architektura jest zrozumiała, nie ma obszarów objętych „strachem”

  7. Czy przed startem pracy w nowym modelu ludzie dostali celowe przygotowanie — ustalone working agreements/kontrakty między rolami, wyjaśniony proces — czy zaczęli działać „z marszu”, ucząc się zasad w trakcie?

    1brak jakiegokolwiek celowego przygotowania, zasady odkrywane przypadkiem w trakcie pracy
    3część ról/zespołów przeszła przygotowanie, część zaczęła bez niego
    5ludzie mieli celowe przygotowanie: uzgodnione kontrakty ról i zrozumiały proces, zanim zaczęli pracować w nowym modelu

  8. Czy tribe potrafi wskazać, kim są jego kluczowi interesariusze (klienci, użytkownicy, biznes) i choćby z grubsza nazwać ich potrzeby — czy dostarcza, nie zastanawiając się dla kogo i po co?

    1nie potrafi wskazać interesariuszy ani ich potrzeb, dostarcza „bo tak jest w backlogu”
    3interesariusze są nazwani, potrzeby rozumiane pobieżnie lub tylko przez PO
    5interesariusze i ich potrzeby są jasno nazwane i szeroko rozumiane w tribie

  9. Czy ludzie identyfikują się z tribem jako swoim zespołem („my”), czy nadal mówią o nim z dystansu, jako o czymś zewnętrznym względem swojej „prawdziwej” przynależności (dawny dział, dawny zespół)?

    1ludzie mówią „oni, ten tribe”, identyfikują się z dawną strukturą
    3część osób mówi „my w tribie”, część nadal z dystansem
    5tribe jest powszechnie odczuwany jako „my”, niezależnie od tego skąd kto przyszedł
Rozwiązuje →Brak spójności i koordynacji między squadami — tribe przestaje być zbiorem squadów działających każdy po swojemu. Pojawia się wspólny język, rytm i struktura, które umożliwiają planowanie i rozmowę wewnątrz tribe'u.
  • Cykliczny przegląd wyników (np. kwartalny) istnieje i działa jako rytm tribe'u
  • Wrzutki wpadają co Sprint jako zaskoczenie, nie element systemu

Tribe wypracowuje własny, spójny rytm pracy i wspólny język między squadami. Przestaje być zlepkiem squadów działających każdy po swojemu — staje się jednostką z przewidywalną strukturą i regularnym rytmem planowania.

Po czym rozpoznać ten etap

  • Cykliczny przegląd wyników (np. kwartalny) istnieje i działa jako rytm tribe'u
  • Cele tribe'u są widoczne i rozumiane — ludzie do nich wracają, przegląd wyników je omawia
  • Ale: horyzont planistyczny jest terminem, w którym trzeba się „wyrobić”, nie ramą do świadomego układania pracy — stąd wiele inicjatyw otwartych naraz i żadna nie ma priorytetu
  • Wrzutki wpadają co Sprint jako zaskoczenie, nie element systemu
  • Tribe lider wie co chce osiągnąć, ale nie kiedy będzie gotowy
  • Squady pracują coraz bardziej niezależnie — ale każdy dla siebie, bez widoczności na całość
  • Metryki przepływu jak cycle time nie są mierzone — praca „jakoś się toczy”
  • Podstawowe praktyki inżynierskie (CI/CD, testy automatyczne) przyjęte, ale niejednolicie stosowane między squadami
  • Usprawnienia mają już swój rytm (np. retro), ale zgłaszane tematy często przerastają mandat osób, które je zgłaszają — wracają cyklicznie bez rozwiązania

Co zazwyczaj boli

Znacząca część planowanej pracy zmienia się w trakcie cyklu planistycznego bez mechanizmu decyzyjnego (w obserwowanych tribe'ach rzędu 30–50%). Nie wiadomo dlaczego inicjatywy się przeciągają. Zewnętrzne blokery zaskakują mid-sprint. Tribe dostarcza — ale ani nie wie ile, ani nie rozumie dlaczego część tematów się przeciąga.

Co się zazwyczaj dzieje dalej

Pytanie „kiedy będziemy gotowi?” pada coraz częściej i nie ma na nie odpowiedzi. Liderzy chcą danych. Wchodzi etap 3.

Gdzie to widzisz

Organizacje kilka lat po wdrożeniu modelu tribe/squad na szerszą skalę, z ustalonym rytmem planowania ponad-sprintowego, ale bez mechanizmów zarządzania przepływem.

  1. Czy cykliczny przegląd wyników (np. kwartalny) faktycznie działa jako regularny rytm tribe'u?

    1nie ma ustalonego rytmu, przeglądy są sporadyczne lub ad hoc
    3rytm istnieje, ale bywa pomijany/spóźniony
    5rytm jest stały, przewidywalny, nikt go nie kwestionuje

  2. Czy cele tribe'u są widoczne i rozumiane — czy ludzie potrafią je przywołać bez podglądania, i czy przegląd wyników realnie je omawia?

    1cele istnieją tylko na slajdzie, nikt ich nie pamięta ani nie omawia
    3część zespołu zna cele, przegląd czasem je porusza
    5cele są powszechnie znane i regularnie omawiane

  3. Czy lider tribe'u potrafi jasno powiedzieć, co tribe chce osiągnąć w bieżącym horyzoncie planistycznym?

    1lider nie potrafi tego jasno zwerbalizować
    3potrafi z wahaniem, ogólnikowo
    5potrafi jasno i konkretnie

  4. Czy squady zyskują coraz większą samodzielność end-to-end, nie tracąc przy tym widoczności na to, co dzieje się w reszcie tribe'u?

    1squady izolowane, każdy dla siebie, zero widoczności na całość
    3squady samodzielne, ale widoczność całości jest przypadkowa
    5squady samodzielne i świadomie utrzymują widoczność na całość tribe'u

  5. Czy podstawowe praktyki inżynierskie (CI/CD, testy automatyczne) są przyjęte i stosowane spójnie między squadami, czy każdy robi to inaczej?

    1praktyki nieprzyjęte albo skrajnie niejednolite
    3przyjęte, ale niejednolicie stosowane
    5przyjęte i stosowane spójnie w całym tribie

  6. Czy usprawnienia (np. retrospektywy) mają ustalony, powtarzalny rytm?

    1usprawnienia dzieją się nieregularnie lub wcale
    3rytm istnieje, ale bywa pomijany
    5rytm jest stały i konsekwentnie utrzymywany

  7. Czy squady stosujące przyjęte praktyki (np. story pointy, estymowanie, konkretne role) potrafią wyjaśnić po co je stosują i adaptować je do sytuacji — czy stosują je „bo tak trzeba”, książkowo skopiowane z rynku, bez pytania o cel?

    1praktyki kopiowane książkowo, nikt nie pyta po co, odstępstwo od formy traktowane jako błąd
    3część squadów rozumie i adaptuje, część działa z automatu
    5squady rozumieją cel praktyk i świadomie je adaptują do własnej sytuacji

  8. Odpowiedzialności są już nazwane (Etap 1) — ale czy w praktyce trzymają się bez luk i dublowania? Jak często zdarza się, że jakiś temat zostaje niezaopiekowany, bo „myśleliśmy, że to czyjeś”, albo że dwie osoby/role robią to samo równolegle?

    1luki i dublowanie zdarzają się często, nikt tego systematycznie nie zauważa
    3zdarzają się, ale są zauważane i naprawiane po fakcie
    5rzadkie, a gdy się pojawią, są szybko wyłapywane

  9. Czy zespół zaczyna brać wspólną odpowiedzialność za wynik jako drużyna, czy nadal każdy gra głównie na siebie, a wynik zespołu to suma indywidualnych zadań?

    Zaufanie na tym etapie zwykle buduje się na samym fakcie wykonania pracy, niekoniecznie na jej tempie czy jakości — to typowe dla etapu, nie jest tu oceniane osobno.

    1każdy gra na siebie, „moje zadanie/twoje zadanie”
    3część pracy jest wspólna, część nadal czysto indywidualna
    5zespół realnie bierze wspólną odpowiedzialność za wynik

  10. Czy squad sam decyduje i dostosowuje swój sposób pracy (proces, narzędzia, rytuały), czy oczekuje, że zdefiniuje go menedżer/lider z zewnątrz?

    1squad czeka, aż ktoś z zewnątrz zdefiniuje jak mają pracować
    3squad dostosowuje część procesu sam, resztę wciąż narzuca się z zewnątrz
    5squad sam świadomie kształtuje swój sposób pracy

  11. Czy ludzie mogą otwarcie powiedzieć „jeszcze nie umiem tego rytmu/tej praktyki” bez obawy przed oceną — czy błędy popełniane przy wdrażaniu nowych praktyk są traktowane jako nauka, czy jako pretekst do obwiniania?

    1przyznanie się do niewiedzy jest ryzykowne, błędy skutkują obwinianiem
    3zależy od osoby/sytuacji, brak spójnej normy
    5przyznanie się do niewiedzy jest normą, błędy przy nauce nowych praktyk są bezpieczne
Rozwiązuje →Reaktywność i nieprzewidywalność — squady przestają być zaskakiwane wrzutkami i zależnościami. Horyzont planistyczny przestaje być presją „musimy zdążyć” — staje się granicą, którą tribe potrafi bezpiecznie zaplanować z wyprzedzeniem. Tribe lider ma dane, nie intuicję.
  • Miary przepływu jak cycle time/lead time są mierzone i omawiane na forum liderskim i zespołowym
  • Wrzutki mają mechanizm: bufor pojemnościowy, dedykowany strumień lub decyzję „wchodzi zamiast tamtego”

Tribe przestaje być reaktywny. Mierzy i zarządza przepływem. Wie ile może wziąć i kiedy skończy. Przestaje pracować „każdy dla siebie” — zaczyna widzieć całość.

Po czym rozpoznać ten etap

  • Miary przepływu jak cycle time/lead time są mierzone i omawiane na forum liderskim i zespołowym (np. retro)
  • Inicjatywy zarządzane tak, by trwały maksymalnie jeden cykl planistyczny i mają kryterium „skończone” powiązane z wartością
  • Wrzutki mają mechanizm: bufor pojemnościowy, dedykowany strumień lub decyzję „wchodzi zamiast tamtego”
  • Proces wytwarzania ulega „usztywnieniu” — identyfikacja zależności, rozłożenie pracy na Sprinty w cyklu planowania, skupienie liderów na metrykach przewidywalności
  • Zależności od innych tribe'ów planowane z wyprzedzeniem, nie odkrywane w środku sprintu
  • Tribe lider może powiedzieć „będziemy gotowi około X” — i być blisko prawdy
  • Capacity zespołów jest widoczna i śledzona: ile idzie na utrzymanie, ile na rozwój, ile na wrzutki
  • Zewnętrzni aktorzy (marketing, compliance) mają ustalone SLA lub tribe ma strategię na pojawiające się opóźnienia
  • Stabilność mierzona obok przepływu (częstość awarii, czas przywrócenia usługi) — tribe wie nie tylko „jak szybko”, ale „jak stabilnie” dostarcza
  • Dług techniczny ma chronioną pojemność, podobnie jak wrzutki — nie przegrywa automatycznie z nowymi tematami
  • Tribe rozwiązuje większość zgłaszanych tematów sam, na podstawie danych, w granicach własnego mandatu

Co zazwyczaj boli

Zewnętrzne blokady spowalniają systemowo pracę tribe'u, na wiele z nich zespoły nie mają wpływu. Squady nadal nie są w pełni właścicielami tego, co wytwarzają. Pojawia się pytanie: kto naprawdę odpowiada za produkt end-to-end?

Co się zazwyczaj dzieje dalej

Tribe zaczyna widzieć, że przewidywalność ma sufit — bo nie może decydować o wartości ani odrzucać niskowartościowej pracy. Wchodzi etap 4.

Gdzie to widzisz

Dojrzalsze tribe'y, zwykle kilka lat po zmianie modelu operacyjnego, tam gdzie flow metrics są standardowym narzędziem rozmowy na retro, nie tylko dashboardem.

  1. Czy cycle time / lead time są mierzone jednym, wspólnym sposobem dla realnej pracy całego tribe'u (nie każdy squad po swojemu, nie tylko wybrane projekty), regularnie omawiane na forum liderskim i zespołowym — i czy śledzicie rozrzut (wariancję), nie tylko średnią?

    1nie mierzymy w ogóle, albo mierzymy tylko wybrane projekty czy każdy squad po swojemu
    3mierzymy jednym wspólnym sposobem, ale nie omawiamy regularnie na forum, albo patrzymy tylko na średnią
    5mierzymy wspólnie, omawiamy regularnie na obu poziomach, odróżniamy naturalną wariancję od wynikającej z braku procesu

  2. Jaki procent inicjatyw kończy się w ramach jednego cyklu planistycznego, co się dzieje z tymi, które go przekraczają — i czy każda inicjatywa ma jasne kryterium „skończone” powiązane z dostarczoną wartością, a nie tylko z zakresem lub datą?

    Dwie niezależne osie w jednym pytaniu (dyscyplina cyklu i jakość kryterium „skończone”) — ocena to niższa z dwóch osi, nie średnia, żeby słaby wynik na jednej z nich nie zniknął w uśrednieniu.

    1co najmniej jedna z dwóch osi: większość inicjatyw przekracza cykl bez mechanizmu reakcji, lub kryterium „skończone” to wyłącznie zakres/data
    3obie osie co najmniej tutaj, żadna nie spada do 1
    5obie osie tutaj: zdecydowana większość inicjatyw mieści się w cyklu, kryterium „skończone” konsekwentnie łączy się z wartością

  3. Jak wygląda mechanizm obsługi wrzutek (bufor pojemnościowy, dedykowany strumień, decyzja „wchodzi zamiast tamtego”) i jak często jest łamany?

    1brak mechanizmu, wrzutki wchodzą i psują plan
    3mechanizm istnieje, ale bywa łamany pod presją
    5mechanizm działa konsekwentnie, złamania rzadkie i świadome

  4. Na ile potraficie zidentyfikować zależności z wyprzedzeniem i rozłożyć znany zakres pracy na sprinty w ramach cyklu planowania?

    1zależności i zakres wychodzą na bieżąco, w trakcie pracy
    3część znana z wyprzedzeniem, część i tak zaskakuje
    5zależności i zakres identyfikowane systematycznie przed startem cyklu

  5. Czy zależności od innych tribe'ów są identyfikowane i planowane przed startem cyklu, czy odkrywane w trakcie pracy? Jakim narzędziem/procesem są śledzone?

    1odkrywane ad hoc, bez narzędzia
    3częściowo śledzone, bez systematyki
    5systematycznie śledzone narzędziem/procesem, z wyprzedzeniem

  6. Kiedy lider tribe'u mówi „będziemy gotowi około X” — jaka jest rozbieżność między tą prognozą a rzeczywistością w ostatnich kilku cyklach?

    1prognozy praktycznie nigdy się nie sprawdzają
    3trafiają z dużym marginesem błędu
    5trafiają w rozsądnym przedziale w większości ostatnich cykli

  7. Jaki jest rozkład capacity zespołów między utrzymanie, rozwój i wrzutki — czy jest widoczny i świadomie zarządzany, czy tylko szacowany po fakcie?

    1nikt tego nie liczy
    3szacowany po fakcie, bez wpływu na decyzje
    5widoczny z wyprzedzeniem i świadomie zarządzany

  8. Jak wygląda mechanizm dogadywania się z zewnętrznymi interesariuszami i współpracującymi zespołami o terminach dostarczania inputu/decyzji — formalne SLA, nieformalna umowa, ustalony rytm kontaktu — i jak tribe reaguje, kiedy nie jest dotrzymany?

    1brak jakiegokolwiek mechanizmu, zaskoczenia są normą, tribe nie ma na nie odpowiedzi
    3mechanizm istnieje, ale bywa łamany bez reakcji ze strony tribe'u
    5mechanizm działa konsekwentnie niezależnie od formy, a gdy zawodzi, tribe ma wypracowany sposób reakcji

  9. Czy stabilność jest mierzona obok szybkości — jaki jest change failure rate i średni czas przywrócenia usługi (MTTR) po nieudanej zmianie?

    1nie mierzymy stabilności w ogóle
    3mierzymy, ale nie łączymy tego z decyzjami o tempie
    5mierzymy i świadomie balansujemy szybkość ze stabilnością

  10. Czy dług techniczny ma chronioną pojemność w każdym cyklu planistycznym, czy regularnie przegrywa z nowymi tematami pod presją terminu?

    1dług zawsze przegrywa pod presją
    3pojawia się czasem, bez systematycznej ochrony
    5ma chronioną, stałą pojemność niezależnie od presji

  11. Jaki procent zgłaszanych problemów/usprawnień tribe rozwiązuje samodzielnie na podstawie danych, a jaki wymaga eskalacji poza tribe?

    1większość eskalowana lub wraca nierozwiązana
    3część rozwiązywana samodzielnie, część utyka
    5zdecydowana większość rozwiązywana samodzielnie, eskalacja tylko dla spraw poza mandatem

  12. Czy ludzie zgłaszają prawdziwe opóźnienia, błędne prognozy i realny status pracy bez obawy przed konsekwencjami — czy dane wejściowe do metryk bywają „poprawiane” pod dobry wygląd?

    1dane są regularnie upiększane, zgłoszenie prawdy grozi konsekwencjami
    3zdarza się upiększanie, zależnie od sytuacji/presji
    5dane zgłaszane są uczciwie, niezależnie od tego jak wypadają
Rozwiązuje →Pytanie „czy robimy właściwe rzeczy?” — cele tribe'u przestają być tylko tablicą, zaczynają realnie kształtować priorytety. Tribe ma mechanizm odrzucania pracy, która nie uzasadnia inwestycji.
  • Tribe może powiedzieć „możemy zrobić A albo B, nie oba” — i uzasadnić to danymi
  • Tribe aktywnie odrzuca lub odkłada tematy na podstawie danych, nie tylko nacisku

Tribe działa na podstawie danych o wartości, nie tylko o dostarczaniu. Liderzy podejmują decyzje w oparciu o cele biznesowe — i potrafią powiedzieć „nie” niskowartościowej pracy.

Uwaga: mechanizm celów pojawia się już na etapie 2, niezależnie od metody. Różnica jest jakościowa — na etapie 4 ustalone cele wygrywają z „nowym tematem który musi wejść”. Tribe może powiedzieć „nie” — i to jest respektowane przez organizację.

Po czym rozpoznać ten etap

  • Tribe może powiedzieć „możemy zrobić A albo B, nie oba” — i uzasadnić to danymi
  • Decyzje o inicjatywach zawierają ocenę wartości (przychód, konwersja, ryzyko), nie tylko opis zakresu — to wciąż ocena z perspektywy biznesu, niekoniecznie zweryfikowana bezpośrednio z klientem
  • Kolejność pracy w horyzoncie układana pod kątem maksymalizacji wartości, nie kolejności zgłoszeń ani nacisku interesariuszy
  • Tribe aktywnie odrzuca lub odkłada tematy na podstawie danych, nie tylko nacisku
  • Squady odpowiadają za utrzymanie tego, co budują (build-run-maintain)
  • Pojemność tribe jest widoczna i chroniona — tribe negocjuje z organizacją z pozycji faktów
  • Cele tribe'u kształtują kolejkę pracy, nie tylko opisują kierunek
  • Poszukiwania mechanizmu świadomej wymiany inicjatyw w trakcie trwania cyklu planistycznego
  • Decyzje technologiczne (refaktoryzacja, migracja, spłata długu) oceniane pod kątem wartości i ryzyka, tak jak inicjatywy biznesowe
  • Usprawnienia obejmują też hipotezy o wartości i produkcie, nie tylko o procesie

Co zazwyczaj boli

Architektura produktów i podział między squadami nie pokrywa się z tym, jak wartość przepływa do klienta. Pojawiają się kaskadowe zależności między tribe'ami, których nie da się „zaplanować” — wymagają reorganizacji.

Co się zazwyczaj dzieje dalej

Tribe zaczyna rozumieć, że struktura jest źródłem kaskadowych zależności. Wchodzi etap 5.

Gdzie to widzisz

Najbardziej dojrzałe tribe'y w organizacjach produktowych z silną kulturą danych i eksperymentowania — w Polsce wciąż rzadkość, pojedyncze przypadki poza sektorem regulowanym.

  1. Czy tribe potrafi powiedzieć „możemy zrobić A albo B, nie oba” i uzasadnić to danymi, a nie tylko odczuciem?

    1trade-offy nie są nazywane wprost, brak uzasadnienia danymi
    3trade-offy bywają nazywane, uzasadnienie częściowe
    5trade-offy nazywane konsekwentnie, z twardym uzasadnieniem danymi

  2. Czy decyzje o inicjatywach zawierają ocenę wartości (przychód, konwersja, ryzyko), a nie tylko opis zakresu?

    Ocena wciąż z perspektywy biznesu — czy jest zweryfikowana bezpośrednio z klientem, to już pytanie Etapu 5, nie tego punktu.

    1decyzje oparte tylko o zakres/termin
    3ocena wartości pojawia się czasem, niesystematycznie
    5ocena wartości jest standardowym elementem każdej decyzji

  3. Czy kolejność pracy w horyzoncie planistycznym jest układana pod kątem maksymalizacji dostarczonej wartości, a nie kolejności zgłoszeń czy nacisku interesariuszy?

    1kolejność wynika z nacisku/kolejności zgłoszeń
    3wartość brana pod uwagę częściowo, obok innych czynników
    5wartość jest głównym kryterium kolejności

  4. Czy tribe aktywnie odrzuca lub odkłada tematy na podstawie danych, a nie tylko pod presją braku zasobów?

    1tribe rzadko odmawia, wszystko „jakoś” wchodzi
    3odmowa zdarza się, ale bez systematycznego uzasadnienia danymi
    5odrzucanie na podstawie danych jest normalną praktyką

  5. Czy squady odpowiadają za utrzymanie tego, co budują (build-run-maintain), czy utrzymanie jest oddzielone od budowy?

    1utrzymanie w innym zespole/dziale
    3częściowa odpowiedzialność, zależnie od squadu
    5pełna odpowiedzialność build-run-maintain w każdym squadzie

  6. Czy pojemność tribe'u jest widoczna, chroniona, i czy tribe potrafi negocjować z organizacją z pozycji faktów, a nie ulegać presji?

    1pojemność niewidoczna, tribe ulega presji bez negocjacji
    3pojemność widoczna, negocjacje zdarzają się, ale nie zawsze skutecznie
    5pojemność widoczna, chroniona, negocjacje oparte na faktach są normą

  7. Czy cele tribe'u realnie kształtują kolejkę pracy (wygrywają z nowym, pilnym tematem), czy tylko opisują ogólny kierunek?

    1cele to deklaracja, nowy temat zawsze wygrywa
    3cele czasem wygrywają, czasem nie
    5ustalone cele konsekwentnie wygrywają z nowymi tematami

  8. Czy tribe eksperymentuje z mechanizmem świadomej wymiany inicjatyw w trakcie trwania cyklu planistycznego (np. „wymieniamy X na Y, bo Y ma wyższą wartość”)?

    1nie ma takiego mechanizmu, WIP tylko rośnie
    3pojedyncze próby, bez utrwalonej praktyki
    5świadoma wymiana jest ugruntowaną praktyką

  9. Czy decyzje technologiczne (refaktoryzacja, migracja, spłata długu) są oceniane pod kątem wartości i ryzyka, tak jak inicjatywy biznesowe?

    1decyzje technologiczne oceniane wyłącznie technicznie, bez wartości/ryzyka biznesowego
    3ocena wartości/ryzyka pojawia się czasem
    5decyzje technologiczne konsekwentnie oceniane jak inicjatywy biznesowe

  10. Czy usprawnienia obejmują też hipotezy o wartości i produkcie (nie tylko o procesie) — czy tribe testuje i odrzuca pomysły na podstawie danych, nie tylko przeczucia?

    1usprawnienia dotyczą tylko procesu, brak testowania hipotez produktowych
    3pojedyncze testy hipotez wartości, nieregularnie
    5testowanie hipotez wartości jest regularną praktyką, z odrzucaniem na podstawie danych

  11. Czy ktokolwiek w tribie, nie tylko lider, może realnie powiedzieć „ten temat nie ma sensu” o decyzji priorytetowej i zostać wysłuchany — czy sprzeciw wobec priorytetów jest w praktyce przywilejem stanowiska?

    1sprzeciw wyraża realnie tylko lider, inni się nie odzywają lub są ignorowani
    3sprzeciw zdarza się, skuteczność zależy od stanowiska osoby
    5każdy może realnie zakwestionować priorytet i zostać wysłuchany, niezależnie od stanowiska
Rozwiązuje →Strukturalne wąskie gardła — kiedy granice squadów i tribe'ów nie pokrywają się z tym, jak wartość naprawdę przepływa do klienta. Kaskadowe zależności zastąpione strukturą dopasowaną do value streams.
  • Squady są definiowane wokół strumieni wartości, nie funkcji lub systemów IT
  • Tribe może odmówić niskowartościowej pracy — i organizacja to akceptuje

Struktura tribe'u wynika z przepływu wartości, nie z historii organizacyjnej. Tribe modyfikuje własną strukturę, żeby zminimalizować kaskadę zależności wytwarzania.

Po czym rozpoznać ten etap

  • Squady są definiowane wokół strumieni wartości, nie funkcji lub systemów IT
  • Tribe regularnie weryfikuje własną strukturę pod kątem dopasowania do value streams
  • Zależności kaskadowe są minimalizowane przez reorganizację, nie przez zarządzanie nimi
  • Tribe wnosi do organizacji naukę: „próbowaliśmy X, oto dane, zmieniliśmy strukturę”
  • Backlog zawiera hipotezy o potrzebie klienta, testowane bezpośrednio z klientem/użytkownikiem
  • Tribe może odmówić niskowartościowej pracy — i organizacja to akceptuje
  • Architektura systemów regularnie weryfikowana pod kątem dopasowania do strumieni wartości

Co zazwyczaj boli

Na tym etapie bolą rzeczy poza tribe'm: governance, budżetowanie i struktury decyzyjne, które nie nadążają za sposobem pracy tribe'u.

Co się zazwyczaj dzieje dalej

Organizacja musi dostosować swoje struktury do tego, jak tribe dostarcza wartość. To zmiana na poziomie całej firmy, nie tribe'u.

Gdzie to widzisz

Globalne organizacje produktowe z dojrzałą kulturą eksperymentowania i wysoką autonomią zespołów — w praktyce rzadkość nawet tam, gdzie deklarowana. W Polsce, szczególnie w środowisku regulowanym, praktycznie nie występuje.

  1. Czy squady są zdefiniowane wokół strumieni wartości (end-to-end do klienta), a nie wokół funkcji czy systemów IT?

    1squady zdefiniowane wokół funkcji/systemów, nie strumieni wartości
    3część squadów jest wyrównana do strumieni wartości, część nie
    5squady konsekwentnie zdefiniowane wokół strumieni wartości

  2. Czy tribe regularnie (nie tylko przy kryzysie) weryfikuje, czy jego struktura wciąż pasuje do sposobu, w jaki przepływa wartość?

    1struktura nie jest weryfikowana, zmienia się tylko pod presją
    3weryfikacja zdarza się, ale nieregularnie
    5regularny, ustalony rytm weryfikacji struktury

  3. Kiedy pojawia się powtarzająca się zależność kaskadowa, czy tribe reaguje reorganizacją (usunięciem przyczyny), czy tylko lepszym zarządzaniem/śledzeniem zależności?

    1zależności są tylko zarządzane/śledzone, struktura się nie zmienia
    3reorganizacja zdarza się czasem, obok zarządzania zależnościami
    5powtarzające się zależności kaskadowe systematycznie prowadzą do zmiany struktury

  4. Czy tribe potrafi pokazać konkretny przykład „próbowaliśmy X, oto dane, zmieniliśmy strukturę” — i przekazuje tę naukę dalej w organizacji?

    1brak takich przykładów, zmiany struktury nie są traktowane jako eksperyment z nauką
    3pojedyncze przykłady, nauka rzadko wychodzi poza tribe
    5to ugruntowana praktyka, nauka regularnie trafia do organizacji

  5. Czy backlog zawiera hipotezy o potrzebie klienta testowane bezpośrednio z klientem/użytkownikiem, a nie tylko oceniane wewnętrznie na podstawie danych biznesowych?

    Rozwinięcie Etapu 4 Q2/Q10 — tam ocena wartości jest wewnętrzna/biznesowa, tu wymagana jest bezpośrednia walidacja z klientem.

    1hipotezy oceniane wyłącznie wewnętrznie, bez kontaktu z klientem
    3część hipotez testowana z klientem, część tylko wewnętrznie
    5bezpośrednia walidacja z klientem jest standardową praktyką

  6. Czy architektura systemów jest regularnie weryfikowana pod kątem dopasowania do strumieni wartości, nie tylko struktura zespołów?

    1architektura nie jest weryfikowana pod tym kątem
    3weryfikacja zdarza się, ale nieregularnie lub tylko przy okazji innych projektów
    5regularna, ustalona praktyka weryfikacji architektury pod kątem value streams

  7. Czy inne tribe'y w organizacji proszą ten tribe o pomoc, kopiują jego praktyki albo zapraszają go do dzielenia się nauką — czy ten tribe jest ciekawostką, z której organizacja się nie uczy?

    1inne tribe'y nie sięgają po doświadczenie tego tribe'u
    3zdarza się pojedynczo, bez systematyki
    5tribe jest regularnie proszony o pomoc/mentoring przez inne tribe'y, organizacja świadomie się od niego uczy

Orientacja na mapie

Ten sam zestaw pytań, odpowiedź obok siebie dla wszystkich pięciu etapów.

  Etap 1 Etap 2 Etap 3 Etap 4 Etap 5
Pytanie na poniedziałek Co właściwie robimy? Czy idziemy w dobrym kierunku? Kiedy skończymy? Czy to warto robić? Czy nasza struktura pozwala nam dostarczać efektywnie?
Wrzutka to… codzienność zaskoczenie element systemu kalkulowana decyzja dane do oceny wartości
Tribe lider widzi… chaos – ludzi, nie pracę cele, nie postęp postęp, nie przyczyny wartość, nie tylko postęp przepływ wartości, nie zadania
Zależności zewnętrzne są… niewidoczne niespodzianką planowane zarządzane minimalizowane przez strukturę
Inicjatywa trwa… nie wiadomo cały cykl planistyczny z automatu max jeden cykl, z wartością tyle ile uzasadnia wartość tyle ile uzasadnia – inaczej nie bierzemy
Dług / stabilność jest… dziedziczony, nienazwany widoczny w backlogu, przegrywa z nowym mierzony, ma chronioną pojemność oceniany pod kątem wartości i ryzyka wejściem do decyzji o strukturze
Usprawnianie jest… adhocowe, po awarii lub porażce cykliczne, ale tematy przerastają mandat zgłaszających oparte na danych, w zasięgu mandatu tribe'u obejmuje hipotezy o wartości, nie tylko proces obejmuje zmianę struktury, uczy organizację
Co byś tu zmienił/a?

To wciąż szkic. Jeśli któryś etap nie pasuje do tego, co widzisz w swoim tribie, pytanie sprawdzające wydaje się nietrafione, albo czegoś tu wyraźnie brakuje — zaznacz fragment i zostaw komentarz. Każda uwaga trafia prosto do kolejnej wersji modelu.