Zależności zewnętrzne w zespole

Zależności zewnętrzne potrafią zakłócić pracę niejednego zespołu. Tłumaczymy, czym są i wskazujemy 9 sposobów jak sobie z nimi radzić.

Jak obsługiwać zależności zewnętrzne i jak sobie z nimi radzić, żeby zwiększyć szanse na realizowanie zaplanowanych elementów? Skąd się one biorą i czy powinniśmy je usuwać? Temat ten wybrzmiał podczas jednej Retrospektywy w zespole, który odwiedzał Jacek. Pomyśleliśmy, że może to być ciekawy temat do podzielenia się z Tobą naszą perspektywą i praktycznymi wskazówkami.  

Zaczniemy od zdefiniowania zależności zewnętrznych i podamy kilka przykładów, potem powiemy sobie, dlaczego powinniśmy usuwać zależności. Na koniec omówimy 9 sposobów na radzenie sobie z zależnościami, jeśli nie możemy ich usuwać.

Czym są zależności zewnętrzne?

Zależności zewnętrzne to wszystkie działania, które Zespół powinien wykonać, aby zakończyć zaplanowaną pracę na Sprint, ale nie jest w stanie. Dzieje się tak, ponieważ nie ma odpowiednich kompetencji w zespole, by to zrobić. Mogą to być zarówno kompetencje wewnątrz firmowe, jak i takie, które leżą poza naszą organizacją. 

Niestety często spotykamy się z mało optymalnym zarządzaniem takimi zależnościami. Członek zespołu zgłasza się do kogoś poprzez email lub system ticketowy i biernie czeka, aż ta druga strona odpowie. To często zawodzi, wydłuża pracę i powoduje tylko problemy.

Przykładem zależności zewnętrznej może być współpraca dwóch zespołów. Jeden realizuje rozwiązanie techniczne widoczne na frontendzie, a drugi dostarcza mu API, albo dane, na których ten pierwszy będzie budował. Praca obu zespołów jest od siebie uzależniona. 

Innym przykładem zależności, popularnej w dużych strukturach organizacyjnych lub produktach, jest bazowanie przez wiele zespołów na platformach czy usługach. Są to efekty zcentralizowanej pracy zespołów dostarczających rozwiązania infrastrukturalne lub platformowe. Pojedyncze zmiany nie są w możliwościach decyzyjnych czy wykonawczych danego zespołu i musi on czekać na realizację zlecenia. 

Zależności często są związane z jakimiś zespołami biznesowymi np. z zespołem prawników czy zespołem marketingu. Przykładem może być sytuacja, w której, aby stworzyć produkt jako całość, musimy polegać na decyzjach, pozwoleniach czy półproduktach prawników. Zespół musi integrować rozwiązanie dostarczone z innych działów z tym, co sam tworzy. 

Zależności zewnętrzne są powodem wielu komplikacji, więc co do zasady jesteśmy za tym, żeby takie zależności w miarę możliwości usuwać. Tymi komplikacjami są:

• czas, czyli wydłużenie czasochłonności realizacji całego zlecenia czy funkcji;
• potencjalne niezrozumienie wymagań;
• opóźnienia, jeśli zobowiązania albo standardy procesu nie są dotrzymane;
• nieporozumienia, wynikające z rozproszenia odpowiedzialności;
• brak odpowiednich informacji, jeśli praca jest podzielona na wielu wykonawców;
• konieczność dopasowywania się do różnych metodyk pracy, jeśli zespoły zależne pracują różnie od siebie. 

9 sposobów na radzenie sobie z zależnościami zewnętrznymi w zespole

1. Poczekaj na dostarczenie zależności

Nie zakładaj optymistycznie, że otrzymasz wszystko, czego potrzebujesz na czas od zespołu, firmy czy osoby z zewnątrz. Zamiast tego ustalcie w Zespole, że nie rozpoczniecie swoich prac, dopóki nie otrzymacie wszystkich potrzebnych elementów czy informacji.

Zahaczamy tu trochę o koncepcję Definition of Ready, gdzie przykładowo póki nie dostaniemy interfejsów zewnętrznych, to nie nadbudowujemy na nich swojego działania. Podobnie jest zresztą w leanowym wytwarzaniu produktów, np. w fabrykach samochodów, gdzie prace rozpoczynają się, gdy są wszystkie jego elementy składowe, aby nie zatrzymać pracy fabryki.

Takie podejście zmniejsza ryzyko, że praca stanie w miejscu, bo będziemy musieli czekać lub będziemy zmuszeni do przełączania się między różnymi kontekstami, co nie wpływa dobrze na produktywność i ogólnie na pracę. 

2. Rozszerz tymczasowo zespół o osobę z zewnątrz

