Inicjatywy wielozespołowe

Porządny Agile

Czasem zdarza się, że w organizacji pojawi się projekt, który wymaga działań wielu zespołów zwinnych. Przygotowaliśmy zestawienie pewnych praktyk, z których możesz ułożyć sobie własne rozwiązanie, skrojone do odwagi, dojrzałości i możliwości firmy. Zwróciliśmy też uwagę na ważne przestrogi, które możesz spotkać podczas inicjatyw wielozespołowych.

Porządny Agile · Inicjatywy wielozespołowe

Spis treści

• Założenia do sytuacji, o której powiemy
• Proponowane praktyki pracy wielu zespołów nad jedną inicjatywą
• Przestrogi oraz przemyślenia przy pracy wielozespołowej
• Transkrypcja podcastu „Inicjatywy wielozespołowe”

Założenia do sytuacji, o której powiemy

Zakładamy, że w organizacji działają już pewne zespoły zwinne, stanowiące bazę. Funkcjonują one na zadowalającym poziomie, bez wyraźnych patologii oraz z zaufaniem w zakresie realizacji własnych zadań w dobrze znanych im obszarach. Rozpatrywać będziemy przypadek pojawienia się nowego, rozbudowanego i istotnego tematu, którego wdrożenie wymaga współpracy wielu zespołów jednocześnie.

Co mamy na myśli, gdy mówimy wspólny temat dla wielu zespołów? Przyjrzyjmy się kilku przykładom, które mogą odnosić się do twojej sytuacji.

1. Przebudowa lub przepisanie systemu: starsze, rozbudowane systemy często wymagają gruntownej modernizacji lub całkowitego przepisania, aby wspierać konkretny kawałek procesu biznesowego. Proces ten może obejmować prace niemalże wszystkich zespołów technologicznych w organizacji. W wielu organizacjach starsze rozwiązania bywają na tyle rozległe i kluczowe dla całości, że stworzenie nowej wersji wymaga zaangażowania niemal wszystkich zespołów technologicznych, a czasem nawet wszystkich.
2. Radykalne zmiany biznesowe: Innym przykładem jest radykalna zmiana biznesowa, na przykład spowodowana nowymi regulacjami prawnymi, przeobrażeniem wizerunku lub marki czy przejęciem innej firmy. W takiej sytuacji kluczowe elementy, takie jak wizualne czy marketingowe atrybuty, rozproszone są po całej organizacji, we wszystkich systemach i procesach. To z kolei wymusza skoordynowane działania bardzo wielu zespołów, a niekiedy również wszystkich bez wyjątku.
3. Nowa linia biznesowa: wprowadzenie nowej linii biznesowej, wymaga zbudowania komponentów w różnych miejscach w organizacji, technologiach, warstwach i lokalizacjach organizacyjnych. Przykładem może być nowa hurtownia danych, przebudowa kluczowego systemu bazowego, modyfikacje w aplikacji mobilnej czy integracje upsellingowe z już istniejącymi produktami. W takich przypadkach sukces biznesowy zależy od w miarę jednoczesnej realizacji zmian w wielu miejscach organizacji.

Nie jesteśmy zwolennikami nadmiernego podejścia do skalowania pracy zwinnej. Mamy takie doświadczenie, że praktykowaliśmy skalowanie jeszcze przed pojawieniem się frameworków, co daje nam przekonanie, że najlepiej podchodzić do tego tematu ewolucyjnie. Oczywiście można inspirować się różnymi metodami, ale wciąż uważamy, że to może być pułapka. Zachęcamy do dopasowywania rozwiązań do konkretnego kontekstu organizacji.

Na zakończenie tego rozdziału poniżej wskażemy konkretne praktyki, które sami byśmy zastosowali. Jednak nie traktuj ich jako gotowego zestawu czy procedury, ponieważ każda organizacja ma swoje specyficzne potrzeby. Warto je dopasować do odwagi, możliwości oraz dojrzałości zespołów. Te czynniki mogą sprawić, że w jednej organizacji dane praktyki będą miały sens, a w innej już nie.

Proponowane praktyki pracy wielu zespołów nad jedną inicjatywą

1. Jasny i wyraźny cel inicjatywy

Jasny i wyraźny cel inicjatywy ma za zadanie spajać myślenie ludzi na temat tego, co tak naprawdę jest do zrealizowania. Rekomendujemy tę praktykę, aby uniknąć rozjazdu priorytetów w organizacji i zapobiec rozszerzaniu budżetu czy zakresu projektu. Jasne określenie celu to nasz absolutny klasyk, punkt wyjścia. Tak jak dla pojedynczego zespołu potrzebujemy sensownego celu, tak samo ta praktyka ma zastosowanie w przypadku współpracy wielozespołowej. Ten cel może stać się mantrą, przypomnieniem, o co wszystkim zespołom chodzi.

Tak jak wspomnieliśmy, cele dla zespołów mogą być jasne, ale w przypadku inicjatyw wielozespołowych może się okazać, że dla danego zespołu priorytety się zmieniają. Na przykład zespół rozwijający swój kawałek produktu może mieć swoją road mapę, ale gdy pojawia się większa, ogólnofirmowa inicjatywa, może być konieczne wstrzymanie pracy nad dotychczasowymi zadaniami i skupienie się na wspólnym celu. Ważne jest, żeby ten cel był jasny i zrozumiany przez wszystkich, aby nie powstały sytuacje, w których zespoły realizują równolegle swoje cele, udając, że współpracują nad czymś ogólnofirmowym. Jeśli inicjatywy mają się udać, wszyscy powinni realizować wspólny cel.

2. Budżetowanie przyrostowe

Chodzi o uruchamianie budżetu na wczesnym etapie projektu, ale nie na całą inicjatywę, z góry na wiele miesięcy czy lat. Zamiast tego, podobnie jak fundusze inwestycyjne w start-upy, otrzymujecie pierwszą pulę finansowania, która pokrywa początkowe etapy. Takie podejście jest oszczędne i nastawione na szybkie wyniki, a kolejne rundy inwestowania są przyznawane w miarę osiągania celów. Ta praktyka jest istotna, ponieważ wielozespołowe inicjatywy niosą ryzyko przekroczenia budżetów, zakresu czy harmonogramu. Dlatego ważne jest, by jasno zakomunikować wszystkim zespołom, że dostaną tylko fundusze na początek, a dalsze finansowanie zależy od wyników. Należy unikać komfortowego podejścia, które może prowadzić do opóźnień, ponieważ czas jest kosztowny przez cały okres trwania projektu. Ważne jest, aby projekt realizować małymi krokami, zgodnie z uruchamianym finansowaniem.
Warto pokazać, że rozumiemy cele biznesowe, że ogarniamy technologię, a co ważne, szczególnie przy skalowaniu, potrafimy ze sobą współpracować. Oczekiwanie, że powstanie coś namacalnego, stanowi doskonały pretekst do sprawdzenia i zarządzania wszystkimi ryzykami.

3. Dedykowany zespół pod inicjatywę

Trzecia praktyka, którą rekomendujemy, to stworzenie dedykowanego zespołu pod konkretną inicjatywę. Może to być sprzeczne z tradycyjnym podejściem, w którym zespoły odpowiadają za określone obszary lub produkty. Często pojawia się pokusa, by przypisać część zasobów istniejących zespołów do realizacji wspólnej inicjatywy. Proponujemy jednak odwrotne podejście: zamiast tego, utwórz zespół dedykowany tej inicjatywie, aby uniknąć rywalizacji o czas i zasoby. Takie podejście zapewnia pełne skupienie na zadaniach, które muszą zostać wykonane, eliminując konieczność dzielenia uwagi między konkurujące inicjatywy.

W najlepszym przypadku, zamiast angażować wiele zespołów do jednej inicjatywy, wyciągniemy po dwie, trzy osoby z kilku zespołów, które normalnie musiałyby współpracować, i stworzyć dedykowany zespół skoncentrowany wyłącznie na tym przedsięwzięciu.

