Co uwzględnić w planowaniu zespołowym?

Planowanie sprawia dużo problemów w pracy zespołów. Zjawisko to widzimy bardzo często wśród zespołów, z którymi pracujemy. Na podstawie książki Jacka “Labirynty Scruma” przygotowaliśmy listę niezbędnych elementów porządnego planowania pracy zespołu. Uwzględnij je w swojej pracy, by była ona uporządkowana i natłok zadań nie sprawiał problemu.

Pracując z zespołami zwinnymi częstym problemem, z jakim się spotykamy, są trudności z planowaniem. Postanowiliśmy przyjrzeć się bliżej temu tematowi, bo jest to bardzo istotny element pracy zwinnej, gdyż wpływa na kolejne jej etapy. 

Przede wszystkim, źle zaplanowana praca wpływa na mało efektywną współpracę, brak realizacji celów Sprintów oraz problemy z terminami. 

W tym arykule skupimy się omówieniu niezbędnych elementów porządnego planowania pracy.

Elementy te pochodzą z książki Jacka “Labirynty Scruma”, w której opisuje on konkretne rozwiązania na najczęstsze problemy pracy w Scrumie. My listę tę uzupełniliśmy o naszą aktualną wiedzę i nowe doświadczenia.

Niezbędne elementy porządnego planowania pracy zespołu

1. Dostępność członków Zespołu

Zwykle jest tak, że w większych zespołach i dłuższych (np. dwutygodniowych) iteracjach, prawdopodobnie ktoś z zespołu będzie częściowo lub całkowicie niedostępny. Przyczyn może być wiele, np. urlop, zaplanowane szkolenie, wizyta u klienta. Dlatego warto wziąć to pod uwagę podczas planowania i ustalić dostępność poszczególnych członków. To będzie mocno rzutować na liczbę zadań, jakie może wykonać zespół i ogólnie mówiąc na jego przepustowość. 

Znaczenie mogą mieć nawet 2 godziny nieobecności, bo jednego nie będzie 2 godziny, kogoś innego pół dnia, a jeszcze inna osoba będzie w 2-dniowej delegacji u klienta. W efekcie nie mamy pełnych 2 tygodni do wykorzystania.

W praktyce sprawdzenie dostępności możemy przeprowadzić w tabelce w Excelu czy w kalendarzu, aby klarownie zwizualizować wszystko.

2. Zależności zewnętrzne

Zależności zewnętrzne są to wszystkie tematy, które znajdują się poza obszarem zespołu i nie do końca ma on na nie wpływ.

Może to dotyczyć np. kompetencji, których nie mamy wewnątrz a potrzebujemy ich w konkretnej iteracji czy Sprincie. Mogą to być także dostawcy zewnętrzni różnego rodzaju systemów czy API.

Innymi słowy, są to wszystkie te rzeczy, które nie leżą w ramach naszych kompetencji i na które nie mamy bezpośredniego wpływu, jednak nasza praca od nich zależy. Dlatego musimy wziąć je pod uwagę podczas planowania i tak ułożyć sobie plan, żeby jak najsprawniej przebiegała praca i nie być zaskoczonym, że na coś musimy dłużej czekać. 

3. Kolejność wykonywania pracy

Rekomendujemy tu wspólną refleksję nad tym, w jakiej kolejności wykonamy działania, które mamy do zrobienia. Zanim zaczniemy zapełniać pracą zasoby czasowe poszczególnych osób, popatrzmy bardziej przez perspektywę, jak jako zespół chcemy wykonać kolejne elementy, które są do realizacji w ramach danej iteracji. 

Przykładowo Zespół Scrumowy mógłby zacząć od Celu Sprintu. Gdy Cel Sprintu będzie zrealizowany, można się zabrać za kolejne tematy, które są zaplanowane w tym Sprincie. Unikniemy wtedy sytuacji, że najważniejsza rzecz nie zostanie zrealizowana, bo przykryją ją mniej istotne na chwilę obecną tematy. To tak jak podczas pakowania torby na wyjazd, bez zaplanowania kolejności wkładania rzeczy, może się zdarzyć tak, że butelkę z wodą, którą powinniśmy mieć pod ręką, wrzucimy do torby jako pierwszą i będzie przykryta innymi, niepotrzebnymi w podczas podróży rzeczami. 

4. Zależności wewnętrzne

Mówiliśmy o zależnościach zewnętrznych zespołu. Podobny problem może się pojawić również w ramach zależności wewnętrznych. Częstą sytuacją, z jaką się spotykamy, jest zależność części back-end’owej od części front-end’owej. Pojawiają się tam pytania dotyczące tego, kto powinien rozpocząć pracę, od czego zacząć i jak. Jeśli zależy nam, aby rozwój produktu odbywał się równocześnie na wszystkich warstwach i każdy Sprint kończył się sensownym przyrostem, to należałoby się zastanowić głębiej nad tymi zależnościami i poukładać pracę, tak aby nie było przestojów. 

Innym przykładem takich zależności spoza świata IT to przykład, gdy grafik musi najpierw coś zaprojektować, aby osoba z marketingu mogła tego użyć w działaniach promocyjnych. 