Innymi słowy, uzupełniamy zespół o potrzebne kompetencje, których u nas brakuje. Kluczowe jest tu zadbanie o to, aby taka osoba z zewnątrz poczuła się naprawdę częścią zespołu. Dlatego dobrze, aby uczestniczyła w wydarzeniach Scrumowych i była na bieżąco z postępami prac. 

Przy tym podejściu możemy dodatkowo zyskać nową wiedzę, którą wykorzystamy w przyszłości i nie będziemy musieli już szukać pomocy na zewnątrz.

3. Zwiększaj kompetencje w zespole

Dzięki temu będziemy mogli wyeliminować albo zmniejszyć zależności zewnętrzne. Jest to raczej działanie długofalowe, jednak na koniec może przynieść dużo korzyści.
Jednocześnie przesuwamy też granice odpowiedzialności naszego zespołu, np. jeśli do tej pory byliśmy tylko czystym zespołem wytwórczym, to za jakiś możemy czuć się na siłach, żeby również samodzielnie wdrażać rozwiązania.

4. Wydziel część, na którą masz wpływ

Pracę, którą mamy do wykonania, dzielimy na część wewnętrzną, czyli na taką, na którą mamy wpływ, oraz na część zewnętrzną, czyli niezależną od nas. 

Może to brzmieć trochę jak anty-wzorzec, jednak są sytuacje, w których to podejście może mieć sens, np. w zespołach, które mierzą się z problemem bardzo dużej liczby spadów na koniec Sprintu, często budzących w zespole poczucie, że nic nie realizują. Stąd, jeśli wyraźnie postawimy sobie granicę, że na pewne rzeczy po prostu nie mamy wpływu, to może to podnieść motywację w zespole, bo jednak swoją część zrealizowaliśmy. Dodatkowo pokazujemy też, w jakim stopniu zespoły są zależne zewnętrznie i gdzie mogą być spowalniane, przez co nie dostarczają celów. 

O dzieleniu pracy czy o dekomponowaniu dużych elementów na wiele mniejszych to stworzyliśmy osobny materiał wideo, w którym na przykładach pokazujemy, jak to przeprowadzić w zespole. Zatem jeśli widzisz potrzebę zgłębienia tego tematu, to zachęcamy do zapoznania się z tym webinarem dostępnym na stronie porzadnyagile.pl/dekompozycja.

5. Tymczasowo zasymuluj zależność zewnętrzną

Mamy tu na myśli różne rodzaje mockowania, stosowanie lorem ipsum jako substytutu treści marketingowej na front-endzie, korzystanie z tymczasowego designu rozwiązania od strony graficznej, jeśli nie mamy jeszcze jej finalnej wersji. 

Sami dostarczamy sobie potrzebne składowe pracy i oczywiście może się tak zdarzyć, że będziemy musieli potem trochę więcej poprawiać, niż zakładaliśmy, jednak nie blokujemy sobie pracy i możemy działać.

W efekcie np. na Przeglądach Sprintu możemy pokazać Interesariuszom, co udało się nam już przygotować i otrzymać szybki feedback. 

6. Zaplanuj więcej czasu na sytuacje nieprzewidziane

Na zależności zewnętrzne mamy zwykle mały wpływ, dlatego warto zaplanować na nie więcej czasu i być przygotowanym na pewne opóźnienia związane z problemami komunikacyjnymi lub nieprzewidzianymi sytuacjami, jak choroby.

Mamy tu ważne zastrzeżenie, dotyczące tego, że to nie ma być planowanie czasu na bierne czekanie. To nie jest czas, który możemy zmarnować, czekając na konkretną zależność zewnętrzną. Chodzi o to, że bierzemy sobie na nią dodatkową poprawkę i mamy świadomość, że są to zadania z pewnym stopniem ryzyka. 

7. Wyróżnij wizualnie tematy zależne

W naszej pracy z zespołami widzimy, że dążą one do tego, aby nie przeoczyć tych tematów będących zależnościami zewnętrznymi. Stąd też koncepcja pracy wizualnej w postaci oznaczania zadań zależnych flagami, kolorami czy zgodnie z zasadami ustalonymi w zespole. Dzięki temu zależności są wyraźnie wyróżnione i przykuwają uwagę podczas codziennej synchronizacji zespołu. Od razu widać, gdzie istnieje ryzyko związane z realizacją planu lub celu, jaki ma zespół przed sobą.

8. Przygotuj ścieżki eskalacyjne

Warto mieć ustalone zasady czy też procedury działania w sytuacji, gdy zespół czuje, że nie ma już wpływu na zależności i pojawia się pytanie, czy powinniśmy kogoś powiadomić, czy może to przekroczenie jakiejś nieprzekraczalnej granicy. Mając przygotowane ścieżki eskalacyjne, pokazujące do kogo powinniśmy się odezwać, w jakiej kolejności i w jakich odstępach czasowych daje pewien komfort pracy i oszczędza czas na dyskusje, co teraz zrobić. Działamy zgodnie z ustalonym scenariuszem, bez emocji i rozterek. Wiemy, co zrobić, jeśli czegoś nie otrzymamy i nie musimy się martwić na zaś, co będzie, jeśli coś się zablokuje.