Wiemy, że może to być sprzeczne z zasadą stałych zespołów, które są skupione na konkretnych produktach lub obszarach, ale w tym przypadku zachęcamy do rozważenia przełamania tej zasady, aby zapewnić pełne skupienie na realizacji danej inicjatywy.Zdajemy sobie sprawę, że ta praktyka może być sprzeczna z zasadą tworzenia stałych zespołów, które są przypisane do konkretnych produktów, obszarów lub systemów. Niemniej jednak, zachęcamy do rozważenia przełamania tej zasady, by stworzyć zespół dedykowany wyłącznie realizacji tej inicjatywy, co pozwoli na pełne skupienie się na jednym celu i zminimalizowanie rozproszenia.

4. Dobór najlepszych ludzi z dostępnych w organizacji

Kolejna praktyka, o której mówimy, dotyczy doboru ludzi i polega na wybraniu najlepszych osób dostępnych w organizacji. W przypadku przedsięwzięć wymagających pracy wielu zespołów, które mają szczególne znaczenie biznesowe, warto bardzo starannie przeanalizować dostępne zasoby i wybrać te osoby, które mają największy wpływ na powodzenie projektu. Szczególnie istotne jest, aby wybrać osoby w funkcjach kluczowych, liderskich, Osoba zarządzająca produktem, w tego typu przedsięwzięciach rośnie również potrzeba dobrego architekt, oraz osoby na innych liderskich stanowiskach mogą mieć ogromny wpływ na sukces. Warto, aby osoby odpowiedzialne za tworzenie struktury wielozespołowej w organizacji rozważyły selekcję najbardziej odpowiednich kandydatów do tego przedsięwzięcia, by minimalizować ryzyko i zwiększyć szanse na jego powodzenie.

Za tą praktyką doboru najlepszych ludzi kryje się jednak pewne zagrożenie. Jeśli stworzymy zespół z samych „gwiazd”, mogą pojawić się trudności związane z ich współdziałaniem. Może to prowadzić do problemów z ego, rywalizacją o to, czyje pomysły będą dominować, czy które decyzje będą priorytetowe. Przy tworzeniu takiego zespołu, warto szczególną uwagę zwrócić na proces grupowy oraz jego facylitację. Ważne jest, aby zespół, który początkowo może mieć różne interesy, z czasem stał się spójną grupą. Należy działać w krótkich okresach, raczej myśląc w kategoriach tygodni niż miesięcy, by stopniowo budować efektywną współpracę.

5. Jeden lider biznesowy decydujący o priorytetach

Kolejną praktyką jest wskazanie jednej osoby, która będzie odpowiedzialna za podejmowanie decyzji i wyznaczanie priorytetów, pełniąc rolę lidera biznesowego. Ta osoba powinna pełnić funkcję kompasu lub latarni morskiej, wskazując właściwą drogę. W zależności od struktury organizacyjnej, może to być Product Owner, Product Manager, Project Manager lub inna rola, ale najważniejsze, żeby była to jedna osoba, która posiada autorytet, wizję i asertywność, oraz jest w stanie skutecznie poprowadzić całą inicjatywę.

Podkreślamy, że kluczowe jest, aby była to jedna osoba odpowiedzialna za decyzje, ponieważ w organizacjach z wieloma dobrze działającymi zespołami może być kilka osób liderskich. Jeśli nie zostanie wyraźnie wskazana, namaszczona ta jedna osoba do podejmowania decyzji, istnieje ryzyko, że powstanie komitet produktowy, który podejmie decyzje kompromisowe lub niejednoznaczne, zamiast skupić się na klarownym celu i wartości.

W idealnym scenariuszu, powinna to być jednoznacznie wskazana osoba decyzyjna. Może to być także lider spośród Product Ownerów, który przyjmuje odpowiedzialność za decyzje w trudniejszych sytuacjach, pierwszy wśród równych. Osoba, która decyduje w sytuacji impasu, albo innych trudniejszych, w których przejmie kierownice. W zależności od kultury organizacyjnej rozwiązanie może być mniej lub bardziej wyraźne, ale kluczowe jest, by nie pozostawić tego obszaru niezaopiekowanego, licząc na to, że wszyscy się dogadają.To może nie mieć miejsca.

6. Kontrakt na współpracę międzyzespołową

Kolejna praktyka, którą warto rozważyć, to kontrakt na współpracę międzyzespołową. Kładziemy na tą formę współpracy szczególny nacisk. Zakładając, że bazujemy na zespołach, które już istnieją, mogą one mieć już swoje zasady działania, kontrakty, które są bardziej lub mniej ugruntowane.

Jednak w przypadku, gdy tworzymy nową strukturę międzyzespołową, może się okazać, że zespół A ma świetne zasady, zespół B ma inne zasady, również dobre, ale różne, a zespół C stosuje zasady, które mogą być zupełnie sprzeczne z tymi w zespołach A i B. W takim przypadku, tworząc taką strukturę, warto bardzo świadomie podejść do kwestii współpracy. Ważne jest, by wszystkie zespoły biorące udział w wspólnej inicjatywie miały ustalony co najmniej minimalny standard współpracy. Ten standard może dotyczyć trywialnych rzeczy, jak narzędzia do komunikacji, miejsce przechowywania dokumentów, narzędzia do śledzenia zadań, ale również bardziej praktycznych kwestii, jak odpowiedzialność za zakończenie zadań, przypomnienia czy zasady współpracy z konkretnymi procesami wytwórczymi.
Taki kontrakt może być narzędziem, które pomoże przyspieszyć współpracę konkretnego zespołu, właśnie dzięki temu, że na początku ustalimy, jak podchodzimy do konkretnych tematów. Jasność i przejrzystość podstawowych zasad mogą działać jako akcelerator współpracy w zespole, co w praktyce sprawi, że procesy będą przebiegać sprawnie.

7. Jedno źródło prawdy o priorytetach

Chodzi o to, aby mieć jedno miejsce, które będzie źródłem prawdy, dostępne dla wszystkich, aby uniknąć poczucia, że nie widzimy pełnego obrazu zadań, którymi się będziemy zajmować, lub że część tematów zostanie nam ujawniona dopiero później. To jedno źródło powinno jasno wskazywać, które tematy są do zrealizowania, nad którymi aktualnie pracujemy, a które zostały już zakończone.
Ta praktyka jest bardzo zbieżna z dwoma wcześniejszymi. Z jednej strony jasno pokazuje podjęte decyzje, a w źródle prawdy znajduje się informacja o tym, co aktualnie realizujemy. Jest również powiązana z przyrostowością na poziomie budżetowym, ponieważ prawdopodobnie napotkamy ograniczenia. Rzadko zdarza się, aby takie duże przedsięwzięcie nie miało żadnych ograniczeń. Te ograniczenia muszą być bardzo wyraźne. Konkretnie, te rzeczy robimy, a innych nie robimy, nawet jeśli mogłyby być wykonane. Często pojawia się pokusa, by przy okazji zrobić coś dodatkowego, ale im bardziej rozproszona jest wiedza na temat priorytetów, tym łatwiej może dojść do rozbieżności. Rozszerzający się zakres może szybko wymknąć się spod kontroli. Dlatego lepiej mieć jedną, wspólną listę priorytetów. W przypadku Scruma będzie to jeden Backlog Produktu, a w podejściu kanbanowym jedna kolumna jednoznacznie wskazująca zadania do realizacji w pierwszej kolejności.

8. Praca przyrostowa na poziomie całej inicjatywy

Przedostatnia porada to praca przyrostowa na poziomie całej inicjatywy. Wspomnieliśmy wcześniej o budżetowaniu przyrostowym, a teraz przenosimy akcent na dostarczanie przyrostowe. Jest to oczywiste w wielu zespołach, gdzie kolejne wersje i części produktu są dostarczane stopniowo. Każdy zespół, zwłaszcza gdy jest rozdzielony systemowo lub komponentowo, robi coraz lepsze wersje swojego kawałka. Chcielibyśmy jednak podkreślić, że nie chodzi tylko o to, by każdy zespół robił swój kawałek przyrostowo, ale by cała inicjatywa była realizowana w sposób przyrostowy. Gdy zespół A, B i C zrobią swoje części, te części muszą być połączone i tworzyć przyrostowy produkt. Na początku może to być bardzo prosty produkt, ale z biegiem czasu, gdy będzie rozwijany, coraz bardziej zbliży się do ostatecznej wersji. Ważne jest, by na poziomie całej inicjatywy, przyrostowość była widoczna od samego początku. Na końcu będziemy mieć już prawie gotowy produkt, z drobnymi poprawkami, ale całość będzie już w pełni funkcjonalna, a nie tylko zbiorem niepowiązanych elementów.