Dlatego w toku planowania trzeba po prostu przemyśleć, jakie mamy zależności wewnętrzne i uwzględnić je w planie, aby uniknąć opóźnień w pracy zespołu. Te opóźnienia mogą pojawić się zwłaszcza wtedy, gdy zależności w zespole są bardzo silne i konkretne zadania muszą następować jedno po drugim, w tej właśnie kolejności. 

5. Dostępne kompetencje członków Zespołu

Z zależnościami wewnętrznymi z poprzedniego punktu powiązane są trochę kompetencje członków zespołu. Mogą to być kompetencje związane z konkretnym stanowiskiem, czyli ktoś jest programistą, ktoś testerem, ktoś analitykiem. Mogą to być jednak także kompetencje branżowe czy domenowe, gdzie ktoś zna konkretny fragment kodu lub proces biznesowy. Aby uniknąć przydzielania zadania osobie, która ma najmniejsze doświadczenie w danym obszarze, a w zespole są osoby, które sprawniej sobie poradzą z zadaniem, warto uwzględnić ten aspekt kompetencyjny w trakcie planowania. 

Pomoże to nam uchronić się przed sytuacją, w której podczas planowania tak dobraliśmy zadania, że aby je wszystkie dowieźć, to doba osoby z marketingu powinna mieć 20 godzin.

6. Wszelkie niejasności 

Możemy się spotkać z sytuacją, w której wchodzimy w iterację czy w Sprint i jesteśmy świadomi istnienia jakichś niejasności, ale nie blokują one pracy i bazując na doświadczeniu zespołu, wiemy, że wyjaśnienie tego zajmie około godziny rozmowy z konkretną osobą. 

Jeśli te niedoprecyzowane punkty nie niszczą planu zespołu i można je doprecyzować w trakcie pracy, to jest to sensowna strategia. Jednak warto być ich świadomym i mieć pewność, że nie są one krytyczne dla realizacji celu. 

Przestrzegamy was jednak przed zbytnim optymizmem. Niestety, ale tutaj trzeba bardziej surowo oceniać rzeczywistość, aby plan nie zaczął nam się rozpadać już na samym początku. Jeśli tak się wydarzy, to może to być sygnał, żeby zacząć przeplanowywanie. 

Stąd też bądźcie świadomi niejasności i ustalcie, kiedy będą one rozwiązane. 

7. Ryzyko

Oddzielamy ryzyko od niejasności, gdyż o niejasnościach wiemy, natomiast ryzyko obejmuje sytuacje, o których nie mamy świadomości, a mogą się one wydarzyć.

Oczywiście różne są stopnie prawdopodobieństwa wystąpienia konkretnych ryzyk w trakcie pracy, jednak należy je uwzględnić w trakcie planowania.

W każdym zespole może to być coś innego, jednak doświadczony zespół uwzględni to w planie i weźmie na to poprawkę. Przykładowo takim ryzykiem może być sytuacja, w której nie zadziała środowisko, ryzyko problemów z jakąś starą częścią produktu, czy ryzyko braku odpowiedzi ze strony kogoś, kto jest naszą zależnością zewnętrzną. 

Jeśli konsekwencje wystąpienia danego ryzyka są ważne dla celu biznesowego lub dla sukcesu wdrożenia, to warto sobie zadać kilka pytań, takich jak: jakie ryzyko może się wydarzyć? Co my z tym ryzykiem możemy zrobić? Co możemy zrobić, żeby się jednak nie wydarzyło? 

Aspekt związany z ryzykami jest mocno powiązany z tym, jak zespół dokonuje refleksji po konkretnych iteracjach. Jeżeli faktycznie taka refleksja zachodzi i analizujemy, jak nam poszło, co się udało, co się udało gorzej lub wcale, to łatwiej nam zdiagnozować powody niepowodzeń i wkalkulować potencjalne ryzyka w kolejnych iteracjach. 

Planowanie zespołowe – dodatkowe przemyślenia

Jeszcze na koniec domkniemy pewne myśli, które mogły nie wybrzmieć wcześniej.

Przede wszystkim lista ta została przedstawiona w taki sposób, aby wskazać te elementy, od których warto zacząć i które mogą nastąpić później. Jednak pamiętaj, że mogą się one łączyć, a dyskusje związane z tymi elementami mogą powracać, na co warto być gotowym. 

Pamiętaj też, że ta powyższa lista nie jest algorytmem postępowania. Są to bardziej obszary, na które warto zwrócić uwagę, z lekkim wskazaniem, od czego zacząć. 

Ponadto fakt, że planujemy, że wykonujemy ocenę ryzyka, że patrzymy na zależności, patrzymy na kompetencje, nie oznacza, że pracujemy kaskadowo. W procesach zwinnych te elementy są również istotne i każdy zespół znajdzie sobie swoje własne podejście do tego. Korzystanie ze sprawdzonych i dobrych praktyk nie jest niczym złym, a zwinność zacznie się wtedy, jeśli będziemy reagować na wszelkie zmiany w planie, będziemy blisko ze sobą współpracować i pomagać sobie. 

