Porządny Agile

Czy Twój zespół naprawdę dowozi to, co zaplanuje? A może się przyzwyczailiście do tego, że zrealizowany jest tylko ułamek planu na iterację? Rozkładamy na czynniki pierwsze przewidywalność zespołu. Miara ta może być potężnym wsparciem dla zespołu, ale i źródłem frustracji czy złych decyzji. Pokażemy Ci jak mierzyć ją w Jira, Excelu czy innych narzędziach. Podpowiemy też, jak interpretować wyniki, by realnie ustabilizować w zespole proces dowożenia zaplanowanego zakresu prac. Cała rozmowa odnosi się do case study z naszej pracy z jednym z zespołów. Jeśli masz już dość niewykonanych planów oraz ciągłych tłumaczeń, ten odcinek jest dla Ciebie. Porządny Agile · Przewidywalność zespołu Zapraszamy Cię do obejrzenia nagrania podcastu Transkrypcja podcastu „Przewidywalność zespołu” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile. Jacek: Ostatnio na naszej stronie pojawiło się nowe case study. Dotyczy ono tego, jak w jednym z zespołów poprawiliśmy przewidywalność. Uznaliśmy z Kubą, że jest to dobra okazja, żeby powiedzieć trochę więcej o przewidywalności w ramach tego odcinka. Kuba: Adres case jest nie do przedyktowania w nagraniu audio, więc po prostu zachęcam Cię do tego, żeby znaleźć wspomniany case study w notatkach do odcinka i przeczytanie tego, co Jacek tam pisze. Jacek: Jaki spis treści na dzisiaj? Przede wszystkim zdefiniujemy, czym dla nas jest przewidywalność. Opowiemy, jak mierzyć przewidywalność. Podzielimy się wskazówkami na temat stosowania przewidywalności i na koniec damy kilka wskazówek, jak faktycznie, jakimi praktykami poprawić przewidywalność zespołu. Kuba: To przechodząc do rzeczy, pierwsza część to definicja przewidywalności. Przewidywalność rozumiemy to, jak zespół dowozi czy dostarcza to, co zaplanował. W jakim stopniu realizuje ten plan, który sobie przyjął? Czy, jak mówią, że coś będzie zrealizowane, czy to faktycznie będzie? Z jakim prawdopodobieństwem zespół realizuje swoje zamiary. Jacek: Więc jest to dla nas z jednej strony miara, o której powiemy za chwilę trochę więcej, bo można ją bardzo konkretnie wyrazić, a z drugiej strony, jak mówimy o tym, że zespół jest przewidywalny, to myślimy też w kontekście takim, że jest to pewna pożądana cecha zespołu. To jest taki zespół, na którym w kontekście tych prognoz, z którymi się dzielą z organizacją, można na nim polegać. Kuba: Dla równowagi powiemy też, czym nie jest przewidywalność według nas, choć niektórzy to też tak rozumieją. Niektórzy rozumieją przewidywalność jako pewną taką cechę generyczną rozumianą jako prawdopodobieństwo dostarczania, ale również prawdopodobieństwo o bardzo niskim stopniu albo o bardzo dużej zmienności tej wartości. W sensie, takim matematycznym, to też jest przewidywalność, tak samo jak smród jest zapachem albo jakiś brunatny też jest kolorem, ale jednak jako przewidywalność rozumiemy coś pozytywnego, zjawisko korzystne. W tym sensie nie cieszy nas fakt, że jakiś zespół ma przewidywalność, tylko ta przewidywalność to jest jedno zadanie na cztery zaplanowane albo 20% planu. W sensie matematycznym to jest przewidywalność, ale my się od takiej przewidywalności i takiego rozumienia tego słowa odcinamy, uważamy, że przewidywalność jest cechą czy charakterystyką pozytywną. Miarą, która powinna dążyć też do pewnych wartości. Zespół przewidywalny to taki, który dostarcza to, co planuje, a nie dostarcza tyle, ile zazwyczaj dostarcza. Nawet jeśli zazwyczaj dostarcza bardzo mało. Zespół, który przewidywalnie dostarcza mało, to jest dla nas zespół nieprzewidywalny, a nie przewidywalny w jakimś dziwnym znaczeniu. Jacek: To prowadzi nas do pytania, w jaki sposób możemy przeżyć przewidywalność. Ogólny wzór jest bardzo prosty. W dużym uproszczeniu jest to stosunek tego, co zostało faktycznie zrealizowane w konkretnym Sprincie czy w konkretnej iteracji w stosunku do tego, co było zaplanowane. Najczęściej jest to wyrażone po prostu w procentach. Kuba: Natomiast w szczegółach już może być trochę bogato. Różne zespoły uwzględniają do tego wzoru różne składowe elementy. Najprościej, gdy po prostu bierze się wszystko to, co zespół realizuje, niezależnie od tego, jakie typy pracy, jakie typy elementów planów wchodzą w skład danego Sprintu właśnie czy iteracji. Ale wiemy też i obserwujemy, i czasem ma to sens, że są zespoły, które liczą na przykład tylko historyjki użytkownika, storki, czy jakkolwiek to się w danym zespole nazywa. Czasem ficzery, czasem jakieś wyłącznie prace rozwojowe. Inne zespoły uwzględniają zadania czy jakiś rodzaj subtasków, jakaś praca techniczna do wykonania tego, co jest potrzebne do zrobienia w danym Sprincie. Kontrowersje mogą się zaczynać gdzieś w sferze tego, gdy się zaczyna liczyć do przewidywalności zaplanowane rozwiązania błędów, które wiemy, że istnieją, gdy zaczyna się Sprint, ale jest plan w zespole, żeby je rozwiązać. No i kontrowersją mogą być też zadania utrzymaniowe, czyli jakieś zadania powtarzalne, które z góry wiadomo, że trzeba zrealizować, no i choćby nie wiadomo, co się działo, to one po prostu faktycznie są częścią pracy w Sprincie. W ewentualnej kontrowersji głębiej się nie chcemy zagłębiać. Tutaj tylko jakby sygnalizuje, że jest temat, jakie typy pracy uwzględniać w mierze przewidywalności. No moim zdaniem jest tu temat do przemyślenia i bardzo świadomego zaplanowania czy do doprecyzowania, co jest uwzględnione we wzorze dla Twojego zespołu. Jacek: Może to jest dobry czas na taki prosty, namacalny przykład. Jeżeli zespół planował dostarczyć 10 elementów, nazwijmy to bardzo ogólnie, i dostarczył tylko dwa elementy, no to dla nas, patrząc na ten wzór przewidywalność, to jest 20%. Jeżeli planował dostarczyć 10, a dostarczył 5, no to przewidywalność jest 50%, natomiast jeśli planował dostarczyć 10, a dostarczył 12, to przewidywalność wynosi 120%. Tak więc przewidywalność jest miarą, w której ta wartość oczekiwana raczej jest pewnym zakresem. Takim dla nas powiedzmy akceptowalnym punktem do rozpoczęcia rozmowy, to jest przewidywalność między 80 a 120%. I bardziej chodzi nam o przebywanie w tym zakresie, niż osiąganie jakiegoś konkretnego, precyzyjnego wyniku. W szczególności powtarzalne osiąganie 100% może oczywiście wskazywać na to, że no ta miara być może za bardzo jest traktowana jako jakiś taki punkt do osiągnięcia. Z kolei o tym zakresie, który można nazwać, że jest powiedzmy zdrowy, można myśleć tak jak na przykład o wskaźnikach, kiedy idziemy na badanie krwi. Dostajemy wylistowaną listę, dostajemy poukładaną listę wyników i najczęściej jesteśmy w stanie znaleźć informacje, czy ta konkretna wartość zbadania jest w normie, czy mieści się w jakimś tam spodziewanym zakresie. I bardzo podobnie, właściwie można powiedzieć, wręcz identycznie działa to w przypadku przewidywalności. Kuba: Jeśli chodzi o przewidywalność, warto też wspomnieć to, jak narzędziowo można to mierzyć, jak można to liczyć, czyli jak konkretnie w narzędziu, jakim sposobem to zrealizować. Jest kilka opcji, wymienimy cztery. Jacek: Tak, pierwsze narzędzie takie, no, najczęściej nadal spotykane przez nas w organizacjach, to jest JIRA. Należałoby się skierować do sekcji raportów i znaleźć tam w wersji anglojęzycznej Velocity Chart i na tym wykresie oprócz tej informacji, ile faktycznie zespół zrealizował, czyli jaka jest prędkość zespołu, no, można również znaleźć tę informację o tym, ile na dany Sprint zostało zaplanowane. Te dane, te wykresy powinny się właściwie same wyświetlić, jeśli tylko przestrzegasz jakiejś takiej podstawowej higieny pracy w JIRA. To znaczy faktycznie uruchamiane są Sprinty. We właściwych momentach takich prawdziwych, kiedy zaczyna się Sprint, to ten Sprint jest startowany, powinien też być zamykany faktycznie wtedy, kiedy Sprint się kończy. Sprint powinien zawierać w sobie tę faktycznie wykonywaną pracę. Jak również pewna taka otoczka dotycząca tego boardu, na którym się znajdujemy, czy projektu, który realizujemy, te rzeczy też powinny być poprawnie skonfigurowane, no i wtedy można powiedzieć, że ten wykres dostajemy z pudełka. Właściwie nic nie musimy dodatkowego zrobić, żeby móc zobaczyć sobie historycznie, jak ta przewidywalność się w naszym zespole układała. Kuba: Drugą opcją narzędziową jest po prostu Excel. W porównaniu do JIRA, Excel stanie się, czy jest o wiele bardziej elastyczny, co prawda nie budują się dane same, jak w JIRA. Jeśli dobrze zachować tą dyscyplinę, o której mówi Jacek, no to JIRA liczy to sama, no w Excelu siłą rzeczy, ktoś odpowiedzialny za proces, albo członek zespołu, albo jakiś jego rodzaj lidera, po prostu musi te dane do tego Excela wprowadzić. Pamiętać o tym, żeby je przepisać, żeby złapać te dane historyczne bazowe i też pewnie w odpowiednie formuły wprowadzić te dane, żeby pokazały pewien wynik. Jest to oczywiście praca trochę ręczna, ale za to po drugiej stronie, zwłaszcza gdyby zespół miał jakąś bardziej skomplikowaną sytuację, albo bardziej wysublimowane warunki, co uwzględniać, czego nie uwzględniać, no to może się okazać, że ten Excel jest bardziej wiarygodny i pod większą kontrolą, niż narzędzia, które biorą po prostu wynik jakiegoś filtru lub nie są tak dobrze prowadzone. Jacek: Innymi narzędziami mogą być wszelkiego rodzaju narzędzia, które pomagają nam wizualizować pracę i pewne koncepcje z nią związaną. Czyli z jednej strony w warunkach online’owych to może być jakiś Mural czy Miro. W warunkach stacjonarnych to może być tablica, flipchart czy nawet wręcz kartka papieru. Tak naprawdę istotne jest, żeby te dane się znalazły w tych miejscach, wokół których będziemy się skupiać jako zespół. Na bazie moich doświadczeń bardzo często zespoły pracujące online dokonują refleksji na przykład na Muralu. No i w takim przypadku śledzenie tych informacji procesowych w kontekście tego odcinka, mówię tutaj w szczególności o przewidywalności, może być takim naturalnym miejscem, na które i tak spojrzymy w momencie, kiedy będziemy realizować cotygodniową czy co dwutygodniową refleksję. Tak więc posiadając komplet informacji w miejscu, do którego i tak rutynowo zaglądamy, drastycznie zwiększa szanse, że na te dane spojrzymy i zastanowimy się co z tych informacji, które posiadamy płynie, jakie wnioski do zespołu. Kuba: Ostatnią opcją, którą wymienimy, jeśli chodzi o narzędziowe pokazanie, mierzenie i uwidacznianie przewidywalności to są narzędzia BI-owe. W kilku organizacjach niezależnie od siebie widziałem taki efekt podłączenia bazy danych. Najczęściej pod spodem była jakaś JIRA, może Azure DevOps, albo tego typu narzędzia do mierzenia zadań, pokazywania tych zadań, kończenia ich. Dane surowe z takich narzędzi można przerzucić do narzędzi BI-owych. Czy to jest Power BI, czy to jest Tablo, czy to jest jeszcze coś innego. Kilka narzędzi różnie popularnych w różnych organizacjach. Oczywiście wymaga to już pewnych konkretnych kompetencji, żeby to wszystko podłączyć, żeby też być może odpowiednio skonfigurować raporty. No potencjalnie po stronie nagrody jest dosyć atrakcyjny sposób wizualizacji, być może sposób też jakiejś konfiguracji dodatkowego filtrowania dodatkowego, może dokładania kolejnych danych. W kontekście dużej organizacji wartością w sobie samo może być też pokazanie na jednym dash-boardzie wyników wielu zespołów, czy może pewien rodzaj standaryzacji pomiędzy zespołami, jakie aspekty są tam odpowiednio uwzględniane. Potencjalnie nagroda wielka, no ale tak jak wspomniałem też potencjalnie pewien koszt. Jeśli ma się te kompetencje w zespole, to może ten koszt jest siłą rzeczy pomijalny, a czasami warto to zainwestować, żeby dostać wartościowe widoki, czy wartościowe mierniki. Kuba: Ostatnią opcją, którą wymienimy, jeśli chodzi o narzędziowe pokazanie, mierzenie i uwidacznianie przewidywalności to są narzędzia BI-owe. W kilku organizacjach niezależnie od siebie widziałem taki efekt podłączenia bazy danych. Najczęściej pod spodem była jakaś JIRA, może Azure DevOps, albo tego typu narzędzia do mierzenia zadań, pokazywania tych zadań, kończenia ich. Dane surowe z takich narzędzi można przerzucić do narzędzi BI-owych. Czy to jest Power BI, czy to jest Tablo, czy to jest jeszcze coś innego? Kilka narzędzi różnie popularnych w różnych organizacjach. Oczywiście wymaga to już pewnych konkretnych kompetencji, żeby to wszystko podłączyć, żeby też być może odpowiednio skonfigurować raporty. No potencjalnie po stronie nagrody jest dosyć atrakcyjny sposób wizualizacji, być może sposób też jakiejś konfiguracji dodatkowego filtrowania dodatkowego, może dokładania kolejnych danych. W kontekście dużej organizacji wartością w sobie samo może być też pokazanie na jednym dash-boardzie wyników wielu zespołów, czy może pewien rodzaj standaryzacji pomiędzy zespołami, jakie aspekty są tam odpowiednio uwzględniane. Potencjalnie nagroda wielka, no ale tak jak wspomniałem też potencjalnie pewien koszt. Jeśli ma się te kompetencje w zespole, to może ten koszt jest siłą rzeczy pomijalny, a czasami warto to zainwestować, żeby dostać wartościowe widoki, czy wartościowe mierniki. Kuba: I zanim przejdziemy do następnego rozdziału, przypominamy, że jeżeli chcesz pogłębić wiedzę, jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep. Jacek: Przechodzimy do kolejnej sekcji dzisiejszego odcinka, czyli kilka wskazówek na temat tego, jak stosować miary przewidywalności w praktyce. Kuba: Pierwsza rzecz, od której chcę zacząć, to uwzględnij stopień innowacyjności zespołu. Przewidywalność jako miara w typowym zespole wytwórczym powinna być mierzona. To jest też cecha, którą taki zespół powinien posiadać. Natomiast mamy w swoim doświadczeniu kilka przykładów takich zespołów, które są naprawdę mocno innowacyjne, robią zadania takie mocno polegające na jakimś rodzaju research and development, jakimś badaniu, jakimś odkrywaniu, w takim stopniu innowacyjności naprawdę dużym. Te zespoły siłą rzeczy z racji na taką dużą chaotyczność czy dużą złożoność swojej pracy badawczej, po prostu tej przewidywalności osiągnąć nie za bardzo mogą, w takim znaczeniu, o jakim mówimy w tym odcinku. Dlatego tutaj bierzemy taką poprawkę, może taką dokładamy gwiazdkę do przewidywalności. W wybranej organizacji to niektóre zespoły będą siłą rzeczy nieprzewidywalne, w których firmach może w ogóle wszystkie, bo taka jest natura produktu czy branży, w której się działa, więc może wziąć warto poprawkę na to, że nie we wszystkich zespołach, nie we wszystkich firmach ta przewidywalność, o której dzisiaj powiedzieliśmy i jeszcze będziemy mówić, jest adekwatna, czy jest miarą, na którą warto spoglądać. Jacek: Jednocześnie przy tej okazji warto zwrócić uwagę na taki pewien ewenement, który obserwujemy z Kubą, że wiele zespołów wpada w poczucie, że są właśnie takim bardzo wyjątkowym i innowacyjnym zespołem, który ze względu na naturę swojej pracy nie jest w stanie pracować w przewidywalny sposób i nasze doświadczenie jest takie, że raczej nie do końca jest tak na takiej zasadzie, że faktycznie takie zespoły spotykamy, ale tych zespołów jest zdecydowania mniejszość. Nawet jeśli to faktycznie jest ten research, o którym wspominał Kuba, takie działania też można planować, można dzielić je na mniejsze kroki, bardzo precyzyjnie sobie określać kryteria akceptacji. I też w miarę w uporządkowany sposób decydować, czy to, co zaplanowaliśmy sobie zrobić, niekoniecznie te uzyskane rezultaty, ale tę pracę wykonaną, którą planowaliśmy, jesteśmy w stanie zaplanować. Raczej większość zespołów tę pracę, którą wykonuje ona, ma najczęściej jednak charakter taki, że jesteśmy w stanie przewidzieć, co będziemy realizować. Więc tutaj chcemy z Kubą wyraźnie zaznaczyć taką potencjalną pułapkę, żeby dokonać faktycznej refleksji, czy rzeczywiście ta nasza praca nosi znamiona takiej absolutnie niezarządzalnej, nieprzewidywalnej, czy tylko wpadliśmy w tę pułapkę, że tak o tej pracy myślimy. Jacek: Druga wskazówka, świadomie wybierz zmienne do wzoru. Wspomnieliśmy, jak taki wzór mógłby wyglądać, wspomnieliśmy, w jakiej jednostce wyrażony jest wynik. Taką główną wątpliwością osób, które podchodzą do tematu przewidywalności, jest wybór tego, czy powinniśmy patrzeć na konkretne elementy, które posiadamy jako zakres w danym konkretnym Sprincie, czy iteracji, czy raczej powinniśmy patrzeć na sumę story pointów I o ile historycznie pierwsze próby mierzenia się z przewidywalnością kierowały nas z Kubą w stronę story pointów, no to dzisiaj zdecydowanie jest nam bliżej do tego, żeby raczej patrzeć na tę liczbę elementów, które bierzemy do Sprintu. Konkretnie w Jirze można sobie przestawić wykres, ustawić go na to, żeby pokazywał issue count, czyli żeby po prostu policzył nam tę liczbę elementów, którą mamy w Sprincie. No i generalnie zbliża nas to do myślenia bardziej o patrzeniu i mierzeniu przepustowości i przewidywalności na tej bazie, niż na takie klasyczne Velocity, które najczęściej wyrażane jest jako suma story pointów zaplanowanych na konkretny Sprint. Kuba: Dlaczego poświęcamy na to czas w tym nagraniu? Bo wiele zespołów poświęca niepotrzebnie czas na przykład szczegółowy wycenianie, bo inaczej nie będzie pewien element uwzględniony we wzorze, a po wszystkim zwłaszcza też niezależne próby to potwierdzają w wielu zespołach, w wielu firmach korelacja między ilością skończonych elementów a story pointami zakończonymi jest na tyle silna, że w zasadzie nie ma potrzeby wkładać dodatkowej energii w to, żeby nawyceniać wszystkie prace. Zwłaszcza jeśli ma to prowadzić do, no naszym zdaniem, absurdów takich jak wycenianie błędów czy wycenianie jakichś zadań technicznych, tylko po to, żeby one się później ładnie w słupki sumowały. Może się okazać, że prosta suma ilości elementów jakichkolwiek, które uwzględniamy w takim predictability po prostu są do wzięcia i tyle, to jest dosyć łatwe, łatwo mechanicznie wyliczyć taki wzór i po prostu niepotrzebnie nie wkładać dodatkowej energii w coś, co nie wniesie dodatkowej wartości. I zaakcentuję, czy może tak trochę refrenem powtórzę to, co powiedział Jacek, niestety domyślnie Jira pokazuje, a Jira jest też najbardziej popularnym narzędziem z tego, co widzimy, pokazuje właśnie po story pointach, co może oznaczać, że nie uwzględnia rzeczy niewycenionych do tego typu wzorów na przewidywalność, no i z drugiej strony właśnie trochę miesza w przewidywalności, jeśli zespół cierpi na zadania przechodzące między Sprintami. Jeśli zespół właśnie uwzględnia w swoich działaniach również elementy, które są niewyceniane, więc tutaj domyślny sposób pokazania przewidywalności mierzonej w story pointach może być pewną pułapką, stąd wskazówka świadomie wybierz zmienne do wzoru. Kuba: Trzecia wskazówka to traktuj przewidywalność jako wewnętrzny kompas zespołu. Dużo nieszczęścia dzieje się w organizacjach, w których zostaje się celem. Jacek już to lekko zaznaczył, ja to wzmocnię. Są organizacje, które wręcz żądają, domagają się, zostawiają w celach rocznych, uzależniają premię od tego, czy zespół będzie przewidywalny, ustawiając też konkretne oczekiwane wartości. Najczęściej spotykam, że wartością oczekiwaną jest dokładnie 100%, czyli róbcie dokładnie tyle, ile planujecie, to poprowadzi do pewnych pułapek, ale znam też organizację, w której oczekiwana wartość przewidywalności to jest nie powinna przekraczać powiedzmy 80%. Czyli przewidywalny zespół to taki, który w przewidywalny sposób zawsze trochę nie dowozi. Też nie najszczęśliwszy pomysł. Więc tutaj mocno opieramy się na pomyśle, że przewidywalność to jest raczej miara wewnętrzna do mierzenia procesu przez zespół, do traktowania go jako punkt odniesienia przy usprawnianiu się, do myślenia o nim w czasie planowania, myślenia o nim w czasie Retrospektyw, myślenia o nim w jakimś tam dłuższym horyzoncie, ale na pewno nie jako sposób czy podstawa do tego, żeby dostać nagrodę albo karę, bo siłą rzeczy, zresztą jak każda inna miara tego typu, może się to łatwo przeinaczyć czy wręcz wypaczyć, stać się celem samym w sobie zamiast wiarygodną podstawą do usprawniania. Jacek: I czwarta porada, nie polegaj wyłącznie na przewidywalności. Tutaj zdecydowanie rekomendujemy, żeby przewidywalność nie była jedyną miarą procesu, którą zespół monitoruje. Dobrze jest od czegoś zacząć, ale zdecydowanie nie spoczywałbym tutaj na laurach. Przykładowo jednocześnie warto spojrzeć na throughput, czyli na przepustowość. Można do tego dołożyć sobie jakąś miarę jakości, można dołożyć jakąś miarę wartości biznesowej. To, co jest dla nas w danym momencie istotne i to, na co chcemy zwracać uwagę i wtedy patrzeć na pewien zestaw miar. Patrzeć jak one się wzajemnie zachowują. Może być tak, że poprawa jednej konkretnej miary może pogarszać wyniki w drugiej. Warto na to zwrócić uwagę i tak sobie skonfigurować te miary, żebyśmy mieli taki dosyć pełny obraz tego, jaka jest kondycja naszego zespołu i jego otoczenia. Kuba: I ostatni rozdział. Jak poprawiać przewidywalność zespołu? Ten rozdział będzie krótki, bo tak naprawdę to, co poprawia przewidywalność było tematem masy z poprzednich odcinków. My w zasadzie sami się z Jackiem zaśmialiśmy, że tak późno z naszej strony odcinek o przewidywalności w czasie, gdy mnóstwo praktyk poprawy przewidywalności już było przez nas poruszonych. Więc tutaj nie będziemy pogłębiać tematu, co dokładnie oznacza dana praktyka. Raczej potraktuj tę zawartość tego jako pewnego rodzaju spis treści czy nasze rekomendowane tak dokładnie osiem praktyk poprawy przewidywalności. Jeśli które z nich brzmi dla Ciebie intrygująco albo coś, czego jeszcze nie stosujesz, to po prostu odsyłamy Cię do materiałów, które też zamieszczamy w opisie odcinka. Jacek: Ok, czyli jakie praktyki zastosować, żeby poprawić przewidywalność zespołu? Kuba: Przede wszystkim zacznij kończyć, skończ zaczynać. Stosuj krótkie Sprinty. Wzmacniaj odpowiedzialność zespołu za produkt i dziel pracę na mniejsze kawałki. Jacek: Dodatkowo planuj zespołowo, zarządzaj zależnościami zewnętrznymi, traktuj codzienny stand-up jako bezpiecznik i usprawniaj się w oparciu o miary dostarczania produktu. Kuba: Wszystkie wymienione koncepcje, tak jak powiedziałem, znajdziesz w naszych starszych odcinkach, które linkujemy w opisie odcinka i na stronie tego odcinka porzadnyagile.pl/140 Jacek: Przewidywalność to miara i jednocześnie pożądana cecha zespołu, który realizuje zakres pracy, jaki sobie zaplanował na Sprint. Najczęściej przewidywalność podaje się w procentach jako stosunek liczby elementów faktycznie zrealizowanych do liczby elementów pierwotnie zaplanowanych. Kuba: Przewidywalność jest miarą, której wartość oczekiwana jest zakresem. Naszym zdaniem powinna mieścić się zazwyczaj między 80 a 120 procent. Istnieje szereg praktyk wspierających przewidywalność zespołu i zachęcamy do ich zastosowania w Twoim zespole. Jacek: Przyczyny braku przewidywalności w danym zespole mogą oczywiście być różne. Jako doświadczenie eksperci dołączamy do zespołu lub wskazanej części firmy i jasno je wskazujemy wraz z rekomendacjami sposobów, aby zmienić proces wytwórczy tak, by przewidywalność faktycznie rosła. Sprawdź naszą propozycję na stronie 202procent.pl/diagnoza. Kuba: A notatki do tego odcinka, artykuł, transkrypcję, wspomniane linki do innych rekomendowanych materiałów oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/140. Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba. Kuba: Dzięki Jacek. I do usłyszenia wkrótce. ________ To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę! The post Przewidywalność zespołu first appeared on Porządny Agile.