Cała zabawa w integrację rozwiązania polega na tym, jak podejdziemy do wersjonowania, czy mamy włączoną ciągłą integrację, jak wygląda cały proces code review i zapewnienia, że wszystkie elementy na koniec dnia będą działały razem. Z perspektywy biznesowej to może być coś, co łatwo zostaje niedoszacowane, jeśli chodzi o całkowity wysiłek potrzebny do zintegrowania takiego projektu. Im wcześniej zaczniemy ten proces i będziemy oczekiwać, że integracja przebiegnie na wszystkich poziomach, tym szybciej dowiemy się, czy napotkamy jakiekolwiek trudności, brakuje nam zasobów lub mamy inne problemy. Będziemy mieli wtedy czas na odpowiednią reakcję.

9. Wspólne sesje usprawnieniowe

Ostatnia rekomendacja, którą przygotowaliśmy, brzmi: wspólne sesje usprawnieniowe. Mocno wierzymy w to, że zawsze można pracować lepiej i zawsze można znaleźć usprawnienia. W szczególności w sytuacji, o której piszemy w tym artykule, że na pewno pojawi się mnóstwo tematów, które można zrobić inaczej, lepiej. Będziemy się potykać o różne trudności. Dlatego niezwykle ważne jest, aby regularnie przeprowadzać sesje usprawnieniowe, które prowadzą do konkretnych usprawnień, wprowadzanych w życie. Zwłaszcza że wymiar współpracy międzyzespołowej sam w sobie będzie generował tematy, które w wielu firmach mogłyby już być dość dogrzane. Jeżeli pójście w model wielozespołowy będzie się różnić w zależności od inicjatywy, to te doświadczenia i sposób współpracy będą się dopiero kształtować. Nie zakładajmy, że jedno rozwiązanie będzie działało za każdym razem. Takie wspólne sesje usprawnieniowe mogą być coraz bardziej skomplikowane w miarę wzrostu skali, więc warto rozważyć scenariusz, w którym te sesje nie będą gromadziły wszystkich uczestników projektu, ale tylko odpowiednich ludzi. Na przykład programiści z różnych zespołów mogą się spotkać, by omówić aspekty ze swojej profesji, albo tylko Product Ownerzy, aby rozmawiać o priorytetach. Takie elastyczne podejście będzie bardziej efektywne, niż sztywne trzymanie się dużych spotkań dla wszystkich, które mogą zabić entuzjazm do usprawniania się.

Jeśli czujesz, że temat usprawniania się w twojej organizacji wymaga jeszcze poprawy, zachęcamy Cię do zapoznania się z naszym webinarem, w którym opowiadamy o tym, jak skutecznie wprowadzać usprawnienia. Znajdziesz go na stronie porzadnyagile.pl/retro.

Przestrogi oraz przemyślenia przy pracy wielozespołowej

1. Zaakceptuj, że nie będzie idealnie od początku

Pierwsza przestroga, już częściowo zasygnalizowana w ostatniej praktyce, to zaakceptowanie, że nie będzie idealnie od początku. Wiele osób, które mierzą się z tym wyzwaniem, ma nadzieję, że dobrze zaplanowane procesy i dobrze zarysowane granice sprawią, że wszystko pójdzie gładko już od pierwszego dnia. W innych przypadkach jest pełna świadomość, że robimy to po raz pierwszy w organizacji, więc może nie będzie idealnie, ale pojawia się szybka frustracja, gdy spotkania są nieefektywne, ktoś coś zgubił, coś się nie zgrało. Nasza przestroga: tak, tak będzie. Niestety, tak to wygląda.

Konstrukcje wielozespołowe, zwłaszcza w organizacjach, które nie mają jeszcze dużego doświadczenia, po prostu nie będą optymalne na początku. Potrzebujemy się usprawniać, uczymy się, stosujemy praktyki, które pomagają szybciej wychwycić problemy. Ważne jest, by docenić postęp w kolejnych krokach i nie oczekiwać, że wszystko będzie idealnie na samym początku.

2. Pozwól na odstępstwa od tego, jak zespoły działają zazwyczaj

Część naszych porad może być sprzeczna z tym, jak funkcjonuje twoja organizacja, dlatego chcemy zachęcić cię, aby nie trzymać się kurczowo tradycyjnych ustaleń czy firmowego kanonu, który narzuca, jak zespoły mają pracować. Sytuacja, o której mówimy, jest wyjątkowa i może się okazać, że to, co jest zapisane w firmowym playbooku lub co robiliście do tej pory, nie będzie odpowiednie w tej konkretnej sytuacji. Czasami trzeba na chwilę odłożyć te przyjęte zasady na bok i zastanowić się, co będzie najlepsze w danym momencie, nie martwiąc się o „dług” decyzji podjętych w przeszłości.

3. Pogódź się z faktem, że współpraca wielu zespołów będzie mniej efektywna

Trzecia przestroga to pogódź się z faktem, że współpraca wielu zespołów będzie mniej efektywna. Bez względu na to, jak dobrze wdrożymy praktyki, które rekomendujemy, musimy być świadomi, że przy realizacji dużych przedsięwzięć, w których zaangażowane są setki osób, efektywność per osoba będzie znacznie niższa niż w przypadku mniejszych zespołów, liczących na przykład do dziesięciu osób.

Praca będzie bardziej żmudna, spotkania większe, wymagające więcej uwagi i organizacji. Pojawią się również dodatkowe cykle synchronizacyjne i mechanizmy, które normalnie można by pominąć, ale w przypadku dużych przedsięwzięć będą konieczne.

Nie mamy magicznych rozwiązań, to po prostu koszt większych inicjatyw. Warto zrewidować bądź urealnić oczekiwania, ponieważ duże przedsięwzięcia nie zawsze przyspieszają realizację projektów, a ich wartość może nie być tak wysoka, jak wynikałoby to z analiz w Excelu czy PowerPointach.

4. Bazuj na dobrze działających zespołach i procesach

Bałagan w pojedynczych zespołach, nieefektywności w procesach wytwórczych, problemy z komunikacją czy technologią tylko się pogłębi, uwypukli, gdy zaczniemy działać wielozespołowo. Dlatego ważne jest, aby zadbać o to, by procesy, współpraca i działania na poziomie pojedynczych zespołów były jak najbardziej efektywne. gdy zaczniemy angażować wielu ludzi w dużą inicjatywę, problemy sumują się, a ich skala staje się znacznie bardziej widoczna na poziomie całej inicjatywy.

A co zrobić, jeśli czujesz, że działające zespoły i procesy są nieoptymalne i rzeczywiście będzie to potęgowanie problemów? Może warto zrewidować, czy konieczne jest realizowanie tak dużej inicjatywy w organizacji. Może lepiej podzielić ją na mniejsze, niezależne zadania dla zespołów, zamiast porywać się z motyką na słońce, jeśli obecne warunki są zbyt trudne. Alternatywnie, jeśli jednak zdecydujesz się kontynuować, musisz być gotowy na to, że będzie jeszcze trudniej – pewne rzeczy mogą się rozjeżdżać, a inne psuć w trakcie pracy. W takim przypadku może okazać się, że będzie potrzebne wsparcie zewnętrzne, dodatkowe inwestycje w czas, uwagę, czy budżet, aby jak najszybciej wyprostować problemy i utrzymać inicjatywę na właściwym kursie.

5. Zapewnij wsparcie merytoryczne dla organizacji i zespołów