Oczywiście nie wszystkie wymienione elementy będą adekwatne w każdym zespole i to miej na uwadze, korzystając z tej listy. 

Jeśli widzisz, że w Twoim zespole potrzebna jest pomoc przy planowaniu, to zapraszamy do kontaktu. Dzięki współpracy z nami zespoły podnoszą swoje umiejętności planistyczne, poprawiają przewidywalność pracy i zwiększają efektywność. Napisz do nas, korzystając z formularza kontaktowego na stronie porzadnyagile.pl/kontakt.

Dodatkowe materiały

• Porządne Planowanie Sprintu
• Dlaczego zespoły nie planują zespołowo?
• Książka Jacka Wieczorka o pułapkach pracy w Scrumie: Labirynty Scruma

Transkrypcja podcastu „Co uwzględnić w planowaniu zespołowym?”

Kuba: Kiedy pracujemy z zespołami zwinnymi, pewien wzorzec obserwacji powtarza się w większości z nich. Zespoły mają problemy z planowaniem. To jest element pracy zwinnej, który wpływa później na kolejne efekty pracy. Źle zaplanowana praca wpływa na kiepską współpracę. Niedowożenie Sprintów, czy niewykończenie pracy w planowanych iteracjach, problemy z terminami. Więc jest szereg kolejnych konsekwencji wynikających z kiepskiego, niedoskonałego planowania. Coś, co nas uderza to to, że w temacie techniki metod pracy zwinnych, dużo się mówi o różnych składowych. Przychodzi mi do głowy na przykład Retrospektywa, o której się mówi dużo. Jest dużo technik, dużo historii, jak je robić dobrze. Natomiast element, który jest bardzo ważny, czyli planowanie pracy całego zespołu, jest dosyć mało popularne. 

Jacek: W tym odcinku wymienimy niezbędne elementy porządnego planowania pracy zespołu. Powiemy o dostępności członków zespołu, o zależnościach zewnętrznych, o kolejności wykonywania pracy, o zależnościach wewnętrznych, dostępnych kompetencjach członków zespołu, wszelkich niejasnościach oraz ryzyku.

 Kuba: O planowaniu mówiliśmy już wcześniej w dwóch odcinkach podcastu. Dawno temu w 13. odcinku mówiliśmy o tym, jak powinna wyglądać porządne Planowanie Sprintu. Taka perspektywa bardzo konkretnie scrumowa. A już niedawno, w 77. odcinku mówiliśmy o tym, dlaczego zespoły nie planują zespołowo. Wracamy do tematu planowania, ale w tym odcinku nie zdublujemy treści z tamtych materiałów. Więc jeśli jeszcze ich nie słuchałeś lub nie słuchałaś, to zapraszamy do ich odsłuchania, najlepiej po przesłuchaniu tego odcinka. 

Jacek: Lista, przez którą przejdziemy pochodzi z mojej książki Labirynty Scruma, w której opisuję konkretne rozwiązania na najczęstsze problemy Zespołów Scrumowych. Delikatnie tę listę sobie przedstawialiśmy z Kubą. Uzupełniliśmy ją o taką naszą aktualną wiedzę. I teraz krok po kroku przez tę listę przejdziemy. Od czego byś Kuba zaczął, kiedy myślisz o przygotowywaniu dobrego planu zespołowego?

Kuba: Pierwszym dla mnie absolutnie obowiązkowym punktem takiego planowania zespołowego jest dostępność członków zespołu. Mamy tu na myśli taki przypadek, że zazwyczaj w odpowiednio dużym zespole, przy odpowiednio długiej iteracji, na przykład dwutygodniowej, prawdopodobnie ktoś będzie z jakiegoś powodu trochę niedostępny lub kompletnie niedostępny. To mogą być urlopy, to mogą być planowane szkolenia. To może być też coś, co się wydarzy w firmie. Jakiś wyjazd, może jakaś wizyta u klienta. Szereg czynników, które powoduje, że dostępność nie jest taką jakąś ścisłą regułą. Coś, co można z góry założyć, że przez najbliższe dziewięć dni roboczych z rzędu jestem do dyspozycji całego zespołu. I tutaj to ma bardzo duże konkretne konsekwencje. To może być zmienne. Możemy nie wiedzieć o tych wszystkich aspektach. Może ktoś ma jakieś plany takie bardziej prywatne, o których nie mówił. Jakieś na przykład operacje, czy właśnie jakieś nietypowe urlopy w środku roku, a niekoniecznie w wakacje. Więc to jest coś, co warto sobie ustalić, warto sobie zaobserwować, bo może to konkretnie rzutować na to, jak zespół może wykonać działania. Jaką ma, tak ogólnie mówiąc przepustowość – jaką ilość czasu jesteśmy w stanie wykonać. Ale to też może rzutować na obecność konkretnych osób, aczkolwiek to pokrywa nam się w kolejnym punkcie. Więc pierwszy punkt, o którym myślę to ustalenie dostępności członków zespołu, zanim przejdziemy do jakichkolwiek takich praktycznych czynności planistycznych.