Być może często słyszysz w zespole „Niech ktoś to podzieli” i nie bardzo wiadomo, kto dokładnie powinien się za to zabrać. To jedno z częstych wyzwań w dzieleniu projektów na mniejsze części. Omawiamy też jeszcze kilka innych problemów z tym związanych. Dostaniesz od nas po kilka gotowych rozwiązań do każdego z nich. Odciąży to Twój zespół i sprawi, że dzielenie pracy stanie się naturalnym elementem codziennego działania. Porządny Agile · Wyzwania w dzieleniu projektów na mniejsze części Zapraszamy Cię do obejrzenia nagrania podcastu Dodatkowe materiały Dlaczego warto dzielić pracę na małe części? Transkrypcja podcastu „Wyzwania w dzieleniu projektów na mniejsze części„ Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile. Kuba: Niedawno zakończyłem serię warsztatów na temat praktyk dzielenia większych inicjatyw produktowych i projektowych na mniejsze części. Grupa mierzyła się m.in. z tematem wyzwań, jakie występują przy okazji procesu dzielenia. Wypracowaliśmy w poszczególnych grupach bardzo wartościową treść, zarówno jeśli chodzi o samą definicję tych wyzwań, jak i możliwe rozwiązania, więc tutaj postanowiliśmy, że wycinek tej treści, a konkretnie te konkretne wyzwania, które grupy wygenerowały, będą stanowiły wsad do tego nagrania. A przy okazji serdecznie pozdrawiam wszystkie pięć grup. Wiecie dobrze, że przepracowaliśmy o wiele więcej wątków, ale w odcinku może zmieścić się tylko część z tego, co omawialiśmy. Jacek: Spis treści na dzisiaj to wyzwania, jakie poruszymy. A są to problem z dobrym zrozumieniem celu projektu, presja biznesu na wdrożenie całości, wyważenie perspektywy technologii i biznesu przy podziale, czasochłonność procesu dzielenia i mentalność – niech ktoś to podzieli. Kuba: Schemat odcinka będzie dosyć prosty. Wejdziemy w definicję tego, co konkretnie oznacza daną wyzwanie. Te hasła nie zawsze są zrozumiane na pierwszy rzut oka. No i potem wygenerujemy po trzy rozwiązania, jakie przychodzą nam do głowy jako takie najczęściej się sprawdzające w praktyce rzeczy, które są w naszym doświadczeniu możliwym rozwiązaniem albo chociaż minimalizacją danego wyzwania. Jacek: Pierwsze wyzwanie to problem z dobrym zrozumieniem celu projektu. Jest to naszym zdaniem popularny bloker, który powoduje, że bardzo trudno jest zasiąść do mądrego podzielenia projektu czy inicjatywy, jeżeli tak naprawdę nie rozumiemy, co chcemy uzyskać. Oczywiście bez zrozumienia celu możemy tak bardzo mechanicznie spróbować podzielić pewien projekt na mniejsze części, ale prawdziwa magia dzieje się wtedy, kiedy bardzo dobrze rozumiemy cel, ponieważ wtedy otwierają nam się furtki do tego, jak pewne rzeczy możemy zrealizować w o wiele mądrzejszy sposób, niż tak patrząc na projekt bez zrozumienia, co tak naprawdę chcielibyśmy tym projektem uzyskać. Kuba: I jest tak, że to zrozumienie jest tutaj fundamentalnym wstępem do dobrego podziału, więc pierwsza porada może być dosyć oczywista. Zapewnij, że cel jest zrozumiały. Tutaj mamy na myśli kilka możliwych realizacji tego zapewnienia. Jedną z rzeczy na pewno jest dobry kick-off, czyli jakiś rodzaj spotkania otwierającego daną inicjatywę, dany projekt, daną zmianę produktową czy dany etap rozwoju danego produktu. Nie przechodź do założenia, że ludzie wiedzą, bo ty wiesz, tylko zapewnij jakiś wstęp, jakieś exposé, jakieś dobre wtajemniczenie ludzi w dotychczas zebrane badania, w taki kontekst biznesowy, dlaczego pewną rzecz realizujemy. I te przygotowania się do tego kick-offu nie pójdą na marne, bo też zapewnienie zrozumienia celu może być poprzez powtarzanie tych informacji. Czyli też zbuduj sobie praktykę wracania do celu przy każdej nadarzającej się okazji. To mogą być jakieś Przeglądy Sprintów, jeśli stosujesz Scruma, to mogą być jakieś demo, spotkania projektowe, jakieś warsztaty, jakieś podsumowania. Wszystkie te miejsca, gdzie zebrany jest zespół lub jego wyraźna część, to mogą być okazje do tego, żeby wrócić do tej mantry, co jest celem, co jest istotą tego, co jest realizowane w danym momencie. No i tutaj trochę założenie, że wielokrotne powtórzenie, być może powtórzenie na pewne różne sposoby, przekazanie tej informacji sprawi, że ten cel będzie rozumiany, da okazję do tego, żeby się tak mocniej w zespole osadzić. No i tym samym, gdy przyjdzie moment na aktywność związaną z dzieleniem, czy na początku jakiegoś kroku, czy w trakcie już dalszych prac, to ten cel będzie pamiętany, łatwy do przypomnienia, czy po prostu tak już na tyle zrozumiały, że w zasadzie wszyscy to traktują jako oczywistość. Jacek: Druga porada jest pewnego rodzaju pogłębieniem tego, co powiedział Kuba, czyli rekomendujemy użycie sprawdzonych technik, które wspierają pracę na celach, lepsze zrozumienie tego, czym ten cel właściwie jest. I mamy tutaj na myśli szereg różnych technik, podejść. Chcielibyśmy je teraz troszeczkę wymienić, tak żeby rozsypać takie ziarenka możliwości. Na pewno sensowną techniką do rozważania jest impact mapping, podejście golden circle, koncepcja product vision board, OKR-y czy opportunity solution tree. Jeżeli te nazwy niewiele ci mówią na ten moment, żadna strata po prostu wyszuka je w internecie, jeśli jeszcze ich nie znasz. Mamy z Kubą doświadczenie w większości tych narzędzi no i faktycznie możemy potwierdzić, że nie dość, że są fajnym narzędziem, które wspomaga zrozumienie, po co pewne rzeczy robimy, to zwykle są to też narzędzia, które są wizualne. Tak więc praca z nimi to nie jest tylko rozmowa, jest też ta część taka widoczna, która bardzo mocno poprawia i zwiększa zrozumienie tego, co on tak naprawdę jest esencją danej zmiany. Kuba: I tu konkretnie, jeśli by zespół zawierał się do jakiejś sesji dzielenia, to jeśli do tej pory nie zostało to zrobione, to rekomendujemy wykorzystanie jako swego rodzaju rozgrzewki czy wstępu właśnie któregoś z tych narzędzi lub powrotu do tych narzędzi, jeśli one zostały już przepracowane na wcześniejszych etapach. Kuba: I trzecia praktyka, którą rekomendujemy to stosowanie tak często, jak tylko się da sprawdzenia zrozumienia celu. To nie tylko osoba zarządzająca projektem, lider produktu czy manager zespołu, może być osobą, która komunikuje, jaki jest cel, ale możemy też poprosić o to, aby to uczestnicy w jakiejś formie ćwiczeniowej albo po prostu na zasadzie takiej szybkiej śmierci po prostu powiedzieli, przypomnieli, czy swoimi słowami opowiedzieli, jaki jest cel danej inicjatywy. To może być okazja do tego, żeby w ogóle sprawdzić, czy to jest zrozumiałe, to może być też narzędzia aktywizujące czy rozgrzewające uczestników, ale też jest fajna okazja do tego, żeby skorzystać z różnorodności zespołu, różnych perspektyw, różnych osób, z różnych profesji, które na sprawy patrzą trochę inaczej. Również warsztatowo na wspomnianym szkoleniu przeze mnie było to bardzo doceniane. Mieliśmy miks osób o bardzo różnych specjalizacjach na warsztacie i też właśnie ten aspekt wychodził. Pewne osoby patrzą na sprawy bardziej systemowo, inne bardziej biznesowo. No i ta parafraza celu albo próba zrozumienia celu też może być atakowana na różne sposoby i w efekcie to zrozumienie jest lepsze. Więc dąż do tego, żeby sprawdzać zrozumienie na przykład poprzez parafrazę przez osoby zaangażowane w zespół. Kuba: Przejdźmy zatem do drugiego wyzwania. Jest to presja biznesu na wdrożenie całości. Co mamy na myśli? Całości projektu, całości zakresu, całości inicjatywy, czasami może całość jakiejś zdefiniowanej funkcji w produkcie. To zjawisko może powodować, że jest pewna niechęć czy pewne poczucie bezsensu dzielenia. No bo po co dzielić, jeśli i tak musimy na końcu wdrożyć wielką całość tak, jak została ona zdefiniowana, a czasami z tą presją biznesu może się wręcz wiązać czy z presją może managementu, może się nawet wiązać takie poczucie, że podzielenie to proszenie się o kłopoty, bo być może ta strona, która wywiera tę presję, może wręcz zaraz zacząć dostrzegać się, że my chcemy spróbować się wyślizgnąć z jakiegoś kawałku zakresu. Więc szereg pewnych takich negatywnych emocji, które mogą powodować, że tego dzielenia nie chce zespół zrealizować. Jacek: I pierwsza nasza rekomendacja odnośnie do tego wyzwania jest taka, żeby pokazać korzyści, które wynikają z tej dekompozycji na wczesnym etapie. Warto założyć, że nie wszyscy wiedzą, nie wszyscy doświadczyli tego, jakie to są korzyści. A myślimy tutaj przede wszystkim o wczesnym obniżaniu ryzyk, zarówno biznesowym. Czyli mamy okazję wcześniej przekonać się, że to, co wymyśliliśmy, faktycznie trafia w potrzebę rynkową, jest właściwie rozwiązane. Ryzyk technologicznych, czyli czy potrafimy posługiwać się konkretną technologią, której chcemy użyć, czy ryzyk społecznych, czyli czy ta grupa osób, która odpowiada na implementację tego rozwiązania, czy potrafią ze sobą efektywnie współpracować. Więc ryzyka to jest jakby jedna strona tej monety, a z drugiej strony jest taka koncepcja, że chcielibyśmy tę najważniejszą wartość, tę esencję tak naprawdę, konkretne zmiany projektu czy inicjatywy, chcielibyśmy dostarczyć jak najwcześniej. Jeżeli ten temat jest dla Ciebie interesujący, to zdecydowanie polecamy nasz wcześniejszy odcinek, odcinek, który nazwaliśmy „Dlaczego warto dzielić praca na małe części?”, ponieważ zawarliśmy tam całą masę pomysłów, koncepcji i wskazówek, dlaczego warto dzielić. Odsyłamy do odcinka numer 76 dostępnego pod adresem porzadnyagile.pl/76. Kuba: Drugi z możliwych rozwiązań na presję biznesu na wdrożenie całości jest zrozumienie obaw interesariuszy, które blokują ich na tenże podział. Tutaj proponuję uruchomić empatię, proponuję zrozumieć i wczuć się w perspektywę tych Interesariuszy. Coś, co widać z zewnątrz z perspektywy też może konkretnego zespołu wykonawczego jako jakiegoś rodzaju niezrozumiała albo wręcz nieracjonalna presja, może tak naprawdę być czymś unikalnym dla tej osoby, dla tego konkretnego managera czy tej konkretnej grupy ludzi z jakiejś części organizacji. To może być coś, czego ty nie doceniasz, a jednak trzeba zagospodarować. Co mam tu na myśli? Bardzo konkretny przykład z konkretnej firmy, w której uczestniczyłem. Na przykład zespół odpowiedzialny za operację, czyli jakieś takie działania związane z usługami, na przykład po sprzedaży i obsługą klienta. Bardzo bał się, że ich narzędzia zostaną uznane za nieistotne, albo w ogóle nie zostaną zrealizowane w całym projekcie, dlatego oni byli bardzo sceptyczni i bardzo tacy twardzi w negocjacjach, bardzo niechętni do jakiegokolwiek dzielenia tego, co oni zgłosili, jakichś puli, ich wymagań, ich potrzeb narzędziowych. No bo ich życiowe doświadczenie z przeszłości jakichś poprzednich projektów pokazywało, że często kończyło się tym, że pod presją czasu w ogóle żadne narzędzia dla nich nie były wykonywane i muszą obsługiwać klienta Excelami i mailami pisanymi z ręki, bo system nie zagospodarował tego, choć pierwotnie było to planowane. Więc tutaj warto wziąć na to poprawkę, warto wczuć się w tę perspektywę i też zrozumieć ewentualne obawy. Jacek: Innym przykładem obawy może być sytuacja, w której ktoś komuś obiecał bardzo precyzyjny i zwykle bardzo rozbudowany zakres. Często jest tak, że osoby te nie mówią tego wprost albo po prostu może trochę im jest trudno też przyznać, że gdzieś tam komuś coś takiego obiecały no i będą opornie podchodzić do tematu, żeby ten duży kawałek, tą całość podzielić. Z takiej obawy, że to dzielenie będzie jednak być może pretekstem do tego, żeby z tego zakresu wyleciało. Kuba: Taki przykład specyficzny już dla pewnej grupy firm to to, że jest też w niektórych organizacjach taki pęd ku robieniu dużych, spektakularnych rzeczy. I tutaj w tym kontekście idea dzielenia trochę stoi z tym w poprzek. No bo trzeba robić wielkie projekty strategiczne, robić wielkie wow, mieć wielkie premiery, mieć wielkie nagrody za jakieś tam przełomowe niesamowite odkrycia czy innowacje w danej branży. W tym sensie warto tę perspektywę też złapać, że może być tak, że osoba właśnie szykuje się na przyszłą konferencję innowacji w bankowości i tam naprawdę ma wielką ochotę wyskoczyć na scenę i poopowiadać, jak to wielkie, wspaniałe, nowe implementacje, pewnie w tym roku AI w apce, ma w planach. Oczywiście to nie oznacza, że spektakularne rzeczy muszą być niepodzielone, ale warto może mieć tutaj świadomość tej sytuacji i ewentualnie dbać o tę komunikację, bo jedno nie stoi w przyszłości z drugim. W najgorszym razie faktycznie wdrożenie może mieć miejsce jako wielki wow, co nie znaczy, że nie warto podzielić na wcześniejszych etapach i też dostarczać kawałkami, być może kawałkami, które nie będą jeszcze publikowane. Jacek: I to, co Kuba powiedział, to właściwie przesuwa nas do trzeciej porady, czyli przepracowania z biznesem różnic pomiędzy podziałem na części, a obietnicą realizacji całości. W największym skrócie chodzi o to, że to, że podzielimy na mniejsze kawałki pracę, nie musi automatycznie oznaczać, że nie wdrożymy potrzebnej całości. Przy czym jednak tutaj oczywiście dostrzegamy pewną kontrowersję, no bo może być tak, że masz doświadczenie z aktualnej firmy czy z wcześniejszych firm, że jednak ze względu zwykle na jakieś ograniczenia czasowe taki podział powoduje, że do konkretnej daty jednak wdrażana jest jakaś tam część. Bywa, że ona jest satysfakcjonująca i nie są realizowane te rzeczy, których nie zdążyliśmy zrobić w dalszej kolejności, tylko realizowane są jakieś kolejne inne koncepcje. Więc co do zasady nie musi tak być, ale rozumiemy, że doświadczenie i historię wcześniejszych projektów mogą podpowiadać, że z tą poradą trzeba byłoby czy do tej porady podchodzić w ostrożny sposób. Kuba: W szczegółach jest też druga kontrowersja, to koncepcja potrzebnej całości. Może się okazać, że tutaj ktoś się bardzo kurczowo trzyma tego czegoś, co jest wyobrażeniem całości zakresu czy całości rozwiązania, co powstało na bardzo wczesnym etapie. No i czasami niektórzy zbyt kurczowo się trzymają tej wizji raczej zakładając, że od początku mieli rację co do tego, co jest potrzebne, od początku wiedzieli, że dokładnie ten cały zakres jest tym, czego potrzebuje rynek czy potrzebuje klient. Więc tutaj wracamy też do ryzyk biznesowych. Zbyt dużo decyzji podjętych na zbyt wczesnym etapie może być, tak naprawdę złudzeniem co jest potrzebne. Więc rada z podwójną kontrowersją jak to pokazaliśmy, ale mimo wszystko na etapie takim bardzo wczesnym, być może bardziej dyplomatyczne jest powiedzenie, „Podzielimy na kawałki i wdrożymy to, co jest potrzebną całością”, gdzie ja w swojej głowie mówię, potrzebna całość to nie będzie cały zakres, tak jak go czujemy dzisiaj, bo jeszcze czas pokaże, co to dokładnie będzie to coś, co wdrożymy. Jacek: Trzecie wyzwanie to wyważenie perspektywy technologii i biznesu przy podziale. Mamy tutaj na myśli sytuację po dwóch stronach osi. Z jednej strony, kiedy podział dzieje się wyłącznie w izolacji biznesowej i osoby technologiczne do tego podziału nie są zapraszane, co oczywiście powoduje, że tracimy bardzo istotny aspekt wykonalności, jak również dostępnych opcji, które płyną nie z głów biznesowych, a od osób technologicznych. Z drugiej strony próba podziału wyłącznie technologicznego, co może się udać z perspektywy podziału tego na mniejsze kawałki, ale dobrze nie rozumiejąc aspektów biznesowych albo nie mając możliwości dopytania – przykładowo, jaki to będzie miało impakt biznesowy – również spowoduje, że taki podział będzie jakiś, ale na pewno nie będzie to podział optymalny. Kuba: Rozwiązanie pierwsze jest dosyć oczywiste. Zaproś przemyślany skład, będący reprezentacją potrzebnych stron. I to idzie trochę dalej niż tylko te dwie skrajne kawałki osi, które wymienił Jacek, bo to może być też perspektywa na przykład prawna, to może być perspektywa user experience, więc tutaj uczestników tego typu warsztatów czy aktywności związanych z podziałem powinno być prawdopodobnie sporo w zależności od kontekstu i specyfiki twojego produktu. Natomiast w tej Radzie „Zaproś” jest też koncept tego, że w ogóle rozmawiamy po co, kto, z czym ma przyjść i jaką perspektywę reprezentować. Mnie serce boli, jak często słyszę ze strony biznesowej, że zaprosili na przykład przedstawicieli IT, jakiś architektów, jakiś senior developerów, po czym się okazało, że te osoby były bardzo ciche na spotkaniu, nie za bardzo zabierały głos, nie za bardzo dokładały od siebie – nawet zapytane. Moim zdaniem tu może być taki błąd pierwotny w tym, że ktoś zaprosił te osoby, przyszły, bo warto, bo trzeba, bo tak wypada, bo taki jest zwyczaj, natomiast tak naprawdę te osoby mogłyby nie wiedzieć, po co na danym spotkaniu są. Więc tutaj pojawia się bardzo ważna rola osoby zapraszającej, ktokolwiek to jest w danym kontekście, która również wyjaśnia wszystkim obecnym czy wszystkim planowanym do wzięcia udziału w tych czynnościach, żeby jednak bardzo jasno wyrazić, na co liczę, na czego oczekuję od Ciebie, jako uczestnika tego typu warsztatów. Żeby też nikt się nie bał, nie krygował, nie hamował, zwłaszcza, że prawdopodobnie w ramach takiego dzielenia się będzie trochę tarć. Ktoś zaproponuje podział biznesowy, który nie do końca jest dobry technologicznie, któryś podział biznesowo-technologicznie fajnie się zapowiadający będzie trochę bezsensowny z perspektywy prawnika, czy z perspektywy osoby odpowiedzialnej za bezpieczeństwo. Więc tutaj się rzeczy będą tarcia, więc każdy musi rozumieć też, po co jest na tym warsztacie, czy na tym spotkaniu, czy uczestniczy w tych aktywnościach. Jacek: Druga wskazówka ustal facylitatora i oczekuj od tej osoby, że zadba o każdą perspektywę. Mówiąc prostszym językiem, zadba, żeby była osoba, która zadba o to, żeby przebieg tego warsztatu był maksymalnie efektywny, żeby równomiernie wybrzmiały dostępne na spotkaniu perspektywy, nawiązując do tego, co powiedział Kuba, jak również, żeby zbalansować też głębokość tych rozmów. Czyli przykładowo, żeby nie zabrnąć w jakieś super niskopoziomowe detale na przykład technologiczne, bo to może powodować, że wszystkie te inne osoby, które nie są tak techniczne, może się o nich rodzić poczucie, że to spotkanie tak nie do końca jest dobrze poprowadzone. Kto może prowadzić takie spotkanie? To może być ogarnięty analityk, to może być lead developer, to może być architekt. Tak naprawdę nie ma to znaczenia, jak nazywa się ta konkretna rola. Ważne jest natomiast, żeby ta osoba była po pierwsze dobrze przygotowana do poprowadzenia takich warsztatów, czasem serii warsztatów, bo to może być więcej niż jednorazowa akcja, i żeby starała się ta osoba trzymać perspektywę wszystkich stron będących na tym spotkaniu równomiernie, a nie była tylko reprezentantem tej jednej. Bo tak jak wspomniałem przed chwilą może to spowodować, że nie do końca będzie to dobra reklama na przyszłość dla tego typu inicjatyw w organizacji. Kuba: I trzecia porada, jak sobie poradzić z wyważeniem perspektywy technologii i biznesu, to zastosować techniki wizualne, które są zrozumiałe zarówno dla biznesu, jak i IT. Mamy tu konkretnie przede wszystkim na myśli Story mapping, który lubimy, robimy, często rekomendujemy i sami też regularnie wręcz stosujemy do swojej własnej pracy biznesowej czy pracy związanej z podcastem. Podobnie jak z poprzednimi wymienionymi technikami, nie będziemy tutaj w odcinku ich opisywać. Zakładam, że Story Mapping jest już na tyle powszechną techniką, że akurat on powinien być wśród odbiorców znany naszego podcastu, ale jeśli nadal go nie znasz, to mocno rekomendujemy sprawdź to, może dołącz do jakiegoś warsztatu, gdzie jest to realizowane, bo technika jest supermocna, jeśli chodzi o wizualizację, jeśli chodzi o pokazanie zakresu, pokazanie opcji, ale też między innymi w kontekście tego, o czym tu mówimy, takie pokazanie sobie, czym jest w ogóle to przedsięwzięcie, które realizujemy, jaką ono się dzieli na mniejsze kawałeczki i te kawałeczki najczęściej są realizowane z perspektywy użytkownika, więc zrozumiałe są zarówno dla biznesu, jak i dla strony tych osób, które będą później to implementować. Obiecująco wygląda też zastosowanie Event stormingu. Ja sam osobiście nie prowadzę tych sesji, ale kilkukrotnie uczestniczyłem jako obserwator czy jako uczestnik. Mam tu mniejsze doświadczenia, ale jeśli ktoś umie to poprowadzić, to uważam, że może dać bardzo podobny rezultat co Story mapping, choć rządzi się trochę innymi prawami. Jacek: Zanim pójdziemy dalej, krótka informacja, mamy dostępny z Kuba webinar dotyczący kwestii tego, jak dzielić pracę na mniejsze kawałki. Ten webinar nauczy Cię formułować celne argumenty za tym, że w ogóle warto dzielić, nauczy Cię też używać w praktyce wyselekcjonowanych przez nas konkretnych metod dzielenia. W webinarze pokazujemy wszystko na bazie łatwych, do zrozumienia przykładów, jak dzielić oraz podpowiadamy sporo wskazówek z naszej praktyki, jak lepiej dzielić elementy, angażując w to wydarzenie całe zespół. Więcej informacji oraz możliwości zakupu webinaru znajdziesz na stronie porzadnyagile.pl/deco. Kuba: Czwartym wyzwaniem jest czasochłonność procesu dzielenia. Często, gdy przekonuję jakiś zespół do tego, że warto dzielić, słyszę jako jeden z argumentów przeciwko dzieleniu, jest to, że to jest praca do wykonania, ktoś to musi zrobić, ktoś to musi wpisać, tu będzie dużo elementów, które później trzeba zarządzić, skoordynować. I przyjmuję do wiadomości, że to jest pewna praca, to jest pewien wysiłek, ale dla wielu zespołów czy w wielu organizacjach jest to po prostu pewnego rodzaju wyzwanie, jak się za to zabrać. Co tutaj rekomendujemy? Jacek: Przede wszystkim warto zadbać o zmianę myślenia, że dzielenie to nie jest koszt i tak nie nazywać tego procesu, tylko raczej myśleć o tym, że to jest inwestycja w proces dostarczania, która pomoże zespołowi uchwycić po pierwsze dobre zrozumienie zakresu, da też o wiele lepszą kontrolę nad postępem prac, przez to, że będziemy pracować na trochę mniejszych klockach i też zmniejszy złożoność danego kroku większej inicjatywy, które mamy do wykonania. Za tym wszystkim płynie cały szereg technicznych aspektów, a mianowicie sam przepływ pracy wewnątrz zespołu powinien tak naprawdę przy pracowaniu na mniejszych kawałkach przyspieszyć, przez to, że szybciej coś zostanie zaimplementowane, szybciej będziemy w stanie to przetestować, szybciej będziemy w stanie zrobić code review, czy ostatecznie szybciej pewne rzeczy zmergować, czy wypuścić na środowisko produkcyjne. Jest więc cała masa bardzo pozytywnych rzeczy, które dostaniemy, tylko jeśli zainwestujemy czas w to, żeby tę pracę, która na nas czeka, po prostu, żeby ją podzielić na mniejsze fragmenty. Kuba: Druga rada to wykorzystaj reużywalność narzędzi i instrukcji. Faktycznie może być tak, że ten koszt czy inwestycja, jak to Jacek przed chwilą bardzo wyraźnie wskazał czy skorygował, może po prostu zajmować pewien konkretny czas i częścią tego czasu może być przygotowywanie się lub niepotrzebne wgryzanie się w techniki czy w narzędzia związane z dekompozycją czy właśnie dzieleniem elementów. Tutaj mocno rekomenduję, zwłaszcza osobom, które pełnią jakieś funkcje liderskie w zespole, czy odpowiadają za proces pracy, by jak najmocniej wykorzystywać okazję do szykowania czy reużywania checklist, na przykład metody dzielenia. To jest bardzo prosta checklista, jakimi metodami możemy podzielić dany projekt czy dany element, który podlega właśnie warsztatowaniu. To mogą być przygotowane szablony, wymieniliśmy konkretne już techniki, te techniki można mieć już przygotowane, jakieś boardy na jakimś miro czy jakieś przygotowane gotowe kawałki do przepisania na flipchart czy do przepisania na jakieś kartki. Ale chodzi też o znane zespołowi schematy. Nie trzeba się silić za każdym razem, żeby zrozumieć o co chodzi tej osobie, która prowadzi daną sesję warsztatową, tylko zespół się dopracowuje z czasem gotowych ścieżek, tych, które już można nawet prawie nie dawać żadnych instrukcji, tylko po prostu wejść na takim trochę automacie. Oczywiście nie sugeruję, te instrukcje zawsze jednak jakieś powinny być, ale one mogą być super związłe, niewymagające żadnych dodatkowych omówień i też wchodzące zespołowi, tak nazwij, gładko. Czyli zespół płynnie wchodzi w temat, nie ma żadnych dyskusji, ale o co ci chodzi, gdy każesz nam tu coś rozpisać albo co masz na myśli, gdy mówisz o dzieleniu po jakiś tam elementach, bo to wszystko zespół już zna, czuje. Więc też w jakimś sensie jest okazja do oszczędności czasowej, jeśli tylko do tego podchodzi się w taki bardzo świadomy sposób i dzięki temu, zwłaszcza kolejne dzielenia, gdy już bazujesz na checklistach albo schematach, są już mniej czasochłonne. Jacek: To co powiedział Kuba jest wprowadzeniem do trzeciej porady, czyli nabierzmy wprawy w dzieleniu. Kiedy zbudujemy doświadczenie, kiedy będziemy mieć te wszystkie checklisty, te wszystkie rzeczy, które nam ułatwiają, wtedy dzielenie staje się czymś naturalnym, płynnym, oczywistym i jest po prostu przeprowadzane w sposób generalnie dosyć sprawny. Przestaje być tematem, na którym trzeba się zastanawiać, nic nas nie blokuje, nie ma tej obawy jak to zrobimy, tylko po prostu staje się tu naturalną częścią pracy zespołów, coś co jest absolutnie oczywiste i należy poświęcić na to trochę czasu. To nie jest tak, że to się po prostu wydarzy, ale pierwsze podzielenie, drugie, trzecie. Zwykle pojawiają się bardzo wartościowe efekty dzielenia, powodują, że w tej pamięci mięśniowej zespołu zostaje taka myśl, że to po prostu warto robić, więc z perspektywy czasu nie ma już myślenia, czy to zrobimy, tylko tak naprawdę, kiedy to zrobimy, bo po prostu wiemy, że to po prostu trzeba robić, że to ma sens. I też skojarzenie jest takie, że zrobiliśmy to tyle razy, że zrobimy to z równą łatwością, kiedy przyjdzie kolejna okazja czy konieczność, żeby wykazać się tymi umiejętnościami. Kuba: I pokuszę się o taką szpileczkę, że wyzwanie z czasochłonnością dzielenia, szczególnie przecenia czy niepotrzebnie uwypukla ta grupa, która tego dzielenia nie robi. Czyli tutaj jest pewnego rodzaju obietnica osoby, które realizują dzielenie rutynowo, po prostu uważają to za nieodłączną część pracy, robią to dosyć płynnie i nie robią z tego niepotrzebnego szumu. Jacek: Ostatnie wyzwanie, które chcemy pokryć w dzisiejszym odcinku, to mentalność, niech ktoś podzieli. Czyli jest to sytuacja, w której nie do końca wiadomo, kto powinien się zabrać za dzielenie. Może i czujemy, że dobrze by było podzielić, ale to na pewno nie powinniśmy robić my. To powinni zrobić oni, albo to powinien zrobić ktoś. Jeżeli więcej osób w organizacji pomyśli w ten sam sposób, odrzucając trochę tę rękawicę pod tytułem wezmę i zrobię, to może się okazać, że czas sobie będzie płynął, co jest nieuniknione i po prostu zaczniemy pracę z tym, co mamy, czyli będziemy pracować z projektem w takim stanie, jaki jest, bez podziału. Jakie mamy pomysły na to, żeby sobie z tą mentalnością poradzić? Kuba: Pierwsza praktyka, chociaż nieatakująca problemu wprost, to podział na poziomie całego portfela. Mówię, że nie atakuję to wprost, bo to nie rozwali tej mentalności, że ktoś inny powinien podzielić, a w pewnym sensie nawet wręcz właśnie rekomenduję, żeby faktycznie ktoś inny podzielił, ale mam tu na myśli to, że jednym z problemów tego takiego przytłoczenia albo potrzeby, żeby ktoś podzielił, jest właśnie ta perspektywa, że często do zespołów wykonawczych, czy takich zespołów produktowych, projektowych trafia coś, co jest bardzo dużych rozmiarów i to tak z góry zdeterminowane, czy z góry zdefiniowane w taki sposób, że ten podział nie jest prosty. Więc tutaj mocno rekomenduję, by to na poziomie portfela, czy produktu, czy Road mapy, czy całego portfela projektów, jeśli tak to funkcjonuje w twojej organizacji, zastanowić się, czy by tego podziału jednak w jakimś sensie, albo nie wymusić, albo chociaż propagować jako dobrą praktykę. Bo wtedy, jeśli do zespołu trafi coś, co jest mniejszą cząstką, jakimś mniejszym etapem projektu, mniejszym wycinkiem celu, albo realizacją tylko jednego z najważniejszego celu spośród kilku, które dana inicjatywa pierwotnie miała realizować, to ten podział w tym zespole już konkretnym będzie trochę prostszy. Więc ta mentalność niech ktoś podzieli, moim zdaniem może m.in. częściowo bazować na tym, że zespół jest konfrontowany z trochę za dużymi elementami i rozwiązaniem na to jest podział na wczesnym etapie, jeszcze tak trochę ponad zespołem, czy na tym etapie takim strategicznym, albo chociaż taktycznym. Jacek: Druga porada to zasada, którą chcemy zaproponować, że warto się na nią umówić w zespole, która brzmi, jak widzisz linię podziału, to zgłaszasz propozycję podziału. Czyli koncepcja, w której jeżeli przechodzi Ci do głowy, jak można coś byłoby podzielić, to po prostu mówisz to. Z czego wynika ta propozycja? Wielokrotnie spotykam się z sytuacją, że obserwuję np. podczas procesu superwizji, jak pracuje konkretny zespół. Ktoś zadaje pytanie, pada pytanie, nikt się nie odzywa. Można odnieść wrażenie, że w zespole nie ma odpowiedzi. Kiedy zagłębić się i porozmawiać na spokojnie z pojedynczymi osobami, albo kiedy zastosujemy inną strukturę, która w lepszy sposób aktywizuje osoby dostępne w zespole, okazuje się, że zespół ma całą masę różnych pomysłów, bo tylko z jakichś powodów się tymi pomysłami nie dzieli. Zasada, którą tutaj proponujemy, ma na celu zbudowanie śmiałości w ludziach. Na zasadzie uprościmy sobie życie, jeśli ktoś zobaczy fajny, sensowny sposób podziału, to się w danym momencie odezwie. Brzmi to banalnie, ale wiem z doświadczenia, że czasem pojedynczy sygnał, impuls, komentarz potrafi uruchomić bardzo fajną zmianę w zespole. Zdecydowanie do umówienia się na takie proaktywne działanie rekomendujemy. Kuba: Trzecia, ostatnia porada w tym wyzwaniu to kształtowanie przez management konieczności dzielenia. To dzielenie musi być oczekiwane, czyli członkowie zespołu. Jeśli wprowadzili tę zasadę Jacka, to powinni być za nią doceniani. Jeśli jej nie wprowadzają albo zasłaniają się, że idzie, jak idzie, albo postępów nie ma, albo ryzyka projektowe się ziściły, bo nie podzieliliśmy, to powinien być wstęp do bardzo poważnej rozmowy o tym, że to jest problem, bo jako management organizacji, czy jako Product manager, czy Project manager, czy jakiś manager strukturalny, hierarchiczny, wszyscy wymagają tego, żeby to dzielenie miało miejsce. Warto postawić dzielenie jako oczekiwanie, dawać feedback, jeśli to dzielenie następuje, dawać feedback, jeśli nie następuje. Też wspierać pomysły na podział, zwłaszcza takie bardziej odważne, wiążące się też z zahaczeniem o aspekty wyższego poziomu biznesowe, czy związane ze zrozumieniem celu. Wszystko to warto propagować. I przez odwrotność też powiem, nie doprowadzać do sytuacji, w której zespół ma poczucie, że ma zablokowaną możliwość dzielenia. Mam na myśli takie jakieś wytyczne czy jakieś stawianie pewnych spraw, że na przykład wszystko musi być wdrożone jako całość, co było przedmiotem innego wyzwania, czy jakieś inne rodzaje blokerów albo komunikatów, które powodują, że zespół nie wierzy w efekty pracy przyrostowej i nie widzi w związku z tym sensu dzielenia. Jacek: Na koniec kilka myśli, którymi chcemy się podzielić zamiast takiego klasycznego podsumowania. Dzielenie pracy na mniejsze kawałki to zawsze dobry pomysł. Jeszcze nie spotkałem zespołu, który byłby zawiedziony efektami dobrze przeprowadzonego dzielenia. Kuba: Dzielenie jest superpraktyką. Analogicznie do tego jak o żywności mówi się superfood. Daje masę korzyści na wielu poziomach i jest jednym z fundamentów efektywności zespołów. Jacek: Warto kreować kulturę pracy wspierającą dzielenie pracy na mniejsze części i aktywnie mierzyć się z ewentualnymi wyzwaniami, z takimi aktywnościami. Kuba: Jeśli mierzysz się w swojej organizacji z wyzwaniami związanymi z dzieleniem, tymi, które wymieniamy albo innymi, skorzystaj z naszej oferty wsparcia konsultacyjnego. W Twoim konkretnym kontekście pomożemy przemyśleć dany temat albo wskazać konkretne rozwiązania z naszego wieloletniego doświadczenia. Sprawdź całość oferty na 202procent.pl/konsultacje. Jacek: Ja również polecam się odezwać do nas. Natomiast notatki do tego odcinka, artykuł, transkrypcja oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/139. Kuba: I to by było wszystko na dzisiaj. Dzięki, Jacek. Jacek: Dzięki, Kuba. I do usłyszenia wkrótce. ________ To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!The post Wyzwania w dzieleniu projektów na mniejsze części first appeared on Porządny Agile.