Praca w konfiguracji wielozespołowej jest trudna, co wskazujemy w całym artykule. Jeśli twoja firma nie ma jeszcze doświadczeń w tym zakresie, nie wahaj się skorzystać z pomocy osób, które już to robiły. W dzisiejszych czasach są profesjonaliści, którzy mają doświadczenie w pracy z takimi inicjatywami. Może to być Scrum Master, Agile Coach, doświadczony Product Owner lub Product Manager, a także kierownicy projektów, którzy potrafią poprowadzić zespół w sposób zwinny. Nie zamykaj się na żadną z opcji, ale skorzystaj z doświadczeń, które mogą pochodzić spoza naszej organizacji. To może być także doskonały pretekst do współpracy z doradcami,takimi jak my, którzy wspierają tego rodzaju przedsięwzięcia. Jest to dobry punkt startu czy nawet cała orbita, wokół której zapewniamy wsparcie organizacji. W takim przypadku koncentrujemy się na transferze naszych doświadczeń, co znacząco zwiększa szansę na sukces ważnego przedsięwzięcia w organizacji, które sprowokowało koncepcję pracy wielozespołowej.
Jakie przestrogi mamy dla liderów, którzy potrzebują zrealizować zwinną inicjatywę wieloma zespołami?

• Zaakceptuj, że nie będzie idealnie na początku.
• Pozwól na odstępstwa od tego, jak zespoły działają zazwyczaj.
• Pogódź się z faktem, że współpraca wielu zespołów będzie mniej efektywna.
• Bazuj na dobrze działających zespołach i procesach.
• Zapewnij wsparcie merytoryczne dla organizacji zespołów.

Jeżeli mierzysz się z tematem współpracy na poziomie wielu zespołów i chcesz uniknąć typowych problemów związanych ze skalowaniem, odezwij się do nas. Wsparcie mentorskie podniesie szansę na sukces ważnych inicjatyw w twojej firmie. Opisz nam swoją sytuację, używając formularza na stronie porzadnyagile.pl/kontakt
Dobrze rozumiejąc twoją sytuację, proponujemy kilka opcji współpracy dopasowanych do twojego budżetu. Może to być pomoc w postaci pojedynczych konsultacji, wsparcie przy występowaniu prac, aż po pełne wsparcie mentorskie podczas całych prac wytwórczych czy projektowych.

Transkrypcja podcastu „Inicjatywy wielozespołowe”

Kuba: Rozmawialiśmy niedawno z Jackiem z pewnym liderem IT, który na krawędzi naszej rozmowy, która była o jakimś innym wątku, zapytał nas właśnie o kwestię współpracy wielu zespołów zwinnych nad jednym większym przedsięwzięciem. Mieliśmy swoją odpowiedź w tamtej rozmowie, ale stwierdziliśmy, że temat jest godny nagrania tego materiału.

Jacek: Tym bardziej że uważamy z Kubą, że jest to temat, który dotyczy wielu firm i wiele firm, kiedy opanuje pracę nad konkretnym produktem czy projektem na poziomie pojedynczych zespołów, albo chce, albo staje przed sytuacją, w której będzie trzeba sobie poradzić w sytuacji, gdzie tych zespołów zaangażowanych więcej.

Kuba: I taka mała ironia dla naszych wiernych słuchaczy. Naprawdę mamy jeszcze o czym nagrywać, bo to 129. odcinek, a to pierwszy raz, gdy realnie zabierzemy się za coś, co w gronie praktyków zwinności bywa nazywane skalowaniem czy skalowaniem zwinności. Tego tematu jeszcze nie poruszaliśmy, mamy swoje konkretne zdanie no i opowiemy Tobie co można zrobić, jak sobie poradzić, kiedy jest projekt dla wielu zespołów zwinnych do realizacji w jednocześnie.

Kuba: Spis treści tego odcinka jest dosyć prosty. Najpierw opowiemy o założeniach do sytuacji, którą chcemy poruszyć, potem podzielimy się proponowanymi praktykami pracy wielu zespołów nad jedną inicjatywą i w ostatniej części przekażemy przestrogi oraz dodatkowe przemyślenia w tym temacie.

Jacek: Kilka założeń dotyczących tego odcinka. Zakładamy, że są już jakieś zespoły zwinne, które są pewnego rodzaju bazą. Działają w miarę ok, w zadowalający sposób. Nie ma jakichś wybitnych patologii. Można im zaufać na poziomie dowożenia, dostarczania ich własnych tematów z własnego podwórka. Będziemy rozmawiać o sytuacji, w której pojawia się nowy, duży, ważny temat, który będzie wymagał działań wielu zespołów.

Kuba: I co mamy na myśli, gdy mówimy wspólny temat dla wielu zespołów? Spotykamy bardzo różne układanki. Wrzucimy kilkoma przykładami takimi zanonimizowanymi. Zobaczymy, na ile to jest coś, co też dotyczy twojej sytuacji. Popularny przypadek to jest przebudowa czy może nawet kompletne przepisanie jakiegoś większego systemu, który wspiera konkretny kawałek procesu biznesowego. W wielu organizacjach te starsze systemy potrafią być na tyle rozległe i na tyle integrujące całość rozwiązania, że po prostu napisanie czegoś nowego wymaga pracy albo prawie wszystkich zespołów technologicznych, a może nawet w niektórych przypadkach wszystkich. Inny przypadek to jakaś radykalna zmiana biznesowa, na przykład zmiana wynikająca albo sprawa, albo zmiana wizerunku, zmiana brandu, może przy okazji jakiegoś przejęcia też zmiana jakichś takich podstawowych elementów takich, powiedzmy, wizerunkowych, marketingowych, które po prostu są rozsiane po całej organizacji, po wszystkich systemach, po wszystkich procesach i potrzeba skoordynowanego działania całej masy zespołów albo wręcz dosłownie wszystkich zespołów. Może to być też coś bardzo trudnego. Nowa linia biznesowa, która wymaga zbudowania składowych z kilku zespołów, w kilku technologiach, z kilku warstw, w kilku miejscach organizacji, może jakaś hurtownia, może jakiś core system, może zmiana w appce, może podłączenie przy okazji jakiejś upsell z innych już istniejących produktów, gdzie też zaszyte rozwiązanie będzie w kilku miejscach. No i sukces biznesowy zależy od tego, że w miarę jednocześnie w dosyć różnych miejscach organizacji będzie to rozsiane.

Jacek: I jak usłyszysz w ciągu tego odcinka, nie jesteśmy jakimiś nadmiernymi fanami konkretnego skalowania pracy zwinnej. Raczej z Kubą mamy takie doświadczenie, że praktykowaliśmy skalowanie, kiedy frameworków skalowania nie było i tak do dzisiaj nam zostało, że to chyba tak na koniec dnia jest najmądrzejszy sposób, żeby ewolucyjnie podchodzić do tematu skalowania. Oczywiście można się inspirować, ale to zawsze będzie pewnego rodzaju pułapka. No i całość tego nagrania będzie zachęcać też do tego, żeby zawsze w takich sytuacjach starać się dopasować rozwiązanie, które pasuje do Twojego kontekstu.

Kuba: Już kończąc ten rozdział wstępny, w tym odcinku podajemy za chwilę konkretne praktyki, które sami byśmy zastosowali. Natomiast koniecznie nie traktuj ich jako gotowego zestawu, konkretnej procedury, bo tutaj co organizacja to trzeba to dopasować do pewnej odwagi, możliwości, dojrzałości. To są wszystko składowe, które mogą powodować, że wybrane praktyki mają, a w innych organizacjach jednak nie mają sensu.

Jacek: Więc bardziej chińskie menu, a nie jedna konkretna potrawa, gdzie każdą z tych naszych rekomendacji można wykorzystać w zależności od tego, czy czujesz, że ona ma sens w Twoim kontekście. Praktyki te bowiem mogą się wzajemnie wykluczać.

Kuba: Ok, to przechodząc do sedna. Jakie to są praktyki? Jeśli potrzebujesz działać wieloma zespołami zwinnymi nad jedną całością, rozważ następujące praktyki. Jasny i wyraźne cel inicjatywy. Budżetowanie przyrostowe. Dedykowany zespół pod inicjatywę. Dobór najlepszych ludzi z dostępnych organizacji.

Jacek: Jeden lider biznesowy decydujący o priorytetach. Kontrakt na współpracę międzyzespołową. Jedno źródło prawdy o priorytetach. Praca przyrostowa na poziomie całej inicjatywy oraz wspólne sesje usprawnieniowe.

Kuba: Przejdźmy do szczegółów tych zaproponowanych praktyk. Pierwszą rzeczą, jaką wymieniliśmy, był jasny i wyraźny cel inicjatywy. O co tutaj chodzi?