Jacek: I ten punkt może brzmieć tak bardzo oczywiście no, że przecież tak właśnie powinniśmy zrobić. Natomiast zdecydowaliśmy się o tym punkcie wspomnieć z tego powodu, że oboje z Kubą widzimy sytuacje zespołowe, kiedy zespół zabiera się za planowanie i właściwie kompletnie pomijają ten aspekt, kto będzie dostępny i w jakim wymiarze, jakie to będą dni. Czy to jest właśnie nieobecność na cały dzień, na pół dnia, na dwie godziny? Uważamy, że jednak powiedzenie sobie wprost tego powoduje, że ten plan się nieco urealnia. Bardzo często się spotykam z taką reakcją, gdy zachęcam zespół, żeby jednak tę dostępność sobie tak dosyć dobrze zewidencjonował. Z takim odkryciem –  No jednak nie mamy pełnych dwóch tygodni tak, jak myśleliśmy. Jednak się okazuje, że tu jeden dzień, tu jeden dzień, tu ktoś ma urlop, tu jakieś szkolenie, tu wyjazd. No i realnie widać, że po prostu tego czasu mamy mniej, niż początkowo mogliśmy uważać. Dlatego jest to pierwszy punkt, super istotny i od tego punktu uważam, że warto wyjść. 

Kuba: I to jest coś takiego, że tutaj zespoły, które wykonują faktyczne czynności planowania, prędzej czy później wpadną na to, że na przykład kogoś bardziej nie ma. Więc czasami w jakiejś kolejnej części sesji planowania wyjdzie, że kurczę, kurczę jednak musimy wrócić i ustalić, bo są jakieś wyraźniejsze niedostępności. No ale tutaj jak rzadko w tym odcinku jednak będziemy się upierać, że to jest ten pierwszy krok. Ustalmy sobie dostępności i dopiero na ich bazie wykonujemy resztę czynności. Bo to w zasadzie w ciemno wiemy od razu. Tutaj nie ma żadnej magii, wręcz bym powiedział wręcz taka będzie bardzo sucho – inwentaryzacja. I bardzo często to dokładnie taki kształt też w praktyce ma, jakaś tabelka, jakiś Excel, jakiś rysunek, na którym po prostu nosimy znaną nam wiedzę o dostępności. No i tutaj się trochę się będzie kłaniał temat ze starej dobrej szkoły project menedżerskiej, kalendarze na początku planowania się ustala, a nie dopiero w toku, gdy zaczyna nam się robić zamieszanie i przesunięcia, nad którymi niekoniecznie zapanujemy. 

Jacek: Kolejnym elementem, na który warto zwrócić uwagę na początku, jest sprawdzenie zależności zewnętrznej. Zależności zewnętrzne są to wszystkie tematy, które leżą poza zespołem. Na takiej zasadzie, że nie do końca mamy na to wpływ. To mogą być jakieś inne zespoły. To mogą być jakieś konkretne kompetencje, których my nie mamy w zespole, a w konkretnej iteracji, czy w konkretnym Sprincie takiej osoby potrzebujemy. To mogą być też dostawcy zewnętrzni różnego rodzaju systemów konkretnych, czy jakichś bramek, czy jakichś API. Wszystkie te rzeczy, które nie leżą w ramach naszych kompetencji, natomiast my zależymy od tych rzeczy i musimy tak sobie ten nasz plan ułożyć, żeby po prostu nie być zaskoczonym, że po naszej stronie wszystko jest zrobione, ale jeszcze brakuje nam jakiegoś tam kawałka od zespołu X, czy zespołu Y.

Kuba: Również ten przypadek wymieniamy dosyć wcześnie. Ten element planowania można w zasadzie traktować jako część tej takiej wczesnej inwentaryzacji w czasie planowania. Ponownie zazwyczaj na te zależności zewnętrzne nie mamy aż tak dużego wpływu. Po prostu tak jest, na to się umówiliśmy. Jakiś zespół, który nas wspiera. Jakiś specjalista, który nam coś obiecał. Czy może w ogóle zewnętrzny partner spoza naszej firmy coś nam dostarczy, albo oczekuje, że my coś dostarczymy. Więc to mogą być bardzo różne rodzaje zależności, ale zazwyczaj one po prostu są faktem. Są jakimś takim sztywnym ogranicznikiem, który na jakiś plan możemy sobie po prostu nanieść i powiedzieć – Do środy w drugim tygodniu musi się wydarzyć X, albo dopiero w środę wydarzy się Y. Przyjmujemy to do wiadomości i cała reszta naszego planowania będzie gdzieś tutaj uwzględniała te elementy, ale raczej z nimi nie dyskutowałem. Po prostu jest jak jest, i cała reszta planu przyjmuje do wiadomości ten fakt i wokół tego reszta planu jest ustawiana. 