9. Twardo zarządzaj dostarczaniem zależności

Miejmy w pamięci, że nie wszyscy pracują w sposób zwinny. Stąd też może się okazać, że najskuteczniejszym sposobem będzie klasyczne zaplanowanie sobie pewnych spraw, stworzenie harmonogramu, potwierdzenie zakresu działania, ustalenie konkretnego planu na dostarczenie pewnych konkretnych efektów i przypisanie odpowiedzialności. Jest to po prostu klasyczne zarządzanie projektami, które pomoże nam wszystko ułatwić i rozwiązać różne problemy z zależnościami. Nawet jeśli źle Ci się to kojarzy i przypomina podejście Waterfall, to jednak ma swoje uzasadnienie w tym przypadku. Zwłaszcza że często we współpracy z firmą zewnętrzną pewne rzeczy trzeba mieć po prostu jasno dookreślone.

Powyższe sposoby nie wyczerpują tematu. Co więcej, niektóre z nich są sprzeczne w stosunku do siebie. Pamiętaj też, że raczej nie dają się zaimplementować wszystkie jednocześnie. Wybierz te, które mogą się sprawdzić w Twoim zespole czy środowisku pracy.

TRANSKRYPCJA „Zależności zewnętrzne w zespole”

Jacek: Podczas ostatniej mojej wizyty w zespole usłyszałem na ich Retrospektywnie rozmowę o tym, jak obsługiwać zależności zewnętrzne, jak sobie z nimi radzić, żeby zwiększyć szanse na to, że elementy, które są prognozowane na nadchodzącą iterację czy nadchodzący Sprint były faktycznie realizowane. Uznaliśmy z Kubą, że jest to ciekawy odcinek do nagrania. I właśnie na zależnościach zewnętrznych i sposobach radzenia sobie z nimi opowiemy w dzisiejszym odcinku.

Kuba: Spis treści tego odcinka będzie prościutki. Najpierw zdefiniujemy co mamy na myśli i podamy parę przykładów takich zależności zewnętrznych. Potem najważniejsze zastrzeżenie o tym, żeby zależności przede wszystkim usuwać. No ale sam tytuł odcinka to zależności zewnętrzne w zespole jednak zakładamy, że one jednak są. Więc zasadnicza treść odcinka to będzie 9 sposobów na radzenie sobie z zależnościami, jeśli jednak one są i ich nie usuwamy. No i takie mikro zastrzeżenie na początek. Jeśli wydaje Ci się, że mój głos jest dzisiaj bardziej radiowy niż zwykle, no to wczoraj Lech awansował do 1/8 Pucharu Ligi Konferencji Europy. Wydzierałem się strasznie na tym meczu, więc jestem troszkę zdarty. Ale przejdźmy do rzeczy. 

Jacek: Co mamy na myśli mówiąc o zależnościach zewnętrznych? Mogą to być zarówno zależności wewnątrz firmowe, czyli wszystkie te rzeczy, które powinniśmy wykonać, żeby zakończyć pracę planowaną na Sprint. No, ale jednak nie mamy tych kompetencji w zespole. Jak również mogą to być zależności zewnątrz firmowe, czyli rzeczy, które zupełnie leżą poza naszą organizacją. I bardzo często spotykamy z Kubą takie bardzo domyślne podejście, jeśli chodzi o zarządzanie zależnościami. Może po prostu piszemy do kogoś, odzywamy się do kogoś, czy to mailem, czy to jakimś tam systemem ticketowym, no i czekamy tak naprawdę na to, aż ta druga strona nam odpowie. Co bardzo często nie działa, albo co gorsze w losowych momentach, kiedy się tego nie spodziewamy, niestety zawodzi. 