Jacek: Zdecydowanie. Jasny i wyraźny cel inicjatywy ma za zadanie być pewnego rodzaju takim kapeluszem czy parasolem spajającym myślenie ludzi na temat tego, co tak naprawdę jest do zrealizowania. Rekomendujemy tę praktykę po to, żeby w jakiś sposób nie rozjechały się priorytety, które gdzieś tam w organizacji funkcjonują. Przy okazji, żeby nie doszło do sytuacji, że puchnie nam budżet projektu, czy puchnie nam zakres projektu. Jasne określenie celu to jest taki nasz z Kubą absolutny klasyk, punkt wyjścia, punkt startowy. Tak jak potrzebujemy sensowny cel dla pojedynczego zespołu, no to tak samo ta praktyka jest prawdziwa w momencie, kiedy mówimy o współpracy wielozespołowej.

Kuba: Ten cel może stać się pewną mantrą, pewnym takim przypomnieniem, o co nam wszystkim chodzi, o co chodzi wszystkim zespołom. Zwłaszcza że tak jak Jacek powiedziałeś przed chwilą, cele dla zespołów mogą być jasne, natomiast w przypadku inicjatyw wielozespołowych może się okazać, że dla danego zespołu te cele takie, które zazwyczaj są realizowane, one jednak przez chwilę nie będą najważniejsze. Czyli na przykład jest jakiś zespół, który rozwija swój własny system, czy swój kawałek produktu i normalnie zmierzają w jakimś kierunku, zgodnym z wizją tego produktu, zmierzają w realizacji konkretnych kolejnych kroków na Road mapie. Natomiast gdy jednak jest taka spajająca, większa inicjatywa ogólnofirmowa, to może się okazać, że ten cel jednak nie będzie taki oczywisty i wszyscy muszą czuć, że przez chwilę przestajemy realizować tą naszą normalną Road mapę, bo jednak musimy się podporządkować pod ten cel całości. No i tutaj jesteśmy wielkimi fanami tego, żeby to było bardzo klarowne, żeby wszyscy to rozumieli, wszyscy tak samo to interpretowali, żeby nie było takie, no dobra, dobra, robimy niby coś ogólno-firmowego, ale tak naprawdę dalej robimy swoje, bo nic się nie zmieniło. Jeśli te inicjatywy mają się udać, a często one są bardzo ważne biznesowo, z jakichś konkretnych przyczyn firma jednak chodzi o inne konstrukcje, no to też wszyscy realizujmy wspólnie ten sam cel.

Kuba: Druga praktyka to budżetowanie przyrostowe. Co to znaczy budżetować przyrostowo? To znaczy uruchamiać budżet, albo uwalniać ten budżet, nie na całą inicjatywę, z góry na wiele miesięcy, kwartałów, a w wielu przypadkach nawet na wiele lat w przód, tylko raczej przyjąć takie założenie, jak fundusze inwestycyjne inwestują w start-upy. Dostajecie pewną rundę finansowania, na wczesnym etapie dostajecie tylko pewne środki, które z góry można założyć, że w zasadzie są niewystarczające na całą wielką rzecz, która jest szykowana, ale chodzi o to, żeby już na wczesnych etapach pójść w takie rozwiązanie bardzo świadomie oszczędne, bardzo też nastawione na pierwsze wczesne rezultaty, po to, żeby ewentualnie dosypać kolejnego inwestowania. Odwracając trochę to od strony ryzyk, te wielozespołowe inicjatywy niestety mają bardzo dużą korelację też z takim zagrożeniem przekroczenia budżetów, przekroczenia zakresów, przekroczenia harmonogramów. To wszystko jest związane z tym, że po prostu jest to bardzo duże coś, no i trzeba świadomie postawić pewną tamę. Dać jasny komunikat do całej grupy, do tej grupy zespołów. Wykorzystajcie, zróbcie pierwszą wersję, zróbcie jakieś NVP i dopiero potem zdecydujemy o kolejnych rundach finansowania, tak żeby nikt się gdzieś tam nie poczuł zbyt komfortowo albo żeby się nawet, bym powiedział, nie rozleniwił taką optyką. Ok, ok, najbliższe wdrożenie dopiero za rok, możemy mnóstwo czasu nawet zmarnować. Zmarnowany tydzień developmentu jest tak samo drogi w pierwszym tygodniu projektu, jak po roku projektu i od razu nastawiałbym całą ekipę na to, żeby jednak iść z tym takim założeniem, że nie mamy nadmiernego budżetu i nawet przełamać tę zasadę, że to coś, co robimy, jest tak wielkie. To jest wielkie, ale będziemy robić to małymi krokami zgodnymi z uruchamianym finansowaniem.

Jacek: I tutaj na pewno odporność psychiczna osoby, która buduje takie oczekiwanie, jest istotna, bo spodziewałbym się, słysząc w wielu organizacjach takie głosy, że nie da się, nie można, nie w naszej firmie, to jest nierealne, zawsze robiliśmy to inaczej. Czyli takie klasyczne argumenty, że się nie da. Mimo wszystko tutaj należy zacisnąć zęby i trzymać się tej wersji, że okej, rozumiem, to nie będzie tak kompletne, tak idealne, tak perfekcyjne, ale udowodnijmy sobie wszyscy, tak jak jesteśmy zaangażowani w ten projekt czy inicjatywę, że jesteśmy w stanie dać jakiś zalążek i tak jak wspominałeś Kuba w tych ryzykach. Pokazać, że rozumiemy, o co chodzi biznesowo, pokazać, że ogarniamy technologię no i co istotne w szczególności w przypadku skalowania, pokażmy, że potrafimy ze sobą współpracować. Oczekiwanie, że powstanie coś namacalnego jest świetnym pretekstem, żeby wszystkie te ryzyka sprawdzić.

Jacek: Trzecia praktyka, którą rekomendujemy, dedykowany zespół pod inicjatywę. Jest to praktyka, która może wstać w sprzeczności z klasycznym podejściem, które funkcjonuje w organizacji. Czyli mamy stworzone zespoły, które odpowiadają za jakieś określone obszary, procesy, produkty w zależności od tego, po jakim kluczu organizacja zdecydowała się na podział. No i mogłaby istnieć pokusa, żeby wydzielić jakąś część pojemności zespołów na realizację jakiejś wspólnej inicjatywy. Praktyka, którą proponujemy, jest pewnego rodzaju kontrą, czyli raczej mówimy, stwórzmy dedykowany zespół pod inicjatywę, po to, żeby nie trzeba było rywalizować z innymi tematami, które dzieją się w ramach konkretnych zespołów. W takim przypadku uzyskamy tutaj efekt skupienia, polegający na tym, że doskonale wiemy, co jest do zrobienia. Nic innego nas nie rozprasza. No i nie musimy się zastanawiać, w jaki sposób dokonać podziału czasu pomiędzy wiele konkurujących ze sobą inicjatyw.

Kuba: W najszczęśliwszym obrocie spraw może się okazać, że jednak nie będziemy mieli współpracy wielu zespołów nad jedną inicjatywą, bo być może powyciągamy po dwie, trzy osoby z kilku zespołów, które normalnie musiałyby współpracować. Możemy z nich nawet tylko tymczasowo pod daną inicjatywę stworzyć po prostu dedykowany zespół w pełni oddany, w 100% oddany temu przedsięwzięciu. Zdajemy sobie sprawę, że to może być sprzeczne z zasadami. Jeszcze trochę będziemy dzisiaj o tym mówić. Z zasadami związanymi np. ze stałymi zespołami. Czyli gdzieś tam łatwo wchodzi praktyka – miejmy zespoły, które skupione są wokół konkretnego produktu, wokół konkretnego obszaru czy systemu. Natomiast my tutaj zachęcamy wśród możliwych praktyk do rozważenia, czy by nie przełamać tej zasady i jednak dla dobra inicjatywy stworzyć dedykowaną ekipę skupioną wokół konkretnego tematu.