Kuba: Trzecim punktem, który warto uwzględnić w planowaniu zespołowym, to kolejność wykonywania pracy. Mamy tutaj na myśli to, że rekomendowaną przez nas alternatywą do takiego zapełniania sobie pracy przez poszczególne osoby, jest jednak taka wspólna zespołowa refleksja nad tym, w jakiej kolejności wykonamy działania, które mamy do zrobienia. I tutaj nawet specjalnie położę akcent na słowo pracę, a nie zadania. Czyli na przykład konkretne ficzery, które byśmy chcieli razem jako zespół zrealizować, konkretne kroki, konkretne skończone kawałki produktu, które nawet może są gotowe do wdrożenia w środku iteracji. Czyli zanim wrzucimy się w wir zapełnienia sobie pracą poszczególnych osób, popatrzmy bardziej przez perspektywę, jak jako zespół chcemy wykonać kolejne elementy, które są do wzięcia w ramach danej iteracji. Tutaj zespoły mogą pracować w bardzo różnych trybach, bo niektóre zespoły biorą po prostu pierwszą najważniejszą rzecz, która jest do zrobienia. Patrzą, jak ją będą robić i dopiero potem dokładają drugą, dopiero potem trzecią. Inne zespoły bardziej myślą tą perspektywą, jest jakaś suma porcji pracy. Te pięć elementów, które czujemy, że mniej więcej zrobimy, zwłaszcza te drugie zespoły mogą wpaść w pułapkę takiego zapakowania, takiego dopchnięcia jak bagażnik w aucie na wyjazd urlopowy. Po prostu byle się zmieściło, a dopiero później się zastanawia, że butelkę z wodą włożyłem na sam dół i to kompletnie nie ma sensu. Przenosząc analogię na planowanie zespołowe, warto się zastanawiać, w jakiej kolejności będziemy mieli skończone kawałki naszych produktów. No i na przykład, jeśli jest to Zespół Scrumowy, to mógłby zacząć od Celu Sprintu. Miejmy Cel Sprintu z głowy i wtedy ewentualnie te dodatkowe rzeczy, które jeszcze może robimy, mogą być jakimś tam, nazwijmy to potocznie, dopchnięty. 

Jacek: Uśmiechałem się, jak mówiłeś o tym pakowaniu, bo ostatnio wyciągałem głęboko schowaną miskę do wody Jobsa, jak jechaliśmy na wycieczkę całą rodziną i z psem. Pewne rzeczy jednak trzeba trochę bardziej przemyśleć. Natomiast komentując to, co mówisz. Częste odkrycie, że kolejność jest niewłaściwa, następuje dopiero w toku planowania. Czyli zespół zaczyna sobie planować i odkrywa, że na przykład to, co jest najważniejsze do zrobienia w nadchodzących dwóch tygodniach, trochę nam wychodzi poza te dwa tygodnie i następuje takie wizualnie, to najczęściej się przedstawia w ten sposób, że cała ta praca cofa się. Na zasadzie, że przyciąga ją zespół do początku iteracji, czy do początku Sprintu. Wtedy się okazuje, że ok, to się mieści. Czyli często ta refleksja przychodzi, ale dopiero za późno. Trochę podobnie jak z tymi nieobecnościami. Jakby stąd wielokrotnie widząc takie zachowania zespołów, jestem na dzisiaj przekonany, że na to pytanie, od czego powinniśmy zacząć i dlaczego, trzeba sobie zadać na samym początku planowania. 

Jacek: Kolejnym aspektem, który warto rozważyć, są to zależności wewnętrzne. Mówiliśmy o zależnościach zewnętrznych zespołu. Podobny problem może się pojawić również wewnątrz. Takim bardzo popularnym klasykiem, który często widzę, pracując z zespołami, jest zależność części back-end’owej od części front-end’owej. I rozpoczynają się dyskusje. Kto musi rozpocząć pierwszy? Kto na kogo czeka? Od czego zacząć? W jaki sposób to zrobić? Mówię tutaj oczywiście o takiej sytuacji, w której dążymy jednak do tego, żeby ta praca na różnych warstwach działa się w sposób symultaniczny. Oczywiście prostym rozwiązaniem jest to, że w jednej iteracji robimy back-end, w drugiej robimy front, ale nie do końca o to chodzi. Jednak zależy nam na tym, żeby rozwój produktu dział się na wszystkich warstwach. W sensie, żeby po prostu każda iteracja, czy każdy Sprint kończył się jakimś sensownym przyrostem. Jeżeli chcemy pracować w ten sposób, do czego oczywiście gorąco zachęcam, no to te zależności musimy sobie troszeczkę głębiej rozpracować i zastanowić się, jak sobie poradzić z sytuacją, w której na przykład robimy front-end, ale nie jest jeszcze gotowy back-end. Oczywiście są na to sposoby, co jakby nie jest treścią tego odcinka. Niemniej, warto mieć to na uwadze, że też taka praca, w której efektem Sprintu jest coś namacalnego, wymaga zastanowienia się, na jakich warstwach się poruszamy i jakie zależności pomiędzy tymi warstwami występują.