Kuba: No i zamieniając to, co Jacek przed chwilą powiedział na większe konkrety czy takie faktyczne praktyczne przykłady. Jednym z przykładów zależności zewnętrznej może być to, że są dwa zespoły, na przykład jeden realizujący jakieś rozwiązanie techniczne bardziej widoczne na front endzie. Drugi z zespołów dostarcza temu pierwszemu zespołowi jakieś API, albo jakieś dane, na których ten pierwszy będzie coś budował. I tak naprawdę praca tych zespołów jest od siebie uzależniona. Popularnym innym przykładem zależności jest to, że w dużych strukturach organizacyjnych czy takich dużych produktach technicznych wiele zespołów będzie bazować np. na zespołach dostarczających jakieś rozwiązania infrastrukturalne, albo jakieś rozwiązania platformowe i pewne rzeczy, jednak nie są w możliwościach decyzyjnych czy wykonawczych danego zespołu. Przechodząc dalej, często zależności będą związane np. z jakimiś zespołami biznesowymi, może np. zależność od zespołu prawników albo zależność od zespołu marketingu. Gdzie żeby stworzyć produkt jako całość musimy albo polegać na jakichś decyzjach, albo jakiś pół produktach, które integrujemy w to, co w naszym zespole realizujemy. I ten przykład zupełnie zewnętrzny, że np. nasza organizacja ma podpisany kontrakt z jakimś dostawcą jakiegoś rozwiązania, czy to jednego z systemów, który tworzy jakąś całość, czy może mamy jakieś grupy czy zespoły, które nas wspierają w jakimś stopniu. No i w większym przedsięwzięciu po prostu to, co robimy musi się połączyć z tym, co robi dostawca i dopiero jako całość połączona będzie stanowiła jakąś wartość biznesową. 

Kuba: No i przechodząc do drugiego punktu treści, takie najważniejsze zastrzeżenie, takie bardzo, bardzo potrzebne na wczesnym etapie tego odcinka, to to, że co do zasady jesteśmy za tym, żeby takie zależności przede wszystkim w miarę możliwości usuwać. Czyli szukać tych okazji do tego, żeby te zależności nas nie spowolniały, ale żeby te zależności nam nie wprowadzały ryzyk. No i można to robić na różne sposoby. Ale to jak to usuwać akurat nie będzie częścią tego odcinka. 

Jacek: Zanim wskoczymy w zasadniczą treść, krótkie przypomnienie, że cały czas dostępne są nasze płatne webinary o agile – wszystkie znajdziesz na stronie porzadnyagile.pl/sklep. 

Jacek: No dobrze, to jakie Mamy 9 sposobów, żeby sobie radzić z zależnościami zewnętrznymi? Zakładając, że to jest ten wariant, kiedy one nie są usunięte i musimy jakoś nimi zarządzić. 

Kuba: Taki pierwszy sposób, może on nie brzmieć jak radzenie sobie, to poczekaj na dostarczenie zależności. Coś, co jest szczególnie kłopotliwe w niektórych zespołach to takie optymistyczne założenie. Tak jak Jacek wymieniłeś chwilę temu, że wysłaliśmy ticketa, czekamy. Na pewno wszystko dostaniemy albo mailem uzgodnimy, czy na jakimś spotkaniu się dogadamy. Obiecują, że zrobią, na pewno zrobią. No i teraz wielokrotnie robią. Ale może być też tak, że pierwszym ze sposobów na poradzenie sobie z zależnościami, no to jednak jest przyjęcie takiego założenia troszkę pesymistycznego, że póki nie dostaniemy wszystkiego tego, czego potrzebujemy od zespołu, osoby, firmy, która wprowadza nam zależność zewnętrzną, to nie rozpoczynamy swoich prac. I to jest takie trochę zahaczenia o koncepcję Definition of Ready, że na przykład, póki nie dostaniemy interfejsów zewnętrznych, to nie nadbudowujemy na nich swojego działania. Cała taka filozoficzna koncepcja, żeby jednak nie rozpoczynać pracy, która może nam utknąć. To trochę jest takie leanowe czy takie ze szczupłego wytwarzania znanego z procesów wytwórczych, np. w fabrykach. Jednak musimy mieć wszystkie elementy składowe najpierw, żeby dopiero potem to auto składać, a nie, że ze zdziwieniem odkryjemy, że jednak drzwi nie dotarły na czas i cała fabryka stoi. Albo przełączamy się i niepotrzebnie tracimy czas na przełączanie kontekstu, zamiast po prostu faktycznie jak już coś podejmiemy, to to zrobić, dostarczyć i zabrać się za następny element. 

Jacek: Kolejny sposób radzenia sobie z zależnościami zewnętrznymi to rozszerzenie tymczasowo zespołu o osobę z zewnątrz. Podejście to polega na tym, żeby włączyć do naszego zespołu kompetencje osoby bądź osobę, która tymczasowo jest nam w stanie pomóc. Czyli w przeciwieństwie do tego podejścia, o którym Kuba powiedział przed chwilą nie czekamy, żeby rozpocząć pracę, tylko włączamy konkretną osobę, która może wnieść jakieś brakujące kompetencje do naszego zespołu. I myślę, że kluczowe jest tutaj to, żeby ta osoba maksymalnie poczuła się częścią zespołu, czyli faktycznie uczestniczy w ważnych wydarzeniach, czy to w jakiś tam formach codziennych stand-up’ów, czy to w planowaniu, czy w jakichś formach Refinementu, po to, żeby to faktycznie była współpraca, a nie tylko taki wariant, że jest wyznaczona osoba X, która na przykład dostarczy jakąś wiedzę związaną, powiedzmy, z frameworkiem front-end’owym, tylko faktycznie ta osoba jest z nami. Takim fajnym efektem ubocznym tego podejścia jest to, że być może jeżeli włożymy w to trochę wysiłku, no to będzie szansa zaczerpnąć tej wiedzy i być może za jakiś czas będziemy w stanie jakieś proste rzeczy na tym wspomnianym już front-endzie robić samodzielnie. 