Kuba: Następna praktyka też jest o doborze ludzkiej, czy dedykowanym zespole. Praktyka, którą nazywaliśmy dobór najlepszych ludzi z dostępnych w organizacji. Zwłaszcza jeśli to przedsięwzięcie, które wymaga pracy wielu zespołów, wielu osób, jest z jakiegoś powodu krytyczne biznesowo, może być potrzebne, żeby naprawdę przeselekcjonować, kogo mamy do wyboru i wybrać te osoby, które podniosą nam prawdopodobieństwo, że się to uda. Szczególnie myślimy o tym, żeby dobrać takie osoby w funkcjach krytycznych, liderskich. Osoba zarządzająca produktem, na pewno w takich przedsięwzięciach strasznie rośnie potrzeba na dobrego architekta, na pewno też w zależności od tego, jak organizacja to układa, jakieś osoby w funkcjach liderskich, też mogą zrobić dużą różnicę. Więc zwłaszcza gdy jest pewne pole manewru w organizacji, myślę, że grono managerskie, które układa taką strukturę wielozespołową, mogłoby rozważyć też pewną selekcję osób do zadania i zmniejszyć ryzyko poprzez wybranie osób najlepiej dopasowanych do tego przedsięwzięcia.

Jacek: I jednocześnie za tą poradą, za tą praktyką kryje się pewne zagrożenie. Czyli jeżeli zbudujemy sobie zespół gwiazd, no to może pojawić się problem związany z ich współdziałaniem, może pojawić się temat związany z ego, z tym, czyj pomysł będzie wyżej, niżej i na jakie rzeczy będziemy się decydować. Więc przy okazji budowania takiego zespołu, zdecydowanie warto zwrócić uwagę na sam proces, jakim konstruujemy zespół, proces grupowy, sensowna facylitacja. Wszystkie takie rzeczy, których ostatecznym celem jest sprawienie, że ta grupa ludzi, być może początkowo nawet z nieco sprzecznymi interesami, za kilka tygodni, lepiej myśleć o tygodniach niż o miesiącach, stanie się faktycznym zespołem.

Jacek: Kolejna praktyka. Jeden lider biznesowy decydujący o priorytetach. Mamy tutaj na myśli, żeby wskazać konkretną osobę, która będzie odpowiedzialna za podejmowanie decyzji, będzie osobą wskazującą kierunek, będzie takim trochę kompasem, trochę latarnią morską wskazującą właściwą drogę. W zależności od tego, jak aktualnie wygląda struktura twojej organizacji, czy modele, którymi się inspirujesz, taka osoba może być nazywana czy Product Ownerem, czy Product Managerem, czy Project Managerem i tak naprawdę na koniec dnia ta nazwa nie jest tak istotna, jak to, żeby była to faktycznie jedna wskazana osoba, która ma autorytet, ma wizję, jest osobą asertywną i jest w stanie z sukcesem poprowadzić tego rodzaju inicjatywę.

Kuba: Dlatego kładziemy nacisk na to, że ma być to jedna osoba, bo przyjmując założenie, że bazujemy na organizacji, która ma już sporo dobrze działających zespołów, to takich osób liderskich może być w organizacji sporo. Jeśli się tak nie namaści do decydowania o tej inicjatywie konkretnej jednej osoby, to możemy wpaść bardzo popularną pułapkę takiego komitetu produktowego, który będzie podejmował decyzje kompromisowe albo takie niewyraziste zamiast jednak ostrego cięcia, ostrego skupienia na wartości, ciągłego przypominania, gdzie jest cel, a niekoniecznie gdzieś zadowalania po kolei wszystkich, włącznie z tymi, których zadowolić po prostu ta wspólna inicjatywa nie będzie w stanie. Tutaj w idealnym scenariuszu jest to jednoznacznie namaszczony decydent. Może jest też coś pośredniego typu spośród grona istniejących Product Ownerów wskazujemy kogoś, kto jest pierwszy spośród równych. Jednak osoba, która na przykład decyduje w sytuacji impasu albo w sytuacjach trudniejszych jednak przyjmuje tę kierownicę. W zależności oczywiście od kultury organizacyjnej, od dotychczasowych relacji pewnie rozwiązanie będzie mniej lub bardziej takie wyostrzone, ale w szczególności nie zostawiłbym tego zupełnie niezaopiekowanego albo liczył na to, że po prostu się dogadają albo będą sobie przekazywać o to jedną priorytety i zadania. To może nie mieć miejsca.

Kuba: Następna praktyka, którą proponujemy rozważyć to kontrakt na współpracę międzyzespołową. Mocno dookreślam to, że międzyzespołową. Zakładam, że zwłaszcza jeśli będziemy bazować na zespołach, które już istnieją, to one pewnie swój kontrakt albo oficjalnie mają, albo po prostu już się dotarły i jakieś reguły działania mają. Ale właśnie jakieś reguły działania może się okazać dosyć szybko, że zespół A ma fajne zasady, zespół B ma też fajne zasady, tylko inne, a zespół C ma bardzo unikalne zasady, które są totalnie sprzeczne z zespołami A i B. Więc tutaj, zwłaszcza gdy tworzona jest taka struktura, trzeba bardzo świadomie zwrócić na to uwagę, oddzielnie to zaznaczyć, oddzielnie to przeprocesować, przypilnować, żeby wszystkie zespoły składowe, wchodzące w przykład takie struktury, realizujące taką wspólną inicjatywę, miały ustalony minimalnie potrzebny standard. Ten standard może być również na poziomie dość trywialnym, w jakich narzędziach się komunikujemy, gdzie trzymamy dokumenty, jak korzystamy z narzędzi do trackowania zadań czy czasu, ale to też mogą być takie rzeczy związane na przykład z odpowiedzialnością. Co to znaczy skończona robota? Kto ma dopilnować, kto ma się przypomnieć? Na co sobie pozwalamy w takich kwestiach międzyzespołowych czy związanych z konkretnymi procesami wytwórczymi.

Jacek: I taki kontrakt to może być narzędzie, które pomoże nam, wracając do tego punktu, który mówiliśmy z Kubą wcześniej, sprawić, że współpraca tego konkretnego zespołu przyspieszy, tylko dzięki temu, że na wstępie umówimy się na to, w jaki sposób podchodzimy do konkretnych tematów. Jest to taka jasność i przejrzystość, jeśli chodzi o podstawowe zasady, no jest całkiem dobrym akceleratorem współpracy w zespołach.

Jacek: Kolejna praktyka, jedno źródło prawdy o priorytetach. Myślimy tutaj o sytuacji, w której mamy jedno miejsce prawdy, jedno źródło konkretne, wskazane, dostępne dla wszystkich, tak, aby nie było poczucia, że albo nie widzimy całego obszaru i tematów, którymi będziemy się zajmować, albo że jest to tylko jakiś wycinek na teraz i część dopiero zostanie nam odsłonięta w późniejszym czasie. Jak również jedno źródło, którego zadaniem będzie powiedzenie w taki jasny, binarny sposób, te tematy są do zrobienia, nad tymi tematami aktualnie pracujemy, a te konkretne tematy zostały już zrealizowane.

Kuba: I ta praktyka jest bardzo zbieżna już z dwoma wcześniejszymi. Z jednej strony jest tutaj jasne pokazanie, jakie zapadły decyzje, w takim źródle prawdy jest informacja, tak, to właśnie robimy. Jest to też bardzo powiązane z tą przyrostowością na poziomie budżetowym. Prawdopodobnie będziemy mieli ograniczenia. Rzadko się zdarza sytuacja, żeby takie wielkie przedsięwzięcie nie miało ograniczeń. Te ograniczenia niech będą bardzo jednoznaczne. Czyli te konkretne rzeczy robimy, a innych nie robimy, choć może można. I czasami jest taka właśnie pokusa, jeśli już robimy, to przy okazji róbmy jeszcze to. Im bardziej rozproszona jest wiedza na temat tego, co jest ważne, im bardziej rozproszona jest wiedza na temat tego, jaki jest tak naprawdę zakres do realizacji w danym kroku, w konkretnych kilku kolejnych krokach, to się to może niesamowicie prosto rozjechać. Czyli pokus do tego, żeby się ten zakres ciągle zwiększał, będzie pełny. I lepiej zastosować coś, co jest wspólną listą priorytetów. Jeśli korzystać się ze Scruma, to to będzie jeden Backlog Produktu. Jeśli korzysta się z jakiegoś podejścia bardziej kanbanowego, to będzie po prostu jedna kolumna jednoznacznie pasująca, co jest do zrobienia w pierwszej kolejności.