Kuba: No i użyliśmy tutaj przykładu, czy Jacek wspominałeś taką bardzo programistycznym perspektywę. Część naszych Słuchaczy jest również spoza tego świata IT. Zazwyczaj w zespołach, zazwyczaj w jakichś działaniach tego typu zależności mogą następować. One mogą być bardziej z perspektywy kompetencyjnej. Czyli na przykład, najpierw grafik musi coś zaprojektować, żeby ktoś później mógł tego użyć, na przykład w jakichś materiałach marketingowych. A czasami jest też taka zależność bardzo naturalna. Najpierw musimy wymyślić koncept szkolenia, żeby później do tego konceptu dorobić jakieś konkretne ćwiczenia, czy konkretne szczegółowe materiały. Więc te zależności, one nawet nie zawsze są takie do pominięcia kompletnie, one są dosyć naturalne. No i w toku planowania trzeba po prostu przemyśleć, jakie te zależności są i je uwzględnić. One mogą mieć szczególnie niebezpieczny charakter, jeśli sobie tak troszkę zignorujemy pomyślenie, czy nie ma takich zależności bardzo sztywnych i coś musi się skończyć, żeby coś następnego musiało się zacząć. Jeśli tak jest autentycznie, to może powodować, że akurat ta sekwencja zadań, zadanie pierwsze, zadanie drugie, zadanie trzecie. Jeśli każde z nich jedno po drugim musi następować, to one mogą być dosyć istotne, żeby przewidzieć je, przemyśleć, żeby być może też, to by one też nie łapały żadnych opóźnień. Bo opóźnienie na tej właśnie sekwencji zadań, może też opóźnić całą pracę całego zespołu. I jeśli na coś patrzeć, to właśnie na to, żeby te zadania następowały po sobie w dobrej kolejności. 

Kuba: Piątym punktem, który chcielibyśmy uwzględnić w planowaniu zespołowym, to dostępne kompetencje członków zespołu. To jest trochę powiązane z tymi zależnościami wewnętrznymi wymienionymi wcześniej, ale myślimy też o czymś szerzej. Zazwyczaj w zespole jakiś miks kompetencji u każdej osoby następuje. Mogą być jakieś kompetencje takie generyczne na zasadzie, jestem programistą, jestem testerem, jestem analitykiem, znam się na tej konkretnej technologii. Jestem w tej konkretnej profesji specjalistą. Ale to też mogą być kompetencje takie branżowe, czy domenowe. Znam ten fragment kodu, znam się na tym konkretnym procesie biznesowym. No i może się okazać, że to jest czynnik, który warto w planowaniu uwzględniać. Niekoniecznie jesteśmy wielkimi fanami tego, żeby z automatu dawać zadania temu komuś, kto się najbardziej zna na tym zadaniu. To jest oddzielne pytanie, komu przydzielane dane zadanie. No ale, zwłaszcza jeśli podejmie się ktoś zadania, kto się na tym kompletnie nie zna, albo zlecając zadania, dla danej osoby o kompetencjach w jakimś unikalnym zespole jest cała masa. Może się okazać, że to planowanie będzie w którymś momencie do zatrzymania, bo nagle się okazuje, że specjalista od marketingu w zasadzie musiałby mieć dwudziestopięciogodzinną dobę, żeby się wyrobić z tym wszystkim, co musimy zrobić, bo akurat tak się poskładały zadania. Tak się poskładały jakieś cele, które mamy do osiągnięcia. Że wyjątkowo mocno tą daną konkretną osobę przeciążamy. Więc tutaj bądźmy czuli na to, jakie mamy dostępne kompetencje. Zamapujmy też to, na to co jest do zrobienia, no i z tego wyciągajmy wnioski. Ten plan niech będzie pochodną, czy niech uwzględnia ten aspekt kompetencji. 

Jacek: Kolejnym aspektem, przed ostatnim, który warto wziąć pod uwagę, są wszelkiego rodzaju niejasności. Możemy się spotkać z sytuacją, w której wchodzimy w iterację czy w  Sprint i nie do końca wszystkie detale mamy zapięte na ostatni guzik. Na takiej zasadzie, że decydujemy się na to, że jest jakaś tam niejasność jeszcze, na przykład na poziomie kryteriów akceptacji jakiejś tam pracy do wykonania. No, ale to jest nieblokujące i na bazie doświadczenia zespołu wiemy, na przykład, że doprecyzowanie tego to jest jakaś tam godzinna rozmowa z jakąś konkretną osobą. Stąd zespoły decydują się na to, żeby jednak nie blokować sobie pracy. Na zasadzie, że wszystkie te elementy jakiejś tam definicji gotowości są już na zielono, czyli są spełnione i jednak decydują się na to, żeby w trakcie pracy pewne rzeczy doprecyzowywać. I, dopóki to nie niszczy planu zespołu, nie powoduje, że pewne rzeczy, które planowaliśmy zrobić, nam nie wychodzą, to uważam to za sensowną strategię. Przy czym warto używać jej z głową, bo to jest jakby coś zupełnie innego, niż wchodzimy sobie w iteracje kompletnie nieprzygotowani i jakoś to będzie. Więc tylko tutaj zwróciłbym uwagę, że to nie jest taki hurra optymizm i chaos, raczej bardzo świadoma decyzja. Te rzeczy sobie dociągniemy w trakcie Sprintu i jakby nie ma problemu, że na dzisiaj ich nie wiemy. 