Kuba: I trzeci sposób nawiązuje do tego ostatniego Jacka zdania. Ten sposób jest trochę sprzeczny z zasadniczą myślą tego, co Jacek powiedział, bo tutaj tego chyba nie wymieniliśmy. Ale te sposoby, które tutaj proponujemy, one niekoniecznie się dają zaimplementować wszystkie jednocześnie. Niektóre z nich będą sprzeczne albo atakowały problem zależności z trochę innej strony. Więc ten trzeci sposób to rozbuduj kompetencje w zespole. Czyli trochę nie tak, jak Jacek mówi pożycz kogoś z innego zespołu, nawiąż bliską współpracę, wyciągnij Sprint. Tylko jednak takie podejście, może już trochę zahaczające o to usunięcie zależności, czyli budujmy sobie kompetencje, dążmy do tego. Pewnie jest to działanie dosyć długofalowe, czyli dzień po dniu to może nam jeszcze problemu nie uratować, ale długofalowo, jeśli na przykład te kompetencje wspomniane przez Jacka front-end’owe zbudujemy sobie w zespole, to może się okazać, że nie jest to taki znowu kłopot, albo po prostu już ta zależność w ogóle zaczyna zanikać. Bo na przykład, chociaż częściowo jesteśmy w stanie sobie zrobić pewne działania sami lub jesteśmy w stanie poszukać sobie rozwiązania, któremu my sami podołamy i nie musimy bazować na tym, czy zespole, czy specjaliście spoza naszego zespołu. Co długofalowo może oznaczać, że przesuwamy też granice odpowiedzialności naszego zespołu. Czyli np. do tej pory byliśmy tylko czystym zespołem wytwórczym, ale np. ponieważ na tyle blisko współpracowaliśmy z dev-ops’ami czy osobami odpowiedzialnymi za risk management, że na przykład za jakiś czas czujemy się na siłach, żeby również np. samodzielnie wdrażać rozwiązania. Co może nie jest standardem w danej organizacji albo np. do tej pory jako zespół tego nie robiliśmy. 

Jacek: Kolejne podejście to podejście, w którym wydzielamy część, na którą mamy wpływ, czyli doprowadzamy do tego, że z jakiegoś większego fragmentu pracy, który chcemy zrealizować, wydzielamy tą część naszą, nazwijmy ją wewnętrzną i wydzielamy sobie część zewnętrzną. I w pewnym sensie to trochę brzmi jak taki anty wzorzec. Ale są sytuacje, w których to może mieć sens, czyli doprowadzamy do tego, że realizujemy tą część, która jest jakby dostępna po naszej stronie. Natomiast bardzo w wyraźny sposób sygnalizujemy, że są pewne elementy, które nie zależą od nas. I to może być szczególnie ważne, jeśli zespoły mierzą się z problemem np. bardzo dużej ilości spadów na koniec Sprintu. Czyli rodzi się w zespole takie już potem psychologiczne poczucie, że właściwie cały czas niczego nie realizujemy. No to w szczególności myślę, że w takich zespołach może podnieść morale, jeśli sobie wyraźnie postawimy granicę, że na pewne rzeczy nie mamy wpływu. I pomimo wielu wysiłków, które kierujemy w stronę rozwiązywania zależności zewnętrznych, nadal nie ma efektów. No to my jednak mamy coś, co nam się udało dostarczyć. Jeżeli temat dekomponowania dużych elementów na wiele mniejszych sprawia Ci kłopot albo jest to wyzwaniem w Twoim zespole, to zachęcam do zapoznania się z naszym materiałem o dekomponowaniu pracy na mniejsze kawałki, dostępnej w formule video on demand na stronie porzadnyagile.pl/dekompozycja.