Poznaj 11 prostych, ale jednocześnie skutecznych sposobów na ogarnięcie własnej produktywności — od listy rzeczy do zrobienia i planowania dnia, po technikę Pomodoro, regularne przerwy… The post Praktyki wspierające produktywność osobistą first appeared on Porządny Agile.

Czy Twój zespół jest ciągle zajęty, a mimo to efekty nie robią wrażenia?  A może ktoś w firmie wierzy, że wystarczy „dowieźć szybciej” albo kupić… The post Mity o efektywności zespołów first appeared on Porządny Agile.

Czy wiesz, że wiedza w Twojej firmie może niepostrzeżenie zanikać?  Erozja umiejętności pojawia się wtedy, gdy nowe osoby uczą się głównie od starszych stażem kolegów… The post Powolna erozja efektów szkoleniowych first appeared on Porządny Agile.

Jakie miary warto śledzić, żeby naprawdę usprawniać proces wytwarzania produktu? Poznaj nasz zestaw sześciu rekomendowanych miar procesu dostarczania od Time To Market po Delivery Predictability.… The post Rekomendowane miary dostarczania produktu first appeared on Porządny Agile.

Jak przygotować się do Retrospektywy wielu zespołów? Wyjaśnimy Ci, jak skutecznie organizować spotkania usprawnieniowe obejmujące więcej niż jeden zespół. Omawiamy najczęstsze błędy i podpowiadamy, jak… The post Spotkania usprawnieniowe wielu zespołów first appeared on Porządny Agile.