Kuba: Przedostatnia porada, którą chcielibyśmy przekazać, to praca przyrostowa na poziomie całej inicjatywy. Wspomniałem już na samym początku o budżetowaniu przyrostowym, a teraz akcent przeniosę na to, żeby również dostarczanie było przyrostowo. Dostarczenie przyrostowe jest takie oczywiste w wielu zespołach. Po prostu będą kolejne wersje, kolejne kawałki. Każdy zespół, zwłaszcza jeśli jest rozdzielony jakoś tak systemowo, albo komponentowo, to po prostu będzie robił coraz lepsze wersje swojego kawałka. Natomiast ja bym akcent położył na to, że to nie tylko chodzi o to, żeby każdy robił swój kawałek przyrostowo, ale żeby na poziomie całej inicjatywy powstawały przyrostowy. Jeśli zespół A, B i C zrobią swoje kawałki, to w dodatku te kawałki też są przyrostem. One są połączone, one albo spełniają w jakiejś prostej wersji cały proces, od początku do jego końca, albo to jest jakaś pierwsza wersja całego produktu. Cokolwiek co jest realizowane, ale żeby było również międzyzespołowo przyrostowe, czyli tworzyło kolejne wersje bardzo prostego produktu, na początku wręcz prymitywnego, ale później rosło, rosło, rosło, rosło, aż w końcu, zwłaszcza w drugiej połowie, czy tak bliżej końca, cokolwiek to jest ten koniec, będzie wręcz widać, że w zasadzie to już prawie wszystko mamy. To są jakieś drobne doróbki. Z perspektywy całego zakresu to wcale nie będą drobne doróbki. No ale już będzie bardzo dosyć wcześnie, najlepiej byłoby jak najwcześniej widać, że to już jest jakaś pierwsza część produktu i on jest całością na poziomie całej inicjatywy, a nie tylko sumą jakichś gotowych puzzli, które jednak na razie zupełnie nie tworzą wspólnego obrazku.

Jacek: Moja przeszłość developerska, jak słucham Kuba tej opowieści, pokazuje mi całą masę nieoczywistych problemów, które mogą się pojawić w trakcie implementacji. Cała zabawa w integrację rozwiązania, to w jaki sposób podejdziemy do wersjonowania, to czy mamy zapiętą jakąś ciągłą integrację, pod spodem cały proces code review i zapewniania, że te klocki na koniec dnia połączymy i ze sobą zadziałają. To jest coś, co w szczególności z perspektywy biznesowej może być nieoczywiste i takie trochę bym powiedział niedoszacowane, jeśli chodzi o całościowy wysiłek, który będzie potrzebny, żeby taki projekt zintegrować. Tak więc im wcześniej zrobimy, im wcześniej będziemy oczekiwać też, że zostanie to zintegrowane na wszystkich koniecznych poziomach, to tym wcześniej w najgorszym przypadku dowiemy się, że czegoś nie potrafimy, mamy jakieś problemy, brakuje nam jakichś zasobów. No i będziemy mieć czas, żeby odpowiednio zareagować.

Jacek: Ostatnia rekomendacja, którą przygotowaliśmy z Kubą, brzmi wspólne sesje usprawnieniowe. Jeżeli słuchasz naszego podcastu od dłuższego czasu, to na pewno ten punkt nie jest dla Ciebie zaskoczeniem. Mocno z Kubą wierzymy w to, że zawsze można pracować lepiej i zawsze można poszukać usprawnień. No i w szczególności w takiej konfiguracji, o której od początku dzisiejszego odcinka rozmawiamy, tam na pewno będzie cała masa tematów, które będzie można zrobić inaczej, które będzie można zrobić lepiej. Będzie pełno tematów, o które się potkniemy. Stąd niezwykle istotne jest to, żeby zadbać o to, żeby takie sesje usprawnieniowe pojawiały się często i żeby prowadziły do faktycznych, konkretnych usprawnień, które też będą faktycznie wprowadzane w życie.

Kuba: Zwłaszcza że ten wymiar współpracy międzyzespołowej sam w sobie jeszcze będzie generował tematy, które normalnie pewnie już byłyby w wielu firmach dosyć dogrzane. Zwłaszcza jeśli też pójść w ten model, którym mocno rekomendujemy, że być może w danej organizacji co inicjatywa to trochę inaczej się zabierzemy na tę wielozespołowość. Więc również te doświadczenia muszą się dopiero kształtować i też ten sposób zgrania się dopiero się będzie tworzył, więc nie przyjmujmy założenia, że raz w dobrze wymyślony sposób będzie dobrze działał. Tu oczywiście takie wspólne sesje usprawnieniowe mogą wraz z rosnącą skalą być coraz bardziej skomplikowane, więc również rozważmy scenariusz, w którym te sesje usprawnieniowe już nie są zebraniem wszystkich uczestników całego wielkiego przedsięwzięcia. Może to jest coś, co się powinno odbywać w odpowiednich gronach dedykowanych danemu zagadnieniu. Na przykład spotykają się tylko programiści między sobą z różnych zespołów, bo mają coś do przegadania na swojej profesji. Czy na przykład tylko Product Ownerzy, bo rozmawiają o priorytetach lub mapach. To jest w porządku, tutaj fajnie byłoby uruchomić jakąś taką elastyczność, takie dopasowanie rozwiązania do sytuacji, a nie takie podejście sztampowe. Co do zasady wszyscy wszystko na wspólnych wielkich spotkaniach, bo one w którymś momencie mogą, dosyć łatwo zabić entuzjazm do usprawniania się.

Jacek: Jeżeli czujesz, że temat usprawniania się w twojej organizacji wymaga jeszcze poprawy, to zachęcamy cię do zapoznania się z naszym webinarem, w którym opowiadamy o tym, jak skutecznie wprowadzać usprawnienia. Znajdziesz go na stronie porzadnyagile.pl/retro

Kuba: Jeśli chodzi o listę praktyk, to moglibyśmy jeszcze wymieniać dalej. Postanowiliśmy się zatrzymać na jakimś etapie. Mamy kolejne pomysły, ale też nie mieliśmy ambicji zrobić zamkniętej listy, raczej wyliczyć te, które czujemy, że są tymi najważniejszymi, od których zaczynamy nasze rekomendacje, więc tu się zatrzymamy w tym rozdziale i przejdziemy do drugiej części.

Jacek: W drugiej części chcieliśmy podzielić się już nie konkretnymi praktykami, a raczej pewnego rodzaju przestrogami i dodatkowymi przemyśleniami, które uważamy, że mogą być pomocne, jeżeli jest przed Tobą wyzwanie dotyczące pracy wielozespołowej.

Kuba: Pierwsza przestroga, już w zasadzie była trochę zasygnalizowana w ostatniej z praktyk, czyli zaakceptuj, że nie będzie idealnie od początku. Wiele osób, z którymi rozmawiam, które właśnie mierzą się z takim wyzwaniem, mają ochotę, mają potrzebę, czasami taką pokusę, że jak dobrze to rozplanujemy, że jak dobrze to poukładamy, dobrze wymyślimy procesy, dobrze granice zarysujemy, to już będzie w zasadzie jak z płatka, już od pierwszego roku będzie dobrze. W innych przypadkach może nawet jest pełna świadomość, że po prostu robimy to pierwszy raz w tej organizacji, może idealnie nie będzie, ale jest też taka dosyć szybka, wczesna frustracja, że kurcze, ale te spotkania są nieefektywne, tu ktoś coś zgubił, coś się nie zagrało. To przemyślenie przestroga od nas, tak, tak będzie. Tak, niestety, tak będzie. Czyli te konstrukcje wielozespołowe, zwłaszcza gdy jest, do tej pory nie ma dużego doświadczenia, one niestety po prostu nie będą optymalne. Po to potrzebujemy się usprawniać, po to się uczymy, po to zastosujmy pewne z tych praktyk, które my podpowiedzieliśmy, żeby to wcześniej wyłapać. Żeby pracując przyrostowo, się wcześniej zorientować, żeby ciągle się doskonalić dzięki usprawnieniom i raczej być zadowolonym z tego, jak będzie to wyglądało w kolejnych krokach rozwoju tej dużej inicjatywy, a nie mieć marzenia o tym, że będzie idealnie dobrze.