Kuba: I wspomniałeś o tym, że to zespół może być tak psychologicznie lekko zdołowany, nierealizowaniem zadań, które są uzależnione zewnętrznie. Ja myślę, że jest jeszcze taka perspektywa może przejrzystości, takiej organizacyjnej doskonałości, że odróżnienie tych rzeczy, które zespół robi samodzielnie, od tych rzeczy, które są zależne od kogoś innego czy wewnątrz, na zewnątrz organizacji, może być też takim ważnym sygnałem do tego długofalowego jednak usuwania zależności. Czyli pokazanie, na ile zespoły są pouzależnione i na ile spowolnione przez te części, które gdzieś tam są poza mocą sprawczą zespołu. Do tego stopnia, że też jestem czasem świadkiem takiej rozmowy, zespół ma rozterkę np. na Sprint Review. Na ile jednoznacznie powiedzieć, że dany element czy nawet cały Cel Sprintu nie został dostarczony z tego powodu, że gdzieś tam zawiodło jakieś np. współdziałanie pomiędzy zespołami, albo dosłownie, że zawiódł np. dostawca zewnętrzny. I tutaj jednak jestem za tym, żeby bardzo przejrzyście to zaznaczyć.

Kuba: Przechodząc do następnego sposobu na radzenie sobie podobnego do tego, co Jacek wymieniłeś z wydzielaniem to taki sposób, który nazwaliśmy tymczasowo zasymuluj zależność zewnętrzną. Mamy tu na myśli zwłaszcza na poziomie technologicznym, wszystkie możliwe rodzaje mockowania, ale również np. zastosowanie lorem ipsum jako zastępnik tekstu, który jednak jest jeszcze np. nieprzygotowany przez prawnika czy przez np. zespół marketingu, w zależności od tego, czym jest dany produkt, czy np. zastosowanie tymczasowego designu rozwiązania od strony graficznej. Jeśli jeszcze nie mamy ostatecznej wersji od np. agencji interaktywnej albo grafika, czy po prostu założenie, że mamy jakąś wersję rozwiązania od tej strony zewnętrznej. Przyjęcie pewnych założeń może optymistycznych albo jakiś takich uzgodnionych i realizacja całego naszego zadania przy założeniu czy takim, takim właśnie w mówieniu sobie, że mamy już to, co potrzebujemy i na tej bazie możemy bazować. I wtedy w optymistycznym scenariuszu to się fajnie złoży w całość, gdy już wreszcie ta zależność zewnętrzna zostanie rozwiązana, czy ten produkt tego zewnętrznego zespołu, czy specjalisty zostanie dostarczony. Może się zdarzyć ten pesymistyczny scenariusz, ale jednak tu mówimy o tym, żeby może jednak nie czekać, jak w pierwszej poradzie, którą wymieniłem w odcinku, tylko po prostu przyjąć pewne założenia. Być może sobie lekko dołożyć roboty, żeby jednak nie czekać i nie blokować całego swojego rozwiązania.

Jacek: Takim dodatkowym efektem może być to, że jeżeli prowadzimy jakieś spotkania w stylu Przegląd Sprintu, gdzie pokazujemy co nam się udało zrealizować, to ten brakujący element to np. może być jakaś odpowiedź, powiedzmy sobie, systemu płatniczego. Jeżeli mamy zasymulowany ten zwrot, czyli zakładamy, że np. płatność zawsze przebiega poprawnie, to jesteśmy w stanie pokazać interesariuszom cały proces. W zasadzie proces kupowania jest dłuższy niż ta odpowiedź, więc jesteśmy w stanie uzyskać informację zwrotną jak ten proces wygląda tak generalnie i to, że ten zwrot z płatności na razie jest zawsze ok, czyli zawsze płatność przeszła pozytywnie. Tak naprawdę nie ma aż tak dużego znaczenia. Jeśli naszym celem jest zaprezentowanie tego, co udało nam się zrealizować. 

Jacek: Kolejnym pomysłem na radzenie sobie z zależnościami zewnętrznymi jest zaplanowanie więcej czasu na sytuacje nieprzewidziane. Czyli wszystkie te czynności, rzeczy, które są związane z zarządzaniem zależnościami zewnętrznymi. One najnormalniej w świecie potrzebują pewnej opieki, pewnego zarządzania. No i po prostu trzeba na to przewidzieć czas. Jeżeli planujesz z zespołem kolejne iteracje czy kolejny Sprint i w tym planie nie ma przewidzianego czasu na sytuacje nieprzewidziane, no to w pewnym sensie jest to proszenie się o kłopoty. Bo w sytuacji jakiegoś opóźnienia czy spowodowanego jakimiś opóźnieniami komunikacyjnymi, czy ta strona, która ma nam coś dostarczyć, po prostu z jakiegoś powodu się opóźnia, to tak naprawdę, jeżeli nie mamy przestrzeni jakiejś takiej zarezerwowanej na to, żeby obsłużyć te opóźnienia, no to tak naprawdę możemy mieć spory problem. Więc warto ten czas przewidzieć już na etapie planowania, czy to na poziomie planu, czy to na poziomie nawet konkretnych elementów, które gdzieś tam w procesie być może estymujemy. Warto wtedy uwzględnić to, podając nieco wyższą estymatę. 

