Artwork

محتوای ارائه شده توسط Porządny Agile. تمام محتوای پادکست شامل قسمت‌ها، گرافیک‌ها و توضیحات پادکست مستقیماً توسط Porządny Agile یا شریک پلتفرم پادکست آن‌ها آپلود و ارائه می‌شوند. اگر فکر می‌کنید شخصی بدون اجازه شما از اثر دارای حق نسخه‌برداری شما استفاده می‌کند، می‌توانید روندی که در اینجا شرح داده شده است را دنبال کنید.https://fa.player.fm/legal
Player FM - برنامه پادکست
با برنامه Player FM !

Inicjatywy wielozespołowe

38:15
 
اشتراک گذاری
 

Manage episode 453571326 series 2440361
محتوای ارائه شده توسط Porządny Agile. تمام محتوای پادکست شامل قسمت‌ها، گرافیک‌ها و توضیحات پادکست مستقیماً توسط Porządny Agile یا شریک پلتفرم پادکست آن‌ها آپلود و ارائه می‌شوند. اگر فکر می‌کنید شخصی بدون اجازه شما از اثر دارای حق نسخه‌برداری شما استفاده می‌کند، می‌توانید روندی که در اینجا شرح داده شده است را دنبال کنید.https://fa.player.fm/legal

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.

Zapraszamy Cię do obejrzenia nagrania podcastu

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.

  continue reading

148 قسمت

Artwork

Inicjatywy wielozespołowe

Porządny Agile

77 subscribers

published

iconاشتراک گذاری
 
Manage episode 453571326 series 2440361
محتوای ارائه شده توسط Porządny Agile. تمام محتوای پادکست شامل قسمت‌ها، گرافیک‌ها و توضیحات پادکست مستقیماً توسط Porządny Agile یا شریک پلتفرم پادکست آن‌ها آپلود و ارائه می‌شوند. اگر فکر می‌کنید شخصی بدون اجازه شما از اثر دارای حق نسخه‌برداری شما استفاده می‌کند، می‌توانید روندی که در اینجا شرح داده شده است را دنبال کنید.https://fa.player.fm/legal

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.

Zapraszamy Cię do obejrzenia nagrania podcastu

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.

  continue reading

148 قسمت

همه قسمت ها

×
 
Loading …

به Player FM خوش آمدید!

Player FM در سراسر وب را برای یافتن پادکست های با کیفیت اسکن می کند تا همین الان لذت ببرید. این بهترین برنامه ی پادکست است که در اندروید، آیفون و وب کار می کند. ثبت نام کنید تا اشتراک های شما در بین دستگاه های مختلف همگام سازی شود.

 

راهنمای مرجع سریع