Etap 1

Trudne początki

„Co właściwie robimy?”

Początki działania tribe'u. IT i biznes teraz działają razem w ramach jednej struktury. Kompetencje end-to-end dopiero się budują, część z nich może być (nie)świadomie wydzielona poza zespoły. To try & buy - organizacja sprawdza czy ten model w ogóle u nas zadziała.

Rozwiązuje

Oderwanie IT od biznesu - tworzenie zespołów, które mogą dostarczać wartość bez ciągłych transferów między silosami funkcjonalnymi.

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
„Transformacja” oznacza głównie nową strukturę, ale nie nowy sposób pracy
Brakuje kluczowych kompetencji end-to-end w zespołach
Poszczególne zespoły (squady) działają inaczej - brak wspólnych standardów, narzędzi, zdarzeń
Zidentyfikowane problemy zrzucane są na karb zmiany (np. narzędzia)
Praca i priorytety napływają z zewnątrz, decyzje zapadają poza tribe'em
Zależności między zespołami wychodzą w trakcie pracy, nie wcześniej
Dług techniczny i architektura są dziedziczone sprzed podziału na tribe'y, nie zaprojektowane pod niego - część zespołów „boi się” dotykać odziedziczonych wraz ze zmianą systemów i aplikacji
Usprawnienia pojawiają się adhocowo, zwykle po większej awarii lub porażce - nie ma regularnego rytmu wyciągania wniosków

Co zazwyczaj boli

Tribe dostarcza pracę, 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 - rytuały pracy w nowym sposobie. Brakuje jednak zrozumienia intencji i głębokości zmiany. Brakuje wspólnego rozumienia odpowiedzialności za wyniki i procesy.

Co się zazwyczaj dzieje dalej

Tribe dostarcza pracę lepiej niż poprzednio. Na tyle lepiej, że jest sens kontynuować, ale brak wspólnego rytmu i języka między zespołami zaczyna go ograniczać i przeszkadzać. 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, e-commerce, retail), zanim wejdą szersze programy transformacyjne.

Rozpoznajesz u siebie ten etap? Pogadajmy, co zwykle blokuje przejście do etapu 2 i od czego zacząć u Was.

Porozmawiajmy o etapie 1

Przejście 1 → 2

Jak przejść na etap 2

Sygnał, że czas zacząć

Tribe dostarcza, ale każdy zespół robi to inaczej - inne narzędzia, inny rytm, inne rozumienie „gotowe”. „Agile theatre” (nazwy, zespoły, spotkania, tablice) przestaje wystarczać - lider tribe'u i liderzy zespołów zaczynają wspólnie nazywać, że problem nie leży w strukturze (ta już istnieje), tylko w braku wspólnego sposobu pracy. Kluczowe pytanie do wspólnego uzgodnienia: „co nas dziś różni między zespołami, i czy to musi tak zostać?”

Kto prowadzi

Lider tribe'u wspólnie z liderami zespołów - to pierwsze przejście, które tribe przechodzi głównie własnymi siłami.

Kiedy potrzeba kogoś spoza tribe'u

Rzadko potrzebna. Wyjątek: gdy różnice między zespołami wynikają z odgórnie narzuconych standardów (np. bezpieczeństwo, wymogi działu IT) - wtedy ujednolicenie praktyk inżynierskich wymaga najpierw zgody poza tribe'em.

Pierwszy namacalny efekt

Pierwszy wspólny przegląd wyników, w którym wszystkie zespoły odnoszą się do tych samych celów, nie do własnych, lokalnych priorytetów.

Sygnał ostrzegawczy

Rytm istnieje na papierze, ale w praktyce bywa pomijany albo przekładany - to znak, że tribe formalnie deklaruje Etap 2, ale realnie wciąż działa jak zbiór osobnych zespołów z Etapu 1.

Konkretne kroki ustalamy w rozmowie, bo zależą od Waszego kontekstu.