Kuba: No i konsekwencją tej świadomości, o której powiedziałeś, jest też to, że na przykład planuje sobie, że uzupełnimy jakąś wiedzę, albo przemyślę, zaprojektuję jakiś fragment, który dzisiaj jeszcze nie wiem, jak będzie wyglądał, ale w środku Sprintu będę o tym decydować. Jeśli w planie założę sobie, że na przykład za dwa dni będę mieć projekt, model, brakującą wiedzę i informacje jak działa dana biblioteka, a jednak upłynęły dwa dni, jest trzeci dzień, gdy na Daily nadal mówię o tym, że jeszcze projektuję. To może być już wyraźny sygnał, efekt tego takiego zespołowego planowania. Wiele osób może też gołym okiem zobaczyć, że kurczę to już mieliśmy mieć zaprojektowane, a nie mamy. Oczywiście nie chodzi o to, żeby się tutaj winić, żeby ciągać się po sądach za to, że ktoś nie wypełnił obietnicy. Ale dla panującego i później monitorującego swój plan zespół, to jest pewien sygnał. Przewidywaliśmy, że te niejasności wyjaśnimy, a jednak ich nie wyjaśniliśmy. Dlaczego o tym mówię? Bo w sumie w pewnym sensie klasykiem jednak jest postępowanie w ten sposób, że na początku Sprintu te niejasności zazwyczaj są wyjaśniane. Jak są wyjaśnione z opóźnieniem, to jeszcze jesteśmy optymistami, a później nam tego czasu brakuje pod koniec danej iteracji. I niestety, ale tutaj trzeba być chyba takim trochę pesymistą. Może tak bardziej surowo oceniać rzeczywistość. Jeśli w pierwszym, drugim dniu tego naszego planu, ten plan zaczyna nam się rozpadać, co jest niestety klasykiem, no to już być może jest sygnał, żeby zacząć przeplanowywanie. Przeplanowywanie nie jest częścią tego odcinka, ale to jest coś, co chciałem tutaj dopowiedzieć o tych niejasnościach. Zaplanujemy sobie świadomie i zdyscyplinowanie, kiedy te niejasności będziemy mieli rozwiązane. Jeśli ten plan nam wychodzi poza zaplanowane ramy, to już jest czas, żeby reagować. Jak reagować? To już jest poza zakresem odcinka, ale to jest coś, co może być bardzo przydatne też w środku iteracji.

Kuba: I podobno ostatnia rzecz, którą warto uwzględnić przy planowaniu zespołowym to ryzyko. Dla ścisłości tak bym zdefiniował, co mamy na myśli i dlaczego to nie są niejasności. Niejasności, to jest coś, co z góry wiem, że nie wiem. No i powiedzmy, umiem w miarę sobie powiedzieć, co dokładnie tam ma się wydarzyć. Ryzyko to będą rzeczy, które nawet nie wiem, że mogą się wydarzyć, albo to są rzeczy, które mogą się wydarzyć, ale nie uważam ich za tak prawdopodobne. Oczywiście to jest zawsze ocena, jak prawdopodobne pewne rzeczy są, no ale są takie ryzyka w wybranych zespołach, które jednak trzeba przy planowaniu uwzględnić. Na przykład ryzyko, że nie zadziała środowisko, ryzyko problemów z jakąś starą częścią produktu, może jakieś ryzyko braku odpowiedzi ze strony kogoś, kto jest naszą zależnością zewnętrzną. Jest kilka takich powiedzmy, najczęściej z doświadczenia wynika kilka takich aspektów. W każdym zespole to może być co innego, które jednak doświadczony zespół uwzględni i weźmie poprawkę na nie. Bo, jednak jeśli po pierwsze, to może się wydarzyć, a jak się wydarzy, to konsekwencje dla naszej pracy mogą być istotne. Więc ryzyko to jest właśnie prawdopodobieństwo wystąpienia plus konsekwencje. Jeśli ta konsekwencje są ważne dla celu biznesowego, dla sukcesu wdrożenia, to są wszystko pytania, które sobie warto zadawać. Jakie ryzyko może się wydarzyć? Co my z tym ryzykiem możemy zrobić? Co możemy zrobić, żeby się jednak nie wydarzyło? To czasami jest o wiele trudniejsze, ale co też możemy zrobić, żeby może nie miało takiego efektu na naszą pracę.