Kuba: Ważne zastrzeżenie, że gdy mówimy, żeby zaplanować więcej czasu na takie sytuacje nieprzewidziane, to nie mamy na myśli tego, żeby właśnie np. agresywnie czekać na odpowiedź na ticketa. Czyli to nie jest tak, że zakładamy sobie jakiś dodatkowy czas, który możemy zmarnować na czekanie na tę zależność zewnętrzną, tylko raczej taką jakby bierzemy dodatkową poprawkę na to, że zadania z tymi zależnościami z doświadczenia danego zespołu zapewne będzie jasne, że to są po prostu zadania ryzykowne. Tam pewne rzeczy jeszcze mogą wyjść dodatkowe, możemy się słabiej dogadać. Na przykład może będzie słabsza jakość tego rozwiązania, które dostarczył nam jakiś partner, współpracownik czy zespół inny. To po prostu trzeba w tym planowaniu uwzględnić, czy to w samych wycenach, czy po prostu w jakimś planie pracy w ramach danego Sprintu, iteracji czy jakkolwiek te zadania sobie układamy. 

Kuba: Dobrze. To kolejny sposób na radzenie sobie z zależnościami. Też taki związany bardzo z planowaniem. To wyróżnij wizualnie tematy zależne. Tutaj trochę z innego poziomu abstrakcji niż te inne rady, które mamy, ale jednak widzimy, że zespoły w praktyce dążą do tego, żeby nie przeoczyć tych tematów zależnych. Dosłownie. Jakbym tam był w tych zespołach. Takie rozmowy się toczą, zwłaszcza np. na Retro. Albo gdy się odkrywa, że temat jest trudny, to jednak wielokrotnie wraca temat dosłownie na poziomie stwierdzeń typu – Przeoczyłem to zadanie. Albo – Faktycznie mieliśmy się przypomnieć, tylko jakoś tak przemknęło. I tutaj jest cała koncepcja pracy wizualnej, czy to poprzez jakieś umówione oczywiście w każdym zespole zasady, ale czy to jakieś flagowanie, czy jakiś kolor, czy może nawet dedykowany swimlane dla takich zadań na tablicy zespołu. Po to, żeby jednak te zadania były w jakiś sposób bardzo widoczny wyróżnione i żeby np. przykuwały uwagę czy to na codziennej synchronizacji, czy nawet po prostu w takiej codziennej pracy. Na zasadzie zaglądam w listę zadań, zaglądam w tablicę, co tam jest do zrobienia i widzę te zadania, one są w jakiś sposób bardzo wyraźnie wyróżnione czy widoczne. Co po prostu pozwala na to, żeby się wokół nich może trochę bardziej zogniskować, no bo znowu tutaj jednak jest ta koncepcja, że te zadania zależne prawdopodobnie są ryzykowne. To one wprowadzają ryzyko do realizacji całej pracy czy sukcesu danego kroku, nad którym zespół w tej chwili planuje. Więc tutaj szukajmy sposobów na to, żeby pomóc sobie w tych narzędziach czy do planowania, czy do dzielenia się zadaniami, czy do układania jakichś np. Backlogów, żeby te zadania zależne rzucały się na pierwszy rzut oka. 

Jacek: Przedostatnia porada, przygotuj ścieżki eskalacyjne. Bardzo często obserwuję zespoły w takiej sytuacji, gdzie trochę już nie czują, że mają wpływ. I zaczyna się dłuższa dyskusja w ogóle czy powinniśmy kogoś powiadomić? Trochę wydaje mi się, że to są takie właśnie rozterki czy to powiadomienie, czy to nie jest przekroczenie jakiejś, nazwijmy to czerwonej linii. Natomiast z mojej perspektywy, jasne przygotowanie sobie, jakie są te ścieżki eskalacyjne, czyli do kogo się odzywamy, w jakiej kolejności, kogo informujemy, w jakich odstępach czasowych, może dać zespołowi pewien taki komfort. Na zasadzie, no skoro umówiliśmy się, że po dwóch dniach coś otrzymujemy i tego nie ma, to postępujemy w jakiś tam konkretny sposób. Myślę, że może to wprowadzić sporo takiego, nazwijmy to spokoju do Sprintu, gdzie nie jest to jakiś taki nowy obszar, który trzeba zagospodarować, tylko mamy bardzo konkretny plan. Mamy gotowe ścieżki, które po prostu, jeśli zachodzą pewne warunki, uruchamiamy. 