Gdzie powinno znajdować się właścicielstwo produktowe w organizacji? W IT? W biznesie? A może to temat, który wymaga zupełnie innego podejścia? Poznaj różne modele umiejscowienia… The post Właścicielstwo produktowe – w Biznesie czy w IT? first appeared on Porządny Agile.

Czy masz wrażenie, że Twój zespół wykonuje zadania, ale nie czuje realnej odpowiedzialności za produkt? Brakuje u nich inicjatywy, zaangażowania i proaktywnego podejścia? Pokażemy Ci… The post Jak szef produktu buduje odpowiedzialność zespołów? first appeared on Porządny Agile.

Czy wiesz, że ślepe podążanie za jednym modelem pracy może ograniczać Twój zespół? Nie istnieje jedna najlepsza metoda pracy. Dowiesz się jak łączyć różne podejścia… The post Jedna najlepsza metoda pracy nie istnieje first appeared on Porządny Agile.

Czy wiesz, jak skutecznie zbliżyć biznes i IT, by wspólnie brać odpowiedzialność za sukces produktu? Masz problem, żeby pokonać typowe bariery w komunikacji między zespołami,… The post Jak zbliżyć do siebie biznes i IT first appeared on Porządny Agile.

Czasem zdarza się, że w organizacji pojawi się projekt, który wymaga działań wielu zespołów zwinnych. Przygotowaliśmy zestawienie pewnych praktyk, z których możesz ułożyć sobie własne… The post Inicjatywy wielozespołowe first appeared on Porządny Agile.