Jacek: Drugie przemyślenie, pozwól na odstępstwa od tego, jak zespoły działają zazwyczaj. Część naszych porad może stać w sprzeczności z tym, jak funkcjonuje Twoja organizacja i chcemy zachęcić Cię do tego, żebyś nie trzymał/trzymała się zwyczajowych ustaleń czy jakiegoś takiego kanonu firmowego, który nakazuje, że zespoły mają funkcjonować w jakiś konkretny sposób. Sytuacja, o której opowiadamy, jest sytuacją taką, nazwijmy to zwykle nadzwyczajną i może się okazać, że to, co mamy w naszym firmowym playbooku, czy to, jak to robiliśmy od zawsze, czy to, jak to robimy teraz i nam się wydaje, że to jest najlepsze, może ćwiczeniowo będzie trzeba na chwilę te koncepcje odłożyć na bok i zastanowić się, co byłoby najlepsze w tym momencie. Nie ciągnąc za sobą tego, nazwijmy to, długu decyzji, które podjęliśmy w stosunku do tego, jak powinien wyglądać nasz proces pracy.

Kuba: Trzecia przestroga, to pogódź się z faktem, że współpraca wielu zespołów będzie mniej efektywna. Jakby się nie starać, ile praktyk, które sami rekomendujemy, by nie wprowadzać, mamy poczucie, że jednak jeśli robimy coś wielkiego, jeśli to w tym przedsięwzięciu zaangażowane będzie kilkanaście albo wręcz kilkadziesiąt czy kilkaset osób, to siłą rzeczy ta efektywność będzie znacznie słabsza per osoba zaangażowana, niż to, do czego może byśmy byli w stanie się przyzwyczaić w sytuacjach, gdy zespoły są takie maks dziesięcioosobowe. No i tutaj nie mamy dobrej odpowiedzi, to jest taka pewna przestroga. Ta praca będzie po prostu trochę bardziej żmudna, te spotkania trochę większe będą wymagały też trochę więcej zachodu, trochę więcej przypilnowania. Być może pojawią się również siłą rzeczy pewne dodatkowe cykle synchronizacyjne, pewne mechanizmy, które normalnie można by żyć bez nich, można by się obyć bez nich. No ale niestety takie duże przedsięwzięcia mogą być po prostu niemożliwe do realizacji bez tego. I tutaj nie mamy sekretów, nie mamy żadnych jakichś magicznych rozwiązań, to po prostu jest pewnego rodzaju koszt, z którego trzeba sobie zdać sprawę, wziąć na niego poprawkę. Może też trzeba tak zrewidować czy urealnić swoje oczekiwania. Po prostu takie bardzo duże przedsięwzięcia wcale nie będą na przykład przyspieszały projektów, albo ta wartość dodana z takich dużych inicjatyw wcale nie będzie aż tak wielka, jak może można by wnioskować na poziomie Excela albo Power Pointu.

Jacek: Przedostatnia porada, bazuj na dobrze działających zespołach i procesach. Bałagan na poziomie pojedynczych zespołów, wszelkiego rodzaju nieefektywności, czy to procesów wytwórczych, czy tego, jak ludzie ze sobą się komunikują, wszelkiego rodzaju potykacze technologiczne. Wszystko to tylko się uwypukli i spotęguje, kiedy będziemy musieli zacząć działać wielozespołowo. Więc ta rekomendacja czy przestroga to jest takie wskazanie mówiące o tym, że warto zadbać o to, żeby na poziomie pojedynczych zespołów proces, współpraca, działania wyglądały jak najlepiej. No bo tak jak Kuba mówił w poprzednim punkcie, jeżeli zaczniemy działać wielozespołowo, jeżeli zaczniemy mówić o wielu osobach zaangażowanych w jakieś duże inicjatywy, no to niestety zacznie się to nam sumować i suma tych problemów uwidoczni się jeszcze boleśniej na poziomie jednego dużego zespołu.

Kuba: A co zrobić, jeśli jednak czujesz, że te działające zespoły i procesy są nieoptymalne i będzie to potęgowanie, przed którym przestrzega Jacek, to może zrewiduj, czy na pewno musisz w organizacji zrealizować tak dużą inicjatywę. Może trzeba ją skroić, może trzeba ją podzielić na mniejsze cząstki, które można dać jednak niezależnie zespołom i po prostu nie porywać się z motyką na słońce, jeśli jest na razie z tym za ciężko lub alternatywnie można wziąć poprawkę na to, że w takim razie będzie jeszcze trudniej, bo tu się pewne rzeczy będą rozjeżdżały, pewne rzeczy będą się psuły w trakcie, gdy pracujemy. No i na przykład nadnaturalne wsparcie jest potrzebne albo doinwestowanie w jakichś obszarów, czy to uwagą, czy to czasem, czy dosłownie budżetem, żeby pewne rzeczy wyprostować tak szybko jak to możliwe, żeby inicjatywa wycierpiała.

Kuba: I ostatnia porada, to zapewnij wsparcie merytoryczne dla organizacji i zespołów. Praca taka wielozespołowa jest po prostu bardzo trudna, o czym chyba mówimy przez cały ten odcinek. Jeśli do tej pory takich doświadczeń w firmie nie masz, nie zawahaj się skorzystać ze wsparcia kogoś, kto już to robi. To nie jest nic nowego. Dzisiaj już istnieją osoby czy profesjonaliści, którzy mają doświadczenia z tego typu sprawami. Być może trzeba zapewnić takie wsparcie. Co to może być? W praktyce to mogą być albo Scrum Masterzy, którzy mają takie doświadczenia, albo Agile Coach’e, którzy mają takie doświadczenia. Może odpowiedni Product Owner, który już był w takiej sytuacji, czy Product Manager? Może również doświadczeni kierownicy projektu, którzy umieją tutaj zwinnie to wyprowadzić? Nie zamykajmy się na żaden ze scenariuszy, ale skorzystajmy po prostu z doświadczeń, które być może są, tylko są na razie poza naszą organizacją. To może być też dobry pretekst do współpracy z takimi doradcami jak my. My też wspieramy takie przedsięwzięcia i to jest czasami dobry punkt startu czy nawet w ogóle cała orbita, wokół której możemy takie wsparcie organizacji zapewnić. My się wtedy skupiamy na transferze naszych doświadczeń. Przy okazji też organizacja podnosi sobie szansę na sukces tego konkretnego, ważnego przedsięwzięcia, które sprowokowało całą koncepcję pracy wielozespołowej.

Jacek: Podsumowując drugi rozdział dzisiejszego odcinka. Jakie przestrogi mamy dla liderów, którzy potrzebują zrealizować zwinną inicjatywę wieloma zespołami? Zaakceptuj, że nie będzie idealnie na początku. Pozwól na odstępstwa od tego, jak zespoły działają zazwyczaj.

Kuba: Obudź się z faktem, że współpraca wielu zespołów będzie mniej efektywna. Bazuj na dobrze działających zespołach i procesach. Zapewnij wsparcie merytoryczne dla organizacji zespołów.

Jacek: Natomiast jeżeli mierzysz się z tematem współpracy na poziomie wielu zespołów i chcesz uniknąć typowych problemów związanych ze skalowaniem, odezwij się do nas. Wsparcie mentorskie podniesie szansę na sukces ważnych inicjatyw w Twojej firmie. Opisz nam swoją sytuację, używając formularza na stronie porzadnyagile.pl/kontakt.

Kuba: Dobrze rozumiejąc Twoją sytuację, zaproponujemy kilka opcji możliwej współpracy dopasowanej do twojego budżetu. Mogą to być pojedyncze konsultacje, to może być też pomoc w występowaniu prac, aż po możliwy wariant maksymalny wsparcie mentorskie podczas całych prac wytwórczych czy projektowych.

Jacek: Notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/129

Kuba: To by było wszystko na dzisiaj. Dzięki Jacek.

The post Inicjatywy wielozespołowe first appeared on Porządny Agile.