Kuba: I to uruchomienie eskalacji wtedy jest po prostu realizowaniem z góry założonego scenariusza, gdzie nie ma żadnej emocji w tym wszystkim. Po prostu tak jakbyśmy zasady gwarancji realizowali. Na początku umówiliśmy się, że mogę złożyć reklamację, więc składam i postępuję zgodnie z tym, na co się umówiliśmy. Jest szansa, że gdy jesteśmy na wczesnym etapie, to takie spokojne dogadanie tej eskalacji będzie na zasadzie dobra, dobra i tak nic takiego złego nie nastąpi. No ale, jednak jeśli nastąpi, no to już możemy się trzymać wzajemnie danego sobie słowa kto do kogo, kiedy się odzywa i jaki hałas ma prawo, albo jaki hałas jest w dobrym guście do zrobienia, żeby pewne rzeczy uruchomić czy przepchnąć. 

Kuba: I ostatnia porada już nie będzie taka miła. Przypadła w moim udziale. Ostatnia porada to twardo zarządzaj dostarczaniem zależności. Jesteśmy w kontekście podcastu Porządny Agile. Jest miło, jest fajnie, jesteśmy samoorganizującymi się zespołami i tak dalej, i tak dalej. Ale, zwłaszcza gdy wchodzą w grę zależności też między firmowe albo między częściami organizacji, które niekoniecznie pracują w zwinny sposób. Czy to właśnie np. jakieś takie działy wsparciowe, czy jakieś osoby, czy specjaliści, którzy po prostu na co dzień nie pracują w Sprintach, nie pracują w tej już w tym klimacie zwinnej pracy. Może się okazać, że po prostu najskuteczniejszą formą będzie klasyczne zaplanowanie sobie pewnych spraw, zbudowanie harmonogramu, potwierdzenie zakresu działania, ustalenie konkretnego planu na dostarczenie pewnych konkretnych efektów. No i nie ukrywajmy, to, co właśnie wymieniłem, to jednak jest klasyczne zarządzanie projektami, które wewnątrz zespołu zwinnego może bardziej się kojarzyć, jakiś taki zły waterfall i ten mityczny wróg czy chochoł, przeciwko któremu zawsze się wszyscy źle nastawiamy. No ale bądźmy tutaj rzetelni. To są normalne metody zarządzania. One mają swój sens, mają swoje miejsce i może się okazać, że do konkretnej potrzeby, czyli poradzenie sobie z jakimiś trudnymi zależnościami, najskuteczniejsze co możemy zrobić, to uruchomić działania, które być może w zespole są w postaci kompetencji kierownika projektu, albo ktoś ma po prostu do tego trochę bardziej taki talent organizacyjny, że taki może bardziej asertywny, asertywne postawienie pewnych spraw. Więc tutaj nie bójmy się też tego, że być może na styku między naszym zespołem, a jakimś innym zespołem lub światem zewnętrznym, gdy mamy te zależności, to odrobinę planu takiego klasycznego. Jakiś gancik, jakiś zakres prac, jakaś umowa, co do tego, co będzie zrobiona jest potrzebna i to trzeba zaplanować, a później też bardzo surowo rozliczać. Czyli jednak też śledzić to, czy ten plan działania jest realizowany. Jeśli nie jest, to też jednak natychmiast realnie reagować, nie odpuścić tematu. Bo o ile wewnątrz zespołu można się fajnie dogadać, to może się okazać, że już np. w relacji z firmą zewnętrzną, to już to już na gębę pewne rzeczy nie dogadamy. 

Jacek: Podsumowując dzisiejszy odcinek. Jak zespół może radzić sobie z zależnościami zewnętrznymi. Poczekaj na dostarczenie zależności. Rozszerz tymczasowo zespół o osobę z zewnątrz. Rozbuduj kompetencje w zespole. Wydziel część, na którą masz wpływ. 

Kuba: Tymczasowo zasymuluj zależność zewnętrzną. Zaplanuj więcej czasu na sytuacje nieprzewidziane. Wyróżnij wizualnie tematy zależne. Przygotuj ścieżki eskalacyjne i twardo zarządzaj dostarczaniem w zależności. 

Jacek: Zapraszam 25 i 26 maja na warsztaty Labirynty Scruma, które będę prowadził w Warszawie. Są to warsztaty oparte na treści mojej książki o tym samym tytule. I jest to bardzo dobra okazja do wymiany wiedzy, w szczególności dla osób, które mają już doświadczenie w pracy w Scrumie i chciałyby pogłębić pewne tematy, niekoniecznie sięgając do teorii, a maksymalnie skupiając się na praktykach, pomysłach i inspiracjach, które mogą wykorzystać w swojej codziennej pracy. Zapisy znajdziesz na stronie labiryntyscruma.pl/warsztaty. 

Kuba: Notatki do tego odcinka. Artykuł, transkrypcję oraz zapis wideo naszej rozmowy znajdziesz na stronie porzadnyagile.pl/104. 

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

Kuba: Dzięki Jacek. 

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba. Dzięki Jacek i do usłyszenia wkrótce.