Praca nad wieloma produktami jednocześnie w jednym zespole może być wyzwaniem. Jak sobie z tym poradzić? Jednym ze sposobów jest skoncentrowanie całej organizacji na priorytetach… The post Jak radzić sobie z wieloma produktami w jednym zespole? first appeared on Porządny Agile.

Grupa Product Ownerów z jednej z firm zadała nam pytanie: „Czego w praktyce możemy oczekiwać od Scrum Mastera?”. To zagadnienie zainspirowało nas do szerszej dyskusji… The post Czego oczekiwać od Scrum Mastera? first appeared on Porządny Agile.

Poznaj narzędzie Circle of influence, które pomaga zespołom zwinnym zidentyfikować, na co mają pełny, częściowy lub żaden wpływ. Dzięki temu zespoły mogą skupić się na… The post Circle of influence first appeared on Porządny Agile.

Poprawnie skonstruowany Cel Sprintu to wyzwanie dla niejednego zespołu. Widzimy to dosyć często w naszej codziennej pracy. Z czego może wynikać ten problem? Zdradzamy kilkanaście… The post Dlaczego tak trudno ustalić Cel Sprintu? first appeared on Porządny Agile.

Scrum Masterzy coraz częściej mierzą się z ogromną odpowiedzialnością, ale brakuje im adekwatnego wsparcia. Nierealistyczne oczekiwania stanowią dla nich wyzwanie, a jednocześnie są dużym problemem… The post Scrum Masterzy samodzielnie nie zmienią Twojej firmy first appeared on Porządny Agile.