Jacek: Kawałek związany z ryzykami jest mocno powiązany z tym, jak zespół dokonuje refleksji też po konkretnych iteracjach. Jeżeli faktycznie taka refleksja zachodzi i analizujemy, jak nam poszło, co się udało, co się udało tak sobie, co się w ogóle nie udało, no bardzo często na skutek takich rozmów jesteśmy w stanie zdiagnozować powody niepowodzeń. Wiedząc, w których obszarach jest ryzykownej, jesteśmy w stanie takie ryzyko następnie wkalkulować. Z kolei, jeżeli zespoły nie poddają refleksji, w swojej pracy w jakiś taki sposób świadomy, to trudno oczekiwać, że te pomysły, czy zgłoszenia związane z ryzykami będą się podczas takiego planowania pojawiać. One gdzieś tam pewnie w głowach siedzą, ale nigdy głośno niewypowiedziane. No powodują, że jakoś tak nikt się nie odezwał, nikt nie podniósł ręki. I wielkie zaskoczenie, że zmienianie na przykład deweloperskiej, zmienianie jakiegoś kawałka produktu, gdzie wszyscy dobrze wiedzą, że tam są same problemy  – kolejny raz nas zaskoczy. Tak więc ta refleksja na pewno jest czymś, co długofalowo podnosi nam skuteczność planowania. 

Jacek: Kilka dodatkowych przemyśleń, chcielibyśmy jeszcze dołożyć na koniec tego odcinka tak, żeby domknąć pewne myśli, które mamy w głowie, a nie zostały wymienione jako te elementy, które warto rozważyć w trakcie planowania. Z jednej strony, próbowaliśmy tę listę przedstawić w taki sposób, żeby wskazać, które elementy są tymi elementami, od których warto zacząć, a które elementy następują później. Czyli to planowanie dostępności, zależności zewnętrzne, wymieniliśmy dosyć mocno jako te rzeczy, od których warto zacząć. I to jest prawda. Jednocześnie te wątki, te elementy, o których powiedzieliśmy, mogą się łączyć, a dyskusje związane z tymi elementami  nawracać. I na po prostu to warto być gotowym. Ta lista, o której powiedzieliśmy, to nie jest algorytm postępowania. Bardziej obszary, które warto zwrócić uwagę, z lekkim wskazaniem od czego zacząć. Warto tego używać z pełną świadomością, że to nie jest tak, że tylko raz rozmawiamy o zależnościach zewnętrznych, no i jakby kończy się okienko na te dyskusje i przechodzimy dalej. Tak więc korzystaj z tej listy po prostu w taki sposób, żeby ten plan był jak najlepszy, co może oznaczać, że wielokrotnie będziecie, czy będziesz zahaczał lub zahaczała o wątki, o których mówiliśmy. 

Kuba: Druga myśl to taka, że fakt, że planujemy, że wykonujemy ocenę ryzyka, że patrzymy na zależności, patrzymy na kompetencje to, że to wykonujemy, to nie oznacza, że pracujemy Waterfallem. Zimny dreszcz przebiega mi po plecach, jak słyszę argumentację o tym, że w zwinności nie wolno planować, nie planuje się, że polega się na samoorganizacji rozumianej jako takie wyłanianie się i się zobaczę, co się stanie. Absolutnie nie jest to prawda. Każdy zespół znajdzie sobie swoje własne podejście do tego, ale nie ma absolutnie nic złego w tym, żeby skorzystać, z powiedzmy już funkcjonujących, znanych, dobrych praktyk, które pomagają zespołom być skutecznym i pomagają przemyśleć, co jest do zrobienia. Pomagają przemyśleć to, jak można to poukładać. Oczywiście zwinność właśnie wtedy zacznie się, jeśli będziemy też reagować w trakcie na zmiany planu. Będziemy blisko ze sobą współpracować, pomagać sobie. Ale to nie oznacza, że zwinny zespół nie może zbudować sobie na przykład szkieletu planu działania, albo skorzystać z bardzo konkretnych praktyk, które wielu kierowników projektów zna, chwali. I też słuchając tego, co mówimy poznać, choć zazwyczaj nie wymieniliśmy w zasadzie żadnej z technik. 

Jacek: I ostatnia myśl. W zależności od konkretnego zespołu wybrane elementy listy, którą wspomnieliśmy, mogą nie być adekwatne. Czyli przykładowo, jeżeli mamy zespół deweloperów typu full stack, którzy samodzielnie testują, w szczególności, jeśli polegają na automatyzacji testów. No to przykładowy obszar kompetencji wewnętrznych zespołu w trakcie planowania, może nie jest najistotniejszym aspektem. Jako że te osoby są w stanie zrobić różne rzeczy. Być może na różnym poziomie, ale najprawdopodobniej na wystarczającym. Z drugiej strony, jeżeli w zespole mamy bardzo duże skupienie konkretnych kompetencji w konkretnych osobach, no to na pewno takich dyskusji będzie więcej. 

Kuba: Pomagamy lepiej pracować zespołom, które mają problemy z planowaniem swojej pracy. Dzięki współpracy z nami zespoły podnoszą swoje umiejętności planistyczne, poprawiają przewidywalność pracy i zwiększają efektywność. Jeżeli jesteś zainteresowany, albo zainteresowana współpracą z nami odezwij się do nas przez formularz kontaktowy na stronie porzadnyagile.pl/kontakt.

 Jacek: Notatki do tego odcinka, artykuł, transkrypcja, a także zapis wideo znajdziesz na stronie porzadnyagile.pl/87. I to by było wszystko na dzisiaj. Dzięki Kuba.

 Kuba: Dzięki Jacek. 

Jacek: Do usłyszenia wkrótce.