Obserwujemy, że w niektórych firmach kompetencje zwinne rozwijane są tylko na początku transformacji zwinnej. Potem zwinność i kompetencje z nią związane powoli zanikają. Z czego… The post Wzmacnianie kompetencji zwinnych w zespołach first appeared on Porządny Agile.

Lessons Learned jest narzędziem pracy powszechnie stosowanym w zarządzaniu projektami (bardzo popularnym u kierowników projektów). Dowiesz się, dlaczego naszym zdaniem ta koncepcja jest antywzorcem? W… The post Jak uniknąć pułapki Lessons Learned? first appeared on Porządny Agile.

Jak budować zaufanie z klientem? To pytanie, które nurtuje wiele firm, zwłaszcza w branży IT, gdzie relacje z klientem odgrywają kluczową rolę. Dla software house'ów,… The post Budowanie zaufania jako software house first appeared on Porządny Agile.

Skąd się wzięła rola Agile Coach'a? Czy Scrum Master nie powinien być rolą tymczasową? To kilka pytań, na które odpowiedzi usłyszysz w tej rozmowie. Poruszyliśmy… The post  Q&A cz.2 first appeared on Porządny Agile.

Czy Scrum Masterzy rzeczywiście słabo wykonują swoją pracę? Co daje nam największy napęd w szerzeniu “zwinności”? Czy agile umiera? Słuchacze pytają, a my odpowiadamy. W… The post Q&A cz.1 first appeared on Porządny Agile.

Agile poza IT – to jest możliwe! W ostatnich latach owocnie współpracowaliśmy z firmami z innych branż i mamy listę przemyśleń na temat na temat… The post Agile poza IT first appeared on Porządny Agile.

Jesteś osobą odpowiedzialną na zmianę w organizacji i czujesz, że nic więcej nie da się zrobić? Czasami warto odpuścić. Poznaj siedem sygnałów, które naszym zdaniem… The post O tym, kiedy odpuszczać first appeared on Podcast "Porządny Agile".

Przedstawiamy nasze wrażenia ze szkolenia u Alistair'a Cockburn'a “Advanced Agile Masterclass”. Tym razem to nie my szkoliliśmy, a poszerzyliśmy naszą wiedzę u jednego z inicjatorów… The post Po szkoleniu Advanced Agile first appeared on Podcast "Porządny Agile".

Jak mogą wyglądać elementy Backlogu Produktu, czyli potocznie story lub storki? Dowiesz się, jak takie porządne story powstaje i z jakich elementów się składa. Podajemy… The post Porządne story first appeared on Podcast "Porządny Agile".

Co robić gdy słyszysz od zespołu, że “tego nie da się tego zrobić?”. Z czego może wynikać to założenie? Poznaj siedem porad, które pomogą Ci… The post Zespół mówi “nie da się” first appeared on Podcast "Porządny Agile".

Co to jest zaawansowany agile i jakie ma odcienie? Tym razem nieco bardziej refleksyjna treść, w której rozważamy o tym, kiedy możemy mówić o dojrzałym… The post Zaawansowany agile first appeared on Podcast "Porządny Agile".

Najlepsze pomysły rodzą się w zespołach, na bazie współpracy i wzajemnej inspiracji. Definiujemy „mądrość zespołu.” Wyjaśniamy też, dlaczego to podejście jest tak istotne w dzisiejszym… The post Czerpanie z mądrości zespołu first appeared on Podcast "Porządny Agile".

Cel Produktu jest elementem, który pojawił się w ostatniej aktualizacji Przewodnika po Scrumie. Nadal spotykamy się z tym, że zespoły nie używają go w codziennej… The post Cel Produktu first appeared on Podcast "Porządny Agile".

Dlaczego warto rozważyć używanie Scruma do organizacji pracy zespołów managerskich? Jak budować takie zespoły? Jak może wyglądać praca w takim zespole? Dzielimy się też naszymi… The post Scrum w zespole managerskim first appeared on Podcast "Porządny Agile".

Spotkania 1 na 1 to okazja do indywidualnej regularnej rozmowy, gdzie jedna osoba spotyka się bezpośrednio z drugą. Mogą być one bardzo wartościowe w kontekście pracy Scrum Mastera i członków […] The post 1 na 1 ze Scrum Masterem first appeared on Podcast "Porządny Agile".

Czym są modele VUCA i BANI? Jak sobie radzić z aspektami, których dotykają? Poznaj nasze zdanie odnośnie do tych modeli zarządzania. Zaproponowaliśmy też nasze praktyki, które odpowiadają na wizję świata […] The post Świat VUCA i BANI first appeared on Podcast "Porządny Agile".

Zespoły często pracują projektowo, poprzez formułowanie dosyć precyzyjnych zakresów prac. Chcemy Ci pokazać i zainspirować do innego sposobu pracy, przez formułowanie celów. Zaznaczamy, że nie jest to takie łatwe i […] The post Trudności z pracą na celach first appeared on Podcast "Porządny Agile".

Jak może wyglądać dalsza ścieżka kariery Scrum Mastera? Agile Coach, Agile Lead, manager zespołu, Product Owner, a może konsultant zewnętrzny? Zdefiniowaliśmy każdą z tych ról i wyjaśniamy, co trzeba rozwinąć, […] The post Ścieżki dalszego rozwoju Scrum Mastera first appeared on Podcast "Porządny Agile".

Odpowiadamy na pytanie, czy jest sens łączyć podejście agile i waterfall. Tłumaczymy, co mamy na myśli pod tymi dwoma pojęciami. Wskazujemy dziewięć cech odróżniających podejście zwinne od kaskadowego oraz pokazujemy […] The post Agile i waterfall – łączyć czy nie? first appeared on Podcast "Porządny Agile".

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ć. Porządny Agile · #104 – Zależności zewnętrzne w zespole Jak obsługiwać […] The post Zależności zewnętrzne w zespole first appeared on Podcast "Porządny Agile".

Scrum Masterzy dosyć często muszą mierzyć się z hejtem skierowanym w ich stronę. Wyjaśniamy, jaka może być przyczyna takich zachowań wobec nich. Podpowiadamy, co możesz zrobić, żeby nie wpaść w […] The post Hejt na Scrum Masterów first appeared on Podcast "Porządny Agile".

Nie zawsze trzeba wyceniać błędy. My należymy do tej grupy, która ich nie wycenia. Poznaj nasze argumenty, które nas do tego przekonały. Dowiesz się też jak poradzić sobie z błędami […] The post Dlaczego nie estymujemy błędów? first appeared on Podcast "Porządny Agile".

Jak może wyglądać codzienne spotkanie w zespole, który nie używa Scruma? Może on spotykać się na codziennym stand-upie, podczas którego członkowie zespołu dzielą się tym, co jest dla nich ważne. […] The post Praktyka codziennego stand-upu first appeared on Podcast "Porządny Agile".

Agile rośnie na popularności, ale nie jest łatwo znaleźć rzetelną definicją, co to jest. Z tej rozmowy dowiesz się, czym jest zwinność oraz jakie są korzyści ze stosowania podejścia zwinnego […] The post Co to jest agile? first appeared on Podcast "Porządny Agile".

Na co zwracać uwagę, jeśli chcemy faktycznie uzyskać wartość ze zwinności? Jak rozpoznać sztuczną zwinność i jakie sygnały ostrzegawcze mogą wskazywać, że Agile w Twoje firmie nie działa, jak należy. […] The post Jak rozpoznać sztuczną zwinność? first appeared on Podcast "Porządny Agile".

Co możesz zrobić, żeby zainteresować zarządzających Przeglądem Sprintu? Sprawdź listę naszych pomysłów. Mamy dla Ciebie garść wskazówek, żeby podejść do tematu porządnie. Porządny Agile · #098 – Zarządzający na Przeglądzie […] The post Zarządzający na Przeglądzie Sprintu first appeared on Podcast "Porządny Agile".

Agile w organizacji niesie za sobą korzyści, które zachęcają do wprowadzenia tego podejścia. Pierwsze transformacje miały miejsce w firmach IT, ale obecnie zwinność wychodzi poza ten obszar. Transformacja w stronę […] The post Transformacja jest trudniejsza niż myślisz first appeared on Podcast "Porządny Agile".

Jakie korzyści może przynieść praca w krótszych Sprintach? Często w naszej pracy spotykamy zespoły, które pracują w Sprintach trwających nawet 3-4 tygodnie. Naszym zdaniem krótsze Sprinty zwykle są korzystniejsze i […] The post Korzyści z krótszych Sprintów first appeared on Podcast "Porządny Agile".

Czym jest reestymowanie? Poznaj taktyki i podejścia, które są przydatne przy reestymowaniu. Nie zabraknie też przestróg związanych z ponownym oszacowaniem. Porządny Agile · #095 – Czy reestymować pracę? Zapraszamy Cię […] The post Czy reestymować pracę? first appeared on Podcast "Porządny Agile".

Czym są kryteria akceptacji? Wiele osób stosuje tę praktykę zamiennie z Definicją Ukończenia, myląc je ze sobą. Kryteria akceptacji to z góry ustalone warunki, które produkt albo projekt (lub ich […] The post Kryteria akceptacji first appeared on Podcast "Porządny Agile".

Praca z organizacją to wszystkie zmiany, które są do zrobienia poza zespołem, ale nie wydarzą się samoistnie. Praca Scrum Mastera z organizacją to dopełnienie usprawnień i zmian, które są do […] The post Praca Scrum Mastera z organizacją first appeared on Podcast "Porządny Agile".

Jeśli jesteś szefem zespołu lub szefem danej grupy specjalistów, to możesz skorzystać z naszych rad na temat Twojej roli w Scrumie. Jedna z naszych podpowiedzi, to organizowanie wymiany wiedzy. Porządny […] The post Rola lidera merytorycznego w Scrumie first appeared on Podcast "Porządny Agile".

Scrum Guide nie określa wprost roli managera w Scrumie, dlatego często taka osoba ma wątpliwości, jaka jest właściwie jej rola w podejściu zwinnym. Z tego odcinka dowiesz się czym może […] The post Rola managera w Scrumie first appeared on Podcast "Porządny Agile".

Przygotowaliśmy kilka wskazówek, dzięki którym dowiesz się jak stworzyć zespół zarządzania zmianą w Twojej organizacji. Dowiesz się też, dlaczego taki zespół jest potrzebny i jakie są jego główne zadania. Porządny […] The post Tworzenie zespołu zarządzania zmianą first appeared on Podcast "Porządny Agile".